No questions, just thanks so much for maintaining it!

Back in 2019 the project enabled me to listen to the local baseball team's broadcasts [1] without a traditional radio since their online streams were restricted due to MLB's dumb blackout rules.

[1] https://www.jeffgeerling.com/blog/2019/hospital-stay-and-mlb...

I'm happy to hear you found it useful!

What dongles and antennas are recommended. Asking as a noob always fascinated by SDR.

Also, is SDR computationally expensive?

My preferred dongle is the RTL-SDR Blog V3: https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/

They also have a new V4 version, but it requires updated drivers that will take a bit of time to percolate out to Linux distributions and the like.

NooElec also has a line of RTL-SDR dongles that I would recommend: https://www.nooelec.com/store/sdr/sdr-receivers.html

The best antenna will depend on what you're trying to receive. Different antennas are optimized for different frequency ranges, and may be either omnidirectional (receiving equally well from many directions) or favour reception in one particular direction. To get started, you could buy a dongle that comes with an antenna included, but you may eventually want to switch to something targeted to the particular application you have in mind.

As for the computational cost, it depends a lot on what you're trying to do. As a general rule, the wider the bandwidth of the signal, the more processing power it will take to demodulate. HD Radio is relatively narrow-band (400 kHz), so it doesn't require much CPU power to receive it.

FM Band and TV antennae are easy to DIY, and you'll find loads of great leading and bleeding edge designs and plans online at forums like this:

https://www.digitalhome.ca/forums/antenna-research-developme...

Would it be feasible to do something similar with OpenWRT opkg packages to support capturing weather radar (and weather forecasts and alerts?) data from digital FM radio with a USB RTL-SDR radio?

Python apps require a bunch of disk space, which is at a premium on low-wattage always-on routers.

OpenWRT's luci-app-statistics application supports rrdtool and collectd for archived stats over time (optionally on a USB stick or an SSD instead of the flash ROM of the router, which has a max lifetime in terms of number of writes) https://github.com/openwrt/luci/tree/master/applications/luc...

From https://news.ycombinator.com/item?id=38138230 :

> LuCI is the OpenWRT web UI which is written in Lua; which is now implemented mostly as a JSON-RPC API instead of with server-side HTML templates for usability and performance on embedded devices. [...] Notes on how to write a LuCI app in Lua:

It might be possible, but I'm not sure whether a typical router would have enough CPU horsepower to do the processing required to demodulate the signal.

What models of Raspberry Pi are sufficient, or how many Mhz and RAM are necessary?

I haven't investigated the CPU and RAM requirements in depth, but I have used nrsc5 on a Pi 3B without issue.

I suspect a Pi Pico would be too small.

Also, I should mention that Python is not a requirement. The GUIs that people have created so far were written in Python, but the nrsc5 project itself is built entirely in C, and it exposes a C API.

Have you ever found interesting/unexplained data in the packet streams? I know there's provision for traffic stuff in there, and a few other defined types, but what else is hiding?

Reason I ask, is analog FM had all sorts of sideband streams for the longest time, like SCA audio and DirectBand digital, that weren't well known at the time. And while internet access is certainly easier to get these days, there might still be a justification for one-way data broadcasts in certain applications, so I wonder if someone's out there leasing subchannels or sub-packet-IDs or what-not, and shuffling encrypted data around in them.

Some stations have "HD TMC" (traffic message channel) streams. The others that I've encountered are "HERE Images" (traffic & weather radar images, discussed and mostly reverse engineered in https://github.com/theori-io/nrsc5/pull/308), "HERE TPEG", "TTN TPEG", "TTN STM", "NavteqAdmin" and "NavteqPacketData1."

At present, nrsc5 makes these streams available through its API, but doesn't otherwise do anything useful with them. I don't believe any of the GUIs process them either. Some reverse engineering work is needed.

Also, all of those stream types seem to be used across multiple stations. I haven't seen any weird one-off streams.

There was the somewhat recent issue in Seattle where a station included an image file with no file extension, and it bricked the radios in Mazdas: https://arstechnica.com/cars/2022/02/radio-station-snafu-in-...

Awesome project! I hope it doesn't get taken down by DTS!

Here's my question: Was there a reason for not using the GNU Radio framework for this project?

https://www.gnuradio.org

Thanks!

That decision was made by the original author (Andrew Wesie), but I think it makes sense because nrsc5 only needs a tiny fraction of the functionality that GNU Radio provides. Implementing the functionality directly in nrsc5 avoids the need for a large and complex dependency.

One downside is that we don't get the broad hardware support that GNU Radio provides, but maybe we'll someday take another crack at integrating SoapySDR. (See https://github.com/theori-io/nrsc5/pull/131 for an earlier experiment with that.)

What documentation did you use to decode hd radio protocol? From what I recall, the formats were all closed in some capacity. Did you reverse engineer it?

Most of the details are available in the specification, which is available here: https://www.nrscstandards.org/standards-and-guidelines/docum...

The missing parts are the audio codec (HDC) and the formats of the various data streams. These have required reverse engineering.

oh I thought it was closed. Thanks for the pointer.

Did you take any notes on the reverse engineering or is your code the documentation?

The code of nrsc5 (and my transmitter project, https://github.com/argilo/gr-nrsc5) would be the best source of information for the undocumented parts. I do have some private notes, but the useful information has already gone into the code.

What would it take to get this functionality merged into Cubic or Gqrx?

I am also the maintainer of Gqrx and I would love for it to have a built-in NRSC-5 receiver. The trouble is that some aspects of NRSC-5 are still patent-encumbered, which makes software distribution problematic. For that reason, nrsc5 is only provided in source form today. The situation may change once the relevant patents have expired.

Thank you for the hard work! Gqrx allowed me to identify the "Alternate Frequency" flag on one of my favorite FM stations that was causing my car to change channel every couple minutes. I was actually able to contact the station and they fixed it!

https://www.radiodiscussions.com/threads/kqrs-rdbs-alternate...

Ooh, since I have your ear, Gqrx performance is pretty unusable on my Apple Silicon Mac, like 1-2 FPS rendering the charts and the whole UI chugs. It was fine on my Intel Mac.

There any work going into that? I fully understand if it's a QT UI toolkit issue and out of your hands.

There's an issue open for this: https://github.com/gqrx-sdr/gqrx/issues/1104

I could really use some help from a software build expert. Gqrx and all its dependencies would need to be built in CI with Apple silicon support, and I don't know how to do that.