LimeSDR Mini not receiving

I have had communication with you guys through Mouser regarding this problem and your advice was to join this forum, so here I am :slight_smile:

Since unboxing my new LimeSDR Mini I have had no success in receiving any signals with it, I am trying to use it with piHPSDR and a RPi4 which is set up for an RTL-SDR or a LimeSDR. Now the RTL-SDR works with no problem but the Lime Mini fails to receive anything apart from a strong RF source placed near a 1/4 wave aerial connected to it, indicating that it is very deaf.
It is recognized by piHPSDR and the display shows a panoramic display and waterfall but no signals, however I have just done a transmit test and that seems to be working and the RF drive control does adjust the output.

As LimeSuite seems to have limitations when we come to the Mini what can I try next prior to returning for your examination?


Further to my original message I have been trying to check out the Mini with LimeSuite and following the test procedure outlined I down loaded the Self_test.ini file and opening it in LimeSuite as the instructions state got the following result:
Connect to Mini shows:
[13:22:19]INFO:Reference Clock 40.00MHz
[13:22:20]INFO:Connected Control Port:LimeSDR-Mini FW:6 HW:3 Protocol:GW1.3RefClk:40MHz

When I try to open the Self_test.ini file I get in red:
[13:22;40]ERROR:TuneVCO(CGEN)-failed to lock(cmphl!=0)

Is there something I can do with LimeSuite to get it to lock?


Take a look here: Fix in Lime Suite for LimeSDR Mini loopback test failure

Thanks for that, this morning I downloaded and compiled the latest version but using it following the instructions in “Testing_the_LimeSDR” as soon as I open "self_test.ini I get The message:
ERROR:TUNEVCO(CGEN) - failed to lock(cmphl!=0).
I can continue and will get a result in FFTViewer but connecting the Mini to my RPi running piHPSDR will give me a display of signals but as soon as I try to move frequency the signals disappear as though the Mini has shut down.

Sounds like you might be following the test procedure for LimeSDR-USB and LimeSDR-PCIe board versions, which won’t work with LimeSDR Mini. For this you’ll need to use LimeQuickTest.

Thanks Andrew, interesting but I am following the instructions at this link:

Section 2.4 Makes reference to the Mini,
Section 2.4.2 mentions it again so I assumed it was suitable to test the Mini.
Incidentally section 2.3.1 issues the same instruction twice should the second statement actually say CLKGEN not SXT?

LimeQuickTest shows a pass to all tests initially but fails the last one once the Mini has warmed up. This surprises me because if the device is housed in a box which is most likely it is bound to fail. Is something being pushed beyond its limits?

Thanks, I see where the confusion is coming from. This page was written some time ago and wasn’t verified/approved — I’ll remove it. For LimeSDR Mini related info and links, see:

LimeSDR Mini doesn’t have DDR memory and so the waveform player in Lime Suite cannot be used (this loads a waveform into the board DDR memory and then configures it to play this).

But even with boards that do have DDR RAM, LimeQuickTest should be used, as it’s more comprehensive in coverage and less error prone (the old manual test that involved using the waveform player required the user to interpret the results).

We’re planning to move official documentation from the wiki to a much better structured static website.

Have you updated your Lime Suite to a source build from git master? As @whitequark noted this includes fixes for problems such as this.

EDIT: also LimeQuickTest pass/fail is set for operating performance at cold. There shouldn’t be too much performance degradation as it warms up, but there will be some and it could be enough to cause a test to fail where there is no hardware issue. In addition it’s important to make sure that there is nothing connected to the RF ports while the test is being run.

Hi @Rob.Ltx,

Could you provide log file created by LimeQuictTest, please.

Herewith as requested Zack,

bob@radio-desktop ~ $ LimeQuickTest
->Start time: Wed Jul 22 11:16:26 2020

->Device: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1D58988963A873
Serial Number: 1D58988963A873

[ Clock Network Test ]
->REF clock test
Test results: 35551; 48748; 61945 - PASSED
->VCTCXO test
Results : 6711048 (min); 6711203 (max) - PASSED
->Clock Network Test PASSED

->Read data: 13 0A 17 13 0A 17 02

[ 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):
CH0 (SXR=1000.0MHz, SXT=1005.0MHz): Result:(-52.7 dBFS, -3.06 MHz) - FAILED
->Run Tests (TX_1 -> LNA_H):
CH0 (SXR=2100.0MHz, SXT=2105.0MHz): Result:(-13.4 dBFS, 5.00 MHz) - PASSED
->RF Loopback Test FAILED

=> Board tests FAILED <=

Elapsed time: 2.46 seconds

I am finding problems getting GQRX or CubicSDR to recognize the Mini whereas SDRAngel does and it works without “shutting down” when I move frequency. However piHPSDR finds it and works until I do a large frequency shift then it stops receiving, a driver problem possibly? Oddly TX still works I think.


I have now done a complete new install of Linux Mint 20.0beta and installed all the latest Soapy modules. With the latest version of GQRX my HackRF One, and RTL-SDR are found and run well with no problems that I can see, however when I try to use the LimeSDR Mini GQRX finds it but crashes with the following message:
Launching I/O device editor
CIoConfig : Available output devices:
0 : “Built-in Audio Analogue Stereo”
1 : “High Definition Audio Controller Digital Stereo (HDMI 2)”
Output device 2 : “alsa_output.pci-0000_01_00.1.hdmi-stereo-extra1”
Loading configuration from: “/home/bob/.config/gqrx/default.conf”
Configuration file: “/home/bob/.config/gqrx/default.conf”
gr-osmosdr (0.2.0) gnuradio
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
[INFO] Make connection: ‘LimeSDR Mini [USB 3.0] 1D58988963A873’
[INFO] Reference clock 40.00 MHz
[INFO] Device name: LimeSDR-Mini
[INFO] Reference: 40 MHz
[INFO] LMS7002M register cache: Disabled

This is followed with a “Crash Detected” window showing:

gqrx exited with an exception:


Any ideas where I should go from here, getting this Mini to function seems somewhat over complicated perhaps I should take up fishing:-)


For some reason the auto-detect for LimeSDR in Gqrx doesn’t seem to work and instead you need to use the device string:


Thanks Andrew, now have it working with GQRX using that device string and can make large frequency moves without it stopping. Now have to fine a way to get working with piHPSDR and the Raspberry pi4 so I can start my little transceiver project.

1 Like

I’ve had PiHPSDR working with a LimeSDR Mini and Raspberry Pi 4 , but I don’t think support <30MHz was working properly, which if so could be that a fix is needed in PiHPSDR. Though I didn’t spend long investigating this, you may get on better and, should you confirm there is such an issue, I can’t imagine the fix in PiHPSDR would be too hard for them to implement.

Thanks Andrew, I’ve just been trying the 145MHz band with PiHPSDR and the receive function was working well using cursor tuning so I connected a 1/4 wave whip to the TX port on the Mini and found a strong carrier permanently on after trying to transmit. I shut down PiHPSDR but it was still there and continued transmitting until I removed the Mini from the USB port. Now for simplex use that is not helpful as it obliterates the signal you are listening to.
Is there a setting in LimeSuite I need to use to stop that happening?

A setting in LimeSuiteGUI you mean? Whatever settings you apply using this will be lost when the device is closed, then subsequently reopened and reset by an application, e.g. PiHPSDR. Some applications have the ability to load an INI file, such as one generated using LimeSuiteGUI, but this sort of approach should only ever really be used to support development and edge cases. The best approach is to have the app take care of configuration properly instead.

Getting back to your issue, this sounds like PiHPSDR may not be configuring the SDR properly and I’d raise this with the developers. Just to be sure you could also try SDRangel or SDR Console, to make sure that you don’t have the same issue with these.

One other thing you could try, just to ensure that it’s not suffering power brownout during transmit, is to plug the SDR directly into the USB port if you’re currently using a cable. Sometimes poorer quality cables can result in voltage drops which cause issues, e.g. the SDR to effectively crash.

Hi Andrew, thank you for your guidance. This is a Windows free zone so I tried SDRAngel and got a nice clean tone modulated AM transmission which cuts off cleanly, so the problem as you suggest is with PiHPSDR and I will contact John Melton and see if he can offer any help.
If I use the calibrate functions in LimeSuiteGUI is that retained by the Mini or are we again relying on the SDR software to set calibration? I do have a GPS linked 10MHz source for other equipment so if I can find a suitable cable I assume I can use that.
Incidentally the Mini works well with Gqrx on the 145MHz band but I have not as yet tried any lower frequencies.

1 Like

Calibration has to be done for a given set of configuration parameters and so it’s not something which is set and forget and persisted to the chip. Instead it’s done automatically as you (re)tune or forced by the software application. The MCU on the LMS7002M chip runs the actual process. You can read more about it here:

But it’s not something you should have to think about, unless the application has a “calibrate” button that you can press.

You can provide an external reference, e.g. from GPSDO, for better frequency accuracy/stability. See:

In particular the notes regarding the external reference requirements.

The app you use should then have a button to enable/disable use of this.