New VirtualBox VDIs are up on my Google account and CAN be pulled for your own use with the following links. These are PREFAB VDIs that you can import into VirtualBox that will allow you to run native HF to SHF tuning on the LimeSDR using GQRX and have been fully tested and are KNOWN WORKING. Here are those links:
These Zip File archives are large - about 2.5GB per distro, but when they expand on your HD where the VDIs are stored, they are capable of 8GB of drive space to allow more apps to be loaded on along with LimeSDR and GQRX - those are PRE-INSTALLED AND KNOWN WORKINGā¦!
Again these are zipped VDIs. All you need to do is unzip the archive, move the entire folder into the same subdirectory that VirtualBox stores its VDIs and then use VirtualBox to import those VDIs and youāre done. Just launch VirtualBox and double-click the appropriate distro made for LimeSDR and then allow it to launch. The username is already set for both, but the password for both is: LimeSDR Just type LimeSDR into the password box when the distro launches. From there, find the small USB symbol in the VirtualBox control panel, right click on it and click on the LimeMicrosystems entry in the list. Open a terminal session, type: SoapySDRUtil --find and then press the Enter key. Allow the application to see if the LimeSDR is present, if it is, then type: gqrx at the command line to launch GQRX. If it comes up with a pop-up box, just enter 1500000 into the āInput Rateā entry in the form and click OK. From there, click the 1/0 button at the top left of the GQRX window and watch your LimeSDR play on Ubuntu or Lubuntu Linux from a Windows desktopā¦!
Again, there are RECENTLY updated VDIs for the LimeSDR that will NATIVELY TUNE HF to SHF.
I will continue to update these VDIs as more features are added - Stay tunedā¦!
As it turns out, my problem has to do with some changes we made to Gqrx since the 2.5.3 release. The 2.5.3 release is working fine while the latest code from git causes the driver to throw an exception. I will have to figure it out with @joshblum whether it is gqrx or the driver that does something bad.
In any case, I will hold back the gqrx 2.6 release until this is resolved.
One other question, which antenna connector are you using? I tried LNA_W because as I understand it doesnāt have any matching, but it seemed quite deaf compared to other shortwave SDR receivers I have.
Iām using the LNAH port on the āstockā LimeSDR as they provided us from Lime Microsystems. Seems to be MUCH better than LNAW and even LNAL. So please switch your U.FL connector over to LNAH and give it a spin.
Also, did Josh alert you to the issue I had with the tuning below 7.0 MHz? If not, please check in with Josh about that, tooā¦or send me a private message so I can give you more details.
Indeed, LNAH seems to give the best signals! Still 20-30 dB weaker than what I am used to but that can be explained by the matching, I think. Thanks for the pointers Marty.
The crash is the uncaught exception for the tune function going out of range. @csete Is this something gqrx isnt catching, or should be catching. I can also imagine that the tune function just clips to the nearest possible frequency as does not throw. What do you think/what is the assumption for gqrx tuning and throwing?
So why are we out of range? The sample rate is 1.5 Msps, I suspect to get that low, the half band chain is completely in use and the clock rate/ADC clock is also very low. Too low in fact to give the cordic the range we need to tune any lower. In the case of 1.5 Msps, the ADC rate is 48 MHz (which means +/-24 MHz). Technically we can tune as low as but not including 6 MHz with this config. Using a sample rate of 3 Msps, gives us +/- 48 MHz which covers the gap for 30 MHz we need out of the CORDIC. So the solution is to use the LMS7 RFIC at a higher sample rate. And since there is no further, decimating in the FPGA the host has operate on a higher sample rate as well.
It would be really ideal to be able to tune from 500.0 kHz to 30.0 MHz for the HF band if at all possible. We can live with 2.0 MHz and up and that would bypass the 160m band, but most stock SDRs (except RTL-SDR) have the capability to tune 500 kHz to 30 MHz for the HF part of the spectra.
Keep me advised, but thatās what Iām seeing too - at 5.9 MHz GQRX locks up.
In regards to the lockup/crash, its something that should be more elegantly handled either in LimeSuite or in GQRX. We can figure that out one way or the other. But you should be able to get the full tune range with any rate over 1.875 Msps. So 2 Msps will get to below 500 kHz.
To simultaneously receive at a 1.5 Msps rate and to tune below 500 kHz, we need to implement some additional decimation outside of the LMS7 ā to make the numbers work out. This could be in the FPGA, LimeSuite driver, or in a host app. Its definitely an achievable goal, and there is more than one way to handle this.
There is practically no exception handling in gqrx. The general assumption in gqrx is that setting a parameter within its valid range is always successful. So far I got away with this assumption.
There have been a few changes that affect how input sources are initialized and it is probably one or more of these changes that trig the problem. I have tried reverting some of the commits that I suspected but no luck so far.
I can try to add some exception handling during initialization but I donāt think I want to put all runtime tuning requests inside try-catch blocks. Some hardware tune almost instantly and it would be a shame to slow them down with exception handling code.
Clipping it is. I just added the change to clip the value to the maximum (other devices work this way anyhow, and it matches the RF tuning which also clips).
Exceptions? Probably worth catching. Crashing vs error messages can make a huge difference for debugging problems. I do have sympathy for how ugly try/catches can get. :-/
Sorry for the slight delay - Just confirming that 2.0Msps DOES in fact allow the LimeSDR to tune well below the 160m Amateur Radio band. I need to confirm operation once propagation is good - day time is not ideal for testing low band, so Iāll check it out this evening - stay tuned,
The LIMESDR can tune to 100 kHz, but Iāve been ātalkingā 500 kHzā¦that is not the lowest frequency the LimeSDR can tune, though. you are correct that the Input Sampling Rate for GQRX has an effect on what the lowest tuned frequency will be. I just checked out the 160m, 80, and 75m bands this evening and itās working good - albeit with the matching networks on my pre-delivery LimeSDR where the matching networks are not optimized, but still usable in those lower bands.
Just tested by LimeSDR in the 160m, 80m and 75m bands this evening, as well as the 49m SWL band and operationally good. Matching networks on my āpre-deliveryā LimeSDR are not optimal (could use some gain - but I know these matching networks work better above 10 MHz), but I am tuning there and hearing stations operating on those bands using GQRX with a 2.0Msps input rate - - so all is well.
Thanks again for setting me straight on that, Josh,
