Lime Unable to be Found After Use in GNU-Radio

Hello All,

I was hoping someone could help shed some light on why my LimeSDR becomes unfindable after use in GNURadio or osmocom’s command line tests. The command line test has been easier to get reproducible results. After calling osmocom_fft -s 8e6 -a “driver=lime,device=0” I do get the spectral plot, but changing the sampling rate results in an error [Error] BEGIN DATA READING LIBUSB_ERROR_NO_DEVICE. Attempting to run commands SoapySDRUtil –find or LimeUtil –find then continue to return no results, even after disconnecting and reconnecting the SDR to the computer. A restart of the computer solves the problem, so that has me thinking that a driver must be silently crashing on the computer.

I can reproduce the problem by starting at a sampling rate of 8MSPS and increasing to 10MSPS, or by starting at 10MSPS, decreasing to 8MSPS and then increasing again to 10MSPS.

I’m running Ubuntu 17.10 and I followed the instillation procedures for on the Lime Suite Quickstart Tutorial and then installed gr-osmosdr using sudo apt-get install gr-osmosdr. I had gnu radio installed prior.

I’m still fairly new to this hardware so any help on further troubleshooting or solutions would be greatly appreciated. Thank you.

I’ll chime in here as I was looking for solutions to what I believe is an identical (or at least similar) problem.

I have my LimeSDR working perfectly on a laptop running Ubuntu 16.04 and am setting up a second laptop that is more convenient to fly with. Following all of the setup procedures I used with the first, I have installed the packages for LimeSuite, SoapySDR, and GNURadio. I built gr-osmosdr from source, and the appropriate GNURadio support was built and installed.

Now for the fun part:

I can successfully run LimeUtil --find and SoapySDRUtil --find=“driver=lime” and locate the LimeSDR. Once I have attempted to connect to the unit using GNURadio, LimeSuiteGUI, LimeUtil, or SoapySDRUtil (The latter three can discover it correctly) I am greeted with:

[WARNING] Gateware version mismatch!
Expected gateware version 2, revision12
But found version 0, revision 0

At this point, the LimeSDR hardware can no longer be discovered using a --find command or via the LimeSuite GUI. The OpenMoko device no longer shows up after running lsusb, and no attempts to find the board are successful. The hardware LEDs seem to indicate that it is functioning correctly. Rebooting the machine allows the hardware to be discovered until a connection attempt is made at which point it disappears again.

I initially thought this was an issue with SoapySDR dependencies, but LimeUtil returns the same error. At this point, given that the board works fine with the other laptop, I am operating under the assumption that this is a Linux/laptop hardware problem. Jumping down that rabbit hole on other forums has yet to produce any results.

Any thoughts?

Thanks in advance!

-Brendan

My guess is that the power supply is browning out and causing the board to crash. We’ve seen this with bad cables and when using USB 2.0, which won’t really deliver sufficient current.

@Squill, could be that changing settings is somehow triggering this.

@Zack, any thoughts on this?

Hi Andrew,

FWIW, I get similar problems with the mini and USB 2.0. Frequent repeated messages of:
�[1m�[31m[ERROR] TRANSFER ERROR�[0m

Interesting. That uses a completely different USB controller. Perhaps there is a problem with current version of Lime Suite. What triggers this for you?

I wish I could say there’s a usage pattern that triggers it. To me it seems almost random, but when I get these errors in the console the FFT goes crazy and I have to destroy and recreate the Osmocom source. Sometimes it cures it, sometimes not. Maybe it’s not a coincidence that I’ve never seen this when plugged directly into the USB3 port, without a cable.

@andrewback The browning out is an interesting idea. I went ahead and tried running the SDR from the USB 3.0 ports directly on my computers motherboard as opposed to the front panel 3.0 ports which I picked up after the fact for cheap and could have been the issue. But repeating the osmosdr_fft test yielded the same results. I’d be surprised if my computer was under powering it’s native usb ports. I could go further and try and power the LimeSDR from an external power source if you still think that’s the most likely cause.

@adim Regarding your problem, I suspect that the error you’re seeing is caused by the slower transfer speed of USB 2.0. Someone with more understanding that my might be able to correct me but my guess would be that packets are being dropped due to the slow bus speed. In the documents for the LimeSDR it suggests that a USB 3.0 port is required. This theory is backed up by your test that the error doesn’t show up when running on a USB3 port. Trying my SDR on a USB 2.0 port running osmocom_fft -s 20e6 -a “driver=lime,device=0” (sample rate of 20MSPS) results in errors of Rx pktLoss: ts diff: 3060 pktLoss: 2. This doesn’t match your error exactly, but it’s probably the same root problem.

Indeed, I suspect the cable is the problem here. Couldn’t reproduce when plugged in directly into an USB3.0 port.