I am using quite an old Intel Desktop motherboard, the DH55HC (https://ark.intel.com/products/42409/Intel-Desktop-Board-DH55HC) with an Core-i5 760, hence the reason I’m using a PCIe USB3.0 adapter card also (NEC chipset). With the latest driver and gateware update I’m finding the LimeSDR board is working reliably with the USB2 ports on my PC, but still not the USB3.0 port on the adapter card.
Cheers
Richard
I’m using an Nvidia TX2 and I have to use the usbreset script found here every couple of times I run the device (less than optimal).
So the following components are exchangeable:
I really want to work together with myriadrf, as the problem is not reproduceable on their side.
I want to contribute, but I need some code, scripts or something else I can run to give feedback.
Only showing pictures of our setups will not solve the problem.
Cheers
I’ve just tried the LimeSDR on one of my PC’s at home, an HP Elite 8300 with USB3.0 ports on the motherboard. I haven’t determined what the motherboard is yet, but it has an LGA1155 Intel Core-i5, running Linux Mint 18.2, same as at work. I built LimeSuite from latest source, and also SoapySDR. Everything is functioning correctly unlike with my work PC. Not entirely sure what to make of that!
Cheers
Richard
Uh, whatever you folks did in V12 has infected at least one of my Limes with this problem.
I’ve been using it relatively problem-free for months, but after downloading the latest source and building I can’t get the unit to work at all.
Running LimeUtil --update, I get a report that gateware version 2 rev 12 is expected, but 0 rev 0 was found. The update runs, and terminates normally - but I still get the ‘0 rev 0’ when running my application.
I’m going to see if I can revert to a previous version, because being dead in the water is not an option.
Maybe usefull (or not) :
Running
LimeSDR is returning GW issue every 2 times
LimeSDRMini works perfectly
LimeSDR has no issue
LimeSDRMini has no issue
Reading theories re: the problem in earlier posts I decided to try an external power supply.
I plugged in a 12 volt 5A supply, and it has modified the behavior (without really solving the problem).
Prior to plugging in the supply, every time I ran ‘LimeUtil --update’ it would report the gateware mismatch, and seem to re-flash the board. Running the update several times in succession, each time it would report the mismatch.
With the external supply the update sometimes works. But even when it does, when I run my software I get a ‘ResetChip()’ fail. At which point the gateware mismatch is back.
How many folks are using V12?
Try it in a USB2 port. If problem no longer appears, try another USB3 cable.
Finally managed to downgrade the firmware on my Lime - took a detour through bricking, then un-bricking the FX3.
With the ‘LimeSDR-USB_HW_1.4_r2.11.rbf’ image I’m back up and running. I still don’t have a clue what was going on with r2.12, but since it appears I can revert if necessary I’ll try a few experiments over the next couple of days.
Zack,
Any updates in this issue?
After flashing V2 Rev 14 connecting to my Lime 1.4 fails exactly every 2nd time.
Maybe the latest gateware is not integrated correctly into the drivers?
For example a Build from Source of LimeSuite alternates between
WARNING: Gateware version mismatch!
Expected gateware version 2, revision 12
But found version 2, revision 14
and
WARNING: Gateware version mismatch!
Expected gateware version 2, revision 12
But found version 0, revision 0
while connecting through the Menu “Options, Connection Settings”
Best
dme
Sorry, I wasn’t precise enough.
My build from source is based on the current LimeSuite from GitHub. (Date 10 February 2018)
I followed 3.2.1 (unix makefiles) from https://wiki.myriadrf.org/Lime_Suite
omitting the last 2 steps, which is the install part
After the build I started LimeSuiteGUI in ./builddir/bin/
Best
I think this might be the problem of the new firmware/gateware.
I used 2 LimeSDR on the same computer.
I installed the latest LimeSuite from apt-get. And upgraded one of my LimeSDR board to firmware version 4, gateware version 2 revision 12, then sometimes the device will report the version 0 problem
But my another LimeSDR which I keep using as firmware version 3 and gateware version 2, revision 6 is always fine.
For those who have the verision 0 revision 0 problem, I suggest you to download the rbf and img file manually from http://downloads.myriadrf.org/project/limesuite/18.01/ and then manually flash the files into fpga and fx3 through LimeSuiteGUI.
You can change the version number in the link according to the LimeSuite version you are using.
Because I found that LimeUtil --update sometimes might not download the right firmware file, which depends on your internet connection and could cause this kind of problem.
I tried.
For me, going back to gateware version 2 revision 6 had no effect. Still exact every 2nd time the problem shows up.
It makes no difference if I flash with LimeUtil or with LimeSuiteGui.
I tried flashing only an using the most recent software and build a complete package which matches the gateware 2.6. No difference.
For me, the device is useless. I really hope the 5 LimeSDRmini which I ordered as a sample for my company will not show up with the same problem.
Aparently I am not the only one which faces this problem. Again, i want to help to solve it!
There are still 2 ways to upgrade firmware in LimeSuiteGUI, don’t use the automatic one. Do it manually.
Your computer is different from mine, which could cause the problem. Try to find a raspberry pi 3, and use a usb cable with 2 ports to connect to the rpi3. And see if it is still the same. ( You need to remove the fan and hdmi cable to provide enough current, use xrdp or vnc for login with gui).
Here’s a link of the installation procedure for LimeSDR on RPi3:
http://blog.csdn.net/shukebeta008/article/details/76858532
Thanks for you input. See Post #35. My board works with USB 2.0.
But i need the bigger bandwith and and i need it to run on this specific computer. I don’t want to buy a new computer just to get my limesdr to work.
Also in Post #37 @Zack states the problem is fixed in gatware 12. But for my case it did not fix it.
I’m experiencing this issue as well. What I’ve found is that it has nothing to do with the firmware being corrupted on the board. In fact, I can get into a state where successive runs of LimeUtil --make alternate between reporting gateware version 0 and the real version 2, 18. I’ve even had runs where LimeUtil doesn’t print the warning about the gateware version mismatch even though it prints version 0 (maybe the first read succeeds, and the second doesn’t?:
$ LimeUtil --make
Make device
Read(64 bytes) failed
Device name: LimeSDR-USB
Expansion name: UNSUPPORTED
Firmware version: 4
Hardware version: 0
Protocol version: 1
Gateware version: 0
Gateware revision: 0
Gateware target: UNKNOWN
Serial number: 0x9072c02873717
Free connection… OK
I have a Wireshark capture of the USB packets when the gateware version is reported as 0; Wireshark reports the URB status as “ENOENT”. I found https://dri.freedesktop.org/docs/drm/driver-api/usb/error-codes.html which offers two theories - either the interface or endpoint doesn’t exist, or the request was cancelled. I don’t know how either of the former could be true, since there are successful URBs both before and after the failed one.
Let me know if the Wireshark captures would be useful.
Sounds like it could be power brownout in that case. How are you powering the board and have you tried different cables and USB ports?
I’ve tried powering the board 3 different ways: via a powered USB hub, via a powered USB hub and an external 9V power supply, and via an active USB extension cable with an external 9V power supply. I see the same problem in all of these configurations.