Announcing QRadioLink 0.8.0-alpha1

@adim - Adrian

I have all the dependencies installed and compiled the app fine this evening. However, I was unable to start the LimeSDR USB or the Lime Mini I have even when I set the receive and transmit settings in the ‘Setup’ tab like you’d expect for GNURadio (driver=lime, soapy=0). Woudn’t start the Lime at all (both of my Limes have the updated firmware to the currrent revision). So I fell back A LOT and installed an RTL-SDR and set the receive path in the ‘Setup’ to: rtl=0. Restarted the app and I was able to tune and listen to the FM radio band fine and some of the weather stations (162.475 MHz WXL71 in Cedar Rapids, Iowa). So the app works, it just isn’t working (or recognizing) the Lime(s).

Can you let me know the following setup syntax for receive and transmit for the following:

LimeSDR USB
Lime Mini
Red Pitaya
HackRF

I would like to see if I can get any (or all) of those working with the app. I don’t know what setup syntax for receive and transmit will be for all those SDRs that I have for testing.

Also, for the Red Pitaya, is there anything I need to do with the Ethernet setup to make it work? Please let me know on that, too.

I have my Linux Box and a Linux Laptop setup on your app and both work with a RTL-SDR.

Please advise at your soonest - thanks,

73 de Marty, KN0CK

Yep, so my best guess is you don’t have SoapyLMS7 and/or SoapySDR built into gr-osmosdr. This is kind of up to the distro maintainer to build support for what.
If you use SoapySDRUtil you should be able to see the Lime hardware. If you don’t see it, then you’re missing SoapyLMS7 and LimeSuite libraries. Guide for them is on this site’s wiki (sorry, quite busy right now with other things).
If you see it, then gr-osmosdr doesn’t have Soapy devices support, in which case you need to have SoapySDR, SoapyLMS7 and LimeSuite installed, complete with udev rules, and the compile gr-osmosdr manully. Cmake should find everything then.

`
adrian@xbcb43:~/$ SoapySDRUtil --find
######################################################

Soapy SDR – the SDR abstraction library

######################################################

Found device 0
addr = 24607:1027
driver = lime
label = LimeSDR Mini [USB 3.0] 1D35485DAAFDC2
media = USB 3.0
module = uLimeSDR
name = LimeSDR Mini
serial = 1D35485DAAFDC2

`

@adim - Adrian,

Here are a couple of shots when I use SoapySDRUtil --find. As you can see I have SoapySDR installed and SoapyLMS7 is also installed because prior to cloning the QRadiolink subdirectory and compiling the app I made sure the following LimeSDR dependencies were met:

sudo add-apt-repository -y ppa:myriadrf/drivers
sudo apt-get update
sudo apt-get install limesuite liblimesuite-dev limesuite-udev limesuite-images
sudo apt-get install soapysdr-tools soapysdr-module-lms7

So it’s all there…Here’s the picture to prove it:

…Also, here’s what the app screen looks like when it comes up and is in receive mode:

…and moments later it crashes, closes, and the following is the end of the report in terminal:

What I’ll try tonight is compiling gr-osmosdr and see if it changes anything - currently it’s just an install (sudo apt-get install gr-osmosdr).

From my earlier post, can you let me know the following setup syntax for receive and transmit for the following:

LimeSDR USB
Lime Mini
Red Pitaya
HackRF

I would like to see if I can get any (or all) of those working with the app. I don’t know what setup syntax for receive and transmit will be for all those SDRs that I have for testing. Also, for the Red Pitaya, is there anything I need to do with the Ethernet setup to make it work? Please let me know on that, too.

I’m trying to help with the testing, Adrian - making this app work with the LimeSDR will be groundbreaking because it’s what everyone has been waiting patiently for over 3 1/2 years.

73 de Marty, KN0CK

Yes, that looks like it’s coming from gr-osmosdr. You’ve got some audio issues too. Is Pulseaudio running?
The device name should be the same you use in Gqrx (soapy=0,driver=lime)
In fact, if you have no other devices plugged in you can just use soapy=0 and it will be detected just fine by gr-osmosdr.
I had a listen last night on HF (I’m not a big HF fan because of city noise floors and only a small indoor loop that’s good for receiving broadcast and KW operators).
There’s no NCO setting needed. However, it seems to work better at high sample rates (20 Msps) than at low sample rates. At 20 Msps I only need about half of the gain, otherwise I get swamped by commercial FM, cellular and other stuff. At 2 Msps I have to set gain to about 90% to hear anything. Broadcast at 7 Mhz is readable but quite small signal. I probably will never use this for HF but interesting nevertheless.

1 Like

@adim - Adrian,

I have Pulseaudio working - I was listening to both platforms playing last night switching the dongle from the desktop machine to the laptop and the audio is fine from the internal speakers.

I’ll fix the issue with the ‘soapy=0,driver=lime’ when I get home this evening - I do want to try the Lime on receive and then see how transmit works. Thanks for the info on the soapy=0 for other devices - that will help for Red Pitaya and HackRF. I’m assuming that the same arguments that are used in receive are also used in transmit, too? Please let me know on that.

If I already have the resources for Lime and Soapy installed (and they are there and working) then is it safe to assume that recompiling gr-osmosdr from source and then recompiling QRadiolink will resolve the issue I’m seeing? Again, I’ll try the soapy/driver arguments in the correct order and try it again, but if it’s a no-go then I’ll compile gr-osmosdr from source and install, then recompile QRadiolink to see if that straightens it out - more to follow on that.

Thanks for the reply back, Adrian - 73

de Marty, KN0CK

Most likely, a simple HF low pass filter will remove all of the VHF/UHF interferance.

Ed

1 Like

@adim - Adrian,

Okay - I have QRadiolink compiled correctly and with the correct versions of gr-osmosdr and SoapySDR along with LimeSuite. It took a few tries because the suggested gr-osmosdr for Ubuntu (Bionic) is actually NOT the version you want to install - somehow it was incompatible with QRadiolink and the Github version that everyone uses is the correct one to install (compile from source, install). I also hedged and installed the SoapySDR that is normally used with LimeSuite installs, compiled from source, installed and it was the correct one to use, too. Once I got all that straightened out, then I did a ‘make clean’ and recompiled QRadiolink, connected my LimeSDR USB, started the app, and within about 5 seconds I was listening to the FM band on the Lime - so that’s complete and working. I was also able to make it run on the Lime Mini, too.

The issue I see now is that there are no discrete gain settings that can be obtained for TIA, PGA, and LNA gain for the Lime - that’s kinda critical for HF use. Also, I think when you’re calibrating the receiver everytime it changes frequency you’re also adjusting the LPF and in this case - - at least for HF - - you can’t use a low LPF frequency. For HF you must use 130 MHz as the LPF frequency (effectively this opens up everything). SDRAngel had the same issue until that was understood and then the receive gain issue was also made to adjust all three settings (LNA, PGA, and TIA).

Is there any way you can tweak your code to leave the LPF in HF at 130 MHz and then, somehow, make the gain settings adjustable for LNA, PGA, and TIA gains? GQRX had that capability and so does GNU Radio Companion - that would help a lot in receive. I have transmitted in VHF and it appears to work fine, but I have not checked it in HF yet and need to do this later this evening. But the receive gain and LPF appear to be adjusted wrong because I know my Lime receives well in HF under SDRConsole, but it’s barely receiving anything in HF in QRadiolink. So getting the LPF and gain adjustments would take us a lot further down the road.

Let me know your thoughts on the above, Adrian - I’m finally getting somewhere with QRadiolink and think there’s great promise for the HUGE number of Hams that have waited for a more intuitive app that can work for the Lime from HF to SHF…Be the first to make that happen… :slight_smile:

73 de Marty, KN0CK

Hi Marty,
The gain stages are not a problem, I can add controls for them. Right now the automatic gain distribution by gr-osmosdr is used for simplicity. However, is seems like you have a strong use case for separate controls. But I need to come up with a simple and intuitive user interface control.
The LPF is different. I don’t understand why I need to open it up for HF? Normally the LPF 3 dB BW should be equal to the resampled rate / 2 (assuming taps are already stored in the FPGA)? Is the LPF not implemented on the FPGA? If the FPGA decimates by say a factor of 4 (arbitrary number chosen) and the FIR filter is wider than the desired output rate, you are going to have aliasing artefacts from the full band of the ADC. At least that is my understanding of it.

Do you have the annoying waterfall hang when you stop transmitting with your version of LimeSuite? Assuming that issue is not present in latest versions.

@adim - Adrian,

MANY THANKS for implementing the separate gain controls for the Lime receive. Again, I think you can follow what was done for GQRX and GNU Radio Companion to allow the LNA, PGA and TIA gains to be custom set by the operator - - SDRConsole and SDRAngel also implemented the same thing for their apps, they are all custom adjustable by the operator for all three gain settings. If you can add them to the GUI by a ‘if the LimeSDR is present, then apply the controls to the form’ kind of methodology then that would be great. Again, GQRX did just that same strategy for the Lime, too.

It’s weird. The LPF used with the LMS7002 - - at least for HF - - needs to be completely opened up to have decent receive in HF. SDRAngel uses a control to tune the LPF where ever you want and I always tune it to 130 MHz (which, again, opens up the HF so you can hear it). It will, as you’ve suggested, cause some aliasing to occur - - it does happen. Images from the FM band end up being mistaken for signals because the front end hardware filter is also opened up and allows those signals to enter the LM7002 right along with the signal of interest in the HF band. The fix for this, for us HF’ers that use the Lime, is to apply an external hardware Low Pass Filter that is specifically designed to contain from 2 - 30 MHz and strip anything above 35 MHz away. The aliasing will be completely gone and the Lime won’t suffer any issues because of it. So if there’s any way you can - - at least for sensing HF - - modify the LMS-7002’s LPF to run 130 MHz then it will allow GREAT receive in HF. Otherwise, we’re completely screwed if the LPF is anything other than that. I know this collides greatly with your wisdom on this, but - again - it’s the only way HF works for the LimeSDR. Anything other than that makes the Lime deaf on HF. Can you please open it up for us?

Let me know your thoughts on the above, Adrian - we’re really getting someplace with QRadiolink and I’d like to keep the momentum going.

73 de Marty, KN0CK

So, regarding the LPF. There are a couple of ways to do it.

  1. Hard code a special case based on device name and source frequency just for the LimeSDR.
  2. Go look at the real reason this is required, understand the problem and change it if required at the source, whether that’s in SoapyLMS, LimeSuite or elsewhere.

The first one is the easiest but IMHO it’s wrong.
The second one leads to an understanding of device specifics and if it is a bug will fix it properly for other applications as well.
The quick fix is desirable short term but can lead to ignoring the problem and missed potential for improvement long term.
Perhaps we can get a reply from someone who has more information as to why this is needed.

I’ll test the hack myself, and if it improves things I’ll push it in, but I won’t leave it there long term.

1 Like

@adim - Adrian,

I agree that it shouldn’t be there longer term and that a more elegant fix needs to be applied. But hard-coding it seems like the most easy/fastest way to see the results than making a change in SoapySDR that is more established and unchangeable. If you can push the hard-coded piece in - - JUST for the HF case - - then that will give me a way to check the receive along with the new controls (which would be GREAT). Longer term something else can be put in it’s place but this will confirm if this is the reason in QRadiolink that HF seems ‘deaf’.

Let me know your thoughts on the above, Adrian - and MANY THANKS. Let me know if a new version of QRadiolink is pushed to Github and I can check it out this evening when I get home from work.

73 de Marty, KN0CK

By the way.
Try pushing the sample rate to 20 Msps or 30 Msps. Reception last night was ok-ish for me as low as 7 MHz withthe mini and with my indoor loop. I swept my loop across the 7 MHz - 27 MHz range and could see the loop filter response clearly.
It’s going to use your CPU more, but this morning I made a few improvements that should make it less CPU demanding at low FPS. I didn’t know at that point the bandwidth setting was what killed my reception at low sample rate. Thanks for this info btw.

1 Like

@adim - Adrian,

Well…Pushing the sample rate to 20 Msps or higher just kills the QRadiolink app. I’ve actually never tried it above 6 Msps because the reception just gets SO SLOW and choppy that it’s unusable…And I’m running this on a Dell i5 laptop which blows the doors off SDRAngel and SDRConsole at higher sample rates. So I’m not sure what would make this so slow and choppy. If screen FPS plays a role in that please let me know. When I run 2 - 4 Msps it runs pretty decent.

All good on the bandwidth setting. It’s funny…When you start using a lot of the apps that are around, you start noticing the things about the LimeSDR that are quite different than other SDRs out there - especially how bandwidth and receive gain are designed. Nothing else like it, but then again, other SDRs don’t pack in these features that the Lime has either - they’re all external. So it’s a double-edged sword no matter how or which way you cut with it. I’ve been with this SDR the longest of any of them because the potential is so great with this SDR for the price point. There truly is no affordable SDR out there that does MIMO and has the bandwidth that the Lime has. It truly is a unique SDR, so it’s going to come at tricks others learn to know how to optimize it…And I’ve been around the block with this one for over 3 1/2 years since the very beginning, too.

Let me know when you have a code drop ready and I’ll be glad to compile it and put it through it’s paces, Adrian.

73 de Marty, KN0CK

I’ve just spent some time reading through the LMS7002 documentation. The chip is very complex and its capabilities are huge. I think we can’t use this chip with gr-osmosdr and expect to have good results with 10-15 API calls that are general to 10 other devices or so. Programming this chip is not a weekend job, it’s much more complex (given its uses outside of us playing with it as a toy).
I think the proper way to configure it is through LimeSuite. gr-osmosdr doesn’t cover all the possible settings that are required to have LMS7002 working properly. That explains why people use the LimeSuite API directly and don’t use other wrappers around it. Abstracting functionality like this means losing control and getting unexpected results.

I don’t recommend using the bandwidth hack. I’m not even sure if I should check it into Git. Trying to use it like this would be dangerous in that it won’t work properly and would generate strong spurious emission outside of the band.
Using QRadioLink with 10 dBm max out in ISM bands like 433 MHz is one thing, and using it to put Watts out on HF is a different thing. Don’t try that please.

@adim - Adrian,

I would agree that using gr-osmosdr for all the settings for the LimeSDR is a stretch, but I’m not asking for watts out of the Lime for HF…0dBm or less in transmit would be fine and you already do that on 70cm and use the same rule-set for receive and transmit. So it’s not like this is that big of a leap for receive to have a hack until there’s a more elegant solution in place longer term. Again, you’re doing the same things with the LM-7002 at 70 cm that it can do at HF, it’s just a matter of some readjustment to make it go there from what you have. Remember, even at 70cm you can have spurious that will go into public service bands if you stay on the course you’re on now. The risks are no different for HF.

Let me know your thoughts on that, Adrian -

73 de Marty, KN0CK

Adrian, might it be a good idea for to try out SDRAngel, to see how Eduard does it?
Then, with that knowledge, it may be easier to get it to work for HF.
My stuff is all packed for a move soon, so I will not be of help, till November.

My guess is that you developed this software, because you enjoy it.
I am not at all a coder & do not understand it at all, so cannot be of much help.
I donated a sizable amount to one developer to try to get him kick started on HF again (Had it working till a firmware update), but after a few months of me pestering, I was told it was “Pointless”.
I will tell you the same I told him.
$500 for a decent working software that also does HF & TX/RX/CAT inputs/outputs. Windows would be preferable, but I will go Linux if needed.

I have a mobile touchscreen computer that I gutted to install the Lime, Udoo X86 Ultra, Yaseu FT-857 PA/LPF/BPF board. Just needs software to be an HF-440 MHz ham radio.
I also have an old MAC G5 case with water cooled amps 1000-1500W HF-144 MHz & 600W for 440 MHz. It will have a LimeSDR-USB, also, with surplus parts to do the same frequencies.
Both are ready for just software & ready to go.
These have been a 2 year project for me & now just frustrate me.
Please consider my offer, as you seem like my last hope to get HF on the LimeSDR-USB.
THe last Developer just plain refuses & concentrates more on adding different colors of traces & other foo foo junk.

THank you for your consideration,

Ed
AA7QQ

Hi Marty,
I appreciate that, but the specs are pretty clear. There are two filters to be controlled: one is analog and one is digital (decimation filter probably). I don’t have enough granularity to control them. The resampling filter needs to follow the output sample rate to avoid aliasing. The analog filter seems to require a setting of 20 MHz. I need to be able to control them both, or perhaps let the digital filter be set automatically by the decimation rate and just change the analog one.
The SoapySDR API can indeed control them both as can gr-limesdr. I agree that the analog filter widening is not a big issue since you can band-pass externally, however the decimation filter if not set properly will introduce aliasing and will cause you reception or even worse your transmission to be affected adversely.
Regards,
Adi

Hi Ed,
It’s not a question of not wanting to do it, after all the LimeSDR is one of the few affordable SDR devices covering HF. It’s a question of doing it properly with an understanding of the implications. Right now this shortcut presents the risks of aliasing the transmitted signal within the 6 dB window of your external bandpass filter. And it might cause the same issue to occur when receiving. I’ll think of a long term solution. The Soapy sink sets the bandwidth automatically so perhaps that’s where it needs work.
Also $500 barely covers two days of my job so I can’t live on that, it’s going to stay a hobby for now so please be patient. I’m sure there’s a solution for this, it’s just not the one that is easily available. Keep that money for a better band pass filter HI.
73,
Adi YO8RZZ

The offer is just as an incentive. There are many others who will pitch in for a workable HF with the Lime.
I have more filters than you can shake a tree at.
I do fully understand that it is a hobby for you.
I just wish I could really help with pertinent information.
Marty is pretty much the more knowledgable people with the Lime.
I’ll sit back & cheerlead !

Ed

@adim - Adrian,

All good - it was a good try while it lasted. I appreciate your efforts and will now ‘go it alone’ to make this happen for HF.

73 de Marty, KN0CK