fm

FM Stereo reception using RTL-SDR and GNURadio

In my last post, I mentioned that I was playing around with SDR a bit more, having bought a couple. Now, my experiments to date were low-hanging fruit: use some off-the-shelf software to receive an existing signal.

One of those off-the-shelf packages was CubicSDR, which gives me AM/FM/SSB/WFM reception, the other is qt-dab which receives DAB+. The long-term goal though is to be able to use GNURadio to make my own tools. Notably, I’d like to set up a Raspberry Pi 3 with a DRAWS board and a RTL-SDR, to control the FT-857D and implement dual-watch for emergency comms exercises, or use the RTL-SDR for DAB+ reception.

In the latter case, while I could use qt-dab, it’ll be rather cumbersome in that use case. So I’ll probably implement my own tool atop GNURadio that can talk to a small microcontroller to drive a keypad and display. As a first step, I thought I’d try a DIY FM stereo receiver. This is a mildly complex receiver that builds on what I learned at university many moons ago.

FM Stereo is actually surprisingly complex. Not DAB+ levels of complex, but still complex. The system is designed to be backward-compatible with mono FM sets. FM itself actually does not provide stereo on its own — a stereo FM station operates by multiplexing a “mono” signal, a “differential” signal, and a pilot signal. The pilot is just a plain 19kHz carrier. Both left and right channels are low-pass filtered to a band-width of 15kHz. The mono signal is generated from the summation of the left and right channels, whilst the differential is produced from the subtraction of the right from the left channel.

The pilot signal is then doubled and used as the carrier for a double-sideband suppressed carrier signal which is modulated by the differential signal. This is summed with the pilot and mono signal, and that is then frequency-modulated.

For reception, older mono sets just low-pass the raw FM discriminator output (or rely on the fact that most speakers won’t reproduce >18kHz well), whilst a stereo set performs the necessary signal processing to extract the left and right channels.

Below, is a flow-graph in GNURadio companion that shows this:

Flow graph for FM stereo reception

The signal comes in at the top-left via a RTL-SDR. We first low-pass filter it to receive just the station we want (in this case I’m receiving Triple M Brisbane at 104.5MHz). We then pass it through the WBFM de-modulator. At this point I pass a copy of this signal to a waterfall plot. A second copy gets low-passed at 15kHz and down-sampled to a 32kHz sample rate (my sound card doesn’t do 500kHz sample rates!).

A third copy is passed through a band-pass filter to isolate the differential signal, and a fourth, is filtered to isolate the pilot at 19kHz.

The pilot in a real receiver would ordinarily be full-wave-bridge-rectified, or passed through a PLL frequency synthesizer to generate a 38kHz carrier. Here, I used the abs math function, then band-passed it again to get a nice clean 38kHz carrier. This is then mixed with the differential signal I isolated before, then the result low-pass filtered to shift that differential signal to base band.

I now have the necessary signals to construct the two channels: M + D gives us (L+R) + (L-R) = 2L, and M – D = (L+R) – (L – R) = 2R. We have our stereo channels.

Below are the three waterfall diagrams showing (from top to bottom) the de-modulated differential signal, the 38kHz carrier for the differential signal and the raw output from the WBFM discriminator.

The constituent components of a FM stereo radio station.

Not decoded here is the RDS carrier which can be seen just above the differential signal in the third waterfall diagram.

Hand-held radio musings

Just recently, I managed to kill yet another hand-held. Not deliberately, just a combination of conditions and not adapting my behaviour to suit.

I have a Yaesu VX8-DR, which I mainly use on the bicycle for APRS. It isn’t bad, the GPS could be faster, and the Bluetooth is more of a gimmick (in that it only works with some Bluetooth headsets and is intermittent at best), but my biggest nit with it, is that you can’t charge the thing while it’s turned on.

This leads me to the bad habit of just leaving a DC power lead semi-permanently plugged into the side, with the other end plugged into the 12V supply on the bicycle. You guessed it… one bad day of rain, some water got in via the DC jack and basically destroyed it.  I’m pretty sure warranty doesn’t cover that kind of abuse.

I’m not in a hurry to buy another one.  In fact, I probably won’t.  I’m too clumsy to look after an expensive one, so better just to keep the two Chinese cheapies going (Wouxun KG-UVD1P’s).  This lead me to thinking about what I specifically like in a hand-held, and what features I’d look for.

Looking around, it seems the vast majority of sets out there are evolutionary.  An extra handful of memory channels, higher power, bigger battery, ohh look Bluetooth, and this one has {insert some semi-proprietary-digital-mode here}.  Yawn!

Most of them have tiny screens which can’t show a decent amount of information at a glance.  Digital voice is a long way being usable, with about 3 or 4 proprietary or semi-proprietary competing standards.  What about D-Star you say?  Well, what about it.  Nice mode, pity about the codec.  How about P25?  Same deal.

If a digital mode is going to succeed in Amateur radio, it’ll be necessary for a home base to be able to implement it with nothing more than a desktop or laptop computer loaded with appropriate Free Software and a sound card interface.  Not a silly proprietary “DV-Dongle” or some closed-source blob that speaks gibberish no other software can understand.

As for portable use; it should be possible for a hand-microphone that implements the mode on a DSP be plugged into an existing hand-held (like the Wouxun or Yaesu sets I mentioned earlier) to make it interoperable — open standards will help keep costs down here.

Until such a mode comes along (and they’re working on it — already making excellent progress on HF, keep it up guys!) there’s no point in pouring money into a digital mode that will be a white elephant in a few years.

By far the most popular mode on VHF and UHF is plain old FM.  The mode Armstrong made.  It’s everywhere, from your cheap $100 Chinese firecracker set to the most expensive SDR, they all offer it.  Repeaters abound, and it’s available to pretty much all amateur license classes.  And it works good enough for most.

The big problem with FM, is interfacing with repeaters.  In particular, the big use case with hand-helds and repeaters, is being able to recall the settings for a repeater where ever you happen to be.  Now you can carry around a booklet with the settings written in, and punch them into your radio each time.

This works better for some than others.  On the KG-UVD1P with its horrid UI, it is a tiresome affair.  The Yaesu VX-8DR and Kenwood TH-F7E aren’t bad, once you get used to them.  It’s still fiddly and time consuming, definitely not an option while mobile.  This is where memory channels come in.

Now I realise that sets which stored more channels than you could count on one digit-challenged hand were considered a revolution about 10 years ago.  Back then the idea that you could basically control a digital counter, which would supply an address to an EEPROM that would spit out the settings to drive a PLL synthesizer and other control circuitry was truly remarkable.

Today, the EEPROM and counter have been replaced by a MCU that reads the keypad matrix and outputs to a LCD panel, but we’re still basically incrementing a counter that’s acting as an address offset into non-volatile memory.  The only change has been the number of channels.  The Kenwood set I had gave you 400.  The VX-8, gives you 1000 — which can be optionally grouped into 24 banks (by far the best system I’ve seen to date).  The Wouxun gives you a poultry 128.

The hardest thing about this is finding a given repeater in a list.  128 is more than enough if you don’t travel, or if you pre-programme the set with the appropriate channels in some logical ordering before you leave.  In there hints another factor; “logical ordering”, since there’s no way to sort the memory channels by anything other than channel number.

In this day and age, 1000 channels, linearly indexed, is a joke.  I can buy a 2GB MicroSD card from the supermarket for $10.   How much repeater data could you store on one of those?  FAT file system drivers are readily implementable in modern MCUs and a simple CSV file is not that big a deal for a MCU to parse.

It wouldn’t be difficult to build up a few indexes of byte locations to store in NVRAM, and have the CSV store frequency, call sign, a Maidenhead locator and other settings of all the repeaters in the country, then allow the user to choose one searching by frequency, by call-sign, or if the user gives their current grid square (or it derives it from a GPS), by proximity.  That would be a revolution.  The same card could also store a list of Echolink and IRLP nodes, and make a note of such nodes via RF so it can automatically suggest the nearest IRLP node, take you there, then dial whatever node for you after you announce yourself on the frequency.

I’ve seen more elaborate software written for 8-bit micros like the Apple II, the Commodore 64 and the Sinclair ZX Spectrum back in the day, so clearly not beyond today’s equally powerful AVR, PIC, MSP430 and ARM chips.  A STM32F103RE packs 64KB RAM, 512KB flash and a SDIO interface in a nice small TQFP64 package and costs less than $8.  Even for a Wouxun, that’ll maybe add no more than 20% still keeping it rather competitive with the opposition.

As for user interface?  We don’t need Android on there, although that could be nice.  A decent size resistive touch-screen with a reflective dot-matrix LCD would more than suffice.  This technology, thanks to mobile phones, is cheap enough to implement in this application.  The MCUs needed to drive them have also come down in cost greatly.

Even without the touch-screen — a LCD bigger than a matchbox would allow for text that is easily readable, menus that aren’t constrained in their presentation, and a generally nicer user experience.

SDR hand-helds will likely be the next big revolution, if they are affordable, but I feel that’ll be a way off, and for rag chew on a local repeater, I doubt SDR will be that much superior.  It certainly will push the price up though.

I suppose a start will be to try and come up with a suitable front-end device that can be bolted onto existing transceiver hardware, maybe something that drives the computer control port of a mobile rig such as the FT-857 or IC-706.

From there, it just takes one brave manufacturer to package such a device up with a suitable transceiver in a hand-held form factor to put something to market.  If they did so in a way that could keep this UI module open-source, even better.  Bonus points if there’s a bit of an interface that can take a DSP for digital modes.

Want D-Star, P25, FreeDV, Wongi?  You got it, just slot in the right module, load on the firmware into the UI module, and away you go.  Want to do something special?  Break out the text editor and compiler and start hacking.  The RF side of things can still be as it was before, so shouldn’t pose any more of a problem for regulators than a transceiver with a digital modes jack and computer control interface.

I’m not sure if anyone has worked on such a front-end.  Another option would be a cradle that takes a modern smart-phone or tablet, interfaces via USB to the set, and uses the smart-phone as the UI, also extending the phone’s battery at the same time by supplying the 5V it needs to charge.  Bonus points if it can feed the audio signal to/from the phone for digital modes and/or interfacing with BlueTooth.  A pocket APRS I-Gate and Echolink node, perhaps?  Whatever takes your fancy.

I guess the real answer here will be to come up with something and see if there’s any interest — the “throw it against the wall and see what sticks” approach.