FM Reception with the GNU Radio Companion | Hacker News Reader

FM Reception with the GNU Radio Companion

nutsvolts.com

79 pointsWaitWaitWha18 comments

> Digital signal processing is computationally intensive, so you’ll probably need a dual core processor so GRC runs smoothly.

Can someone explain to a radio layperson how come there are plenty of cheap, tiny radios if DSP is computationally intensive.

Because cheap radios do the processing analogically, without digitizing the signal :)

So is analogic signal processing inherently more efficient then?

Efficient at the expense of flexibility and noise, yes, but it depends on the use case - e.g. a Xilinx RFSoC can sample at some ungodly rate and has a phat FPGA on board, but is very expensive , so if you only need narrowband and not many of them you may well be better with a less flexible product.

Generally they are, but they don't scale well. For example, with an FFT you could decode every radio station simultaneously with the same receiver and only log more compute. So if you only want a single high SNR narrowband channel (even tunable) it's easier to do in analog, but if you want all 100 possible channels with stereo and/or some digital processing to add features or reduce noise... it's much better to do digitally. However, doing it with an FPGA/DSP would probably be significantly more efficient than a general purpose CPU.

Cheap FM radios, at least, are also much, much more power efficient. And, well, really cheap to make. (Not an audiophile, but I imagine these statements would not apply to high end analog equipment.)

I'd say that GRC is computationally intensive. You can run rtl_fm [1] on a Rasperry Pi Zero and have CPU power to spare.

[1] https://osmocom.org/projects/rtl-sdr/wiki/Rtl-sdr

Part of why GRC is computationally expensive is multiple reasons...

    1. GRC is really just a python front-end. You can see that by generating the .py script for any flow
    2. sample mismatch

Note about the sample mismatch... "man rtl_fm defaults to 24Ksps" , whereas the flowgraph for retrieving all the sideband data is set to 2.4Msps. The Gnuradio flow is crunching 100x the data as rtl_fm does.

Now, if detection of each pilot tone is done across 2.4MHz of the total sample on the rtl-sdr, then you could retrieve all the stations in view. However, this is centering on a single channel (106.7MHz), and therefore effectively 'wasting' all the extra retrieved IQ data.

Tl;dr. GRC isn't inherently CPU intensive - chewing through 100x the data IS computationally expensive.

The flowgraphs use decimation filters, which reduces the sample rate while increasing the effective bit depth.

Getting the high frequency sidebands takes more than 24k samples/sec.

Then I would ask that you generate the python script associated to the flow, and look yourself.

The data flow is 2.4Msps the whole way through, even with decimation filters. It's one of the inherent issues with using Python in this way.

I looked at the generated python code for some of my flows that do decimation. The __init__ section of python code makes connections. Then the main loop calls the GNU Radio libraries and does a wait().

Here's the relevant section of code.

def main(top_block_cls=top_block, options=None):

    tb = top_block_cls()
    tb.Start(True)
    tb.Wait()

if __name__ == '__main__':

    main()

Note: Each connection has its own sample rate and type, which is implicit in the graph.

Keep in mind that GNU radio is DSP on a general purpose processor whereas if you exploit the generally fixed access pattern nature of many DSP applications you can use FPGAs and DSPs (VLIW processors, usually)

As others have said, many very simple radios do demodulation in mostly analog circuits, saving the digital stuff for only the last step (or not at all, for totally analog systems like an FM radio).

The other thing is flexibility. If you don't need to change your demodulator, you can do all your digital signal processing on a purpose-built ASIC, which brings the cost way down. Radio demodulation and decoding typically falls in the "embarassingly parallel" category, so it's an excellent candidate for efficient implementation on an ASIC or FPGA.

>Can someone explain to a radio layperson how come there are plenty of cheap, tiny radios if DSP is computationally intensive.

If you want to handle a signal in the analog domain, it doesn't take much in terms of electronics. AM radio can be received using a crystal radio, 100+ year old technology, if the signal is strong enough. You need 6 parts, antenna, ground lead, coil, capacitor, diode, headphones.

To receive FM mono, you could use a diode radio, tuning off to the side of the carrier.

To receive FM stereo, you need a fair bit of electronics, including a phase locked loop.

Receiving FM stereo with RDS, etc. is a quite challenging thing to do in terms of signal processing. It is the only time my laptop really just can't keep up in terms of all the experimenting with Gnu Radio. It has the combination of high complexity, and high bandwidth that multiply out to a large compute load.

That is why the warning was included.

--- And now, for more info than you asked ---

I've had an SDR dongle for years, and got back into it when the plague hit. I've received AM, FM, Single Sideband, all are fairly narrow bandwidth, so I have plenty of compute power to spare for making complex graphs.

One of the "radios" I've built can receive all 5 NOAA weather radio channels at the same time.

Another receives the local VOR (VHF Omni Range) station, and plots the direction to the transmitter.

I can record an arbitrary 2 Mhz wide swath of bandwidth to disk (SSD, actually) in real time until I run out of disk space, and then post-process it later in any manner of my choosing.

GNU radio is free software, and so much fun to play with.

If you're a reddit user, I recommend checking out

https://www.reddit.com/r/GNURadio/ https://www.reddit.com/r/RTLSDR/

You can listen to SDR on the net at http://www.websdr.org/

> If you want to handle a signal in the analog domain, it doesn't take much in terms of electronics. AM radio can be received using a crystal radio, 100+ year old technology, if the signal is strong enough. You need 6 parts, antenna, ground lead, coil, capacitor, diode, headphones.

If there's one very strong station near you, you just need an antenna wire, ground, diode, and high-Z headphones. You'll hear the station.

You might want to add a tuning coil to that list.

https://en.wikipedia.org/wiki/Foxhole_radio#Designs_and_oper...

If you live close to an AM radio station, you just need a hunk of metal and a diode... it doesn't need to be resonant or tuned in any way.

Urban legend has it that you can even hear them via metal fillings in your teeth.

https://www.bradfordfamilydentist.ca/lucille-ball-heard-spie...

Of course. But if you have one strong station close to you, it will overwhelm any other signal and you'll hear it.

Reply on news.ycombinator.com