Coexistence between nrsc5 and other rtl-sdr tuning apps

[markjfine]

This is meant as a long-term enhancement suggestion, which may or may not already be planned.

nrsc5 in itself is an amazing application for stand-alone demodulation of HD Radio signals. There are also good user interfaces available to make it useful to the average radio user. Not a knock against nrsc5, but a couple of things that's really missing are:

1. A good way to find/detect stations that contain the HD Radio signature front and back porches within your local signal environment; and
2. A good way to find the best antenna orientation and maximize the signal strength. Right now you can only use the individual (or combined) BER values and manually tweak the gain within nrsc5 (which is cumbersome) as an estimate once it's already been run and locked onto an HD signal.

One possible way is to use something like GQRX to first tune around and then re-orient an antenna for maximum signal and reduced adjacent interference. Then run nrsc5 to decode the HD Radio portion.

The problem is ownership of the rtl-sdr: Would be nice to leave GQRX running, disengage DSP processing, then switch to something like nrsc5-gui, and hit play. The problem is that GQRX already 'owns' the USB port to the rtl-sdr and you get the message:

Kernel driver is active, or device is claimed by second instance of librtlsdr.
In the first case, please either detach or blacklist the kernel module
(dvb_usb_rtl28xxu), or enable automatic detaching at compile time.

The only way to solve it is to kill GQRX before starting nrsc5 (or nrsc5-gui/dui), thus losing the immediacy of a good visual tuning element (and hoping any multipath effects don't change things in the meantime).

Realise that adding the guts of nrsc5 is out of scope for GQRX (would imagine European users then requesting a DAB+ module as well). Likewise, adding the visualization similar to that used by GQRX to nrsc5-gui/dui would likely overtax Python's ability to function.

This logically leaves the ability to have these applications be able to simultaneously run, being able to the 'see' the rtl-sdr receiver, though not necessarily be able to simultaneously operate it (e,g, nrsc5 play while GQRX DSP is engaged, and vice versa).

[TheDaChicken]

I feel the same way. It would be cool to see a spectrum analyzer.

I don't think its possible for 2 applications to be accessing rtl-sdr. I assume that adding a gui to this is out of the guts for nrsc5.

If the API would expose iq samples then it would be possible to create a program w/ a gui using the library that has the spectrum analyzer. It's not fully out of my scope to use some gui library in c++ to create a gui. I ain't a gui designer.

[markjfine]

For those that have nothing but a tripod dipole to twist in unnatural ways (for those old enough to remember what you went through with set-top TV antennas) in order to get a good signal. There should be a seamless way to see it before you hear it - even if it's using two existing applications.

[argilo]

If the API would expose iq samples [...]

It already does:

https://github.com/theori-io/nrsc5/blob/6cbc10649aa3c780407ad18c3560d9ef142f280b/include/nrsc5.h#L129

https://github.com/theori-io/nrsc5/blob/6cbc10649aa3c780407ad18c3560d9ef142f280b/include/nrsc5.h#L276-L279

I assume that adding a gui to this is out of the guts for nrsc5.

I wouldn't be against adding a GUI to nrsc5 itself, provided it is cross-platform. Merging in an existing GUI like nrsc5-gui might be a good way to keep it up to date with nrsc5's improvements.

[markjfine]

I'm just concerned with Python being able to handle it. One of the reasons why I created nrsc5-dui was because mods I made to nrsc5-gui brought audio processing to it's knees.

I wouldn't mind trying to port nrsc5-gui to Qt, if I could re-insert the enhancements made in nrsc5-dui. The latter reverted to a Posix shell call instead of using the API primarily because of Python getting overloaded.

[pclov3r]

I wouldn't be against adding a GUI to nrsc5 itself, provided it is cross-platform. Merging in an existing GUI like nrsc5-gui might be a good way to keep it up to date with nrsc5's improvements.

One the downsides for this Is a more complicated build mainly for windows. I guess in theory all the dependencies should be able to built for Windows without issues?

[TheDaChicken]

It already does:

OH! Hahahaaha

I'm just concerned with Python being able to handle it

With my experience with Python, it'll be too much for Python to handle it. It is okay to grab audio samples and play it back. Which would cause stutters sometimes. Having Python manage iq samples and playing it back is too much.

more complicated build mainly for windows.

On msys2, there are easily installable packages for GUI libraries like qt. There is also vcpkg aswell! vcpkg is so nice.

I wouldn't mind trying to port nrsc5-gui to Qt

I wouldn't mind as well! That may be able to give me something to do....

[ferrellsl]

Someone has already started at QT version and it looks very promising: https://github.com/CamK06/nrsc5-gui-plusplus

[TheDaChicken]

Someone has already started at QT version and it looks very promising: https://github.com/CamK06/nrsc5-gui-plusplus

It doesn't look that bad. Though, it hasn't been worked on since 2022. I do like they used spdlog library. Though, it gives me more motivation to maybe work on something.

[markjfine]

Lol... it's got my buttons. Needs two rows now tho. 😂

[TheDaChicken]

Though, I do wanna ask what should be the plan here? I am a bit unsure.

Qt is for C++ and nrsc5 is a c project. I don't think it would make sense to be put here exactly. Sounds like another git repository?

It is possible to add nrsc5 as an external project in CMake and make an easy script to build everything just like here to build on Windows.

Should I use nrsc5-dui as a reference? Do you want to start the work on it @markjfine? I don't wanna steal your idea 😂.

I am very meh about this because: "Is all of this possible to stay maintained?" If so, let's goo!! get everyone together to work on it!

[markjfine]

Yeah, this heading towards a completely new cooperative project.

Lol... None of -dui was really my idea since I leveraged most of it from -gui to begin with. I just got bored being stuck in NJ a couple of years ago (long story) and started playing as a way to kill time. If you have the time and the motivation, go for it. Just know that my gui design looks a lot better than my actual coding prowess.

Edit: Aren't we all glad it's not Java...

[markjfine]

If nrsc5-dui is being used as a baseline, be advised I've just pushed some minor code changes to nrsc5-dui.py. Well, one not so minor because it accounts for a change to the LOT status message in nrsc5. Otherwise you'll not get any updated station logos or album art.

[markjfine]

Only other thing I would recommend is to move the nrsc5 interface from a Posix-compliant shell call and status message regexes back to API callbacks if practicable. The shell call architecture saved Python cycles no longer needing PyAudio, but became the main stopper for running in Windows. Also, the new Navteq/HERE functionality in nrsc5 currently only works with the API.

Yeah, I outsmarted myself. 😂

[TheDaChicken]

For me, the only problem is designing GUIs. I am very bad at it! Hahaha

[markjfine]

Maybe I can help you there. A few ideas:

First, I would change the tuning to operate similar to how GQRX tunes instead of using the +/- edit box. Could possibly move that entire line below the two rows of 'preset' buttons to bring it closer to the spectrum display, which could reside in a new tab that sits before the Album Art tab. The display would contain a limited, 500kHz-wide tuning spectrum, since you only need to see the current and part of the adjacent channels.

That may be only changes needed right now, with the possible exception of a single button that toggles between the normal FM and HD... we can figure out where that ultimately goes later, but I assume that could go between the stop and bookmark buttons in the toolbar.

The rest of the interface could basically stay the same. Adding a new tab named 'Spectrum' may cause the width to increase a bit, so may need to drop the font down a few points to keep the aspect ratio clean and still looking like the Music app on your phone.

[TheDaChicken]

First, I would change the tuning to operate similar to how GQRX tunes instead of using the +/- edit box

Should you be able to change between displaying the spectrum analyzer & waterfall? Displaying it from a huge window to a small window?

I don't wanna fully copy gqrx. At that point, you could add it to ggrx, you know? There is: (#97). Switching from FM and HD won't switch seamlessly too because nrsc5 doesn't support FM. It is a lot to add everything that ggrx has.

It is possible to give you the UI file for qt designer.

[markjfine]

Not sure you really need a waterfall for this kind of signal. Waterfalls are great when analising afsk-like signals - things that vary in frequency over time. You'll know if the porches that contain the HD info are strong enough by looking at them in a simple spectrum display, which is all we really need it for.

Here's the operational flow:

1. Tune the spectrum in Std FM until you see an HD-capable signal in the spectrum display.
2. Make adjustments (if possible or necessary) to increase or stabilise the signal.
3. Flip the button from FM to HD. Can move off the spectrum tab at this point until you need to retune.

Given this flow, can probably eliminate the stop button completely and just use the play button as toggle for FM DSP on/off or HD play/stop.

Could add all this to GQRX, but then you get Europe saying, hey... what about us? Not a bad idea in the long run, but at some point it starts to get bloated with features that some people can't use.

The advantage of going in the opposite direction is relatively small and efficient bit of code. Don't even need all the fft manipulation parameters. Can just settle on something fixed and optimum: 8192, 25fps, Blackman, etc.

[TheDaChicken]

Not sure you really need a waterfall for this kind of signal

You may be right about that. Nothing wrong with that.

Could add all this to GQRX, but then you get Europe saying

I don't think there is any reason not to. Though, I should rephrase and say "fork of gqrx." It cannot be added to gpqrx due to patents.

If it was a new program, what would that even be called? Doesn't seem like it should be called "nrsc5-gui" because FM and HD would be out of sync.

This is what I was thinking in my head for an "nrsc5-gui" application with FM:

• Being able to easily switch through frequencies.
• It automatically enables HDRadio if it has a good signal (you can disable hdradio if needed).
• Spectrum analyzer for easy turning/adjustments and cools.
• being able to see album art if needed, title etc.

It seems kind of awkward of a program from my perspective to have FM only for adjustments. That last thing in my head would be kind of quirky in gqrx since the interface isn't meant for it.

[markjfine]

Think we're really on the same page. To be honest, we're not really pulling in parts of gqrx as much as providing an freq display of iq data... and a graphical (vice textual) tuning interface, which is a pretty common thing.

The rest is really a port of what already exists.

[ferrellsl]

Maybe welle.io could be modified from DAB/DAB+ to support nrsc5. https://www.welle.io/

[TheDaChicken]

Think we're really on the same page.

We misunderstood each other hahahaha. My bad hahaha.

[pclov3r]

@markjfine does NRSC5-DUI support opening of a I/Q file instead of only being able to use a RTl-SDR?

Figured I'd ask here before opening an issue over there :)

[markjfine]

nrsc5-dui doesn't do it, but it can easily be made to. I just hadn't gotten around to adding a file selection dialog, a toolbar button to initiate it, and the actual execution call.

nrsc5-dui just kicks off nrsc5 as a shell process and uses the command line switches instead of the API. So if there's a CLI call, no problem. That said, the actual shell uses a pipe to send the keyboard commands to change HD channels. That part requires a Posix operating system, which messes things up for Windows. Like I like to say, I outsmarted myself into a silly corner with that one. I generally think things through a lot better than that. I had plans to swap out the pipe into something that would work in Windows, but it seemed like a huge rewrite and I just never got around to it.

Back to the IQ file: The only question is if it's worth it to add to nrsc5-dui now, or do we wait until we have something operational in Qt like we're consorting to do here.

[pclov3r]

Back to the IQ file: The only question is if it's worth it to add to nrsc5-dui now, or do we wait until we have something operational in Qt like we're consorting to do here.

I guess that's a matter of how much work it is to implement. I figure something proposed here will take a lot longer down the road.

I guess ideally everything would be controlled over the API without any shell commands but that is likely a lengthy process to make that happen.

[markjfine]

I mean it's early days now, so it wouldn't really impact anything else on the Qt side. Down the road, making any code or ui changes (except for the nrsc5 interface cycle, of course) would work counter-purpose to anyone working on a port.

Speaking of which... my schedule is not really conducive to focusing on anything intense this week, but I should be [he says...] back 'in-pocket' next week.

[markjfine]

Speaking of which # 2: One enhancement that absolutely needs to go in this (I just checked my TODO on dui, and I apparently never added it to the list) is the ability to swap different bookmark files in and out depending on your location, and to have the station logos track with that.

I go back and forth between central VA and central NJ and it gets incredibly annoying trying to keep things sorted by copying and pasting stuff between text files and config.json. I'm in NJ now and it's bad enough that if I turn the rabbit ears in one direction I get WRNB out of Philly, and turn it another way I get WHTZ (massive bollocks from the FCC allowing that to happen), not to also have to confuse it with WBIG in DC when in VA. All are on 100.3 MHz. Stations aren't supposed to be co-channeled when they're < 150 miles of each other. WRNB and WHTZ are little more than half that.

[TheDaChicken]

Switching from FM and HD isn't that bad with nrsc5... :D (not finished) https://youtu.be/wEf8yMSgDF0

[markjfine]

I like it!

[TheDaChicken]

@argilo ahem

I hate to ask. Is there anyway you could add quick support for pipping float IQ samples? I would create my own pull request but I am not fully confident. It looks like uint8_t is baked in including neon instructions.

I currently received an Airspy because I had LOTS of overloading from the rtl-sdr.

The Airspy doesn't provide the same sample rate that the constant nrsc5 IQ sample rate which means I need to resample down.

I could resample down for nrsc5 only BUT since I am using liquid-dsp, I can resample only with floats or complex floats.

That way I only need to convert to complex iq w/ rtl-sdr. Airspy's library can provide float iq. Though that also begs the question about the const sample rate....

This will lead to easy support for other devices but... shh

[TheDaChicken]

Is it safe to say he is busy? 😭 @markjfine

[markjfine]

Not sure what you mean.

[TheDaChicken]

Not sure what you mean.

I meant I am not sure how to communicate with Argilo. Don't wanna keep pinging him since am not sure he saw my message about support for broader types so I can use nrsc5 with Airspy.

[markjfine]

Oh, yeah, pretty sure he's got his fingers in quite a few things. He just may be unable to respond at the moment.

[TheDaChicken]

Okay, I tried to get around the limitation of the sample rate the dumb way

1. Convert IQ be in floats
2. resample down to NRSC5_SAMPLE_RATE.
3. Convert (back if rtlsdr) to uint8_t to allow to go through nrsc5_pipe_samples_cu8

I ran into a problem: The resample results in a buffer size that hits an assert in nrsc5_pipe_samples_cu8 because the buffer must be able to divide by 4.

Though the whole goal is to mainly get airspysdr working.

This is a little too much for me.

I dont know the criteria for nrsc5_pipe_samples_s16 because it doesn't use fir half-band.

EDIT: I did the annoying and created a ring buffer only to make sure input samples divided by 4. Airspy works great :D