Hello,
I’ve found another strange behavior of LimeSDR-mini. With gqrx I am getting following error messages:
SetFrequencySXR(100.1 MHz) - cannot deliver frequency
It is not consistent, but for frequencies between approximately 100 and 100.3 MHz certain that it happens. I tried also some other frequencies and the same situation seems to be the same for 200 MHz. I wasn’t able to replicate this on any other frequency (e.g. 150 MHz, 300 MHz ). I doesn’t matter how big is the step which changes the frequency (0.1 MHz, 10 MHz or 100 MHz), important is the target value. As far as I know, when it starts happening for some value, it doesn’t stop until I restart gqrx. The RX frequency is changed to a slightly different value (e.g. 100196000 vs. 100195999.15). The difference seems to be always very small, negligible. I’d like to understand what is happening, why do I see this message? Is there any possibility that it is related to this LimeSDR Mini and Spurious signal around 100 MHz (it is happening on the same frequencies, otherwise I don`t see any similarity).
I did some debugging and the message is result of failing all three calls to TuneVCO in SetFrequencySX. Here is some debug output:
[TuneVCO() 1251]: ICT_VCO: 180
[TuneVCO() 1285]: TuneVCO(SXR) - VCO too low
[SetFrequencySX() 1549]: status -1
[TuneVCO() 1251]: ICT_VCO: 180
[TuneVCO() 1302]: csw=64 cmphl=0
[TuneVCO() 1302]: csw=96 cmphl=0
[TuneVCO() 1302]: csw=112 cmphl=0
[TuneVCO() 1302]: csw=120 cmphl=0
[TuneVCO() 1302]: csw=124 cmphl=0
[TuneVCO() 1302]: csw=126 cmphl=0
[TuneVCO() 1302]: csw=127 cmphl=0
[TuneVCO() 1327]: Failed to lock
[TuneVCO() 1302]: csw=192 cmphl=0
[TuneVCO() 1302]: csw=224 cmphl=3
[TuneVCO() 1302]: csw=208 cmphl=2
[TuneVCO() 1302]: csw=216 cmphl=3
[TuneVCO() 1302]: csw=212 cmphl=3
[TuneVCO() 1302]: csw=210 cmphl=3
[TuneVCO() 1302]: csw=209 cmphl=3
[TuneVCO() 1327]: Failed to lock
[TuneVCO() 1358]: cmphl=3
[TuneVCO() 1362]: TuneVCO(SXR) - failed to lock (cmphl!=2)
[SetFrequencySX() 1549]: status -1
[TuneVCO() 1251]: ICT_VCO: 180
[TuneVCO() 1276]: TuneVCO(SXR) - VCO too high
[SetFrequencySX() 1549]: status -1
[ERROR] SetFrequencySXR(100.196 MHz) - cannot deliver frequency
I couldn’t set frequencies around 100MHz using SDRConsole, though I could from LimeSuiteGUI using default settings. There were significant differences between the PLL settings that SDRConsole was using and the defaults.
It turns out that SDRConsole has an ini file containing these settings, so I wrote an ini file containing the defaults from LimeSuiteGUI and temporarily replaced SDRConsole’s ini file for the Mini. With the ‘default’ settings, I could then successfully set frequencies around 100MHz.
First, I’d check that you can set 100MHz from LimeSuiteGUI after unplugging/replugging the Mini and setting everything to defaults. If that fails, I’d guess you have a sick Mini.
Then, I’d take a look at the settings that gqrx is using by exiting it, then starting LimeSuiteGUI , connecting to the Mini and using the Chip to GUI function. See if the PLL settings are different. If so, try to find out where gqrx is getting them from… and try to make gqrx use the default settings.
Hi orin,
thank you for you advises. I`ll definitely take a look on those ini files.
But I wouldn’t describe the behavior as cannot tune the frequency. It is actually tuned. Just a little bit (really little, less than 1 Hz, which is negligible) and the waterfall changes and shows what I expect. I just receive the “cannot deliver frequency” error message. So I suppose that something is wrong. I just don`t know what. As you can see in my first post, I did some digging in limesuite code and found that from SetFrequencySX (which reports the erorr) is three times called TuneVCO and then the best result is chosen. TuneVCO communicates with the Lime MCU and as far as noticed, mostly ony call to this method succeeds. When the “cannot deliver frequency” message is printed, non of them succeeds. So I wonder what is wrong.
OK, it seems that I replicated the problem in LimeSuiteGUI. I connected the device, clicked Default button, then CLKGEN, Calculte, Tune. Then SXR, Calulate, Tune. With default Frequency it is OK. If I change it to 100.1 it fails with the same error message. Does it mean, that there is something wrong with my LimeSDR-mini?
I tried exatly your method and i dont get an error message.
[21:01:26] INFO: Reference clock 40.00 MHz
[21:01:26] INFO: Connected Control port: LimeSDR-Mini FW:5 HW:1 Protocol:1 GW:1.26 Ref Clk: 40.00 MHz
[21:01:37] INFO: CGEN frequency set to 61.439999 MHz
[21:01:53] INFO: SXR frequency set to 1200.000000 MHz
[21:02:09] INFO: SXR frequency set to 100.100000 MHz
srmeister,
thank you for your test, but it is happening everytime and the failing frequency is changing, so sometimes I can tune 100,1 without error message.
orin,
what can I do about it, if it is sick. Are any thorough tests to be sure?
I did some more tests and I’ve found more problematic frequencies. But I am still not convinced that this cannot be solved somehow by software. I wrote a simple C program which tries to tune all frequencies from 30 MHz to 3500 MHz with 0.1 MHz step. I found that it happens above 100, 200, 400, 800, 1600 and 3200 MHz. Sometimes 43 MHz, 723 MHz and some other. It is not happening every time on every frequency, but the list which looks like powers of 2 multiplied by 100 MHz is quite consistent. I’ve also noticed that the difference is sometimes bigger than what I wrote before - something round 5Hz.
Are you using SoapySDR in your C program? I’m using it and sometimes I get the cannot deliver frequency, even if I’m always tuned to the same frequency. I currently don’t know how to fix that, as usually once it appears, all subsequent tries give me the same error. What I would do is run Lime Suite then simply do a GUI --> Chip and things would then work again.
It is not related to SoapySDR, it is happening with or without it. My test C program is based on the basicRX example, I just removed the actual receiving and added a loop which call LMS_SetLOFrequency repeatedly.
I doubt that the GUI --> Chip button alone could solve my problem. Perhaps if I had the correct settings, which I don’t. But this may be to solution - proper ini file. But I have no idea which setting should be changed…
Thank you, but this won`t help. As far as I know SDRAngel uses libLimeSuite, so from the software point of view it is the same. The problem is deeper. The error message originates in the MCU, as I described in the first post. Something goes wrong in the device. But is it because of faulty HW, some error in libLimeSuite, in the firmware, or some settings are incorrect? In LimeSuite there are many things which can be changed, perhaps one of them could be the key one. But this is beyond my knowledge. I was hoping that someone who understands it and how the HW works could give some advice.
I did some more debugging and as I understand it, this procedure is failing. As the frequency is getting closer to a problematic on, the CSW interval is getting smaller to only one value an then it fails. For 100 MHz it just one value round 207. Sometimes this one value is OK, sometimes not and then I get the cannot deliver frequency error. Sometimes no cmphl == 2 is found, sometimes is, but it is not stable.
I`ve been looking into LimeSuite GUI to SXR tab and there are several options, which are somehow related to the PLL, VCO, frequency - e.g. CP2, CP3, CZ in PLL loop filter section, Scales VCO bias current, VCO params, LDO output voltage and other. Is there any possibility that one of these could solve this problem? I tried to find some more information about it, but without success.
I found this document. It is little bit outdated, but more descriptive than the datasheet on wiki. As I understand the section 7.16, the problem I am experiencing means that the selected frequency is not stable and may drift. Is this correct?
But there are still lots of unknowns
@orin - do you still have the ini files, you mentioned? Could you please send them to me - both of them the bad one and the good one, so I can see in what parameters are the differences.
So I tried to change some values on the SXR tab and found that lowering “Scales VCO bias current” make the TuneVCO successful, if it failed before as I described. The error message is gone, but not for the whole spectrum - different frequencies require different values, but it mostly works with the default value 180.
My question now is - does this really solve the problem or just remove symptoms? Is here anyone with good enough understanding of LMS7002M, who could answer this question (and possibly explain in more details what is happening)? Perhaps @andrewback , @joshblum or someone else? Or should I ask on some other place? If so, which one?
If this really solves the problem, I can implement a small patch for libLimeSuite to find a good bias current value it TuneVCO fails.
