Pages

Nov 5, 2013

Broadcast messages on the DARC side

By now I've rambled quite a lot about RDS, the data subcarrier on the third harmonic of the 19 kHz FM stereo pilot tone. And we know the second harmonic carries the stereo information. But is there something beyond that?

Using a wideband FM receiver, like an RTL-SDR, I can plot the whole demodulated spectrum of any station, say, from baseband to 90 kHz. Most often there is nothing but silence above the third pilot harmonic (denoted 3f here), which is the RDS subcarrier. But two local stations have this kind of a peculiar spectrogram:

There seems to be lots of more data on a pretty wide band centered on the fourth harmonic (4f)!

As so often with mysterious persistent signals, I got a lead by googling for the center frequency (76 kHz). So, meet the imaginatively named Data Radio Channel, or DARC for short. This 16,000 bps data stream uses level-controlled minimum-shift keying (L-MSK), which can be thought of as a kind of offset-quadrature phase-shift keying (O-QPSK) where consecutive bits are sent alternating between the in-phase and quadrature channels.

To find out more, I'll need to detect the signal first. Detecting L-MSK coherently is non-trivial ("tricky") for a hobbyist like me. So I'm going to cheat a little and treat the signal as continuous-phase but non-coherent binary FSK instead. This should give us good data, even though the bit error probability will be suboptimally high. I'll use a band-pass filter first; then a splitter filter to split the signal band into mark and space; detect both envelopes and calculate difference; lowpass filter with a cutoff at the bitrate; recover bit timing and synchronize using a PLL; and now we can just take the bits out by hard decision at bit middle points.

Oh yeah, we have a bitstream!

Decoder software for DARC does not exist, according to search engines. To read the actual data frames, I'll have to acquire block synchronization, regenerate the pseudorandom scrambler used and reverse its action, check the data against CRCs for errors, and implement the stack of layers that make up the protocol. The DARC specification itself is luckily public, albeit not very helpfully written; in contrast to the RDS standard, it contains almost no example circuits, data, or calculations. So, a little recap of Galois field mathematics and linear feedback shift registers for me.

But what does it all mean? And who's listening to it?

Now, it's no secret (Signaali 3/2011, p. 16) that the HSL bus stop timetable displays in Helsinki get their information about the next arriving GPS positioned buses through this very FM station, YLE 1. That's the only thing they're telling though. I haven't found anything bus-related in the RDS data, so it's quite likely that they're listening to DARC.

DARC is known to be used in various other applications as well, such as DGPS correction signals. So decoding it could prove interesting.

Sniffing the packet types being sent, it seems that quite a big part of the time is being used to send a transmit cycle schedule (COT and SCOT). And indeed, the aforementioned magazine article hints that the battery-powered displays use a precise radio schedule to save power, receiving only during a short period every minute each. (This grep only lists metadata type packets, not the actual data.)

oonar@northernspy: ~/darc/darcdec (zsh) ×
darcdec git:(master) perl darcdec-filters.pl|grep Type:|sort|uniq -c 88 Type: 0 Channel Organization Table (COT) 8 Type: 1 Alternative Frequency Table (AFT) 8 Type: 2 Service Alternative Frequency Table (SAFT) 1 Type: 4 Service Name Table (SNT) 8 Type: 5 Time and Date Table (TDT) 112 Type: 6 Synchronous Channel Organization Table (SCOT) darcdec git:(master)

At the moment I'm only getting sensible data out at the very beginning of each packet (or "block"). I do get a solid, error-free block sync but, for example, the date is consistently showing the year 1922 and all CRCs fail. Other fields are similarly weird but consistent. This could mean that I've still got the descrambler PN polynomial wrong, only succeeding when it's using bits from the initialization seed. And this can only mean many more sleepless coding nights ahead.

(Continued in the next post)

(Pseudotags for Finns: HSL:n pysäkkinäytöt eli aikataulunäytöt.)

32 comments:

  1. Terve!

    I just wanted to tell you that I really enjoy all of your deeply-technical posts. While I only have a layman's understanding of what you're saying (you might as well be The Doctor, talking about "reversing polarity"), I still find it tremendously exciting to read this stuff. Simply as a reminder that there is still so much to learn about, should I ever get bored with what I'm doing these days :)

    ReplyDelete
    Replies
    1. Thank you, I'm glad there are people who like reading my posts :)

      Delete
  2. So we know who to blame when these bus stop displays go crazy :3

    ReplyDelete
  3. This is interesting, if this data is being broadcasted that means that devices are listening for it possibly unidirectional. so, with that said, I wonder if the devices listening share an encryption key?

    ReplyDelete
    Replies
    1. It's in the clear; there is no encryption.

      Delete
    2. As a former broadcast engineer this is news to me! All of my previous installs never tx'ed anything above 57KHz. It's nice to see the 4th harmonic being used for something useful.

      Delete
  4. What do you use for visualising waveforms and bytes? It looks nice :)

    ReplyDelete
    Replies
    1. I use Inkscape.

      The two topmost waveforms are actually Audacity screenshots, recolored in GIMP and imported into Inkscape. The bottom one was also a screenshot that I vectorized into splines.

      Delete
  5. Oona, you are a featured Slashdot story! http://tech.slashdot.org/story/13/11/24/148237/tapping-data-from-radio-controlled-bus-stop-displays

    ReplyDelete
  6. Great blog !

    You are also featured on http://www.reddit.com/r/amateurradio/comments/1rcspt/guy_reverse_engineers_mystery_radio_signal/

    88 !

    ReplyDelete
  7. Why use YLE1 instead of a local Helsinki station for transmission? Doesn't that prevent the rest of the country from using the same system (at least on YLE1)?

    ReplyDelete
    Replies
    1. The signal is injected at the transmitter site, not at the programme origin.

      Delete
  8. http://hackaday.com/2013/11/25/sniffing-data-from-radio-controlled-bus-stop-displays/ nice :)

    ReplyDelete
    Replies
    1. Was Sweden 205 years ago ;) Great work, enjoyed reading about it!

      Delete
  9. I'd send a message "goatse.ru - free tickets", just for fun.

    ReplyDelete
  10. Hi!
    What software used in the first picture?

    ReplyDelete
  11. Found this on Hackaday and just wanted to say that you are AWESOME. I'm really jealous! I studied this stuff in school and thought it was super cool but never really played around with it. What are you using for the decoding? That is done in software right? (the filtering, splitting, mixing, comparing, etc). Any tips for those of us with technical knowledge of modulation schemes who'd like to play around with actual hardware?

    Again, really nice!

    ReplyDelete
  12. Oona, I saw your 30C3 talk, it was fantastic. Can you please share any tips on which baudline channel/input mapping operations and transforms that you use when evaluating signals with data like this? I have been trying to become more familiar with using baudline, sox, inkscape, & perl as they seem to be your toolset of choice.

    Keep up the fantastic work & stay fluxy!

    ReplyDelete
    Replies
    1. The top screenshot is just FFT on the demodulated FM signal. Everything else was pretty much done without baudline, using SoX and Perl.

      Delete
  13. Detecting L-MSK as binary FSK? how? L-MSK has 4 states, FSK has only 2!

    ReplyDelete
    Replies
    1. but.. what about other two states?

      Delete
    2. Google for: noncoherent GMSK detection

      Delete
  14. I have no idea of the data transmitted in the DARC channel, but according to my RTL-SDR readings, here in Kauhava, I am receiving the same 76k carrier with Yle Radio 1.. So would it be possible that it is national data channel, not regional since this supports the fact that it is present in every transmission of Radio 1?

    ReplyDelete
    Replies
    1. I'd love to have a few-minute recording of the local signal.

      Delete
    2. Yeah, I just have to figure out how to capture the FM demodulated part (MPX) from RTL-SDR...

      Delete
    3. rtl_fm -N -f 88.2M -l 0 -F -p 96 -s 180000 -g 25 > yle1kauhava.pcm

      replace numbers with local YLE1 frequency (-f) and your PPM error (-p)

      Delete
    4. Oh man.. I think the Windows-version of rtl_fm is a bit crippled, since it doesn't provide a way to output to stdout, it outputs directly to a file and it's name is the PPM number without a suffix, but I will post here a suitable file, I need to examine the quality first.

      Delete
  15. Hi again! Here's an file, the signal is quite noisy, and I couldn't verify that the DARC-channel is above the noise level since MPXtool shows at max to RDS. Hope you can scavenge data out of it, if not, I shall try to improve my receiving conditions, only a poor antenna was now used. http://www.modu.fi/snd/yle1kauhava.pcm (deep journalism can be heard...)

    ReplyDelete
    Replies
    1. Yes, my noncoherent detector requires a low-noise signal = bigger antenna with correct polarization.

      Delete

To prevent spam, comments will only appear after moderation.