John Graham-Cumming's blog: radio

2022-10-31

The hidden "code" inside 2-XL's space age noises

The other day I posted about getting my old 2-XL toy working again. In that post I had a short video clip of 2-XL operating. Listening to the clip after I blogged I suddenly thought "that sounds like RTTY or FSK" and instantly wondered if it was decodable.

If you're unfamiliar with RTTY or FSK then (a) it's time you went off and got your amateur radio license and (b) here's a quick primer.

FSK means "frequency shift keying". It's a way of sending data that uses two levels (0 or 1, or mark or space in the jargon). Data is encoded in some format (e.g. Baudot code or ASCII) and then sent using those two levels as audio or radio. One such radio format is RTTY which I messed around with in the past when sending up a high-altitude balloon.

I grabbed an audio file version of the clip of 2-XL and fed it into Fldigi to see if I could get an instant decode. No such luck. But I shoved the file into Audacity and took a look at the spectrum and there are two distinct peaks:

Which made me think it looked even more like FSK with a gap between frequencies of about 500Hz.

Switching the audio file itself into Spectrum mode was a real "a ha" moment because that looks a lot like two frequencies being used to send data with a regular period. Measuring that period it looks like the time for a single symbol is about 60ms (which would correspond to a data rate of 16.67 baud).

Aside: typically RTTY uses a 170Hz gap rather than 500Hz, a data rate of 45.45 baud rather than 16.67 baud, and the typical upper frequency would be 1447Hz rather than what looks like around 3300Hz. Nevertheless this does look like data transmission with FSK and could be some RTTY or ASCII variant.

Zooming in a bit you can see this more clearly.

Here's what a clean RTTY signal might look like:

So, I went ahead and turned this into a stream of 1s and 0s, assume that the upper frequency is 1 and the lower 0.

which gave me:

011010110110011101101111011000001110100011100100111010011010001011101010111001101110111010101110101010011110010111101001101000

Since I don't know what format this is I went hunting for start and stop bits by breaking this string at various widths. e.g. standard RTTY would be 1 start + 5 data + 1 stop bit, ASCII might be transmitted as 1 start + 7 data + 1 stop. And there are many other variants.

Breaking at 8 bits I get

01101011

01100111

01101111

01100000

11101000

11100100

11101001

10100010

11101010

11100110

11101110

10101110

10101001

11100101

11101001

101000

You can quickly see that there's an entire column of zeroes and an entire column of ones (which I have highlighted). A very common format is 1 start bit (0) + data + 1 stop bit (1). So adjusting to start with 0 and end with 1 I get:

011

01011011

00111011

01111011

00000111

01000111

00100111

01001101

00010111

01010111

00110111

01110101

01001111

00101111

01001101

000

It's very common for data to be sent LSB first so removing the start, stop bits and reversing the data I get:

101101

101110

101111

110000

110001

110010

011001

110100

110101

110110

010111

111001

111010

011001

And a pattern emerges. The data seems to be counting up with some interruptions. But the counting doesn't seem to break down even with the interruptions.

101101 45

101110 46

101111 47

110000 48

110001 49

110010 50

011001 25

110100 52

110101 53

110110 54

010111 23

111001 57

111010 58

011001 25

Why this pattern? I don't know. Anyone have an idea? Why six bits? Teletypesetter code? 6-bit BCD? If this had just counted up then I would have dismissed it as test data. But why those breaks?

2021-07-08

Receiving the WWVB time signal in Portugal (by accident)

For many, many years I've owned a Sharper Image clock that sets itself from the WWVB time signal in Fort Collins, CO. Well, it used to set itself when I lived in the US. For much more than a decade the clock has sat by the bed and I've manually set it. And it dutifully looked for a time signal it never received. But it worked absolutely fine with manual setting.

Until last night.

At some point between 0300 UTC and 0600 UTC the clock received the WWVB time signal and set itself to EST with DST enabled. This morning the clock was "off" by five hours based on time in Lisbon.

The NIST propagation chart for the night doesn't show the signal hitting Portugal but somehow my trusty little clock picked it up. Although it makes sense that it set itself between those hours as that's the best time to "hear" the signal outside North America.

It's about 7,700 km along the great circle route from Fort Collins to Lisbon but the signal made it! Since this is an LF transmission at 60kHz the likely path is via bouncing off the ionosphere. Given that at night such bounces might be 2,000 km long it's likely the signal bounced two to three times to reach Lisbon.

Perhaps even more surprising than the long transmission path is that the UK MSF time signal (which uses a different format) transmits on the exact same frequency and is way closer.