Problems with LimeSDR mini


#52

AFAIK updating via JTAG may need to be done only with the pre-production LimeSDR Mini boards. Even then, I don’t recommend attempting to solder a header on and do this until it has been confirmed this is required.

Will drop you a line to get some more details and we’ll be looking into this.


#53

Also having trouble getting the LimeSDR mini to do anything interesting.

  1. Installed the latest PothosWare
  2. Downloaded and replaced the LimesuiteGUI - Current Pothosware does not have the latest version and installs the 1.22 version FPGA code. V1.24 sucessfully programmed via the GUI.
  3. LimesuiteGUI will talk to LimeMini. If I hit ‘default’ first then FFTviewer works. I can use the SXR tab to set the frequency and RFE tabs to set the front end. RX_rate stays at zero, but the spectrum looks correct for the selected bands…
  4. I can run Zacks windows test program and it reports everything as passed.
  5. However when I try and use applications with it it does not work. So far tested SDRconsoleV3,GQRX,CubicSDR,Pothosflow,GRC.
  6. Tried setting the arguments to “driver=lime,soapy=2” in GQRX, but nothing.
  7. Tested on 3 different machines using both Windows and UBUNTU.One of these successfully talks to the LimeSDR-USB.

I am fairly sure that the radio is not broken and that I have the latest drivers for everything installed. Running out of things to try.

Any ideas what to try next?


#54

As for SDR-Console V3 if you have the FTDI 601 driver installed it should just work.
as for the rest tis F*cked up


#55

In Linux buntu/debian only thing i got to work rigtht was osmotrx not sure why thou


#56

This issue has been opened to fix the frequency range report: https://github.com/myriadrf/LimeSuite/issues/171

Note: I noticed that the step information seems to have been removed. However it is still present in the API documentation:
http://docs.myriadrf.org/LMS_API/structlms__range__t.html

Do you plan to update the API documentation? Apparently the Lime Suite API does not work at all as it used to be and these are undocumented changes that makes it very difficult for third party developers to follow.

Note2: many of these changes seem to have been done with this commit: https://github.com/myriadrf/LimeSuite/commit/c02f4358b6eb3a83f333e8951419f34b18667dde


#57

I have made some progress.

A new build of Pothosware was uploaded by Josh on Monday 12/3/18 that replaces 6/2/18. I installed this and things seem to have improved marginally.

CubicSDR - Will now work - I can successfully demodulate FM signals in the central 100KHz. If I increase the sample rate the spectrum is zero except over the central 100KHz. It seems like there is a filter in the FPGA rejecting wider band signals.

SDRv3 - Still not working with the mini - but works with the SDR-USB.

GQRX(Windows - Pothos build) - Not working at all
GQRX(Ubuntu) fails and shos the following errors:-

 [ERROR] SetFrequencyCGEN(80 MHz) failed:
INT: 63	FRAC: 0	DIV_OUTCH_CGEN: 15
VCO: 2560 MHz	RefClk: 40 MHz
TuneVCO(CGEN) - VCO too low
[ERROR] SetFrequencyCGEN(80 MHz) failed:
INT: 63	FRAC: 0	DIV_OUTCH_CGEN: 15
VCO: 2560 MHz	RefClk: 40 MHz
TuneVCO(CGEN) - VCO too low
[ERROR] MCU working too long 4
[ERROR] setBandwidth(Rx, 0, 30 MHz) Failed - SetFrequencyCGEN(80 MHz) failed:
INT: 63	FRAC: 0	DIV_OUTCH_CGEN: 15
VCO: 2560 MHz	RefClk: 40 MHz
TuneVCO(CGEN) - VCO too low

Pothos Flow - Will not work and returns the following errors

[13:14:42.830000] SoapySDR: Make connection: 'LimeSDR Mini [USB 3] 1D3A0BF36xxxxx'
[13:14:43.455000] SoapySDR: Reference clock 40.00 MHz
[13:14:43.470000] SoapySDR: Device name: LimeSDR-Mini
[13:14:43.470000] SoapySDR: Reference: 4e+07 MHz
[13:14:44.469000] SoapySDR: LMS7002M calibration values caching Disable
[13:14:44.500000] SoapySDR: SetFrequencyCGEN(80 MHz) failed
[13:14:44.547000] SoapySDR: SetFrequencyCGEN(128 MHz) failed

GNUradio Companion - using OSMOCOM driver - runs, but the spectrum looks wrong and the following errors are returned.

Executing: C:\Python27\python.exe -u C:\Users\hagst\Documents\top_block.py
Error: EnvironmentError: OSError: LoadLibrary failed to load "C:\Program Files\PothosSDR\lib\uhd\modules\umtrx.dll"
gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf airspy soapy redpitaya 

[INFO] Make connection: 'LimeSDR Mini [USB 3] 1D3A0BF36xxxxx'
[INFO] Reference clock 40.00 MHz
[INFO] Device name: LimeSDR-Mini
[INFO] Reference: 4e+07 MHz
[INFO] LMS7002M calibration values caching Disable
e[1me[31m[ERROR] SetFrequencyCGEN(80 MHz) failede[0m
e[1me[31m[ERROR] SetFrequencyCGEN(160 MHz) failede[0m
[INFO] RX LPF configured
gr::pagesize: no info; setting pagesize = 4096
[INFO] Rx calibration finished

Seems like the issue definitely resides in the SetFrequencyCGEN(80 MHz) routine.


#58

Could it be that all of them at startup just reset chip and do not set default settings for LimeSDR mini board, with incorrect LDO settings CGEN/SXR/SXT won’t work on mini board


#59

here i run quick test following error received

[ RF Loopback Test ]
->Configure LMS
->Run Tests (TX_2 -> LNA_W):
->On board loopback test:
Test 1:(SXR=1000.0MHz, SXT=1005.0MHz, TXPAD=8): Result:(-63.3 dBFS, -6.72 MHz) - FAILED
->Configure LMS
->Run Tests (TX_1 -> LNA_H):
->On board loopback test:
Test 1:(SXR=2100.0MHz, SXT=2105.0MHz, TXPAD=8): Result:(-63.3 dBFS, -6.72 MHz) - FAILED
->RF Loopback Test FAILED

=> Board tests FAILED <=


#60

Zack i test limsdr mini results Board Test Failed, here detailed log

[ TEST STARTED ]
->Start time: Wed Mar 14 06:12:45 2018

->Device: LimeSDR Mini, media=USB 2, module=FT601, serial=1D3A01219BCC7B, index=0
Serial Number: 1D3A01219BCC7B

[ Clock Network Test ]
->REF clock test
Test results: 54262; 1923; 15120 - PASSED
->VCTCXO test
Results : 6710989 (min); 6711154 (max) - PASSED
->Clock Network Test PASSED

[ FPGA EEPROM Test ]
->Read EEPROM
data: 18 02 07 18 02 07 2
->FPGA EEPROM Test PASSED

[ LMS7002M Test ]
->Perform Registers Test
->External Reset line test
Reg 0x20: Write value 0xFFFD, Read value 0xFFFD
Reg 0x20: value after reset 0x0FFFF
->LMS7002M Test PASSED

[ RF Loopback Test ]
->Configure LMS
->Run Tests (TX_2 -> LNA_W):
->On board loopback test:
Test 1:(SXR=1000.0MHz, SXT=1005.0MHz, TXPAD=8): Result:(-63.3 dBFS, -6.72 MHz) - FAILED
->Configure LMS
->Run Tests (TX_1 -> LNA_H):
->On board loopback test:
Test 1:(SXR=2100.0MHz, SXT=2105.0MHz, TXPAD=8): Result:(-63.3 dBFS, -4.80 MHz) - FAILED
->RF Loopback Test FAILED

=> Board tests FAILED <=

Elapsed time: 11.76 seconds

[ TEST STARTED ]
->Start time: Wed Mar 14 06:16:37 2018

->Device: LimeSDR Mini, media=USB 2, module=FT601, serial=1D3A01219BCC7B, index=0
Serial Number: 1D3A01219BCC7B

[ Clock Network Test ]
->REF clock test
Test results: 46088; 59285; 6946 - PASSED
->VCTCXO test
Results : 6710993 (min); 6711157 (max) - PASSED
->Clock Network Test PASSED

[ FPGA EEPROM Test ]
->Read EEPROM
data: 18 02 07 18 02 07 2
->FPGA EEPROM Test PASSED

[ LMS7002M Test ]
->Perform Registers Test
->External Reset line test
Reg 0x20: Write value 0xFFFD, Read value 0xFFFD
Reg 0x20: value after reset 0x0FFFF
->LMS7002M Test PASSED

[ RF Loopback Test ]
->Configure LMS
->Run Tests (TX_2 -> LNA_W):
->On board loopback test:
Test 1:(SXR=1000.0MHz, SXT=1005.0MHz, TXPAD=8): Result:(-63.3 dBFS, -6.72 MHz) - FAILED
->Configure LMS
->Run Tests (TX_1 -> LNA_H):
->On board loopback test:
Test 1:(SXR=2100.0MHz, SXT=2105.0MHz, TXPAD=8): Result:(-63.3 dBFS, -6.72 MHz) - FAILED
->RF Loopback Test FAILED

=> Board tests FAILED <=

Elapsed time: 12.38 seconds


#61

It seems the instability on the “big” Lime Rx was due to a problem with an USB cable. Plugging in directly reverts to stable operation.

For the NCO it seems the control has been inverted so calculating the new center frequency goes in the opposite direction from the actual new center frequency, I think the change is in the LMS_SetNCOIndex function with the last parameter (downconvert or upconvert). The direction has been changed. No big deal but big consequence if the client code is not updated accordingly.


#62

Hi @aligrt,

Could you repeat test using USB3 instead of USB2, please.


#63

Already plugged in USB3, however issue resolved, I just upgrade firmware v1.24 using LimeSuite on Windows 10


#64

While the “big” lime now works fine with the latest Lime Suite the Mini still has issues. In fact it seems all samples are null. No signal but samples flow normally. Then if I engage the NCO I get a few carriers.

Edit: at open time I get these messages:
Reference clock 40.00 MHz
SetPllFrequency: timeout, busy bit is still 1


#65

@IgnasJ, could you assist @F4EXB in resolving this, please.


#66

@andrewback I still cannot upgrade to 1.24 from 1.18 either on Linux or Windows. I have the pre-production board. Maybe this explains.


#67

Yes, it would need JTAG. Will see about getting a production board out to you, which will be upgradeable from Lime Suite.


#68

That would be great. My address has not changed. Thanks.


#69

I’m getting the same PLL Frequency error as @F4EXB with my pre-production unit (GW v1.18) with the latest LimeSuite. I got the board working before with an old version of LimeSuite, but no luck with the latest drivers. Probably something became unsupported along the development.

12


#70

As the Lime Suite drivers get updated every now and again it becomes necessary to update the gateware. Unfortunately, the gateware loaded on pre-production boards does not support update via LimeSuiteGUI, so you would need to solder on a JTAG header and need a suitable cable. The cheap Altera Blaster clones don’t seem to work, so you’d need an authentic one else perhaps the much lower cost Terasic Blaster.


#71

I still have a problem with the LO control when A and B channels are active. I have opened issue https://github.com/myriadrf/LimeSuite/issues/173 for this problem.