Radio Data System reception using Software Defined Radio.
I'm returning to SDR investigations. Why - what's new?
Hardware is getting cheaper.
There's growing interest in SDR.
There seems to be many ways of doing SDR!
Please take a look at FM RDS Reception with GNURadio and RTL SDR on YouTube...
... and now back to my notes from 2012...
Use GRC (GNU Radio Companion)
Focus on the end to end path of SDR hardware to reception of RDS data received from a broadcast FM transmitter.
Last year I proved to myself that C# had enough poke to process real time radio frequency signals. See my previous exploits with SDR and Youssef's latest SDRSharp.
I'm documenting my discoveries for others to follow and/or ignore. I am not:
A picture says a 1000 words...
The following pictures give a quick overview from start to finish.
Obtain a cheap TV Radio USB stick. It comes with bundled software...
Installing GNU Radio Companion on Ubuntu...
Back in my familiar .NET VS2010 IDE under Windows...
I "know" the modulation. (Installing and repairing FM Stereos when I left school.) I'm familiar with the FM transmission standard.
Obtaining a consistent signal is easy. It's not so easy to find an amateur beacon that has anything interesting to "pull out", and that's clear and always there. "FM" is also very convenient - and there's an aerial socket on the wall marked "FM".
I "know" RDS-TMC, the Traffic Message Channel. The local commercial FM station, Heart FM, transmits RDS data from the Northampton transmitter on 96.6MHz. (Without giving too much away - it's my day job. [No, I'm not a DJ! Think Traffic!])
unix Linux Ubuntu landscape is
terse and hostile - but it does get the results!
The GNU Radio Companion is very good. And no hardware! No soldering irons. All the empirical tweaking is done in software! Yes - great for learning - especially if you've never played with a "Fractional Interpolator" before.
The FUNcube dongle is excellent - but no good for wideband FM.
I had it running with Radio 3 - the UK national station that plays quiet classical music at low deviation. All was well, until someone started hitting a drum - up goes the loudness and deviation - hello clipping!
But the station I'm interested in is compressed and uses all available deviation - the full 150kHz (±75 kHz). The Ezcap USB 2.0 DVB-T stick captures the necessary bandwidth.
The FUNCube dongle sample rate is 96kS/s; the Ezcap USB 2.0 DVB-T stick has 2.8MS/s.
Currently the FUNCube dongle is un-plugged, languishing on the bench, waiting for me to play with satellite or amateur bands.
My GRC RDS source code for Ubuntu is here.
My .NET RDS recovery code that runs under Windows is here. Warning...a Bug! (Well - it's amusing to see how this bug has propagated in various SDR applications!)
"We all make mistakes" - as the Dalek said climbing off the dustbin.
2A Text handling is broken in my code. Find the following in GroupHandler.cs:
(sb.ToString().Any(ch => (ch < ' ') || (ch > 0x7f)))
return; // ignore garbage
It's faulty! What about the CR (0x0d) used as
a end of text filler? And the LF (0x0a) used as a preferred line
break? These codes aren't garbage are they?
Next time I will read the spec.
Take a look at these frames hot off the press from Heart FM containing the recalcitrant control code....
RDS 22:12:41 C363 2550 4E6F 7720
RDS 22:12:42 C363 2551 6F6E 2048
RDS 22:12:42 C363 2552 6561 7274
RDS 22:12:42 C363 2553 3A20 4A61
RDS 22:12:42 C363 2554 636B 736F
RDS 22:12:43 C363 2555 6E73 2077
RDS 22:12:43 C363 2556 6974 6820
RDS 22:12:43 C363 2557 426C 616D
RDS 22:12:44 C363 2558 6520 4974
RDS 22:12:44 C363 2559 204F 6E20
RDS 22:12:44 C363 255A 5468 6520
RDS 22:12:44 C363 255B 426F 6F67
RDS 22:12:45 C363 255C 6965 0D20
RDS 22:12:46 C363 2550 4E6F 7720
or - what's missing?
Do not have the FM carrier at 0Hz on the hardware - offset it. (Poor RF sensitivity around 0Hz.) I know something's amiss - the audio quality from the bundled software sounds far better than my GRC coding effort.
Implement a proper RDS syndrome detector - this frames the RDS stream and corrects data errors. Looking for the station ID code (the PI code) is a bit too simplistic; and some would say a right bodge. (In my defence, I don't want to see error correction hiding the quality of what's being received.)
Add a bit error rate report.
The 1187.5 clock recovery is implemented in .NET code. The clock recovery should use the regenerated 57kHz carrier, not the messy "huff and puff" loop.
Change the front end sample rate. I'm using 2.8MS/s, the default. Try 1.4MS/s? Or higher?
Page last updated 11th June 2016 firstname.lastname@example.org