Re: Working Narrowband FM examples?

[Kristoff]

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:
https://www.youtube.com/watch?v=SrJq2AzXZME

. 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")?
>
> Gary
>
> *************************************************
>
> 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,
>
> Nathan
>
> 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,
>     Mike
>
>     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.
>
>         Nathan
>
>         On 8/3/21 3:47 AM, Mike Markowski wrote:
>
>             Nathan,
>
>             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
>
>
>                https://udel.edu/~mm/gr/
>
>             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 3.8.2.0, a promising sign.
>
>
>             Hope it's useful,
>             Mike
>
>             On 8/3/21 2:40 AM, Nathan Van Ymeren wrote:
>
>                 Hello,
>
>                 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+?
>
>
>                 Thanks,
>
>                 Nathan
>
>                 [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