Convert old computer cassette signal into binary

Question

Completely new to this but keen to learn :)

I have an old BBC Micro computer cassette which I've recorded into unsigned 8-bit pcm wav file format. The file comprises tracks separated by virtual silence and each track is split into a series of blocks separated by a carrier tone at 2400hz. The blocks are a series of 1200hz and 2400hz signals representing binary data. I think this is frequency modulation? (as you can tell, I'm not very educated in these things)

Where would I start if I wanted to convert this into binary?

Answer 1

First of all, you'd go on an information scavenger hunt through the internet on that cassette's data format: http://beebwiki.mdfs.net/Acorn_cassette_format tells us you're quite spot on:

Signal

The signal may be in one of three states; zero, one or no carrier. Breaks in the carrier are detected and used to reset the cassette loading firmware.

Zero is represented by a sinusoidal wave at 1200 Hz. The exact frequency is nominally 16 000 000 / 13 312, or 1201.9 Hz, but tape decks vary in speed so small differences are tolerated. One cycle (at 1200 baud) or four cycles (at 300 baud) represent one zero bit.

Binary one is represented by a sinusoidal wave at 2400 Hz. The nominal frequency is closer to 2403.8 Hz. Two cycles (at 1200 baud) or eight cycles (at 300 baud) represent a one bit. An odd number of 2400 Hz cycles can and does occur.

To allow the tape deck circuitry to settle, each data stream is preceded by 5.1 seconds of 2400 Hz leader tone. This is reduced to 1.1 seconds if the recording computer has paused in the middle of a file, or 0.9 seconds between data blocks recorded in one go.

At the end of the stream is a 5.3 second, 2400 Hz trailer tone. This is reduced to 0.2 seconds when pausing in the middle of a file (giving at least 1.3 seconds' delay between data blocks.) The timings are derived from VSYNC interrupts so they vary between recordings.

So, yes, this is Frequency Shift Keying (FSK) and can be demodulated as such.

Considering modern PCs'/laptops'/phones'/fridges'/toaster ovens' computational power is basically huge compared to the data that fits on a cassette, we don't need to be very considerate on how efficiently we demodulate this, at all.

So, you'd go and

1. design two bandpass filters: one that's centered around 1201.9 Hz, the other one at 2403.8 Hz,
2. take their outputs, convert them to their absolute value, then
3. weight one of them so that they have the same amplitude when excited,
4. subtract them and finally
5. make a 0/1 decision based on the sign of the result to get the bit.

Sounds a bit taunting, but looks roughly like this in GNU Radio 3.9:

^{(You can ignore everything that says "QT" in its name, it's just for interaction / vizualization. Once you've figured out the right amplitude so that 0 and 1 bits come out the same (and that's really just necessary to minimize the probability of bit errors), you'd just multiply with that fixed value instead of having the Qt range.)}

You'll have to add some discarding for the start and stop bits surrounding each byte, and you'll need to keep synchronized to these – I think the most elegant (and easy) way would be to write a quick few lines of python code in an "embedded Python Block" in GNU Radio Companion to detect the start of the start bit, then pass on through the 8 data bits, ignore the stop bit and go waiting for the next start bit. Pretty doable!