Calibration Error: SetPLLFrequency: error configuring phase

I’m using a pair of LimeSDRs to transmit and receive BPSK at 15kbps. I’ve hit an error when modulating data that the data can only be demodulated part of the time. Bit errors are frequent. I think I might have tracked it down to an issue with the PLL in the SDR. When running a calibration in the Lime Suite GUI, I get the error “SetPLLFrequency: error configuring phase.” When bumping up the log level to debug, I get the following results:

23:45:16] INFO: Disconnected control port
[23:45:40] INFO: Reference clock 30.72 MHz
[23:45:40] INFO: Connected Control port: LimeSDR-USB FW:4 HW:4 Protocol:1 GW:2.15 Ref Clk: 30.72 MHz
[23:45:43] INFO: LMS7002M cache /home/odroid/.limesuite/LMS7002M_cache_values.db
[23:46:00] INFO: SetFrequency using cache values vco:0, csw:225
[23:46:00] INFO: SetFrequency using cache values vco:0, csw:201
[23:46:00] ERROR: SetPllFrequency: error configuring phase
[23:46:21] DEBUG: INT 158, FRAC 797354, DIV_LOCH 1, EN_DIV2_DIVPROG 0
[23:46:21] DEBUG: VCO 5000.00 MHz, RefClk 30.72 MHz
[23:46:21] INFO: SetFrequency using cache values vco:0, csw:225
[23:46:21] DEBUG: INT 152, FRAC 262144, DIV_LOCH 1, EN_DIV2_DIVPROG 0
[23:46:21] DEBUG: VCO 4800.00 MHz, RefClk 30.72 MHz
[23:46:21] INFO: SetFrequency using cache values vco:0, csw:201
[23:46:21] DEBUG: INT 77, FRAC 131072, DIV_OUTCH_CGEN 14
[23:46:21] DEBUG: VCO 2400.00 MHz, RefClk 30.72 MHz
[23:46:21] DEBUG: ICT_VCO_CGEN: 18
[23:46:21] DEBUG: csw=64 cmphl=0
[23:46:21] DEBUG: csw=96 cmphl=0
[23:46:21] DEBUG: csw=112 cmphl=0
[23:46:21] DEBUG: csw=120 cmphl=0
[23:46:21] DEBUG: csw=124 cmphl=0
[23:46:21] DEBUG: csw=126 cmphl=0
[23:46:21] DEBUG: csw=127 cmphl=0
[23:46:21] DEBUG: Failed to lock
[23:46:21] DEBUG: csw=192 cmphl=3
[23:46:21] DEBUG: csw=160 cmphl=0
[23:46:21] DEBUG: csw=176 cmphl=3
[23:46:21] DEBUG: csw=168 cmphl=2
[23:46:21] DEBUG: csw=172 cmphl=2
[23:46:21] DEBUG: csw=174 cmphl=2
[23:46:21] DEBUG: csw=175 cmphl=2
[23:46:21] DEBUG: CSW: lowest=168, highest=175, selected=171
[23:46:21] DEBUG: cmphl=2
[23:46:21] DEBUG: M=195, N=3, Fvco=1300.000 MHz
[23:46:21] DEBUG: M=195, N=3, Fvco=1300.000 MHz

This is an error that shows up on both LimeSDRs I’ve tested. The strange thing is that I was able to get tests with successful data recovery earlier today, but now not so much. Below is a screenshot showing the phase vs time of the system. There are portions that look like clean BPSK, but then the phase jumps up and down in very large steps. I believe that this could be a result of the PLL losing it’s lock.

I’ve attempted to repeat the tests that I ran earlier today now that I’m getting this error and the tests are failing, even when using the code which I backed up from before.

I’d appreciate any advice I can get on resolving this error. Thank you in advance!

I’m facing the same issue with one of my two LimeSDRs, but this has nothing to do with BPSK and I hope to have some feedback from the Lime team. See thread LimeSDR PCIe bandwidth and GQRX

1 Like

Chris,

You’re certainly right about the BPSK not being a portion of the error, I just thought it provided for an interesting symptom of the problem. Here is my phase vs time plot looked like during tests earlier that day. This was before I was getting errors about the PLL during calibration.

You can see that the phase behaves much more predictably here. There is one point where it jumps unexpectedly, but that’s the only point that it does in 1.5 seconds of recorded data. Data was recoverable here.

Looks like digital DC correction. If these jumps period changes with sampling frequency, then it’s definitely digital DC correction, it can be disabled.

Update, problem solved!

I’ve removed calibration caching and upgraded from gateway firmware 2.15 to version 2.16. The problem is no longer present. I believe the firmware update was what fixed the problem.

Interesting point though, when updating the SDRs, the process worked when only one SDR was plugged in at a time. Otherwise it was unclear on what was happening. This wasn’t a huge issue, but could trip others up.

Hi,Squill
It seems that I have met similar problem like you have met, please see this :

I have tried to update gateware and firmware by LimeUtil --update and programming in LimeSuiteGUI
but it didnt work.
I want to know how to remove calibration caching, can you tell me?
Thank you very much

Hey,

I turned off calibration caching in LimeSuite in the options drop down menu. With regard to your attempt at updating, are you sure it worked? When I tried to update mine, it looked like it worked but then an update that I ran later did different stuff and took about 3 times as long. I believe my issue was fixed with an update of the SDR. The update that worked took at least 5 minutes. I don’t know what I did differently to help you, but I did only have one LimeSDR connected. I’ve seen some people on here metion that updates should be done manually because the update command doesn’t always work, but I’m not sure how to do that.

edit:

Just looked closer at your post and I see that you are running the Lime on a USB 2.0 port. Just a heads up, the LimeSDR is suppose to only support USB3.0. That being said, I’m seeing better reliability and have seen an error go away (where every second time progamming the SDR to transmit would fail) after switching to a USB 2.0 port myself. An issue that I was seeing others talk about on the forum was that power delivery could be an issue. You could try and external power source for the SDR to see if that gets any improvement. (Mine is working fine now without one, but I’m working at relatively low sample rates/bandwidths)

Thanks! Squill
It’s really the problem of USB! When I connect the board to USB3.0 interface, there are no more Errors that SetPLLFrequency and Error configuring phase. It seems work. :smile:
But there is still an error- [INFO] LMS7002M calibration values caching Disable
gr::pagesize: no info; setting pagesize = 4096
But I think that it’s due to my wrong data setting. I would check it.
Really thank you.

Does that error stop your program from working? It looks like that might just be an informative print. The calibration values caching Disabled is a result of turning off the calibration caching in LimeSuite. Mine does this as well since I have calibration caching off, it just forces the SDR to recalibrate every run.

Sorry, it seems that I rejoiced too early. :cry:
Maybe windowsGUI didn’t show completely. When I ran it in ubuntu, it still showed in terminal:
gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in sink types: uhd hackrf bladerf soapy redpitaya file
[INFO] Make connection: ‘LimeSDR-USB [USB 3.0] 9061C02CD2507’
[INFO] Reference clock 30.72 MHz
[INFO] Device name: LimeSDR-USB
[INFO] Reference: 3.072e+07 MHz
[ERROR] SetPllFrequency: error configuring phase
[INFO] LMS7002M calibration values caching Disable
[INFO] TX LPF configured
[ERROR] Tx Calibration: MCU error 3 (SXR tune failed)

I don’t know if it is related to VMware virtual workstation in which I run Ubuntu. It seems that this problem still remains


By using LimeUtil – update, I tried to update firmware and gateware after I attached it to USB3.0. This process ran much faster than before, Within not longer than 1 minuite it showed: [100%] 578141/578141 Bytes programming: completed (/home/yangzeyu/.local/share/LimeSuite/images/18.03/LimeSDR-USB_HW_1.4_r2.15.rbf)
Programming update complete!
which seems that it updated successfully?
I am kind of troubled


So can you tell me how you update the software, it seemed that my updating process was not was fixed with an update of the SDR

I unfortunately don’t know, I’m relatively knew and inexperienced to this as well. Did you try running the update command from your VM, maybe it needs to be installed from the system that’s going to run it? Could you increase the log level of the print statements? This can be done in the bottom right corner of the LimeSuite software.

Thank you
I tried to set log level to “Debug”
There seem to be some useful information:
when I tried to set SXT frequency to 850Mhz:

[08:26:06] DEBUG: M=195, N=3, Fvco=1300.000 MHz
[08:26:06] DEBUG: M=195, N=3, Fvco=1300.000 MHz
[08:26:11] DEBUG: INT 106, FRAC 709973, DIV_LOCH 2, EN_DIV2_DIVPROG 1
[08:26:11] DEBUG: VCO 6800.00 MHz, RefClk 30.72 MHz
[08:26:11] DEBUG: ICT_VCO: 255
[08:26:11] DEBUG: TuneVCO(SXT) - VCO too low
[08:26:11] DEBUG: VCOL : csw=0 tune fail
[08:26:11] DEBUG: ICT_VCO: 255
[08:26:11] DEBUG: csw=64 cmphl=0
[08:26:11] DEBUG: csw=96 cmphl=0
[08:26:11] DEBUG: csw=112 cmphl=0
[08:26:11] DEBUG: csw=120 cmphl=0
[08:26:11] DEBUG: csw=124 cmphl=0
[08:26:11] DEBUG: csw=126 cmphl=0
[08:26:11] DEBUG: csw=127 cmphl=0
[08:26:11] DEBUG: Failed to lock
[08:26:11] DEBUG: csw=192 cmphl=0
[08:26:11] DEBUG: csw=224 cmphl=0
[08:26:11] DEBUG: csw=240 cmphl=0
[08:26:11] DEBUG: csw=248 cmphl=2
[08:26:11] DEBUG: csw=252 cmphl=2
[08:26:11] DEBUG: csw=254 cmphl=2
[08:26:11] DEBUG: csw=255 cmphl=2
[08:26:11] DEBUG: CSW: lowest=247, highest=255, selected=251
[08:26:11] DEBUG: cmphl=2
[08:26:11] DEBUG: VCOM : csw=251 tune ok
[08:26:11] DEBUG: ICT_VCO: 255
[08:26:11] DEBUG: csw=64 cmphl=0
[08:26:11] DEBUG: csw=96 cmphl=2
[08:26:11] DEBUG: csw=112 cmphl=3
[08:26:11] DEBUG: csw=104 cmphl=3
[08:26:11] DEBUG: csw=100 cmphl=3
[08:26:11] DEBUG: csw=98 cmphl=2
[08:26:11] DEBUG: csw=99 cmphl=3
[08:26:11] DEBUG: Failed to lock
[08:26:11] DEBUG: csw=192 cmphl=3
[08:26:11] DEBUG: csw=160 cmphl=3
[08:26:11] DEBUG: csw=144 cmphl=3
[08:26:11] DEBUG: csw=136 cmphl=3
[08:26:11] DEBUG: csw=132 cmphl=3
[08:26:11] DEBUG: csw=130 cmphl=3
[08:26:11] DEBUG: csw=129 cmphl=3
[08:26:11] DEBUG: Failed to lock
[08:26:11] DEBUG: cmphl=2
[08:26:11] DEBUG: VCOH : csw=90 tune ok
[08:26:11] DEBUG: Selected: VCOH
[08:26:11] INFO: SXT frequency set to 850.000000 MHz
[08:26:13] DEBUG: ICT_VCO: 255
[08:26:13] DEBUG: csw=64 cmphl=0
[08:26:13] DEBUG: csw=96 cmphl=2
[08:26:13] DEBUG: csw=112 cmphl=3
[08:26:13] DEBUG: csw=104 cmphl=3
[08:26:13] DEBUG: csw=100 cmphl=3
[08:26:13] DEBUG: csw=98 cmphl=2
[08:26:13] DEBUG: csw=99 cmphl=3
[08:26:13] DEBUG: Failed to lock
[08:26:13] DEBUG: csw=192 cmphl=3
[08:26:13] DEBUG: csw=160 cmphl=3
[08:26:13] DEBUG: csw=144 cmphl=3
[08:26:13] DEBUG: csw=136 cmphl=3
[08:26:13] DEBUG: csw=132 cmphl=3
[08:26:13] DEBUG: csw=130 cmphl=3
[08:26:13] DEBUG: csw=129 cmphl=3
[08:26:13] DEBUG: Failed to lock
[08:26:13] DEBUG: cmphl=2
it showed that failed to lock.


I want to know if my updating way was wrong or not. I just use LimeUtil --update word in terminal, it seems that the software only use gateware and firmware program which were already available in limesuite. Do I have to move gateware and firmware files that I download from official github to limesuite folder?

Oh, I think I have found the mistake. I follow the instruct in wiki and update it to 2.16. But it shows this:
[INFO] Make connection: ‘LimeSDR-USB [USB 3.0] 9061C02CD2507’
[WARNING] Gateware version mismatch!
Expected gateware version 2, revision 15
But found version 2, revision 16
Follow the FW and FPGA upgrade instructions:
http://wiki.myriadrf.org/Lime_Suite#Flashing_images
Or run update on the command line: LimeUtil --update

Oh, I have solve it! Ridiculously it’s all the contrary side. I tried to reduce the version of firmware and gateware. It does work!

This suggests that your software is not up to date.

but even if version 15 doesn’t work. So I tried to downgrade the the version to 12 and it works

But the purpose of version 16 was to fix this error, right?

yes, according to description of Squill, I tried to upgrade version 16 to solve this problem first, but still it showed SetPLLFrequency Error. I think that it’s the problem of LimeSuiteGUI version.