Announcing QRadioLink 0.8.0-alpha1

#47

@adim - Adrian,

I had the prior version qradiolink in cold storage so I could fall back from the latest pull - so I’m back to square again and receiving with the release candidate R2. Does this release candidate R2 support transmit in HF? I guess I’ll try it here in an hour or so (currently on an HF net with my regular gear) and I’ll let you know my findings. I can put the transmit off my Lime into my Agilent spectrum analyzer and see how it goes.

When you do a major revision of the code that will affect other dependencies, please add that to the notes in Github so everyone that’s following along won’t have a broken compile and pester you with trivial stuff like this. I thought it had some bearing on GNURadio Companion but it also contained FreeDV in its own build so I thought it would be fine. If there’s a new (or updated) version of GNURadio Companion required for your builds going forward, then please let us know how to implement that. Anything you have to do to make your compile right has to affect us the same way - - otherwise all of us following your builds can’t verify your updates.

Let me know if the latest version of QRadiolink requires a new GNURadio to be compiled or how to make that change for FreeDV.

73 de Marty, KN0CK

#48

The “next” branch will always contain bleeding edge stuff and is expected to break things as stuff is added. Unless you want to test the latest code, please build from one of the tags (or the master branch). The latest tag I considered stable enough was 0.8.0-rc3.

#49

@adim - Adrian,

All good, but when you go to a release candidate 4 and consider it stable (and it has FreeDV) if there are any new dependencies or package updates required for that please edit your installation notes so the compile can happen without any errors.

73 de Marty, KN0CK

#50

@adim - Adrian,

I see in your latest version it has a lot of the newer features that I’ve been asking for but will likely crash the compile because of the newer FreeDV stuff for the GNU Radio that’s installed for Ubuntu. Mine is the latest version of GNU Radio Companion, but I know the compile is going to nosedive. Can you modify your build such that it won’t have the compiler issues I noted yesterday, or what do I need to do with the latest QRadiolink to make it compile right? I don’t think this is a dependency thing anymore as it is a difference between Buster (Debian) and Bionic (Ubuntu). Let me know - I’m anxious to try the latest version. Keep me advised at your soonest -

73 de Marty, KN0CK

#51

I’ve had some issues with the Travis job in the last days after upgrading it to use Buster as a base, but they’re now solved and I’ve tagged 0.8.0-2 which is also the main Debian package release. No more major changes will go into 0.8.0, only bug fixes if necessary.
As far as FreeDV is concerned, it requires libcodec2 version 0.8 or later. Mode 700D doesn’t work on Debian’s version of it, only 700C.
GNU radio 3.7.10 is still (semi) supported.

#52

@adim - Adrian,

I’ll go add that codec this evening and recompile the latest version of QRadiolink to see the differences. Can I assume that the 3.7.10 version of GRC is good enough to try with the latest QRadiolink build or do I need to remove that version of GRC and then reinstall 3.7.13? Let me know on that, too.

73 de Marty, KN0CK

#53

@adim - Adrian,

I added the libcodec2 (and it was version 0.8 which is the latest) and I still have a compiler error in the same spot:

…/gr/gr_mod_base.cpp: In constructor ‘gr_mod_base::gr_mod_base(QObject*, float, float, std::__cxx11::string, std::__cxx11::string, int)’:
…/gr/gr_mod_base.cpp:60:96: error: ‘MODE_700C’ is not a member of ‘gr::vocoder::freedv_api’
r_mod_freedv_sdr(125, 1000000, 1700, 2500, gr::vocoder::freedv_api::MODE_700C);
^~~~~~~~~
Makefile:1188: recipe for target ‘gr_mod_base.o’ failed
make: *** [gr_mod_base.o] Error 1

…So I hedged and thought that by pulling ‘codec2-dev’ from Subversion, compiling and installing might help me…it just made matters worse and now it fails the compile right out of the chute at main.o. What’s even worse is that I cannot remove what I installed. Doing a ‘sudo apt-get remove codec2-dev’ or a ‘sudo apt-get --purge remove codec2-dev’ didn’t help.

So at this point I’m pretty much forced to blow away and reload my 18.04 Bionic OS, build the support stack (dependencies for Lime, GNURadio, QRadiolink) and then reinstall QRadiolink from scratch.

If it’s at all possible, when you post a new function for your app, please identify ALL the dependencies that you used to compile your app such that those following your effort can have a clean compile, too. Doing an install for 0.8 version libcodec2 didn’t do the trick after I installed it and then did a complete ‘make clean’ recompile of QRadiolink. It just blew up in the same spot as before for FreeDV which leads be to believe there are other dependencies other than libcodec2 at play here that I didn’t have.

What say you, Adrian?

73 de Marty, KN0CK

#54

Woah there! Why would you blow away your Ubuntu? That’s some pretty drastic action.
Just remove your manually installed libraries and you should be good. I acknowledge that libcodec2 has no make uninstall target, that’s annoying but hardly fatal.
It’s no use installing a later libcodec2 if the GNU radio version has no support for it.
If you want to follow what’s happening on next branch, you have to be prepared for new dependencies coming over night and not even being mentioned in the README since it’s fluid. For example, I just pushed in support for USB relays to control antenna switches and amplifiers, that needs ftdi-dev.

Otherwise, if you want to have an easy life, just stick to a release version and its strict dependencies as that’s going to be much more cleaned up in general.

#55

@adim - Adrian,

Did that…I tried uninstalling the manual installation of codec2-dev (described in my prior message) and it would not uninstall but it affects the compile of Qradiolink somehow early in the compile. So I’m pretty much screwed…I’ll have to reload because I can’t uninstall codec2-dev.

My bottom line is this: I’m trying to use ANY application right now that I can add resources (AKA code) to control the LimeRFE (using their API and support files) and have receive and transmit running for HF to further characterize the LimeRFE for other digital modes (FT-8, PSK-31, etc). QRadiolink looked like the app of choice because SDRConsole is a closed development, SDRAngel uses duplex communications for completely independent receive transmit channels, and LinHPSDR isn’t developed enough for the Lime to even use. I’m banging my head against the wall trying to get QRadiolink set up to do this simple stuff. It would be incredibly cool if I could just get this from QRadiolink:

HF Transmit and Receive
Control of the LNA, PGA, TIA gain settings for the Lime
Access to the PTT functionality to add LimeRFE API calls to control its own transmit and receive (I can do this on my own)

Until that happens (for QRadiolink), I’m pretty much going to use SDRAngel and cobble something together to make it run on the 'RFE since it will TRULY run HF, has the gain settings independently, and I can add the RFE’s API calls to that codebase. Since I have to blow away my Bionic OS because I can’t clean-compile QRadioliink anymore and have to have that functionality I really need, then it just makes sense to focus by energy to SDRAngel and make it work with the 'RFE instead of giving that honor to QRadiolink because I blog and show this to those who really want to know and will use the apps I describe. That’s why SDRAngel is doing great with the Lime for a lot of Hams.

There it is in black and white…

73 de Marty, KN0CK

#56

Yeah, SDRAngel looks very cool. I’ve never tried it, perhaps I should give it a spin sometimes. It seems to have a very polished and professional UI, multiple modulators and demodulators and a bunch of other features that I’ll never implement in qradiolink. It even runs on Windows. However it seems to also have one big drawback, it doesn’t use GNU radio which is the most performant open source DSP library out there, short of using Octave directly.

Anyway, everything is a tradeoff, and at some point it’s a matter of preferences I guess. My focus is a robust VOIP layer, robust digital voice and to make the most use out of GNU radio. That’s why it’s great to have more than one alternative for everything, to suit everybody’s taste.

Edit: oh I just re-read your post there. So you’re trying to remove the manually compiled libcodec2 using apt-get? That’s not going to work. Apt-get is for distribution packages. Since it’s got no make uninstall target as of now, you have to remove the library and headers manually from /usr/local or wherever you specified in -DCMAKE_INSTALL_PREFIX and then run ldconfig again to update the cache.

#57

@adim - Adrian,

Okay - so I fixed the issue with the codec2-dev by removing it from /usr/local/include and I put a subdirectory up there called ‘codec2’ that your code expects to be there and installed the missing headers the compiler was whining about. Each time I had to do another ‘sudo ldconfig’ to set everything straight, and I was able to compile to the exact same spot as before and it blew up:

…/gr/gr_mod_base.cpp:71:100: error: ‘MODE_700C’ is not a member of ‘gr::vocoder::freedv_api’
r_mod_freedv_sdr(125, 1000000, 1700, 2500, gr::vocoder::freedv_api::MODE_700C, 0);
^~~~~~~~~
…/gr/gr_mod_base.cpp:79:100: error: ‘MODE_700C’ is not a member of ‘gr::vocoder::freedv_api’
r_mod_freedv_sdr(125, 1000000, 1700, 2500, gr::vocoder::freedv_api::MODE_700C, 1);
^~~~~~~~~
Makefile:1188: recipe for target ‘gr_mod_base.o’ failed
make: *** [gr_mod_base.o] Error 1

…and I have the latest libcodec2 installed but it’s still whining that 'MODE_700C is not a member of the gr::vocoder::freedv_api. Is this because I’m not using the latest GNU Radio Companion you are (I’m on 3.7.10 and you’re on 3.7.13). Is that the issue I’m fighting here, because I cannot compile past this point and I have to think this is because there’s a difference in the GRCs being used. GRC 3.7.13 must have ‘MODE_700C’ capability where 3.7.10 does not.

I’ve gotten this far without reloading my OS, so I’m willing to fight this a little more if you can let me know why I have that error when I compile. I was able to knock all the other ones out easily - it’s just down to this one for now. How would I go about loading a new GRC? Please let me know.

73 de Marty, KN0CK

#58

If you remove the /usr/local/include headers of Codec2 and reinstall the Ubuntu provided libcodec2, you won’t need to upgrade GNU radio to 3.7.13. This thing is because GNU radio itself links against libcodec2 and it expects it to be the right version.
So, again: GNU radio 3.7.13 with libcodec2 0.8, or 3.7.10 with the version of libcodec2 you had before and worked.
If the linker complains at the end, you probably need to remove the library form /usr/local/lib as well and update ld.so.cache

You can avoid a lot of this frustration by keeping a list of software manually installed in /usr/local. Some of them you can just go and do make uninstall, some of them you need to be more rude and rm them yourself.
Never manually build and install software directly into /usr, always into /usr/local.

#59

@adim - Adrian,

Performed all the steps you mentioned (removed the files and did a completely clean ldconfig) and even - - at one point - - completely uninstalled and reinstalled GNU Radio Companion for the 3.7.13 branch…Nothing. Still hits a wall at the same place in the compile.

So, I’m giving up. Until you have this in release state and it has all the things I’ve requested, I can’t make QRadiolink build in the bleeding edge. It still compiles fine release candidate 2 (rc2) but I cannot make the ‘next’ compile - it just hits that vocoder 700C set of steps and then it’s all over - compile stops.

Let us all know when there’s a release candidate available above rc2 and the documentation has all the info for dependencies and such…Then I’ll try it.

73 de Marty, KN0CK

#60

After careful consideration of options, there is no good way for me to oficially keep supporting older GNU radio versions.
I first tried to enable them at compile time based on what libcodec2 headers advertise. That broke in Marty’s case because he had a combination of newer libcodec2 and older GNU radio. Then I tried linking the FreeDV mode to the version of GNU radio present on the system. That would break if GNU radio was not built by the distribution maintainer with a new (>0.8) libcodec2.

So I gave up since there is no way for me to support all the possible combinations of libraries that a distribution might ship as default.
I’m leaving it up to maintainers which feature to enable or disable by patching the code.
By default, if you stick with the dependencies that are shown for Debian, the FreeDV mode (which is sort of a core feature) will work since I can test this myself.
I’ve since added in FreeDV 800XA which seems to be gaining some popularity. There is one outstanding bug which prevents me from adding mode 700D yet.

Using FreeDV with GNU radio wouldn’t be possible without the work of A. Maitland Bottoms who maintains this code.

#61

@adim - Adrian,

If this will provide some sort of help, here’s what SDRAngel does for FreeDV (but Edouard doesn’t use GNURadio as the basis for his code):

sudo apt-get -y install libspeexdsp-dev libsamplerate0-dev
cd /opt/build
git clone https://github.com/drowe67/codec2.git
cd codec2
git reset --hard 76a20416d715ee06f8b36a9953506876689a3bd2
mkdir build_linux; cd build_linux
cmake -Wno-dev -DCMAKE_INSTALL_PREFIX=/opt/install/codec2 ..
make -j $(nproc) install

For what it’s worth…And - for now - I’m back using SDRAngel until this can get sorted out and documented in a way that it compiles clean for Qradiolink.

73 de Marty, KN0CK

#62

Marty, thank you for the suggestion. That is of course one way of doing things, and it works. But unfortunately it tends to lead to more fragmentation instead of less, and towards “maintaining” in a certain sense several upstream dependencies. I have done this in the past, and it is not sustainable long term for a project with limited manpower. I will not pursue this path, and instead I will try to work towards including the software in packages for Linux distributions, which should trickle eventually downstream to users.

There is nothing wrong with building software for your own use from source. I have been a user of both Slackware and Gentoo in the past, where such a thing is common. It is indeed necessary up until a certain stage in developement where code quality reaches a good enough level to match the QA requirements of a distribution. But it is not desirable from a maintainers point of view.

#63

@adim - Adrian,

There is one other way you can do this that you have complete control and no one has to compile the code…Make the QRadiolink app a ‘Docker-ized’ image and let the masses install it that way. Then everyone gets the same results because it’s from your Docker image. SDRAngel is distributed that way, too.

73 de Marty, KN0CK

#64

Marty, yes, that could be a way forward, even if only for short term. Perhaps Docker is a little overkill, perhaps app-image or similar. I’ll look into it.
Anyway, some steps I took recently make it just a little more probable for a Windows port to exist in the future.

1 Like
#65

How about a snap? E.g. for Gqrx the config is:

#66

Andrew, that’s also a valid way forward. My problem currently is that my dev laptop is an old 32 bit system so I can’t use that to build packages and can’t/won’t upgrade or use my other hardware for different reasons (lack of time for new install mainly).

I’d like to set up a virtualized environment (perhaps Jenkins/Travis powered) for CI builds and an automated QA suite. Right now Travis CI only checks succesful build and deploys Debian archives if a new Git tag is detected. Any QA engineers with expertise in automating tests for user facing programs can chime in with ideas if they want.

I’m also working a bit behind the scene towards getting the package included in mainline Debian so this could trickle downstream to other distros based on it. But good QA is paramount for that. I don’t like buggy packages in my stable system and neither should anyone.

Cheers,
Adrian