I was able to narrow the gateware-problem which in my case gives me a gateware mismatch every 2nd initialisation of libLimesuite. For example if I want to run the Limesuite example-program “singleRX”
I extracted the core USB-calls out of Limesuite which are called to get the gateware-version.
The following two LMS-Commands are sent to the USB-Driver (of course with the corresponding read-backs):
CMD_USB_FIFO_RST (libusb_control_transfer)
CMD_BRDSPI_RD (libusb_bulk_transfer)
I wrote a simple C++ program which calls those commands, surrounded with a proper initialisation and closing of the USB-port.
With the CMD_USB_FIFO_RST-Command, every 2nd run of the program, the call to CMD_BDRSPI_RD ends in a timeout (independent of the timeout value)
NOW, if I omit the CMD_USB_FIFO_RST-Command, everything works as expected and the gateware can be read on every program run.
BTW: All the Python examples from pyLMS7002M are working fine and they do no include a CMD_USB_FIFO_RST-Command
Any ideas what the CMD_USB_FIFO_RST-command does exactly and why it is called in Limesuite, but not in pyLMS7002M?
Checking further I noticed some strange behavior (current from the power supply, status leds, this didn’t make sense depending on what was actually plugged) and found out that I had some faulty cabling along the way … So I rebuild a proper jack power cable (now that I have space to actually plug the power jack), and it’s been a week without any error. So a proper power supply might, indeed, make everything perfectly stable as far as gateware is concerned. Lets not draw any conclusion yet, and wait for a few more weeks before stating the issue is solved on my side.
Just to make sure - do you have a possibility to check if the problem persists when using “Y” split cable plugged into USB 3.0 port (main plug) and USB 2.0/3.0 port (additional power plug)?
Yeah, this still happens to me. It’s really annoying and it’s something that is not supposed to happen. So far I’ve not seen anyone from the team trying to fix the issue.
I experience these same symptoms with latest firmware, gateware, and drivers, and I am powering the LimeSDR with an external power supply (set at 9V, capable of 2A), and have it plugged into a USB3 port. Also happens when plugged into USB2 port. So, I’m not convinced this is a power related issue. I’m watching this thread with great interest as this issue has been preventing me from really putting the LimeSDR board to use as a viable alternative to our Ettus USRPs, and holding me back from being able to recommend to other colleagues that we order LimeSDR’s instead of Ettus USRPs in future. Obviously I would dearly like to be able to switch as the cost difference is compelling and really widens the number of applications we can apply SDR too.
As I told some time ago, we are not able to reproduce such a behavior in our lab. Hence a detail description of the setup (photos would be great too) and a description of when it happens would be much appreciated.
so far I’ve only tried the LimeSDR on my work PC running Mint 18.2, with a PCIe USB3.0 adapter card. Although, as I’ve already noted, there are similar issues when using the motherboards native USB2.0 ports. However, I don’t think this is a hardware or low level driver problem as so far, whenever I run LimeSuiteGUI I can always connect suv=ccessfully with the board, on both USB2.0 and USB3.0 ports. I can also run the Quick Start tests and leave the FFT running for quite some time and the Rx Stream seems to run happily enough, reaching 92MB/s for high sample rates. All my issues occur when I try using an SDR app (e.g gr-osmoscom, or SDRAngel, GQRX) or even the simple single file C example, such as the 'C_API_Example.c" (https://github.com/pothosware/SoapySDR/wiki/C_API_Example), that interfaces to the LimeSDR via the SoapySDR middleware layer.
If there is any specific diagnostic test or information that you’d like me to provide please let me know.
A small update for my case (gateware mismatch every 2nd initialisation of libLimesuite)
I can confirm the limesdr works on different machines as expected.
The machine which gives me headaches is a “AMD Ryzen 7 1700” on a “X370 GAMING PRO CARBON (MS-7A32)” Motherboard.
Connecting the lime through a USB 2.0 Hub on any of the USB 3.1-Ports on any OS works fine. Although multiple times it was stated, the limesdr doesn’t get enough power. I can run gqrx, but the bandwith is limited to around 10mhz.
Connecting the lime directly to any USB 3.1-Ports fails on the latest liveCD of “Linux Mint”, “Ubuntu 17.10” “CentOS” “Fedora”
BUT
I got it to work with the pure debian liveCD on one specific Port, the only USB 3.1 GEN 2 Port with a ASMedia ® ASM2142 chipset on the mainboard.
Anyone have an idea, what is so special on the debian-distribution?
Or is there anyone who sucessfully uses a similar motherboard together with the limesdr?
The difference is in the kernel-configuration.
Debian runs in the SLAB-memory-configuration, while the other runs with SLUB.
Building my kernel in the SLAB-configuration, makes the problem disappear.
So somehow a memory-allocation-problem seems to bee the root-cause. But where?
I have no idea on how to proceed now, but I think i will have a look at the chipset drivers, or even try with an adaptercard.
I my case, V2 Rev 12 did not solve the problem.
Also a new PCIe- USB3-Card which uses a different chipset
(NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI]))
made no difference.
Hopefully the latest gateware helps some of the others.
I’ve just updated LimeSuite and the FPGA binaries to v12 and I’m still having the gateware mismatch problem every second time I execute a SoapySDR based application, or LimeSuiteGUI->Options->Connection Settings->Connect (LimeSDR-USB [USB 3.0]).
As mentioned previously, I’m running with Linux Mint 18.2 64-bit, and I’m also using a PCIe NEC Corp (chipset) USB3 card. The LimeSDR is powered by an external 9V, 2A DC source.
Doing exactly the same but connected to the USB2.0 port (LimeSDR externally powered) now seems to be reliable, with no reported gateware mis-matches.
Let me know if I can collect or provide any further info that may help.
