Support for NRSC5 executables built for SDRplay functionality?

[dragonbytes]

Hi, I use an SDRplay RSPdx device instead of the RTL ones and was able to build and use a forked version of nrsc5 that supports it no problem. A few of the command-line arguments are a little different than the RTL ones though and I wondered if you might be able to add a few tweaks so that nrsc5-dui can spit out the right flags for device id and allow you to tweak the gain settings? I don't know if you are still actively working on the project, but just figured i'd ask! nrsc5-dui is an awesome program!

[markjfine]

Hi back, and thanks for the kind words. Yes, I'm still somewhat engaged in this, I've just not had much time to do it recently. Am thinking of making a few more enhancements given the time.

I think expanding to other devices is an excellent idea. I myself would personally prefer to use an AirSpy Discovery HF+ over the RTL because it's a lot more sensitive, selective, and less prone to artifacts in the sidebands. Perhaps we can swap ideas on how you modified nrsc5 for the SDRplay RSPdx so I can possibly emulate similar modifications for the AirSpy. In short, I have no problem expanding the calling interface to work with these or other specific radios. I'll also assume the command line is really all that needs slight modification and that nrsc5 still spits out the same info as before - this would make things very simple. Otherwise it might complicate things a bit.

[dragonbytes]

Well it wasn't actually me that did the fork but here is a link to the project that did: https://github.com/fventuri/nrsc5

As far as I know, the output is all still the same and the only differences are in the flags for controlling gain and specifying the ID of the SDRplay device. I do have some coding/development experience in C and I know a little bit of python so i'd be happy to help and contribute in any way I can. I could post some logs/samples of output so you can compare/confirm it's the same output as nrsc5-dui expects already as well as more specific information on the syntax of these custom CLI flags.

I'm also interested in helping nail down a specific more official path for Windows 11 users to get it working under WSL2 as the current versions have all kinds of new support for native GUI apps with audio support and even graphics acceleration etc so theres gotta be an official way to run nrsc5-dui under that enviroment! Just let me know what you need and i'll try my best to pitch in! :)

[ferrellsl]

It runs just fine under WSL.  See:  Simple Fix for Windows users/WSL2 · Issue #20 · markjfine/nrsc5-dui

|

Simple Fix for Windows users/WSL2 · Issue #20 · markjfine/nrsc5-dui

I found a very simple fix to get your app running under Windows/WSL2 without any issues. No need for pulseaudio ... |

|

|

-- The quality of your thoughts will determine the quality of your life.

On Wednesday, October 26, 2022 at 12:16:33 PM MST, DragonBytes ***@***.***> wrote:  

Well it wasn't actually me that did the fork but here is a link to the project that did: https://github.com/fventuri/nrsc5

As far as I know, the output is all still the same and the only differences are in the flags for controlling gain and specifying the ID of the SDRplay device. I do have some coding/development experience in C and I know a little bit of python so i'd be happy to help and contribute in any way I can. I could post some logs/samples of output so you can compare/confirm it's the same output as nrsc5-dui expects already as well as more specific information on the syntax of these custom CLI flags.

I'm also interested in helping nail down a specific more official path for Windows 11 users to get it working under WSL2 as the current versions have all kinds of new support for native GUI apps with audio support and even graphics acceleration etc so theres gotta be an official way to run nrsc5-dui under that enviroment! Just let me know what you need and i'll try my best to pitch in! :)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[markjfine]

Not really to get into a Windows debate (since this is mostly about other radios), but I'd rather like to get it working so an additional environment such as WSL2 isn't even needed and still is able to spawn and interface with nrsc5.exe in a thread. The solution will be very involved and I just need the time to do it. I actually have a stand-alone Win11 box coming tomorrow, so trying to debug inside a VM (that had known USB problems on top of other things) will no longer be an issue.

[dragonbytes]

Sorry I haven't gotten back to you sooner, but this is the usage info for the sdrplay build of nrsc5:

Usage: nrsc5 [-v] [-q] [--am] [-l log-level] [-d device-serial-number] [-p ppm-error] [-g gainRF.gainIF] [-w iq-output] [-o wav-output] [-A antenna] [--dump-hdc hdc-output] [--dump-aas-files directory] frequency program

I have also attached a log of the output when nrsc5 has tuned a station that also includes album artwork and traffic maps etc. I think its all the same as the standard version. Would it be alot of work to support the nrsc5 binary built for sdrplay? If there's anything else I can do to help in the development process, please let me know :)

nrsc5_sdrplay_log.txt

[markjfine]

Seems like I just need to make it automatically use --am when in the AM band (if it doesn't already) and add two entries for device and antenna (if the default isn't needed). I think everything else is similar and taken care of already. I just need to take a closer look at the log to see if it's posting the kind of responses needed.

[dragonbytes]

So I did some tinkering with the python source code and have successfully gotten it working. The pipe communication seems to work exactly the same as the standard RTL build and all your regex parameters grab the data perfectly as far as I can tell. I even started tinkering with the .glade files to modify some of the fields for use with SDRplay devices (for example, on SDRplay devices, the IDs contain alpha-numeric characters so I had to change that from the numbers-only mode). For some reason, my version of GtkBuilder found version incompatibilties with some of your existing parameters like xalign etc. Do you plan to offer a completely separate build for SDRplay devices or would you add further fields, etc in the settings tab to select your device type for an all-in-one program?

[markjfine]

I'll probably add a switch that shows/hides those two SDRPlay items and re-distro the existing thing. I may also look at the nrsc5 code to expand it and this app because there's a station here in DC that has 5 channels on it. I believe the current limit for nrsc5 is 4.

Currently have my head stuck in fixing some pretty complex threading-related audio pipe bugs in DReaM (Digital Radio Mondiale decoding for shortwave), but will attack this when that winds down.

[dragonbytes]

Another thing with the SDRplays is that some models (like mine) actually have multiple antenna ports that you can select. Would you also be able to add a field for antenna port? The syntax in nrsc5 is quoted strings of "Antenna A", "Antenna B", etc.

Also, I didn't know you do dev work on DREAM! I freaking love that decoder. I have to have a strong signal usually though to maintain the audio lock. I tried getting the newer versions to work but they require all kinds of QT dependencies that made my brain hurt :)

[markjfine]

That Antenna would have been one of the extra inputs, but if it's only two I can just add a switch for A or B rather than have a text field, which would be clumsy.

Yeah, I'd been involved on and off with Dream for almost 20 years now. The current version has some real issue with the way they open and close pipes across threads, which Qt doesn't like, so it has a habit of crashing when you change an input source or try to load a recorded file. I have a version that works on PCs without QtMultimedia (QtM is no longer distributed with Qt5 and Dream doesn't work on Qt6... yet). I have a list of the minimal dependencies and can provide some Intel-based builds if needed.

[dragonbytes]

My RSPdx has 3 inputs. A, B, and C. Other models only A and B and yet others just only 1 connection and no setting necessery. I noticed in your code, you have stuff pertaining to Windows builds and I wondered what your plan was for that as I dual boot myself between linux and Windows 11. I was able to get it work via WSL2g with ALOT of difficulty. Had to install a ton of dependencies. The windows version of python3 has no equivalent for PyGObject but it would be great to have a version that I can run native-ish when im using Windows :)

[markjfine]

Ok, combobox antenna select it is!

I've grown tired of VMs like WSL2 and Msys. Nothing works the way it should. I used to run Win11 and Fedora 36 in VMs on a Mac, but just bought a new Intel-based Lenovo and migrated both to it. The reason is because I had to upgrade my old Mac because nothing was supported on it anymore. New Mac is an M1 ARM architecture and the old Intel-based VMs wouldn't run on it. Quite a few things no longer run on it, such as my 360 controller and VB-Audio Cable. So, the last few weeks have been an adventure.

[markjfine]

Almost forgot.. As for running on Win11, I am looking for alternate ways to get around those issues, now that I have a separate box that can actually use USB ports the way they're supposed to.

[dragonbytes]

Yeah USB passthrough with VMs is iffy at best. Been there :) I think at some point soon, im just going to have dedicated machines for OSes. Too much of a pain forcing them to play nice with each other. M1 Macs are nice for portable devices, but a desktop computer, yeah I agree. Nothing works with M1 macs and Rosetta (or whatever they call their compatibility layer these days) is less than ideal. WSL2 is nice to have for terminal stuff, but GUI stuff and dedicated hardware support is wonky.

Have you ever considered porting nrsc5-dui over to something like C++ that could be built more easily for multiple platforms? Would be neat to wrap the actual nrsc5 C code around an actual GUI, no STDOUT pipes necessary :) Buuut probably not worth all the work. I'm very new to GUI coding but I want to learn more :) WxWidgets looks interesting.

[dragonbytes]

Oh one other observation. I didn't realize at first that those sub-channel tabs are actually buttons, and if you select sub-channel 2 on one station, and then tune to another station that doesnt have a sub-channel, it wont work because it sends the value from previous tuning attempt. Maybe reset that to 1 after tuning is stopped? Also maybe you could have pre-populated labels for each one like "Ch 1", "Ch 2" so that its obvious what those are for when you first open the GUI. Just an idea :)

[markjfine]

Funny you mention this button issue. At one time they had labels on them with the station name from the bookmarks on them. They should also show on the info tab with the type, as well as any digital feeds. See the screenshot at the bottom of the Code page. Something must have changed somewhere because as I was moving things to the Mac and PC I noticed it no longer looked like that.

I agree regarding developing a compiled app. Python was fun, quick, and made it easy to leverage from an original idea (nrsc5-gui), but it's starting to remind me of Java in the way things get deprecated so easily. I once wrote an entire ADRG map package with overlays and a map server that was prototyped in Borland Delphi and ported to Java before ESRI was even providing GIS options. Feel like that's how you keep maintainers employed because you're always having to chase that stuff. Qt is reminding me of this as well.

So, yeah, I may just port the whole thing into something that works once and keeps working. I hate having to say "It used to work". I now have Visual Studio on the PC, Xcode on the Mac, and virtually anything I need for Linux.

[dragonbytes]

Yeah even the Form builder was complaining about deprecated parameters. "These parameters require at least version 3.16". So I change version to 3.16 and then it says "Ok, but now these OTHER object types were deprecated in version 3.12 and no longer valid". Damned if you do, damned if you don't LOL. wxWidgets is a very cross-platform-friendly toolkit for GUIs and I think it's alot easier to use to Qt.

[markjfine]

Ok. Try pulling down a new nrsc5-dui.py and res/mainForm.glade. Basically the only two files I changed.

When you run it, click on Settings, click the Enable next to the SDRPlay # and enter the Serial#, then add just the antenna letter below it (I think it was B in the log you sent). You need just the letter B, not the whole "Antenna B" string.

This is a preliminary just to get things working. In the future I'll change the Antenna entry to a combobox. There are other interface changes I'll need to make in order to make it more error-proof.

[srs4511351]

dragonbytes, I noticed The new nrsc5-dui changes for SDRplay so I decided to try the sdrplay version. If this is too far off topic, maybe we can go to email.

I installed https://github.com/fventuri/nrsc5 The SDRplay version keeps losing sync. It plays for a while, then pauses to re sync. The SoapySDR version works better, but it has slight pauses when the text updates. The original nrsc5 with the rsp_tcp server doesn't do any of these things. I am running dietpi Debian Linux on a Raspberry Pi 4. You seem to be running Windows. Are you having any of these problems?

[markjfine]

Finally settled on making the receiver selection at the top of the settings, which shows or hides the irrelevant portions. Naturally this puts an awkward space where the hidden rows are, but I can deal with that later (when I add SoapySDR, which is also supported by that version of nrsc5).

Updated nrsc5-dui.py and res/mainForm.glade accordingly. Those two will need to be re-pulled.

[srs4511351]

I am using a Raspberry Pi 4 running DietPi Debian. I have a SDRplay RSP1A. I don't know if the antenna selection is a problem with this device, as it is a single SDR. The problems mentioned in my previous post greatly improved the next day, after a reboot.

While using nrsc5-dui, I find that on most stations, it stops playing after a few minutes and does not resume. A few stations don't crash, others crash right away. These are the messages. ...na A"', '100.3', '0'] Dec 08 22:24:07 : Error creating weather map Dec 08 22:24:38 : Error creating weather map Exception in thread Thread-2: Traceback (most recent call last): File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner self.run() File "/usr/lib/python3.9/threading.py", line 892, in run self._target(*self._args, **self._kwargs) File "/home/dietpi/nrsc5-dui/nrsc5-dui.py", line 985, in play self.parseFeedback(output) File "/home/dietpi/nrsc5-dui/nrsc5-dui.py", line 1458, in parseFeedback self.processTrafficMap(fileName) # proccess traffic map tile File "/home/dietpi/nrsc5-dui/nrsc5-dui.py", line 1176, in processTrafficMap imgTS = imgTS.resize((imgMap.size[0], imgMap.size[1]), Image.Resampling.LANCZOS) # resize it so it's proportional to the size of a traffic map (981 -> 600) File "/usr/lib/python3/dist-packages/PIL/Image.py", line 62, in getattr raise AttributeError(f"module '{name}' has no attribute '{name}'") AttributeError: module 'PIL.Image' has no attribute 'Resampling'

Once, pressing stop, then start caused nrsc5-dui to crash, another time it played again.

Using nrsc5 from the command line is much more reliable. One station that repeatably stopped paying after a few minutes ran for hours from the command line.

[markjfine]

@srs4511351 sounds like it could be a problem with your version of Python (I'm using 3.10) or something in the way fventuri's coding of nrsc5 that is vastly different than the original wrt to saving maps. Quite possibly the latter.

I should point out that nrsc5-dui is nothing more than a shell and precessor of what nrsc5 produces. If nrsc5 stops playing it has to do with something inside of nrsc5. That said, when you run it from a command line, you're likely not giving it the command to save maps to a folder like nrsc5-dui does. So if nrsc5 doesn't produce what nrsc5-dui expects in an image, you'll likely see trapping errors.

Have to also ask, when you built nrsc5, did you give it any architecture directives for SSE or NEON, or did you let it try to figure out which if any should be used? For example, I know on my Intel Mac I had to use the SSE directive, but on this new M1 I have to not use any directive.

[srs4511351]

I can check the version later tonight, but it would be the latest for Debian Bullseye. nrsc5-dui still stops playing when maps are not selected in Settings. All of the boxes there were deselected. I think the image error message was also present. With the original nrsc5 and the previous nrsc5-dui, the UI would slow down and appear to freeze for several seconds at a time but still played.

I specified NEON when I built nrsc5.

I should find the switches to save images from the command line and try it.

One annoying similarity with the original is a fluttering effect that sounds like a bad tape player (if you are an audiophile). There are issue tickets about this and argilo acknowledged that there is no buffering and should have. Here is a different post about that. https://github.com/theori-io/nrsc5/issues/177

[markjfine]

Again, nrsc5 is running in it's own process. All nrsc5-dui is doing is sending it commands and trying to process what it produces. If it's not the maps, it's the other images that a station sends, such as station logos and cover art. Either way, the error you showed seemed to relate to maps.

The reason why I keep pinging on this is because the whole point of this particular project was to isolate nrsc5 and specifically the audio generation from any python routines to avoid the problems you keep bringing up, and that nrsc5-GUI (not DUI) was doing.

[srs4511351]

I do not mean to be difficult. Sorry if you thought that. I assumed what you said without a further thought. I do realize that nrsc5-dui isn't the basic application that we are using, but something is different. I have never tried nrsc5-GUI, as I thought nrsc5-DUI was more advanced. I threw in the part about the fluttering effect hoping it would hint that the fventuri/nrsc5 version works a lot like the original. I got slightly carried away in detail.

I have Python 3.9.2 Is NEON appropriate for my arm64 CPU?

Although I am getting the map files, they do not appear is the Maps tab or the maps viewer. The art files do appear in the Album Art tab.

I tried the same command line that nrsc5-dui uses. /home/dietpi/nrsc5-sdrplay/build/src/nrsc5 --dump-aas-files /home/dietpi/nrsc5-dui/aas -l2 -A "Antenna A" 100.3 0

/home/dietpi/nrsc5-dui/aas fills up with jpg, png and txt files. They are album art, station art and maps. It hasn't crashed or frozen yet.

Could you verify that the Download Album Art and Include Station Art options work? Running under nrsc5-dui, it is downloading art files regardless of the settings.

P. S. I noticed that the error messages do not coincide with playback stopping. Playback stops minutes after they appear.

There are also these initial messages: (nrsc5-dui.py:5865): Gtk-WARNING **: 00:14:58.704: Theme parsing error: gtk.css:4:28: The style property GtkRange:slider-width is deprecated and shouldn't be used anymore. It will be removed in a future version

(nrsc5-dui.py:5865): Gtk-WARNING **: 00:14:58.704: Theme parsing error: gtk.css:5:28: The style property GtkRange:stepper-size is deprecated and shouldn't be used anymore. It will be removed in a future version ['/home/dietpi/nrsc5-sdrplay/build/src/nrsc5', '--dump-aas-files', '/home/dietpi/nrsc5-dui/aas', '-l2', '-A', '"Antenna A"', '100.3', '0']

[markjfine]

Some of this is already covered in the README...

Python 3.9 and 3.10 should be fine. I haven't tested with 3.11 yet.

nrsc5 will download any cover art and station logos that the station generates automatically into the aas folder. Any map images, if provided, go into the map folder, not aas, however defining text files will go into aas for some reason - this is a function of nrsc5 and nrsc5-dui is just displaying the images.

Sometimes the station doesn't provide album art, so the Download Album Art functionality was added to supplement this by doing a search at Musicbrainz. Depending upon your processor power and/or internet speed this may take some time and slow things down in the nrsc5-dui app, but it should never really impact nrsc5 itself. That is, unless it's impacting the processor that much. But yes, this feature works and was heavily tested a long time ago. If it's annoying you or creating a problem, recommend leaving them unchecked. For clarity: Download Album Art ignores station logos and album art provided by the station by default so Include Station Art was added to get both. Extended Queries does a deeper search in Musicbrainz, which may create additional delays as they process the query, but that will generally come up with a result if the regular setting doesn't.

I have no idea if NEON is appropriate for your processor or architecture, but the logical thing to do is to trying a clean cmake/build without any directives to see if the resulting nrsc5 is more efficient. As I mentioned, I'm running on an aarch M1 Mac and a NEON-build wouldn't work.

I can't help you with your gtk environment other than to say this app uses and expects GTK 3+, not just GTK 4. I get none of those warnings on either my Mac running the latest gtk3+ environment from homebrew, nor on my native Fedora 37 box. Both have gtk3+ and gtk4, and are using an Adwaita theme. All I get is a Cursor Theme warning on the Mac. If you're familiar with GTK, the warnings are annoying and may trigger a few OCDs, but mean absolutely nothing - especially the deprecation warnings.

[markjfine]

I might also add: When was the last time you pulled an updated nrsc5 and built it? You referenced a 3 year old issue with it that has been long since resolved. The latest revision extends it's ability to the full complement of 8 streams, per the nrsc5 spec, and I just updated nrsc5-dui accordingly. They are also in the process of adding some previously unsupported service modes and fixing a parametric stereo issue. I am working with them on both of these.

Bottom line is that nrsc5 is constantly changing as the current maintainer is tirelessly and aggressively working on it. As such, it should regularly be checked for updates by running git pull origin master --tags at the root of the code tree and doing a clean rebuild as necessary.

[srs4511351]

I am running nrsc5 revision 9696b56, pulled and built on 11/24/2022, so it is recent, but not with the really recent updates.

With the fventuri SDRplay version of nrsc5 and the most recent version of nrsc5-dui, I am getting map files in both the aas and map directories. With the somewhat current version of the original nrsc5, SDRplay thru the rsp_tcp server, I have the same problem. Initially, traffic maps appear in the maps directory. Then they disappear are in the aas directory. There are weather overlay images there too. This may start after the PIL / images message appears.

I tried an older version of nrsc5-dui. git checkout v2.1.1 With nrsc5-dui 2.1.1, maps initially appear in the aas directory, then appear to be moved to the maps directory under another name. There are no PIL / image error messages and the audio does not stop playing, just messages like MusicBrainz image list retrieval error for id 1dad6ba1-008b-4e2e-9724-31da48b06171. I do get album and station art. I do get maps in the maps tab and maps viewer. Still the same somewhat recent version of nrsc5 with SDRplay thru the rsp_tcp server. What's different? For me, it's the nrsc5-dui version. Switching back to the newest nrsc5-dui causes the problem to return.

As for the gtk deprication errors, I brought it up as they claim that a feature being used will be removed in a future version. It isn't a problem yet, but you say don't worry, so it's OK.

https://github.com/theori-io/nrsc5/issues/177 is still an open issue and I still have the fluttering problems. https://github.com/theori-io/nrsc5/issues/261 is more recent, seems to be related and is still open. Buffering issues. If the slight garbling and fluttering are the fault of my system, I need help with that. It has always been there for me.

[markjfine]

Absolutely no code regarding traffic or weather maps changed between 2.1.1 and 2.2.0. The images are initially staged in aas because that's where nrsc5 puts them. nrsc5-dui moves them to map after they are produced. Only the index files (TMI.txt, DWRI.txt) could possibly be left behind, but they are supposed to be deleted as well.

Traffic map images consist of a grid of 9 individual image tiles that are combined and then shrunk to size. Once the individual tiles are combined in the map directory they are deleted. So if they are getting left behind in aas, it may only appear to be moved back to aas.

Weather maps consist of a background image downloaded from the internet and the weather overlay provided from the station via nrsc5. Once the overlay is merged with a copy of the background map, the overlay file is deleted. If they are getting left behind in aas, like with the traffic maps, it may only appear as if they are being moved back.

In both cases the resulting image is sized, then overlaid with a date-time stamp.

It is not possible for any of the files to be moved from map to aas - there's no code to do it. Therefore, I can only guess there's a problem with not having enough memory to run 2.2.0. A significant amount of code and widgets were added to support the additional 4 streams that are part of the nrsc5 spec, and several stations are starting to implement more than just 4 streams.

As a result, Python's calling stack is likely getting crushed when you use 2.2.0 in concert with nrsc5, and the processing isn't progressing as expected - likely where the unusual errors are coming from, as well. Perhaps increasing memory (or swap space, if used) will solve the problem you are having.

[markjfine]

Check that... Image.LANCZOS was changed to Image.Resampling.LANCZOS in a few of places in order to squelch a Pillow deprecation warning that was annoying the hell out of me, but that's the only thing that changed in the map routines. You can try searching and removing the Resampling. part and see if anything changes, but I kinda doubt it.

[srs4511351]

I think I was a little confused, as it worked correctly until the error appeared. Maps stopped appearing in the map directory after the error occurred. Memory usage is 971M/7.58G. Swap usage is 0K/0K. None of the cores have over 15% load except for short peaks of over 30%.

Changing Image.Resampling.LANCZOS to Image.LANCZOS seems to have fixed the problem. It has played error free, way longer than it did before. I am now getting weather maps with weather on them, as well as traffic maps. The animation worked, but it went blank after a while and showed this error. MusicBrainz image list retrieval error for id fc422da5-df42-487c-801c-d4efbe33c098 Could it be that a new image was sent and it tried to show it before it was actually available?

Another time, after deleting all of the files in the aas and map folders, then running nrsc5-dui, I got this error, although the file was there. The GUI freezes. gi.repository.GLib.Error: g-file-error-quark: Failed to open file “/home/dietpi/nrsc5-dui/aas/22927_SLWNIC$$0110050000.png”: No such file or directory (4) When I restart nrsc5-dui with the image already there, it works. Was it called for before it was available?

Another thing I had to figure out is that if nrsc5-dui had been set to RTL-SDR and RTL_TCP was enabled, it will try RTL_TCP it even if you select SDRPlay, which does not show that feature. You have to switch back to RTL-SDR to disable it.

[markjfine]

You may be showing only 1 used out of 7.6G of memory, but how much is Python allocating to itself, and how much of that allocation is being used for graphics, widgets, or call stack? Just the fact that it's failing over time at all tells me either there's not enough allocated or you have a memory leak somewhere that's eating it up and crushing the call stack. Changing LANCZOS only alleviated some of the problem (you may be running an early version of Pillow), but it just delayed the inevitable somewhere else.

You should not have deleted everything in your aas folder. It contains all the station logos that are cached and indexed in stationLogos.json, which is why you got the error - it couldn't find what you deleted. Please delete the stationLogos.json so it can regenerate, to make the problem go away for other stations.

The MusicBrainz messages are only a status that no match for the given information was found, or the image specified doesn't exist in the correct format, etc. I use it for debugging queries to MusicBrainz, which has been known to be flaky. Ignore it. It's not important, and most of all, is contributing to your memory problem. I'd keep Download Album Art switched off anyway - it's not helping you.

As stated, if you want this (and other things) to work correctly, you should focus on your environment - particularly how Python is set up, as well as gtk3+. You are clearly running into memory boundaries, running things that aren't really expected to be run on minimalist systems such as Pi. The fact that Python or any interpretive/scripted language for that matter is running on only 7G of memory with other things running is a minor miracle.

[srs4511351]

After removing Resampling from Image.Resampling.LANCZOS, it no longer fails for images. I occasionally see the GUI slowing down and freezing over time, but I have no idea where to look for the problem. The results from the free command today show 6587868 available/5970744 free and that's the total system memory with nrsc5-dui running, python, web browsers, etc.

             total        used        free      shared  buff/cache   available

Mem: 7948744 1279344 5970744 94444 698656 6467828 Swap: 0 0 0

If we need to know specifics about python's memory management and current usage, it becomes difficult. Maybe you would like to know to help other Raspberry Pi users? What can be done to the python setup to improve memory allocations, and performance? It is all the system defaults, which are supposed to be good for this system.

On DietPi bullseye, where this is an issue, Pillow Version is 8.1.2 On DietPi bookworm, Pillow Version is 9.3.0 and if works just fine with Image.Resampling.LANCZOS. That suggests that it is related to the Pillow Version. Also bookworm is also running python 10.

The GTK errors are deprecation notices. The GTK setup is controlled by the package maintainers. I don't see any problems related to that. I have many other SDR GUI applications that work correctly.

[markjfine]

Ok, so I've added a test for the PIL version, and it now only uses Resampling.LANCZOS if v9 and above. Hopefully that's a compromise. Also filtered the RTL-only command switches from appearing on the command line meant for SDRPlay.

[srs4511351]

dragonbytes, I found out what fixed fventuri SDRplay constantly losing sync. When I set my Raspberry Pi CPU governor to Performance to keep it at full speed, it basically losing sync. Any more dropouts are probably reception issues. The current/original nrsc5 does not have this problem.

[srs4511351]

markjfine, Thanks for the updates for the older software versions. It helps a lot. Now I need to find out what is causing my very intermittent freezing of nrsc5-dui. Trying a different video driver and unchecking Download Album and Station art features don't fix it. I have had problems with it slowing and freezing for a long time under several OS versions. It's probably something to do with Raspberry Pi issues. Still plenty of RAM and disk space after a freeze, less than 10% average CPU load.

When I press ^C, I see this.
Traceback (most recent call last):
  File "/home/pi/nrsc5-dui/nrsc5-dui.py", line 2210, in 
    Gtk.main()
  File "/usr/lib/python3/dist-packages/gi/overrides/Gtk.py", line 1649, in main
    return _Gtk_main(*args, **kwargs)
  File "/usr/lib/python3.9/contextlib.py", line 124, in __exit__
    next(self.gen)
  File "/usr/lib/python3/dist-packages/gi/_ossighelper.py", line 237, in register_sigint_fallback
    signal.default_int_handler(signal.SIGINT, None)
KeyboardInterrupt

[markjfine]

That's Python telling you that you pressed Ctrl-C to create a SIGnal INTerrupt (not signals intelligence).

[srs4511351]

So, there is no clue as to the details of the frozen GUI.

[dragonbytes]

I apologize for being MIA. Finally had a chance to try out the SDRplay functionality. It didn't work at first until I removed the quote characters from around the "Antenna" parameter. I didn't realize that the quotes are only necessary from the command-line, but mess things up when sending arguments via PIPE. As long as the "Antenna x" is sent as a full discrete parameter (like through append), it works just fine. I love the new controls for SDRplay! Just be aware though that not all SDRplay models have multiple antenna inputs so including that parameter may mess things up on those models. Maybe you could have an option (thats also the default) called "Single" or "Auto" maybe, because when you dont specify -A, nrsc5 will autmoatically choose the first antenna port. Thanks for all your work!

[markjfine]

No problem. Not sure I understand the quote issue. I shouldn't wrap the string in quotes and just sending -A Antenna A is fine?

[markjfine]

Ok... Pushed a new thing that takes the quotes out and adds an Auto option that sends no -A switch (hopefully).

[srs4511351]

The SDRPlay Ant Auto setting does not send the antenna switch, just as expected. I have the SDRPlay RSP1A, which is a single SDR. The antenna selection does not seem to affect it when selected.

The SDRPlay gain parameter in nrsc5-dui for SDRPlay is not correct. If I try to enter 1.59, it only takes the "5" resulting in 1.5. The LNA state (RFGR) limits at 49, for example 49.6. The gain parameter in nrsc5 is SDRplay: LNAstate.IFGR (IFGR=0 -> AGC enabled) I think it would be appropriate to allow 2 digits for IFGR. SoapySDR reports: Full gain range: [0, 48] dB IFGR gain range: [20, 59] dB RFGR gain range: [0, 9] dB

gqrx, using the native SDRPlay driver has gain ranges for IFGR from -59 dB to -20 dB. RFGR is different. it goes from -61 dB to 0 dB.

There some clues here: https://www.sdrplay.com/docs/SDRplay_API_Specification_v3.08.pdf

Here are some nrsc5 examples that show the gain values printed on the terminal: ./nrsc5 -g 0.42 100.3 0 LNA state: 0 IF gain reduction: 42 IF AGC: 0

/nrsc5 -g 1.59 100.3 0 LNA state: 1 IF gain reduction: 59 IF AGC: 0

Unfortunately, nrsc5 takes values that are out of spec: ./nrsc5 -g 15.78 100.3 0 LNA state: 15 IF gain reduction: 77 IF AGC: 0

AGC works: ./nrsc5 -g 1.0 100.3 0 LNA state: 1 IF gain reduction: 50 IF AGC: 2

[dragonbytes]

the source for the SDRplay port of nrsc5 is on github, so if its just a matter of extracting a more precise number from the arguments and feeding it to the API, I may be able to update the C++ code to do that. if a deeper understanding of gain parameters and API configuration is necessery though to pass a more accurate value, that would be beyond my ability

[markjfine]

@srs4511351 If the version of NRSC5 doesn't properly interpret the gain value I'm giving it, or the user doesn't enter the gain value the way that version of NRSC5 expects it, then it's not a problem I can fix with nrsc5-dui. In fact, it's way out of scope for what nrsc5-dui does. Might I recommend that it's best to raise it as an issue with the NRSC5 developer rather than here.

[markjfine]

That said, if nrsc5-dui is adequately talking to (and working with) the SDRPlay version of nrsc5 per the original issue, can this issue be closed out? Would like some consensus from the SDRPlay users.

Additionally, would much rather that things regarding general use with SDRPlay and workarounds to any of that version of nrsc5's quirks that are not necessarily issues with nrsc5-dui be moved to a separate Discussion item, rather than continuing an open Issue, here.

[srs4511351]

The point is that we need 2 digits to the right of the decimal point in order to adequately specify gain to SDRPlay. There are already 2 digits available to the left. When AGC is specified on the command line (0.0), it gives IF gain reduction: 50 (2 digits, equivalent to 0.50). IFGR, being to the right of the decimal, point is limited to 1 digit by NRSC5-DUI. This should be accommodated by NRSC5-DUI by allowing 2 digits. This is not an NRSC5 issue, as 2 digits for IFGR is correct.

[markjfine]

"The point is that we need 2 digits to the right of the decimal point"

This was all I needed to know. The rest made it sound like there was a problem with nrsc5 that you wanted me to compensate for in the interface, which definitely would be beyond scope. I also don't have an SDRPlay, so all the other info trying to explain about LNA State and Gain Reduction just confused me.

I've pushed an update to address this. Please test to make sure it's correct. If so, I would like to know if the issue can now be closed.

[dragonbytes]

I'm fine with you closing it. I really appreciate you putting in the time to add support for SDRplay's unique parameters. Thank you!

[markjfine]

You're certainly welcome!

[srs4511351]

Sorry to confuse you by trying to justify my request. The information that I find on this is not clear. I don't always find that people are willing to accept my opinion at face value.

Thank you for making this feature rich program and taking care of these issues.

Near the top of my first post about this I said: The SDRPlay gain parameter in nrsc5-dui for SDRPlay is not correct. If I try to enter 1.59, it only takes the "5" resulting in 1.5. and a few lines later I said I think it would be appropriate to allow 2 digits for IFGR.

The NRSC5-DUI gain parameter always shows 2 digits to the right of the decimal point, leaving a training 0 for a single digit entry, for example 0.10. The command line parameter it issues is '-g', '0.1', which is what it should be. Do you think this is a problem? If you don't think it will confuse the user, then I'm good with closing this issue.