Random Quote Board

A Review of Dave Rowntree's Gnu Radio FM Receiver

Gary Schafer, February 2024

Youtube suggested a video with Dave Rowntree doing a talk on Gnu Radio at (if I understand this correctly) "Electromagnetic Field 2022". Of interest to me was his statement that he was going to make a FM receiver using Gnu Radio live in front of the audience.

Fast forward to the flowgraph he made. It looked like this:

Dave Rowntree's Gnu Radio flowgraph to make a FM receiver. His SDR hardware was a RTL-SDR.

His flowgraph only output noise when he first ran it. He finally managed to get audio (to much applause from the audience) when he tuned around.

Image showing spectrum when Rowntree finally is able to demodulate audio from an FM broadcast station. Note that the signal is not centered but is quite large. The RTL-SDR is centered at 103.8 MHz, while the radio station is at 103.5 MHz, 300 kHz below his center frequency. This should have created a large DC offset in the output audio. However, he still heard audio from his speakers.

Why Did It Work?

I was perplexed at first with the question of, "Why did it work?" I'm running Linux (primarily). In the version of Gnu Radio I run on my Linux Mint box, there's a small, but crucial, bit of trivia about Gnu Radio. The "Audio Sink" block requires the input signals have amplitudes between +/-1. Any values outside of that range are not played (at least, not on any of the various desktop and laptop computers I've tried this on). If you receive a FM station when it is not centered, that will turn into a DC offset going into that audio sink block. That offset might push the audio levels out of that +/-1 range. Which means no audio. And Rowntree's signal was not centered when he recovered audio.

Then I realized that Rowntree was running Gnu Radio in Windows. Maybe Windows was different when it came to the audio sink? Turns out that is exactly correct. I rebooted into Windows, recreated Rowntree's flowgraph (with a modification), and it worked just as his did.

The modification in my Windows-based flowgraph was a lowpass filter at the output of the RTL-SDR source block, followed by a complex frequency shifter consisting of a "Multiply" and "Frequency Shift" block. I tuned the RTL-SDR to a FM station, filtered the station so that it was the only signal in the spectrum, then used the frequency shifter to shift the signal to different parts of the spectrum. This would mimic the signal as seen on Rowntree's spectral display. He received audio, even though the signal was not centered.

I used this flowgraph to mimic how Rowntree was able to demodulate the FM station, despite the fact that it was not centered. The RTL-SDR is tuned to a FM station. The lowpass filter removes everything except for that station in the center. The multiply and signal source blocks create a frequency shifter. By shifting the frequency, I mimicked the offset FM station in Rowntree's flowgraph, namely when he finally recovered audio. This only works in Windows. The frequency offset creates a DC offset in the demodulated output. Windows audio cards can apparently handle this; Linux cannot. This is why it worked for Rowntree, who was running Gnu Radio in Windows. In Linux, this DC offset would create... silence.
Display of the time-domain and spectrum when the FM station was offcenter by -300 kHz, similar to what Rowntree had when he heard audio running his flowgraph.
This is how the Windows-based flowgraph that (roughly) mimics Rowntree's flowgraph. It shows a FM station being offset from the center frequency. Note that the audio is distorted when offset by 100 kHz or 200 kHz. But it sounds perfect once the offset is 300 kHz. This seems to be similar to what I heard in Rowntree's video as he was tuning around. I heard a bit of distortion, but it sounded perfect once he set the center frequency at 103.8 MHz, with a signal at 103.5 MHz (-300 kHz offset).

This is different from my review of the Hak5 video also making a FM receiver. In that case, I didn't know why it worked. This time, I do. It worked because Gnu Radio's "Audio Sink" works differently in Windows than it does in Linux.

Some Improvements to Rowntree's Flowgraph

Let me provide a few ways that Rowntree's flowgraph would have worked better.

Suggestion #1: Set the Sample Rate to either 1.92 or 2.4 MHz. Ultimately, the demodulated output will be sent to the audio sink. A standard sample rate for the audio sink is 48 kHz. The overall sample rate of 1.92 MHz or 2.4 MHz corresponds to an integer multiple of 48 kHz. This means that the sample rate from this initial value (1.92 MHz / 2.4 MHz) can be decimated down to 48 kHz. For example, if the sample rate was set to 2.4 MHz, the output of the filter could be decimated by a factor of 10. The output from the filter would have a sample rate of 240 kHz (2.4 MHz / 10). From there, the output could be decimated by 5 to get to 48 kHz (240 kHz / 5 = 48 kHz).

Suggestion #2: Adjust the Gain. Rowntree set the "Gain" value in the RTL-SDR block to 100. That means he wanted the gain to be 100 dB. That's... a lot of gain for ANY amplifier. Plus, the RTL-SDR cannot provide that much gain. The most it can provide is roughly 50 dB of gain. I'm also thinking that the reason we saw signals and their mirror images in the spectrum was that he had the gain maxxed out, and the strong signal was saturating either his RF front end, or the digitizer in the RTL8832 chip.

Suggestion #3: Center the signal. Complex signal processing works best when signals are centered at 0 Hz (DC). Further, as I discussed above, if you attempt to frequency demodulate a signal with a frequency offset, that offset will create a DC offset in the demodulated output. Gnu Radio's "Audio Sink" cannot handle that DC offset in Linux; Windows is a different beast. It apparently does not care. That's why Rowntree was able to get audio output even though the signal was not centered. But another reason to center the signal is to allow for a...

Suggestion #4: Filter. Rowntree's flowgraph was able to see signals from the moment that he first ran it. But he didn't hear audio until he tuned in a much stronger signal. The problem was all of that noise that was demodulated along with the signal. And there was a lot more noise than signal. The filter will get rid of all of that noise.

Suggestion #5: Decimate After Filtering. Another bonus of filtering, aside from getting rid of all of that noise, is that the filtered signal can be decimated (sample rate lowered). This makes for easier processing later in the flowgraph. By decimating at the output of the filter, the decimation is dirt simple; throw away every N-1 samples if the decimation factor is N. Decimation normally requires filtering first. You just filtered, so that parts done. Decimate and go on your merry way.

Suggestion #6: Add a Volume Control. This is really only needed for Linux installations. The input to a Linux-based "Audio Sink" block wants its values to be between +/-1. At least, for every version of Linux I've tried this on (Ubuntu, Mint) and with several, different desktops and laptops. The volume control ensures that, if the signal falls outside of the +/-1 range, it will be reduced until it does fall in that range. There's another reason for the volume control. Not all FM stations use 75 kHz deviation, which is what the "WBFM" block assumes. Some have greater deviation, up to 82.5 kHz. If you use a 75 kHz deviation for scaling on a 82.5 kHz deviated FM signal, the output will be greater than +/-1. Again, this is a problem for Linux-based systems.

Recreating (and Improving) His Flowgraph

I recreated his flowgraph, then modified it. I added a gain adjustment for the RTL-SDR, a lowpass filter at the output of the SDR source block, modified the various interpolation and decimation values, and added an audio level adjustment just before the audio sink. I also changed the "fosphor" block (which I could not get to work on my version of Gnu Radio) to just a plain "Freq Sink" block.

Modified Rowntree FM receiver. I've added gain control, a lowpass filter at the output of the SDR, and an audio level adjustment to ensure that the audio sink is not overdriven.

The "WBFM Receive" Block

Let's look at the "WBFM Receive" block. I'd update the actual wiki page for it, but I've not been able to get a response when I apply for an account. ANYWAY, this block performs the following on the input:

If I were to make the "WBFM Receive" block using separate blocks in GRC, it would appear as follows:

Rowntree's flowgraph (modified) but with the equivalent circuit for the WBFM block. This shows how the WBFM block is essentially three blocks in one. The downside is the inability to change several of the parameters, such as the gain of the demod block or the "tau" value of the deemphasis block.

I prefer to not use the "WBFM Receive" block. It removes flexibility. I do not have the ability to change the deviation of the frequency demodulator, or the "tau" value of the deemphasis filter. I prefer to control both of those things. Further, the only time I want to have a deemphasis filter is when the transmitter is using preemphasis. Not every FM transmitter does so. Therefore, it will not be needed for every FM transmitter.

Instead, I'll keep using the individual blocks as shown above.

Here's a Random Fact...