[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working Narrowband FM examples?

From: Kristoff
Subject: Re: Working Narrowband FM examples?
Date: Wed, 11 Aug 2021 17:07:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

Hi Nathan,

firdes.low_pass(1, 8e6, 5000, 1700)

Oefti! .. that is a very narrow filter!

Keep in mind that in DSP, the more narrow a filter, the more computational expensive it is. And 'narrow' is related to the passband of the filter compared to the samplerate..

5000 Hz compared to 8 MHz, that is very narrow. I'm surprised that you can actually do this.

What I usually do (but other people might have do it differently) is to take down the sampling-rate in multiple steps.

- Start with the xlating FIR filter (to correct the frequency-offset) and do a decimation of 8, so to take the 8 Msps down to 1 Msps
The taps are:
firdes.low_pass(1, samp_rate, samp_rate/(2*decim), transition_bw)

- Next add a 'rational resampler' to down the samplerate even further, e.g. 'interpolate 1, decimate 20 to go down to 50 KHz

- then add your low-pass filter of 5 KHz/1700 Hz.

In this case, your filter is 5 Khz compared to 50 Khz, which is a 1/10 ratio.

Another option is to use a low-passfilter and do decimation at the same time. The low-pass filter block has a parameter 'decimation'.

One more thing:

I think that a NBFM channel is actually wider (on RF) then the 5 KHz you mention: 10 KHz to 20 KHz, depending on the FM modulation index. If there are no other stations on the neighboring channel, 20 KHz will probably be fine. If you have adjacent-channel interference, you can reduce the filter.

I propose you first use an sdr-tool like gqrx, cubesdr or sdr++ and visually inspect what the radio-signal looks like you want to receive.

Note. Another option to get help from the GNU Radio community is to use the matrix chat-server.
(Matrix is an open-source distributed and federated IM/voip/video service).

If you do not yet have an account on a matrix service, you can create one (e.g.) here:

The main chat-room for GNU radio is here:

There are also some other (more specialized) GNUradio-related rooms, like for amateurradio and for the documentation sub-project.

IMHO, IM / chat is more suited to quick issues, while mail is usually better for more indepth discussions.

Matrix does offer the ability to share files, screen-dumps or even voice or video-conference, which can also be useful tools.

Kristoff (on1arf)

On 11.08.21 07:49, Nathan Van Ymeren wrote:
Hi Gary,

Thanks for the reading list.  I’m an engineer, so I have multivariate calculus 
under my belt, but I’m not an electrical engineer, so sometimes when texts get 
too down in the weeds my eyes roll back in my head and I start foaming at the 
mouth, haha.

As for hardware, I mentioned in my opening post to the list that it’s a hackRF. 
 It *should* be capable of up to 20MS/s all the way from 1MHz to 6GHz.  I’ve 
ordered one of those RF shielding kits to hopefully address the noise problem.  
Or at least, I’m not aware of any limitations on the hackrf’s sampling rate 
other than the 20MHz upper limit (but I’m still digging!)

For the low pass filter in the Xlating block I’m calling out to firdes:

firdes.low_pass(1, 8e6, 5000, 1700)

On Aug 9, 2021, at 17:05, Gary Schafer <schafer@site2241.net> wrote:

Several points:

1) Further reading: "Digital Signal Processing" by Steven Smith and "Understanding Digital Signal 
Processing" by Rick Lyons. Smith makes his book available for download at https://www.dspguide.com/. Lyons has 
many of his stuff scattered around "DSPRelated.com" (https://www.dsprelated.com/). Unlike your usual 
textbooks, these books actually *EXPLAIN* stuff, not just throw some math proofs at you and say, "See how easy it 
is to understand?"

2) What hardware are you actually using? USRP? RTL-SDR? HackRF? Something else? 
I've found that the HackRF, while it covers a huuuuuge frequency range relative 
to most other inexpensive SDRs, it also has a much worse noise figure.

3) 384k wasn't too *low*. I was guessing it was just *outside* of what the hardware can 
handle. If the hardware *could* handle it, then you would not have had the issue you did. 
The RTL-SDR, for example, can only handle sample rates between 200 kHz - 300 kHz, then 
jumps to 0.9 - 3.2 MHz. Anything outside of that range gets pushed to the closest sample 
rate the device can handle. The few times I've managed to play with a USRP, I've found 
that it can only handle sample rates that are values of 100 MHz / N, where "N" 
is an integer. As you discovered with whatever hardware you're actually using, if you use 
a sample rate that will work with the hardware, you can change it in Gnu Radio to 
whatever you *need* it to be.

4) I'm game for a comparison between GQRX and Gnu Radio. We need to make sure we have similar 
settings between them. I don't think the sample rate is the problem. So long as you're within the 
parameters that the particular SDR wants, AND you are meeting Nyquist, you should be golden.  To 
me, so long as you're using the same hardware, the critical aspects of comparing audio from an FM 
signal are ensuring we have the same filters and that we're using the same demodulator. I'm willing 
to bet large sums that the GQRX is using a polar discriminator. That's the same as the 
"Quadrature Demod" block in Gnu Radio. Easy enough. But what of the filtering? I can't 
see what parameters you've selected for your lowpass filter in your attached PNG (and, by the way, 
you get major kudos for including those... makes troubleshooting infinitely easier!) What are your 
stop frequency and transition width for your lowpass filter (used in your "Frequency Xlating 
FIR Filter")?



Well, I guess it was the sample rate. As another message alluded to, 384kS/s 
seems too low.  I'm not sure why that is; the arithmetic with decimation ought 
to result in a 48kHz audio output either way, but (with assistance from Andre 
Buhart who replied off-list) I upped the sample rate to 2.4M and now I can make 
out the audio (flowgraph attached).

However, playing with the gain settings to make them identical to gqrx I 
noticed that, quite simply, the audio quality was just plain better in gqrx 
compared to gnuradio. So, investigating further it seems that the default 
sample rate for hackrf in gqrx is 8MS/s.

Now, being a novice to DSP and SDR I conclude from this that a higher sample 
rate simply results in a better quality signal at the front end of the, uh, 
block chain. That is to say at 2.4M or 8M, the osmocom source must be emitting 
a better signal which translates to a better audio product at the other side of 
the flowgraph.

However, my understanding is that a 48kHz audio signal is "good enough", so I'm 
a little mystified as to why 384kS/s, which is more than double what I want on the other 
side, results in such poor audio.  I hope I'm explaining that properly.

Can anyone point me in the right direction for further reading?

Thanks to all who responded thus far,


On 8/5/21 4:10 AM, Mike Markowski wrote:

    You bet, Nathan.  I just verified that the flowgraph demods NWR, so either 
osmocom Source or Audio Sink needs configuring.  You might try simply playing a 
recording into your audio sink.  It might be as simple as adjusting audio rate. 
 Regarding osmocom Source set up, another flowgraph for HackRF was mentioned in 
this thread, and you might compare that src setting to yours.  (Also, not sure 
why I had RF gain maxed. Better to lower that...)

    Good luck,

    On 8/4/21 1:40 PM, Nathan Van Ymeren wrote:

        Hi Mike,

        That's exactly what I was looking for, thanks.

        However:  I swapped out the USRP source for an osmocom source, and it seems to be 
"mostly working" but the audio comes through like the adults from the old Charlie Brown 
show from when I was a kid.  Instead of clearly-intelligible speech like I can hear through GQRX, 
using gnuradio I can only get speech that sounds like "mwah mwah mwah mwah"

        Attached is a .png of my flowgraph, hope it's not too large for the 
list (about 100kB).

        Appreciate any advice anyone might have.


        On 8/3/21 3:47 AM, Mike Markowski wrote:


            When I was refreshing my gnuradio awareness - I hesitate to use the word 
"skills" :-)  - I ran through the official tutorials and modified them as 
needed to work with a usrp b210.  On the page


            about halfway down is the title "Gnuradio Official Tutorials" with the link 
"Here are my versions" where you'll find nbfm.grc.  It's very simple, using 
filter/squelch/NBFM Receive block and runs here on grc, a promising sign.

            Hope it's useful,

            On 8/3/21 2:40 AM, Nathan Van Ymeren wrote:


                I am seeking a working NBFM receiver example, as the one on the 
wiki[0] produces unintelligible output.  I am confident that my hardware is 
functioning properly because if I tune to the same frequency (162.525 MHz ) in 
gqrx, I can hear the weather radio broadcasts clearly.  I am on OpenSUSE 
Tumbleweed, running gnuradio 3.8.x with a HackRF One and a standard telescopic 

                I have reproduced [0] verbatim except with the following 
change: Instead of a ZeroMQ source, I am using an osmocom source for my hackrf.

                I’ve also tried adapting the flowgraph from the “SDR with 
HackRF” tutorial[1], which implements a wideband FM receiver in gnuradio, but I 
wasn’t able to make it produce anything resembling speech when I changed it to 
narrowband FM.

                Additionally, I’ve tried a few NOAA weather radio flowgraphs 
found online but most of what I’ve found either didn’t work or else was for an 
older version of gnuradio and thus had errors that I wasn’t able to work around 
since I am a gnuradio novice.

                Can anyone recommend a working flowgraph for narrowband FM, 
ideally something simple and working in gnuradio 3.8+?




                [1] https://greatscottgadgets.com/sdr/1/

Attachment: working nbfm receive.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]