QuickTest result changed

I don’t know if something has happened to my Lime or if there is a problem with my software or some other persistent settings. I used to get the expected result, but I’ve updated firmware and software since then. Here’s the version numbers

$LimeUtil --make
Make device 
  Device name: LimeSDR-USB
  Expansion name: UNSUPPORTED
  Firmware version: 4
  Hardware version: 4
  Protocol version: 1
  Gateware version: 2
  Gateware revision: 14
  Gateware target: LimeSDR-USB
  Serial number: 0x9060a0259201f
  Free connection... OK

LimeUtil and LimeSuiteGUI have been built from source:

Version information:
  Library version:	v18.02.0-g41ec4d8c
  Build timestamp:	2018-02-27
  Interface version:	v2017.12.0
  Binary interface:	18.02-1

md5sum self_test.ini 
0db00fdf5df58f4387265cfcdfadabc7  self_test.ini

When I do the loopback test as given in:
https://wiki.myriadrf.org/LimeSDR-USB_Quick_Test

I get:

It used to look like the output in URL above. I don’t know if it has changed due to software or some other settings or if my Lime is broken somehow. Did any others experience anything similar?

I also get loopback errors:

LimeUtil --timing
Connected to [LimeSDR-USB, media=USB 3.0, module=FX3, addr=1d50:6108, serial=0009060A0259201F]
Creating instance of LMS7002M:

Timing basic operations:
  >>> SPI write register:	0.023753 us
  >>> SPI read register:	142.735 us
  >>> TSP NCO setting:		1034.36 us
  >>> RFE gain setting:		0.470757 us
  >>> TRF gain setting:		0.905598 us

Timing tuning operations:
  >>> CGEN PLL tuning:		9.44886 ms
  >>> RF PLL tuning:		13.7703 ms
  >>> TBB filter tuning:	175.065 ms
  >>> RBB filter tuning:	300.217 ms
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
  >>> TX corrections:		168.552 ms
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
MCU error code(5): Loopback signal weak: not connected/insufficient gain?
  >>> RX corrections:		199.493 ms

Done timing!

Is it possible to run any of the BIST tests or other test software to check the Lime?

One for @IgnasJ perhaps.

I tested my Lime on my wife’s Windows PC and everything seem to be ok with the hardware. I was asked to downgrade. So I assume this might be a software related problem. On Windows I get this version number:

Version information:
  Library version:	v18.01.0-PothosSDR-2018.02.05-vc14-x64
  Build timestamp:	2018-02-05
  Interface version:	v2017.12.0
  Binary interface:	18.01-1

How can I find out the git sha1 of this build?
There does not seem to be any v18.x tags in the repo:

$ git pull
Already up to date.
$ git rev-parse --short HEAD
64c6155
$ git tag
v16.12.0
v16.12.1
v17.01.0
v17.01.1
v17.02.0
v17.02.1
v17.02.2
v17.06.0
v17.09.0
v17.09.1
v17.10.0
v17.12.0

After the Windows downgrade and running stable branch on Linux:

fe53178a3c74ce983ca8314c582c0547f723ec20 (tag: v17.12.0, origin/stable, stable)
Author: ignasJ <i.jarusevicius@limemicro.com>
Date:   Mon Dec 4 13:09:45 2017 +0200

$ LimeUtil --info
######################################################
## LimeSuite information summary
######################################################

Version information:
  Library version:	v17.12.0-gfe53178a
  Build timestamp:	2018-03-09
  Interface version:	v2017.12.0
  Binary interface:	17.12-1

The “Loopback signal weak” messages are gone:

$ LimeUtil --timing
Connected to [LimeSDR-USB, media=USB 3.0, module=STREAM, addr=1d50:6108, serial=0009060A0259201F]
Reference clock 30.720 MHz
Creating instance of LMS7002M:

Timing basic operations:
  >>> SPI write register:	151.401 us
  >>> SPI read register:	152.716 us
  >>> TSP NCO setting:		1069 us
  >>> RFE gain setting:		152.348 us
  >>> TRF gain setting:		304.848 us

Timing tuning operations:
  >>> CGEN PLL tuning:		10.6214 ms
  >>> RF PLL tuning:		17.0534 ms
  >>> TBB filter tuning:	156.123 ms
  >>> RBB filter tuning:	226.373 ms
  >>> TX corrections:		350.671 ms
  >>> RX corrections:		258.761 ms

Done timing!

Running the QuickTest results in the following output:

I would like to run the exact same SW version on Linux as on Windows, but how can I find the sha1 of the Windows version?

Some questions regarding https://github.com/myriadrf/LimeSuite

  1. Is the git version available in the Windows build somehow?
  2. Is the repository tagged when Windows versions are released?
  3. Does the stable branch go through some kind of hardware based regression test on Linux?

I’ve had similar issues with new-ish Limesuite builds on OSX. I noticed that “Module=STREAM” is now changed to “Module=FX3”. Andrew suggested that this may just be a semantics issue referring to the name of the FGPA, but the problems we’ve experienced seemed to have occurred after this change. I also went back to an earlier version of LimeSuite / drivers and these errors are not present.

Thank you for your reply as I didn’t notice the difference in the module name.

I would like to go back to a stable version too. But which version is stable?

How can I find out the version of the released Windows build? It does not seem to output the git sha1 (unlike the Linux version) and there does not seem to be a tag in the git repository which corresponds to the release.

Also the stable branch results in the fft output above above.

I’m just chiming in here to say that I’m seeing the exact same behavior shown in your screenshot with a new LimeSDR USB running under Windows 10 and PothosSDR-2018.03.12-vc14-x64.exe. I noticed a newer release was available as PothosSDR-2018.03.31-vc14-x64.exe and I went through the same process, which results in a new, but also unexpected (and I suspect undesirable) FFT graph:

I’ll try some downgrades and report back if anything useful happens.

Results with PothosSDR-2017.12.31-vc14-x64.exe now track a little closer to the image shown in the LimeSDR-USB_Quick_Test:

Followup - I just downloaded and installed PothosSDR-2018.04.08-vc14-x64.exe released yesterday and the quick test results with this new version match nicely with the example shown in the guide: