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.
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 12th May 2016 firstname.lastname@example.org