Gateware mismatch only every other time i run LimeSuiteGUI, and only works in sdr software every other time I run it

I am having a some wierd quirks, most of wich are resolvable, but kind of annoying.

When first powered on, i am unable to activate it through sdr console, hdsdr, etc.
Solution is to start LimeSuiteGUI, connect to the LimeSDR, click on default, and then quit LimeSuite before attempting to run sdr console or hdsdr or sdrangel or whatnot.

However, if I quit the software, and then start it again, it will fail to activate the sdr again. Have to unplug it, plug it back in, and run my “solution” steps again.

I have not tried transmitting with any other software then sdr console, so I dont know if this behaviour is the same for other software, but with sdr console, if i’m recieving, then transmit, it will not start receving again after transmission ends, and thus after each transmit I will have to run through my “solution” steps once again. Wich makes it somewhat useless for DXing.

I belive both of these issues stems from the same problem.

When I run LimeSuiteGUI after sdr boot, and connect, all is good and I get this:
[23:52:54] INFO: Disconnected control port
[23:53:17] INFO: Reference clock 30.72 MHz
[23:53:17] INFO: Connected Control port: LimeSDR-USB FW:4 HW:4 Protocol:1 GW:2.23 Ref Clk: 30.72 MHz

If i then quit LimeSuite, only to start it again, and reconnect I get this:
[23:54:03] INFO: Disconnected control port
[23:54:10] ERROR: TransferPacket: Read failed (ret=0)
[23:54:10] WARNING: Gateware version mismatch!
Expected gateware version 2, revision 23
But found version 0, revision 0
Follow the FW and FPGA upgrade instructions:
Or run update on the command line: LimeUtil --update

[23:54:10] INFO: Reference clock 10.00 MHz
[23:54:10] INFO: Connected Control port: LimeSDR-USB FW:4 HW:0 Protocol:1 GW:0.0 Ref Clk: 10.00 MHz

If I then quit LimeSuite, and restart it and reconnect, all is well again.

So basiclly it appears that every other time the sdr is activated, it will “fail” and show gateware version 0, rev 0, and every other it will show the correct GW version.

I also see that it detects HW version correct every other time, and it shows different refclk every other time. (30.72Mhz/10.00MHz)

Its also the same if i run “limeutil --update”:
limeutil --update
Connected to [LimeSDR-USB [USB 3.0] 9083401882019]
Existing firmware is same as update (4)
Existing gateware is same as update (2.23)
Firmware and Gateware update is not required.

Programming update complete!

and then same command right away after the first:
limeutil --update
Connected to [LimeSDR-USB [USB 3.0] 9083401882019]
TransferPacket: Read failed (ret=0)
Gateware version mismatch!
Expected gateware version 2, revision 23
But found version 0, revision 0
Follow the FW and FPGA upgrade instructions:
Or run update on the command line: LimeUtil --update

Existing firmware is same as update (4)
Existing gateware is same as update (2.23)
Firmware and Gateware update is not required.

So again, every other time.

Please advice:D

Other then that I love the SDR, I bought it mostly for HF use. And instead of modifying the board, I’m using a 125M+ upconverter, wich works perfectly.
I might remove the T3 cap as well, as I am under the impression that will be benefitial not only for HF, but also for the freq’s recived using my upconverter.
I’ve also ordered some pass band filters.
My goal is to create a HF tranciever to use for digital modes while at the same time learning and practice :slight_smile:

Thanks in advance for any insight or help to fix this issue.

This sounds familiar and I think it may be to do with the USB device not being released when the application closes. @Zack, any thoughts?

So, I’ve put of getting into SDRAngel for some time now, but I plunged into it today.
And after some fiddeling about to learn how it all works, I have found that even tho it has the same issue as everything else(every other time), it can atleast do RX/TX and what atleast appears to be realtime and without RX crashing during TX or when TX ends, like SDR Console did. So that’s something :slight_smile:
Will spend some time playing with SDRAngel to learn and understand it better.

Another quick question, if i remove MN18 to improve HF reception on one of the inputs, could the modified port have even better HF reception when connected to an external upconverter that shifts the 0-30MHz up by 125M or would reception be the same or better without the upconverter and only the MN18 modification ?

I have a feeling your spot on about the problem beeing a USB release issue. I will try on a USB2 port on the same computer(different chipset and driver), and I will try it on a couple of other copmuters with USB3. If it turns out to only be an issue with this specific chipset, i’ll get a usb3 pcie card with a newer and hopefully functional chipset/driver.

EDIT: When using a USB2 port on the same motherboard, the issue is completly eliminated. I can now start/stop/start/stop/start/ad infinitum with no issue at all. I can use limesuitgui to start/connect/quit/start/connect/quit/ad infinitum, with no mismatch reported.

So you’re defently right, this is an issue between my USB3 and the SDR. (The USB3 does not have this issue with other devices like an rtl-sdrv3, etc.)
But atleast the problem has been found, and can now move on to try fix it.
Thank you @andrewback for quick and accurate help!:slight_smile:

1 Like

Good to hear, although using USB 2.0 may result in other issues, since it it is capable of delivering far less power, in addition to having much less bandwidth.

We have previously seen some issues with certain USB 3.0 host chipsets and LimeSDR-USB, which looked as though other devices using a Cypress FX3 peripheral controller may also encounter. In any case, some have resolved certain issues by using a different computer or USB 3.0 controller.

You can find some plots of stock vs. modified performance here:

So obviously you just need to look at the upconverter output frequency position on the plot.

Awsome, thank you. Defently looks as the combination of modification and upconverter should improve HF reception a lot :slight_smile:

I will order a pci-e usb3 controller, i only used the USB2 as a test to see if that was indeed the problem.
Just for extra information, I have a Renessas USB3.0 using the NEC D720200 chip the motherboard that didnt like LimeSDR.

Can you or anyone else please advice any USB3 chipsets that are known to function well together with the limesdr ?

Also, I just read through the SDR Console help page on transmitting with LimeSDR, and they actually write:
“Use an external power supply (PSU) with the Lime USB when transmitting. The recommended voltage is 8v, more than this is just dissipated as heat.”

I was under the impression USB3 would be able to feed enough power to the SDR to not need external power. But I will try it and see if it helps with the RX/TX issue. Will post my results on this when I have had time to test.

I have a few USB 3.0 ports in my motherboard which use the uPD720200 chipset that does not work well with any SDR hardware that I own, except for some low bandwidth USB 2.0 devices.

So I ended up buying a dirt cheap Renessas USB 3.0 PCIe card that uses the NEC uPD720202 chipset and that works great with every SDR I own. (Search for “NEC720202” on amazon/aliexpress/ebay/… or you could get a different chipset, but that one works for me)

EDIT: If I was looking today, and did not know what worked I’d probably try a PCIe card that uses something like the ASM3242 chipset (no idea if it will work for SDR, but it is USB3.2 20Gbps and is backward compatible. So even if it did not work for SDR I am sure that I could still find a use for it).

1 Like