This problem uses "real-world" data for input, which probably are not too much refined so that solution is expected to be robust enough. However if you feel checker itself should be more permissive, don't hesitate to discuss!
Suppose we want to transmit small amounts of data from the smartphone to some electronic device - for example to pass configuration to it. This could be done in multiple ways - they can connect by bluetooth (so device should have bluetooth), or NFC (so device should have NFC), or cable (so the phone should be able work OTG) etc. - all variants have complication of adding technical requirements to one or the other side.
Let's investigate quite innovative transmission line: the phone should "beep" data out using some kind of modulation, while device needs to catch it using built-in microphone. Well, it should have such microphone built-in, but this is much cheaper compared to BlueTooth or NFC module. And doesn't require establishing connection.
As a matter of fact this task is a "mirror" of practical challenge I'm currently trying to solve in some small educational project.
Have a look at the picture above. This is the actual waveform produced by certain test web-app from the phone and caught by small microcontroller using microphone directly attached to one of ADC inputs.
Your goal is to write BASIC program for processing such sequence of measurements and producing binary output of the encoded data!
ADC takes measurements roughly each 50 microseconds and gives result in range 0..1023 - both values are not
important for our task though, they are given just for clarification. As you may see the waveform consists of
small "bursts", taking roughly 60 points (or about 3 milliseconds). Sometimes such "burst" is immediately
followed by another, but sometimes there is a gap of the same length. That's how we encode zeroes and ones.
This waveform was born as a result of small series of experiments. The issue is that speaker-to-microphone audio connection is not extremely stable - and what is worse - much depends on speaker and mic characteristics, adding unwanted harmonics etc. The method used is not quite fast, but is reliable enough to allow sending few dozens of bytes without errors over the distance of 1-2 centimeters.
Encoding
To further clarify, every "burst" consists of "carrier" sine wave of somewhat higher frequency (about 2500 Hz,
not important again) which is multiplied by "envelope" sine signal (about 167 Hz) - so that "burst" has
specific shape - its amplitude gradually increases and then decreases back.
Gaps between bursts are, really, the same bursts but with envelope 10 times smaller in amplitude. Probably it
is ok to regard them as perfect "silence", small oscillations are just kept for vague technical reason.
As said above, if "burst" is followed by "gap", this means 0. Otherwise it is 1. Obviously "zeroes" are
twice as long in time as "ones".
Your code will read about 1000 measurements from the input and should print out correct sequence of zeroes and ones
(it is just my test recording device had enough memory for such amount). The code is executed several times
against several sequences, recorded with different pairs of speakers/headphones and microphones. Thus expect
data to be somewhat imperfect.
Note about starting and ending: there could be situations when, depending on your approach to detecting bits, it is hard to tell whether to include starting or ending bits if their burst/gap are probably not complete. Checker would be glad if you decode only obvious part of the sequence and should be tolerant enough to variations at both ends.
The sequence above should yield result:
010010011
You'll get some input to practice with, but keep in mind that your submitted solution is executed against several different sequences.
One more restriction: as the code is supposedly run on microcontroller, it is limited to use only small
amount of memory. So your program may create one or more arrays, but their total size should not exceed 100
elements. Particularly you can't "ingest" whole sequence first and only then start processing (in real life
sequence never ends at all, of course).
Input for your program always gives a total amount of measurements first. Then measurements follow, split
to multiple lines, but that shouldn't concern you - they should work fine with INPUT statement.
Answer should contain only the decoded sequence of zeroes and ones.