[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working Narrowband FM examples?
Re: Working Narrowband FM examples?
Tue, 10 Aug 2021 13:25:40 +0200
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
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
* One more resource -be it not free- is the 'wireless pi' book and video
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
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
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
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!!!
On 10.08.21 02:05, Gary Schafer wrote:
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
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...)
On 8/4/21 1:40 PM, Nathan Van Ymeren wrote:
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
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 22.214.171.124, 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 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  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, 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+?
Attachment: working nbfm receive.png
Description: PNG image
- Re: Working Narrowband FM examples?, Gavin Jacobs, 2021/08/03
- Re: Working Narrowband FM examples?, Gary Schafer, 2021/08/05
- Re: Working Narrowband FM examples?, barry, 2021/08/05
- Re: Working Narrowband FM examples?, Gary Schafer, 2021/08/09
- Re: Working Narrowband FM examples?, Gary Schafer, 2021/08/11