[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: Tue, 10 Aug 2021 13:25:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

Nathan, Gary, Mike, all.

1/ Just to throw in some more "interesting sources".

- First, you did already mention the 'software defined radio with HackRF' videos by Michael Ossmann. I always advice people to start by just watching all of them and let it all 'come over you'.

Especially the one about complex numbers is interesting.
Although it will not allow you to create GR flowgraph just yet, it is quite interesting as it helps to get a feeling of what are complex-numbers, what are vectors and how signals can be seen as a rotating vector; or -in most cases- a combination of multiple of these rotating vectors added together.

- The, for people who have more an 'IT" / coding background, there are these two resources:

. the book "Think DSP" by Allen B. Downey.
You can buy the book or download it as a PDF (*1)

There is also a 3-hour video of a workshop on this book by the author from pycon 2018:

. for DSP, there is pysdr from Marc Lichtman (*2) which gives an interesting approach on SDR from a coding (python) point of view.

I personally started out with the dspguide  and then Rick Lyons's book, both already mentioned by Garry.

I am still looking for a good and easy-to-understand resource that provides the basic concepts of the math used by DSP and SDR.

3blue1brown has a playlist on the basics of linear algebra (*3). It is probably a bit overkill for what is needed to understand the basic idea of vectors and complex-numbers, but I do think it does help for people who are interested in a bit more in-depth understanding how these blocks work.

One video of 3b1b I do advice is the one called "But what is the Fourier Transform? A visual introduction." (*4) as the Fourier-transform is very important in DSP and SDR. It helps to understand that -as already mentioned- a signal is usually a number of frequencies (or rotating vectors if you wish) put on top of each other.

* One more resource -be it not free- is the 'wireless pi' book and video course. (*5)

It's a book and  a video course.

The book itself is still quite mathematical -at least, for somebody like myself who do not have a strict engineering-background- but the video course does offer a good alternative to that. If you just take the math as found in the book for granted,  the video course does offer a basic understanding what actually happens inside blocks like the costas-loop, the FLL band-edge filter or the polyphase clock sync block; and or what is matched-filter. Also also connects well with GNU Radio as it uses that as its main platform to experiment with certain basic data-communication principles.

Do you need this?
Well, in a lot of the cases, probably not. If you just uses example flowgraphs with the basic GNU Radio blocks with the basic default parameter values, there is a good chance your graph will work for most signals.

But -as I see it- having some background-knowledge on the internals of these blocks will help to make to build GR flowgraphs that sync quicker to an incoming databurst, which is probably what you need if you want to build a graphs that detects and decodes (say) short databurst.

So consider this as a resource to go from 'basic' to 'intern mediate' GNU Radio user.

Note. I didn't know the 'DSP related website'. Looks like an interesting resource.

Concerning your issue. my basic troubleshooting methodology is 'start at the bottom of the ISO stack'.
In this case, this means, your hardware and capturing the signal.

1/ Can you receive and demodulate the signal with (say) gqrx?
This will at least test your basic hardware-setup.

2/ Start with a very basic flowgraph: a osmocom source (say @ 2 Msps with a hackrf or 2.4 Msps with an rtl-dongle) and a frequency sink ("QT GUI Frequency sink")
You should at least see the radio-stations you are looking for.
Try adding three sliders ("QT GUI range") for the RF-gain, IF-gain and BB-gain of your osmocom block and check what variables change what in the signal you receive.

If this works, build up the graph step by step adding block by block, and test the output with a frequency sink or a time-sink at every step of the process.

One thing that is very important in this:
Adapt the sample-rate of the instrumentation block (e.g. QT GUI time or QT GUI Frequency block) to the sample-rate at the part of the flow-graph you are monitoring. So, if your flowgraph contains a block that does decimation (e.g. the frequency xlating FIR filter, a low-pass filter, the WBFM receive), keep track of the correct sample-rate at the output of that blocks and fill in the correct sample-rate in the instrumentation-block monitoring that output!

If you have a instrumentation-block that has (say) two inputs, the signals at both inputs must have the same samplerate. Say you have an QT time-sink block with two inputs and the sample-rate at one is 1/5 of the sample-rate of the other input, add a 'repeat 5' block in front of that input to correct this!!!

Kristoff (on1arf)

(*1) https://greenteapress.com/wp/think-dsp/
(*2) https://pysdr.org/
(*3) https://www.youtube.com/playlist?list=PL0-GT3co4r2y2YErbmuJw2L5tW4Ew2O5B
(*4) https://www.youtube.com/watch?v=spUNpyF58BY
(*5) ttps://wirelesspi.com

On 10.08.21 02:05, Gary Schafer 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 antenna.

                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+?



                [0] https://wiki.gnuradio.org/index.php/Simulation_example:_Narrowband_FM_transceiver#NBFM_receiver

                [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]