qradiolink does not compile with gnuradio-3.9

[cyberpunkrocker-zero]

Is it even supposed to work?

I'm trying to compile qradiolink-0.8.5-2 on Arch Linux, which uses gnuradio-3.9.
This is what I get:

 LC_ALL=C make
g++ -c -pipe -O2 -D_REENTRANT -Wall -Wextra -fPIC -DUSE_QT_AUDIO -DQT_NO_DEBUG -DQT_MULTIMEDIAWIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I../../qradiolink-0.8.5-2 -I. -I/usr/include/qt -I/usr/include/qt/QtMultimediaWidgets -I/usr/include/qt/QtMultimedia -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui -I/usr/include/qt/QtNetwork -I/usr/include/qt/QtCore -I. -I. -I/usr/lib/qt/mkspecs/linux-g++ -o main.o ../src/main.cpp
In file included from ../../qradiolink-0.8.5-2/src/gr_modem.h:36,
                 from ../../qradiolink-0.8.5-2/src/radiocontroller.h:46,
                 from ../src/main.cpp:33:
../../qradiolink-0.8.5-2/src/gr/gr_mod_base.h:33:10: fatal error: gnuradio/filter/rational_resampler_base.h: No such file or directory
   33 | #include <gnuradio/filter/rational_resampler_base.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:1687: main.o] Error 1

Gnuradio-3.9 doen not have 'rational_resampler_base.h', but instead 'rational_resampler.h'

Gnuradio-3.8 is nearing EOL, major distributions like Arch and Ubuntu have already upgraded to 3.9, 3.10 is already in development... I'd suggest that you should seriously consider updating qradiolink to be compatible with gnuradio-3.9

[kantooon]

Nope, it won't work, sorry. The fact is gnuradio is undergoing fast changes lately, and Qt is also deprecating some of their API very fast. The code will build right now on Debian Bullseye which is just released, but there's not been any work targeting a newer version of gnuradio.

[srs4511351]

Debian Bullseye still has GNU Radio 3.8, but software is starting to require 3.9. The end is in sight.
I have managed to get GNU Radio 3.9 installed on my Debian Bullseye system.
gqrx will compile with either version.
Can you make qradiolink work with both?

----Steve

[kantooon]

Which software is starting to require 3.9? AFAIK 3.9 is not yet in Bullseye, so it's not of great urgency to make the changes required for 3.9. What needs consideration is the fact that Debian testing will probably have different requirements for Qt, and since Qt is deprecating their own API relatively fast, there needs to be some sort of synchronization between a dependency on newer GNU radio and newer Qt to ensure Debian testing is well supported.
Don't worry though, an upgrade to 3.9 is planned, can't say how soon yet.
If anybody else thinks this should happen sooner rather than later then voice your opinion here so that I know how to prioritise.

[srs4511351]

I am using Debian Bullseye on my Raspberry Pi.
For me, there is no hurry. I may have to boot on the GNU Radio 3.9 system for special needs.
So far, the software that I have tried which requires GNU Radio 3.9 are fventuri/gr-osmosdr and fventuri/gr-sdrplay3 GNU Radio blocks on github.
The gr-osmosdr is the only thing that I have found that works with the SDRplay series and it's current api.
In order to build a system with GNU Radio 3.8 and SDRplay, I have to use an old version of fventuri/gr-osmosdr that I have saved from an earlier installation.
There probably are more that I haven't tried yet.
There are just as many that do not yet work with 3.9. We just need the time for them to all upgrade.
A difficult situation caused be GNU Radio.

Debian does have GNU Radio 3.9 packages, listed as experimental.
Here's how to do it:

Edit /etc/apt/sources.list
Add this line:
deb http://deb.debian.org/debian experimental main
sudo apt update

Install GNU Radio 3.9.2.0
sudo apt -t experimental install gnuradio gnuradio-dev

I think it is only experimental because it breaks the packages that are not compatible with 3.9
Other Debian OS do have 3.9, which breaks the older software.

I may experiment with Conda.
https://wiki.gnuradio.org/index.php/CondaInstall

[kantooon]

I'd be careful there with mixing packages from two debian distros. Experimental is not stable, and you risk that some GR dependencies which might b e pulled in by such an install breaking packages from your system if the system is based on stable (Bullseye).

The problem I have right now with a port to GR 3.9 is that my development system is Debian stable and to make the changes for the port (which I'm sure are pretty simple to do) I have to spin up VMs targeting that Debian version, which is time consuming.
If anybody wants to take a stab at porting to 3.9 which should be pretty straightforward, I can accomodate by creating a new branch in the repo that you can use to submit your pull request. Just be prepared for lots of Qt deprecations to happen.

[srs4511351]

What I did to be careful was to build a system with GNU Radio 3.9 on a different boot drive.
It works very well so far. It took Debian 2 years to release Bullseye with GR 3.8, so their packages are way behind. Other Linux distributions do have GR 3.9 in their releases.
I did have a package requisite conflict, so I had to manually specify the experimental version to match the installed package and that fixed it.

I want to experiment with Conda
https://wiki.gnuradio.org/index.php/CondaInstall
Conda is a cross-platform package manager (supporting Linux, macOS, and Windows) that makes it easy to install GNU Radio, its dependencies, and out-of-tree modules in a self-contained environment.
You can use it to install other versions of GNU Radio on your system.

I know that I spent many long hours trying to get a new enough version of Qt installed on my Bullseye system so I could try out qradiolink.

Since there are operating systems using GR 3.9 and others with GR 3.8, it would be a good idea to support both.

[kantooon]

Absolutely agree with moving forward to GR 3.9.

But before that, I'd need to know especially what mixture of Qt and GNU radio are distros providing, so I can set a target. Right now, most installed user base is on Ubuntu 21 and Debian Bullseye. Arch has been mentioned here as well, but I have no insights into their Qt versioning. The other dependencies (except maybe protobuf) have slower API and ABI movement so I don't think we need to be too concerned about them. However by moving all audio and video code towards Qt wrappers means I have to be careful about what Qt is changing. It's a tradeoff between the nice support for a lot of subsystems that Qt provides versus having to rewrite a lot of code when Qt deprecates their own API between versions, which they tend to do more and more frequently.

[alphafox02]

If you’re going to do all the work to upgrade, I’d suggest doing so with GNU Radio 3.10 as some of the developers said on Twitter that could be considered a version they provide longer term support for. I’m slowly building a new Pi image that has 20.04 with 3.10 from PPA and osmosdr from source.

edit: If you’d like to try the combo, have a look here. Username is Ubuntu password dragon. https://drive.google.com/file/d/1qU7cOZNXMQLcneMnqt7nOlz94Evl4Asx/view?usp=drivesdk

[alphafox02]

There’s a gentleman that’s taking time to convert all sorts of Gnuradio modules to 3.10 and higher. I’m going to ask if just the Gnuradio part of qradiolink could be rewritten while leaving everything else Qt related as is, that way maybe it can quickly run on 20.04 w/ GR 3.10 (maybe even 3.9?).. at least that my thoughts.

[kantooon]

Regretably, I won't be able to do any porting anytime soon. I'm currently very busy with a DMR implementation on LimeSDR hardware and other real life engagements.

[alphafox02]

No rush, I’m actually keeping qradiolink w/ 3.8 in my main project as it’s working nicely. I never had it on the Pi version, so I’m not as concerned about changing that build to GR 3.10. Look forward to seeing your other projects!

[kantooon]

I've pushed a new branch gr_3.10 which contains changes to enable build with gnuradio 3.10. This branch builds on Bookworm.
Note I've done nothing to support Qt6 yet.

[alphafox02]

22.04 is still on QT5 and I think will be for it’s lifetime (I think). I’ll give it a try!

[alphafox02]

Running on 22.04 w/ GR 3.10.4. Appears maybe it uses only soapy now and not gr-osmsodr? The rtlsdr worked fine but hackrf, although found, failed to start rx. Maybe due to me having the 2022 hackrf libs and firmware? I’ll try it on something else soapy related. Thanks for putting this branch up, so far so good!

[alphafox02]

I take back what I said about the hackrf. I didn’t realize the “find” button populated the drop down under device setup. Using the entry provided there and the hackrf and other SDRs I’ve plugged in so far works.

[srs4511351]

The latest gr-osmosdr module for SDRplay API 3.x only works for GNU Radio > 3.8 although the readme hints otherwise.
For GR 3.8, I have to use an older version that I archived when it was working on GR 3.8.
I can use what I believe to be gr-osmosdr with gqrx, which works with all of the devices that the GNU Radio 3.8 system had. I should double-check, though.

The latest HackRF driver requires a firmware update. I hope that doesn't wreck everything!

Will this be merged with the master branch eventually, allowing qradiolink to compile with GR 3.7 up?

I will try it when I get some time, maybe tonight.

[srs4511351]

I was able to get gradiolink to compile and run on a Debian bookworm system with GNU Radio 3.10 on my Raspberry Pi.
I had to add the package cppzmq-dev. Is it a new requirement?

When selecting my SDRplay device, I clicked Find and I thought it listed the gr-osmosdr devices.
After rebooting and running qradiolink again, clicking Find just added a new, duplicate set of SoapySDR devices to the list. A new set is added each time I click Find, the list growing longer and longer.
I manually entered sdrplay=0 and it used the rtl-sdr device.
For the TX device, it only listed SoapySDR devices, apparently twice. I manually entered hackrf=0, which was initially accepted, but after restarting qradiolink, it appeared as a soapy device. I did not try to transmit.

[kantooon]

Great! 3.8 will be supported and will remain the main release until at least Bookworm becomes the stable version. Regarding the ZMQ headers, it should only require libzmq3-dev which is listed as a dependency, but on the other hand my VM was a straight upgrade from Bullseye so maybe it's different on a new Bookworm system.

Regarding the bug in the device list dropdown where devices are added again each time you click find, I know about it, and it will be fixed. The code onyl detects devices exposed by SoapySDR and LimeSDR devices. To use an osmosdr device directly, not via Soapy, you have to manually enter the device string just as before, it will not be auto-detected.

[srs4511351]

Other applications such as gqrx automatically detect the gnuradio version, possibly at compile time, and will work with anything it supports.

When I entered anything in the device string, such as sdrplay=0, it always used the rtl-sdr.
I don’t think this is working correctly.

I never installed cppzmq-dev in earlier versions and didn’t notice it in the requirements then. That is why I asked if it is a new requirement. Maybe it was getting installed with other packages as a depency?

[srs4511351]

Looking back at my notes I should enter driver=sdrplay for device string.
I’ll try that next.

[kantooon]

libzmq5 and libzmq3-dev have been dependencies since 0.8.7, they are necessary for the MMDVM SDR operation mode. They are listed in the readme. However cppzmq-dev seems to be a new headers only deb which provides essentially the same functionality as libzmq3-dev but conflicts with it. This package is new in Bookworm and I don't know if I should replace libzmq3-dev in the README. For now libzmq3-dev will remain as a recommended dependency since it's present also on Bullseye.

[srs4511351]

I did a lot of experimentation with device strings and I think I have some useful information.
Entering a variety of device strings, including those found by gqrx, into RX device args were unsuccessful.
Manually entering a device string that is not on the pull-down menu defaults to the last soapy device selected or rtl-sdr. It will not be saved in the cfg file.
rtl=0 is the default device string from new installation/new cfg file. It seems to work, but is also not accepted after selecting a soapy device.

The device strings found by gqrx work when entered into rx_device_args in the cfg file. After running qradiolink, they are added to the pull-down list.
hwVer=255,sdrplay=0 works when entered into cfg file. However, there are 4 gain controls, the first and last are DAB_NOTCH and RF_NOTCH respectively.
gqrx finds the built-in/non-soapy devices. It must be possible to make a query to find these. qradiolink seems to be strict about the string syntax.

With 2 MHz Sample rate, there are occasional dropouts playing WFM. Similar with 4 MHz, frequent dropouts with 8 MHz. CPU load is higher than the soapy device when using the same sample rate, and the soapy device has no dropouts.

[kantooon]

You need to press Save after changing or entering a device string, otherwise the settings won't take effect.

[srs4511351]

I do press save. It has no effect unless the item is in the list. It doesn’t save strings that are typed in unless they match items in the list.
So my findings are as I stated in my previous message but I did press save each time.
The only time I was able to get a typed in string to be used by gradiolink was by entering it in the config file.

[kantooon]

You're absolutely right, that was a bug. I've found it and fixed it. Also scanning devices now won't add more duplicates to the list. Luckily this bug never made it into any release. Thanks for testing it!

[srs4511351]

Glad you were able to find it so quickly.

I noticed that sometimes a string is displayed in the terminal that can be used as a device string for a built in device. Apparently GNU Radio knows what these devices are. Is there a function to query it?
Otherwise it’s difficult to know what the exact device string should be.

[kantooon]

GNU Radio can't know anything about the device, gr-osmosdr might know, but only what the application tells it to use. Possibly you might be seeing the application log, the devices logged are the same as in the combo box in the UI. SoapySDR can scan devices, and LimeSDR can also be found by using the LimeSuite scanning code.
I'm not a fan of this device scanning code introduced this month but I've added it because some people complained about usability.

[kantooon]

As a side note, SoapySDR is pretty mature and I recommend using Soapy devices when possible, with the exception of MMDVM modes where due to specific features used for TDMA it's necessary to use the native Lime device and not go through Soapy which doesn't support tx_time tags.

[alphafox02]

@kantooon can you merge the above fix to the gr_3.10 branch? I was just applying manually now and going to rebuild and try as I was seeing the same happen. Would like to test the hackrf again.

[kantooon]

Done, it's merged now in gr_3.10

[alphafox02]

Applied and built. Maybe it’s just me, I can do a separate ticket if needed. The find/drop down sees the hackrf string. When selected, saved, and then rx button pushed I get fatal Count not init Rx device.

It appears that it’s trying to use soapy via gr-osmsodr. I can see in terminal it’s showing the gr-osmosdr version and the built in source types. String is soapy=0, device=HackRFOne, driver=hackrf etc etc.

I’ll keep messing with it.

[alphafox02]

So typing in hackrf=0 and then save now works. However if I do not do that first and instead take a fresh setup and click find the rtl=0 stays rtl=0, if that makes sense. Once changed to hackrf=0 and then saved, I can hit find and hackrf=0 stays.

So maybe still a small bug? And for whatever reason, hackrf=0 works with gr-osmsodr where as soapy via gr-osmosdr does not (for me with the hackrf at least).

[kantooon]

Split this to a new ticket please. It doesn't really have anything to do with the gnuradio version and likely affects branch next as well.

[alphafox02]

It’s user error. I just wiped the .config/qradiolink directory and started fresh. It appears I did not click save prior to pushing Rx. Sorry! So both soapy via gr-osmosdr which is what find finds and hackrf=0 works.

[kantooon]

no worries

[srs4511351]

I built the fixed gr_3.10 branch.
It works properly with the manually entered device strings and does not keep adding to the list when you click find.

Changing SDRplay Sample rate with SDR running, it crashed:
[FATAL] sdrplay_api_Update(Tuner_BwType) Error: sdrplay_api_NotInitialised
terminate reached from thread id: 7fa3ffe080Got std::runtime_error
sdrplay_api_Update(Tuner_BwType) Error: sdrplay_api_NotInitialised
0x7fb88dfc0c: (std::vector<gr::tag_t, std::allocatorgr::tag_t >* std::__do_uninit_fill_n<std::vector<gr::tag_t, std::allocatorgr::tag_t >, unsigned long, std::vector<gr::tag_t, std::allocatorgr::tag_t > >(std::vector<gr::tag_t, std::allocatorgr::tag_t >, unsigned long, std::vector<gr::tag_t, std::allocatorgr::tag_t > const&)+0xa3c)
0xb5ea16fc: -- error: unable to obtain symbol name for this frame
Segmentation fault

Apparently I need to be careful with this program.