> 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?
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.
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...
> 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:
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.
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.
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.
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.
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?
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.
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!
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.
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.
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.
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.
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.
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:
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
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?
> 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.
> 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"
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:
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.
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.
> 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.
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.
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.
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.
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:
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.
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.
