Enchanting subcarriers on FM, part 2

As explained in the previous post, I modified my Sangean ATS 909 receiver by equipping it with a digital RDS output. May it now be told in pictures.

Of course everything had to start from reading some service manuals and data sheets. Energy drinks were also necessary. Yes, I colored the board schematic with color pencils for ease of use!

[Image: Papers titled BLOCK DIAGRAM and SCHEMATIC DIAGRAM lying on the table or floor. The schematic diagram is colored in. A bottle of energy drink to the right.]

I figured I would need four separate outputs from the decoder (data, clock, quality bit, and ground) so I chose a 4-pin mini-DIN plug in one end of the cable. The other end is a familiar DB-25. Data is input via the parallel port's ACK, BUSY, and Paper Out pins; I picked a random GND pin for the ground.

[Image: The schematic diagram with the part containing the RDS decoder chip magnified. The chip has 16 pins, 4 of which are encircled and labeled Qual, Data, Ground, and Clock.]
[Image: A cable with a  Mini-DIN connector on one end and a DB-25 connector on the other.]

The RDS circuit is hidden under the corner of an RF shielding plate. It would have been tedious and mistake-prone to remove the shielding, so I just used my precision soldering skillz and left all the wires outside the plate. Now the chip was wiretapped.

[Image: Logic board of the radio with four red botch wires going under an RF shielding plate. The wires are secured using cellotape.]

The front cover has a mini-DIN-sized placeholder-looking feature that I used for this purpose. Probably it was related to the speaker's airflow though. I hotglued the 4-pin connector in place. Holes in the control board came in handy when wires needed to be taken through.

[Image: Another part of the insides of the radio, with the addition of a hotglued Mini-DIN socket.]

The socket fits nicely in the front cover. I had to remove the Sangean logo from its place but hotglued it back next to the connector. (If something else looks dissimilar to the classic ATS 909, it's because I've also replaced the default backlight LEDs with super bright ones!)

[Image: The radio, now with its cover closed and operational, and the cable connected.]

I'm relieved the radio still works! Next it will be time to test the connection. It won't happen until my cheap parallel-to-USB converter arrives in the mail, since my laptop is new enough not to have a parallel port.

But even now already, when I wiggle the connector around, the speaker audio gets superimposed by data! Of course this isn't exactly what's supposed to happen since it means I've shorted a connection, but OMG! It's audible and even more evident in the oscillogram:

[Image: Oscillogram showing a signal alternating rougly between two states, with a lot of noise superimposed.]

Update: The converter (idVendor=1a86, idProduct=7584) arrived, but apparently it just emulates a USB printer and low-level parallel bit-banging is not even possible. So I took the thing apart and built a simple twin-channel voltage divider in place of its internals that I then attached to a stereo phone jack (all parts salvaged from an old radio). Data goes to left channel, clock to the right; I'll just have to ignore the quality bit.

[Image: Schematic diagram of the cable and connector setup with a voltage divider. Pins 10 and 12 of a DB-25 are connected to arbitraty points A and B, respectively, via 1 k-ohm resistors. Point A and B are both connected to point C via 200 ohm resistors each. Point C is connected to pin 23 of the DB-25. Points A and B are connected to terminals 1 and 2 of a 3.5mm socket, respectively.]
[Image: The above voltage divider in a series of photos, showing how it fits inside the casing of a parallel port printer adapter.]
[Image: The voltage divider connected to the radio's DB-25 cable. A LED indicator is on.]

I connected this to the sound card's line in and behold! The clearest possible data and clock signals on separate channels!

[Image: A two-channel oscillogram. One channel shows a square wave with regular transition intervals, the other one transitions only at some transition points of the first one.]

There is slight crosstalk, probably via ground since I used quite small resistors for the voltage divider. But the data is good:

[Image: Screenshot of a terminal and a small GUI window. The terminal is showing a stream of text describing RDS information. The little window is showing the text YLEYKSI and Muistojen bulevardi.]

This means I can completely comment out my software clock recovery and PLL. I rolled the FM dial and logged some stations.

Now I'm going to bed.


  1. Hello, Oona! I have been admiring your work for some time, now. :) VERY IMPRESSIVE!! :)

    I was wondering if you could port your soundcard RDS decoder routine to Windows? (Or DOS, which can run in a window.)

    I have a modded Ramsey kit SCA decoder, which uses a PLL chip to decode the SCA signals at 67 and 92Khz. It will also lock onto the 57Khz RDS carrier (here in the US it's called RBDS) and covert it down to audio frequency data. I am only interested in the "in the clear" data, such as artist/song title and station ID. The kit is fed by an analog FM radio that outputs baseband. The Ramsey kit is modded to improve the input filter. (It was allowing too much audio frequency signal through, distorting the SCA and the RBDS signals.) In this application, there is no steady clock frequency, only the data. The PLL does have a test point with the running frequency, but that is frequency-modulated, not steady.

    I am a broadcast Engineer for an FM station, and I'm experimenting with the RBDS features of our new transmitter. It would be nice to see the raw data as I tinker with it. :) I ask for Windows (or DOS) since I have many Windows PCs at my disposal, and only one LINUX machine. (An older laptop with Ubuntu.)

    Thanks!! :)

  2. I can't say that I blame you for not wanting Windows. ;) How about FreeDOS? I'm just being lazy, I guess. ;)

    1. I can write a general Perl script for baseband decoding.

    2. As long as it's fairly easy to integrate into a DOS environment, that would be good. :) DOS can be easily run within a window. I have a GWBASIC program running in a window at the radio station where I work. It feeds our artist/title date to our streaming server as plain text. It's been running flawlessly, 24/7 (with only an occasional reboot) for over a year... so I'm quite pleased with it... even if it is antiquated.

      Why GWBASIC? Simple: I'm old, and it is very familiar to me. ;)

    3. :) The most certain way to get it done is to write it yourself.

  3. If I could do it myself... I'd have done it by now. :) It's totally out of my league, quite honestly. I can "PEEK" and "POKE" in BASIC, and write a few SIMPLE programs. Just trying to THINK about writing code for something like this using Fourier Transforms makes me go cross-eyed! ;) I wouldn't even know where to BEGIN with such a project... which is why I asked... you already know how! :)

  4. This is a really cool application. How are you displaying your output as a gui?

    1. Hi, the window and text are rendered by Gtk+.


Please browse through the FAQ first, it might be that your question is already answered.

Spammers have even found comments sections, so this comments section is pre-moderated; it will take some time for the comment to show up.