Nrsc5: Receive NRSC-5 digital radio stations using an RTL-SDR dongle | Hacker News Reader

Nrsc5: Receive NRSC-5 digital radio stations using an RTL-SDR dongle

github.com

185 pointsgreesil75 comments

A GUI built on top of this: https://github.com/markjfine/nrsc5-dui

From https://github.com/markjfine/nrsc5-dui#maps :

> Maps: When listening to radio stations operated by iHeartMedia, you may view live traffic maps and weather radar. The images are typically sent every few minutes and will fill the tab area once received, processed, and loaded. Clicking the Map Viewer button on the toolbar will open a larger window to view the maps at full size. The weather radar information from the last 12 hours will be stored and can be played back by selecting the Animate Radar option. The delay between frames (in seconds) can be adjusted by changing the Animation Speed value. Other stations provide Navteq/HERE navigation information... it's on the TODO 'like to have' list.

Is this an easier way to get weather info without Internet than e.g. Raspberry-NOAA and a large antenna?

https://www.google.com/search?q=weather+satellite+antenna+ha... https://github.com/jekhokie/raspberry-noaa-v2#raspberry-noaa... :

> NOAA and Meteor-M 2 satellite imagery capture setup for the regular 64 bit Debian Bullseye computers and Raspberry Pi!

If you live within the coverage area of an FM radio station that's sending weather radar, it will probably be easier to receive than NOAA satellites.

> Is this an easier way to get weather info without Internet than e.g. Raspberry-NOAA and a large antenna?

If you're OK with audio only, you cant beat NOAA weather radio: https://www.weather.gov/nwr/

You can listen with a SDR, or any number of cheap radios.

I'm a co-maintainer of this project. If anyone has questions, I'd be happy to answer them.

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 to demodulate an HD radio stream?

(Pi Pico, Pi Zero, and Pi A+/B+/2/3/4 have 2x20 pin headers for HATs. Orange Pi 5 Plus has hardware H.265 encoding with hw-enc and gstreamer fwiu.)

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.

Back in 2015 this title would've read, "Listen to HD radio with a $8 RTL SDR dongle".

First we ran out of E4000 tuners for the rtl-sdr dongles... but there were R820T. Then then R820T ran out and R820T2 replaced them. Then a proliferation of slightly less task specific R828D variants. The price steadily increased. Then the pandemic hit and it spiked even more.

At $8 a pop you could afford to use many of them mod them, etc. But at $30 you pretty much treat it like any other SDR.

You're all correct, except there are not that many $30 SDRs out there. Most of them start at around $200 and end in very very high thousands. Also, most SDRs have clearly superior capabilities to the RTL-SDR, though often those capabilities are not required.

BTW, for simple AM/FM demodulation I cannot recommend enough the handy https://github.com/charlie-foxtrot/RTLSDR-Airband. Most of the LiveATC.net feeds run on it, for example. It can be used for any AM/FM audio, for any number of simultaneous channels, even on a weak machine like a raspberry pi.

I was originally going to have $20 in the headline and then I did a price check on Amazon. Man, the times have changed.

I'm pretty sure the price has gone up because Amazon charges a huge markup/fees.

If you buy it from the source, it's now $9.

https://www.aliexpress.com/item/1005003302259707.html

Models targeting the SDR market (e.g. from RTL-SDR Blog or NooElec) do have some improvements compared to models sold as TV tuners. Most importantly, they often include a more accurate crystal oscillator, which is useful when receiving narrow-band signals.

I was ready to say you've made my day but unfortunately those rtlsdr dongles use the mostly unwanted Fitipower FC0012 tuner and not any of the better Raphael tuners (R820T2/etc) that are most common and expected for rtl-sdr dongles. The frequency range supported and the rtl-sdr software ecosystem for FC0012 are minimal.

    Elonics E4000 (E4K) 54 - 2200 MHz (1100 MHz-1250 MHz gap)
    Rafael Micro R820T 24 - 1766 MHz (>1500 MHz is bad w/o tuner cooling)
    Rafael Micro R820T2 24 - 1766 MHz (>1500 MHz is bad w/o tuner cooling)
    Rafael Micro R820T2  13 - 1864 MHz (mutability's driver)
    Fitipower FC0012 22 - 948 MHz
    Fitipower FC0013 22 - 1100 MHz (FC0013B/C, FC0013G has seperate L band input)
    FCI FC2580  146 - 308 MHz and 438 - 924 MHz

Looking around on aliexpress most at that price at FC0012 tuner based (even if they say R820T). There are a couple actual R828D dongles but the price shown seems to be one time thing "welcome deal"/75% off and the actual price is more like $25. Dang. Still, I'll keep my eyes on aliexpress now as well as ebay, so thanks.

What's surprising is HD doesn't mean high definition. It doesn't mean anything they just named it HD Radio

Hybrid digital, which I believe refers to having both analog and digital over a single carrier.

I've heard that term as well, but the official site denies it: https://hdradio.com/trademark/

This is actually extremely useful when hooked up to a laptop for traveling, because of the embedded traffic information and maps in the sideband data.

If you're willing to share more on this subject, color me interested.

Some stations send out traffic and weather images (as well as album art and station logos). The files can be dumped to disk using nrsc5's "--dump-aas-files" option. A few people have built GUIs that display the information in a more convenient way:

https://github.com/cmnybo/nrsc5-gui https://github.com/markjfine/nrsc5-dui https://github.com/KYDronePilot/hdfm

In addition to files, some stations also send out "stream" and "packet" data. There is ongoing work to reverse engineer the formats. See the discussion here for details: https://github.com/theori-io/nrsc5/pull/308

Are there yet Clock, Weather Forecast, or Emergency Alert text data channels in digital FM radio?

FWIU there are also DVB data streams?

Time information is broadcast, but in my experience it's often inaccurate.

There's also a special stream for emergency alerts, but I haven't seen it in use.

There are various data streams, but not DVB.

A lot of the details are described in the standard: https://www.nrscstandards.org/standards-and-guidelines/docum...

DVB-T could technically carry clock, weather forecasts, and alerts as text data feeds.

What needs to be done to link WEA Wireless Emergency Alerts with HD radio data streams? WX radio could possibly embed a data channel? If it doesn't already for e.g. accessible captioning?

DVB-T: https://en.wikipedia.org/wiki/DVB-T :

> This system transmits compressed digital audio, digital video and other data in an MPEG transport stream, using coded orthogonal frequency-division multiplexing (COFDM or OFDM) modulation.

From https://www.rtl-sdr.com/about-rtl-sdr/ :

> The origins of RTL-SDR stem from mass produced DVB-T TV tuner dongles that were based on the RTL2832U chipset. [...]

> Over the years since its discovery RTL-SDR has become extremely popular and has democratized access to the radio spectrum. Now anyone including hobbyists on a budget can access the radio spectrum. It's worth noting that this sort of SDR capability would have cost hundreds or even thousands of dollars just a few years ago. The RTL-SDR is also sometimes referred to as RTL2832U, DVB-T SDR, DVB-T dongle, RTL dongle, or the "cheap software defined radio"

From https://www.reddit.com/r/RTLSDR/comments/6nsnqy/comment/dkbv... :

> [You need an upconverter to receive the time from the WWV shortwave clock station on 2.5, 5, 10, 15, and 20 MHz] http://www.nooelec.com/store/ham-it-up.html

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

> TIL there's a regular heartbeat in the quantum foam; [...] https://journals.aps.org/prresearch/abstract/10.1103/PhysRev...

Previously discussed at HN:

https://news.ycombinator.com/item?id=14564279

Oops. It was new to me.

Previously discussed is not bad--especially since the last discussion was 5+ years ago!

HN encourages good reposts. You did good.

Nothing personal, not a dig, I'm a data archive exhumer by nature. I and others add such links if there has already been a bit of commentary on the topic. As others have said, reposts can often be valuable. Here are a couple more:

https://news.ycombinator.com/item?id=25192522

https://news.ycombinator.com/item?id=27317802

I have a little hobby project where I record an FM radio music station using a SDR and then remove all the non-music portions for offline listening. I like the music selections the DJs pick, but I prefer not to listen to the DJ commentary and the advertisements.

I evaluated three methods of recording: analog capture from a standalone FM receiver, using this nrsc5 library to record the "HD" radio stream, and using an AirSpy SDR with this library: https://github.com/jj1bdx/airspy-fmradion

Recording the "HD" (what a misnomer) radio was nice in that there was no hiss or multipath effects, but in comparison to the other methods the digital compression artifacts became impossible to un-hear. It seems to top out at about 96 kbps

The airspy-fmradion library has some nice stuff in it to address multipath, resulting in the best audio quality of the three methods I tested.

I use https://github.com/ina-foss/inaSpeechSegmenter to identify which segments of the recordings are speech vs. music.

Oooh nice. I've been wanting to listen to HD radio with my SDR for years. Tried a couple libraries that claimed to work but never had much success.

Is this like DAB/DAB+? I've never heard of NRSC-5.

Yes, it is similar. It is used primarily in North America, while DAB is used primarily in Europe.

It is commercially known as the iBiquity In-Band-On-Channel (IBOC) system a.k.a. HD Radio, now owned by DTS. It has been implemented in the North American FM radio band and features multiplexing of 2 or more subchannels per station. It has been introduced in the AM band as well but a variety of technical issues have tended to be too problematic. Unlike DAB, which has its own dedicated bandwith, HD Radio is a system of sharing an analogue FM radio station's existing bandwidth with a slice of digital payload. HD Radio-capable receivers pick up the analogue signal as usual, and if the digital streams are viable will switch to reproducing them for the listener. HD Radio can be broadcast digital-only, but I'm not personally up-to-date on any presently doing that, given all the legacy analogue FM receivers out there.

I'm not aware of any digital-only FM stations either. But there are a handful of digital-only AM stations, like WWFD.

> if the digital streams are viable will switch to reproducing them for the listener.

This produces a weird effect when listening in the car and moving in-and-out of good digital SNR range. When the radio switches between analog and digital, unless the station has them perfectly synced (never), there's always a little echo or stutter. It seems like it would be nothing but it's quite annoying.

Particularly annoying while driving in very hilly areas, that's for sure. There are some traits of signal propogation that are very difficult to work around, even with buffering and error correction remedies.

It shouldn't be impossible to sync. Here in Europe we even sync FM transmitters so they can broadcast on the exact same frequency without causing interference! That requires a magnitude higher precision than this.

Hmm that doesn't sound like a bad option at all. Here in Europe we're trying to displace FM by DAB+ and it works really crap because the coverage of DAB is worse.

Having fallback to analog would really help to cover the gaps. However the EU seems hell-bent on freeing the 87-108 spectrum so that they can sell it. Just like they did with the analog TV bands. Its 700Mhz band is now one of our cell bands.

Of course the continued ubiquity of FM receivers makes this a bone-headed plan but sadly they have many of those right now, like chat control.

How strong a signal do you need for this to work?

I have an RTL-SDR (R828D tuner) and I can just about receive regular FM stations, but the quality is pretty bad - voice is just about intelligible through the fuzz.

I don't know if my rtlsdr is bad, my antenna is bad, the signal strength is weak, I have interference, or this is just the quality expected from a $10 'TV tuner'.

RTL-SDR tuners usually have very good reception between 50 and 1000 MHz, which includes the FM broadcast band. It is easy to overload the analog-to-digital converter, so it's important to make sure the gain is not set too high. Setting the gain too low could also prevent reception if you're far from the transmitter. If you're receiving from indoors, interference from electronics in your house can cause trouble, and walls attenuate radio signals. You could try moving the antenna, or check whether it works better outdoors.

Given the recent discussion about integrated FM radio receivers in mobile phones, I wonder if those tuners could be used internally in place of a dongle? A bit of discussion here:

https://news.ycombinator.com/item?id=37778149

This would be outside my capabilities.

It would only be possible if the tuner exposed raw RF samples, the way RTL-SDR dongles do. I'm not sure whether any of the integrated FM receivers do that.

If only there were a good library for using DRM (digital radio mondiale) with SDRs.

Are you referring to AM/SW DRM, or VHF DRM?

For AM/SW DRM, the "Dream DRM decoder" works fine for me.

The trouble is that most of the Broadcasters have abandoned AM DRM.

I just now did a quick scan. Of the 17 MW/SW channels I have programmed, there isn't one on air with DRM.

DRM broadcasts are definitely hard to find. A schedule is available here: https://www.drm.org/what-can-i-hear/broadcast-schedule-2/

I've used Dream before, and it works fine, but I wish there was a more modular option in the form of a library. That would be easier to plug into SDR tools.

I would write one when I get the time, but I've never been able to find the actual specification anywhere.

The documents look to be available here: https://www.drm.org/specification/

Reply on news.ycombinator.com