I have had communication with you guys through Mouser regarding this problem and your advice was to join this forum, so here I am
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?
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.
Rob.
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.
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?
Rob.
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.
[ Clock Network Test ]
->REF clock test
Test results: 35551; 48748; 61945 - PASSED
->VCTCXO test
Results : 6711048 (min); 6711203 (max) - PASSED
->Clock Network Test PASSED
[ FPGA EEPROM Test ]
->Read EEPROM
->Read data: 13 0A 17 13 0A 17 02
->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
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
firstTimeConfig
CIoConfig : Available output devices:
0 : âBuilt-in Audio Analogue Stereoâ
1 : âHigh Definition Audio Controller Digital Stereo (HDMI 2)â
saveConfig
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.0 (0.2.0) gnuradio 3.8.1.0
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:
SoapyLMS7::setupStream()failed:
Any ideas where I should go from here, getting this Mini to function seems somewhat over complicated perhaps I should take up fishing:-)
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.
Rob.
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?
Rob.
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.
Rob.
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:
