Don’t worry, I’ll let you know when this is properly fixed.
If your Intel i7 can’t handle 20 Msps without crashing, you should run volk_profile. My old dual core laptop easily handles 30 Msps at 10 FPS albeit with some audio crackles, but those are due to having a single thread for FFT and demodulation so I get some delays in sound (to be fixed later).
Meanwhile, I got FreeDV mode 1600 transmitter and receiver running, but FreeDV 700D is still a mystery and doesn’t work yet. I have a few more free days and hope to get it working before I tag 0.8.0-final.
1 Like
@adim - Adrian,
I took your suggestion and compiled and ran volk on my i5 laptop and the performance now at 30Msps is much better than before plus I am able to receive more of the HF band than I did before, but the gain is pretty low without having the ability to adjust PGA, TIA, and LNA gains for best operation. I have it running on the 40m band at the moment off my station antenna on receive and I’m hearing Hams ragchew when I’m running at 30Msps with the FFT of 131K - that provides the best view of the spectra for tuning. It would great to have more receive gain and some sort of transmit just so it can be beta’ed and worked on incrementally. Look - even if you tell me what part of the code has the most effect(s) on transmit I’ll work on it over here - I can make time for it.
Anyway - I’m still on what was on Github about 3 days ago. If there’s been any improvements since then for just the HF stuff (and non-FreeDV) I will be glad to check that out.
Keep me advised on the drops as you have them -
73 de Marty, KN0CK
1 Like
Marty, I think in the last 3 days I only got FreeDV modes working and the receive LPF widening to 20 MHz. I find 20 MHz is sufficient on the mini as more than that will just bring in lots of interference from FM, cellular and others. If it’s different on the big Lime let me know. For the TX LPF widening I have to test this myself thoroughly before I slip it in (if it’s not harmful).
Ed, I think I should give you a short description of how the free software world operates. I have “lived” in this world for the last 20 years so I think I know it well enough to describe it.
Generally, the software is released “As is”, without any guarantees it will work or not for you or that will cause or not gremlins to eat your computer. Whether you use it or not is entirely up to you. If you want to support the authors, you can do this financially, by sending hardware to work on, by testing it and submitting issues, by adding to the documentation or other small things which don’t require you to be an expert in software development. You should not feel guilty about not supporting a project at all, because you could never do your work without tons of very valuable (in terms of time, not money) software but you would never have the money or time to support them all (except if you are company and you build on free software, in which case it makes sense for other reasons to get in a good relationship with the developers and support them in more ways, because your business kinda depends on the project’s health).
Hence, free software operates towards the advancement of knowledge and technology and not towards material gains.
While donations are always good to keep a project alive, you never condition a donation on a particular feature, because that puts an expectation on developers to stick to a certain specification and deadlines and most user made specifications don’t have a clear and strict scope, therefore developers generally don’t engage in such contractual relationships unless they are very very well defined. Also, since this is free software, authors are free to work on whatever feature they feel like doing and ignore some requests that are not aligned to their interests. However, feature requests usually align with developers interests since they are users of their own software, they might just have their own priorities and schedule, in which case you can either wait or do it yourself since you have the source code available.
Please don’t take this as a lecture, just information that is good to know in this free software world which is somewhat different to what you may be used to.
Regards,
Adrian
1 Like
@adim - Adrian,
I pulled down the latest qradiolink from github and started the compile…I think there may be a dependency missing because there’s a compiler error now in the FreeDV:
…/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
How do I resolve this error? Can you let me know what the dependency issue is or do I have to recompile GNURadio? Let me know at your soonest - thanks.
73 de Marty, KN0CK
Oh yeah… I knew this would happen… In my quest for the latest FreeDV modes I bumped the required version of GNU radio to 3.7.13 which is what’s in Buster. I should probably add some ifdefs around that to keep the support for older GNU radio.
Does Ubuntu have some backports repos like Debian has? Maybe you can find GNU radio 3.7.13 in the backports there. You can also check out this commit from the next branch: bf8e4a8a32288ccdb991961166493a5ade840f53
This is from before I bumped the version of GNU radio.
Edit: use
$ git reset --hard bf8e4a8a32288ccdb991961166493a5ade840f53
to go back to that point in time.
1 Like
One other thing. Don’t try to transmit having selected any sample rate other than 1 Msps. It won’t work because the TX always uses 1 Msps to avoid wasting CPU cycles on resampling (and the two clock problem). You can hwever receive and transmit at different sample rates if you use two separate devices.
@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
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.
@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
@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
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.
@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
@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
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.
@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
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.
@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
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.
@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
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.