SetFrequencySXR(1812,5 MHz) - cannot deliver frequency

[nedsana]

Hi, I am using LimeSDR-USB v1.4s with LimeSuite v20.07.2 (built from source) and srsLTE.

I have problems setting certain frequencies - I get "SetFrequencySXR(1812,5 MHz) - cannot deliver frequency" error. I can reproduce this with LimeSuiteGUI - tab "SRX" - I would type the desired frequency and would press "Calculate" button. Then I get the following debug log:

[10:37:22] DEBUG: INT 114, FRAC 1365, DIV_LOCH 1, EN_DIV2_DIVPROG 1 [10:37:22] DEBUG: VCO 7250.00 MHz, RefClk 30.72 MHz [10:37:22] DEBUG: ICT_VCO: 255 [10:37:22] DEBUG: TuneVCO(SXR) - VCO too low [10:37:22] DEBUG: VCOL : csw=0 tune fail [10:37:22] DEBUG: ICT_VCO: 255 [10:37:22] DEBUG: TuneVCO(SXR) - VCO too low [10:37:22] DEBUG: VCOM : csw=0 tune fail [10:37:22] DEBUG: ICT_VCO: 255 [10:37:22] DEBUG: TuneVCO(SXR) - VCO too low [10:37:22] DEBUG: VCOH : csw=0 tune fail [10:37:22] DEBUG: Selected: VCOH [10:37:22] ERROR: SetFrequencySXR(1812.5 MHz) - cannot deliver frequency

I found that the error happens for frequency ranges: 1710-1920MHz, 859.5-964.0MHz, probably others.

I found out that if I change(usually increase) the Reference Clock from 30.72MHz to 36.72MHz, for example, the desired frequency will be accepted.

I also found that LimeQuickTest fails:

[ TESTING STARTED ] ->Start time: Fri Sep 18 10:55:43 2020

->Device: LimeSDR-USB, media=USB 2.0, module=FX3, addr=1d50:6108, serial=0009081C05C1361B, HW=4, GW=2.23 Warning: USB3 not available Serial Number: 0009081C05C1361B Chip temperature: 53 C

[ Clock Network Test ] ->FX3 GPIF clock test Test results: 23803; 27559; 31315 - PASSED ->Si5351C test CLK0: 17554 / 17554 - PASSED CLK1: 17554 / 17554 - PASSED CLK2: 17554 / 17554 - PASSED CLK3: 17554 / 17554 - PASSED CLK4: 17554 / 17554 - PASSED CLK5: 17554 / 17554 - PASSED CLK6: 17554 / 17554 - PASSED ->ADF4002 Test Result: 10 - PASSED ->VCTCXO test Results : 5112941 (min); 5113077 (max) - PASSED ->Clock Network Test PASSED

[ FPGA EEPROM Test ] ->Read EEPROM ->Read data: 13 01 18 13 01 19 03 ->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 ] Note: The test should be run without anything connected to RF ports ->Configure LMS CGEN: Freq=80 MHz, VCO=2.4 GHz, INT=77, FRAC=131072, DIV_OUTCH_CGEN=14 CGEN: Freq=80 MHz, VCO=2.4 GHz, INT=77, FRAC=131072, DIV_OUTCH_CGEN=14 CGEN: Freq=491.52 MHz, VCO=1.96608 GHz, INT=63, FRAC=0, DIV_OUTCH_CGEN=1 CGEN: Freq=491.52 MHz, VCO=1.96608 GHz, INT=63, FRAC=0, DIV_OUTCH_CGEN=1 SetPllFrequency: error configuring phase SetPllFrequency: error configuring phase SetPllFrequency: error configuring phase SetPllFrequency: error configuring phase SetPllFrequency: error configuring phase SetPllFrequency: error configuring phase SetPllFrequency: error configuring phase SetPllFrequency: error configuring phase SetPllFrequency: error configuring phase SetPllFrequency: error configuring phase LML TX phase search FAIL Failed to set sample rate ->RF Loopback Test FAILED

=> Board tests FAILED <=

Elapsed time: 2.29 seconds

Could you please, give some hints how can I solve this problem?

Thank you.

[mindfocus]

may be not enough voltage

[nedsana]

I use external supply (12V, 1.5A) and USB3. On this same PC, I have tried to use another LimeSDR-USB device, and the result was the same. I have tested also with a laptop - same result.

[mindfocus]

@nedsana

[mindfocus]

two USB3

[mindfocus]

I'll delete this picture if you finish seeing it @nedsana

[nedsana]

I don't have two USB ports on my Lime device. The device I use is described here: https://wiki.myriadrf.org/LimeSDR-USB_hardware_description#Clock_distribution Here is my setup: You can delete your image, thanks.

[mindfocus]

two USB3 plug in the computer not Lime

[mindfocus]

Sorry I'm not an engineer , but two USB3 plug in the computer fixed the same issue as you

[nedsana]

Aha, I did not understand this from the image. OK, I have to try this. But I need to find such cable first. Thanks for the idea.

[gracid]

Hello, could you try to use USB3? From the logs it shows that the board was tested with USB2 connection.

[nedsana]

I have tried all USB ports on this PC, they are all supposed to be USB3. And in any of the cases I was getting the error. Then I decided to use external power supply, as I mentioned (12V, 1.5A). Still the same result.

[gracid]

Does it enumerate as USB2 on all the ports? Do you have any other PC with USB3 ports available to run the quicktest program?

[nedsana]

I just executed the LimeQuickTest on a laptop, on all ports. They were all recognised as USB2. And the test always failed when it tried to set certain frequencies. So no matter if I use the PC or the Laptop, and not matter of the USB port, LimeQuickTest always fails. Does the USB type really matter, when external power source is used? Could it be that the power supply I use is disturbing the SDR? Btw, some time ago, I got another LimeSDR-USB device (unavailable at the moment), which was recognised as USB3 on this same PC. But again I was not able to set the desired 1800Mhz frequencies - I was getting "SetFrequencySXR(1812,5 MHz) - cannot deliver frequency".

[nedsana]

Since you suspect the USB type, I played a bit with my cabling and it turned out that the USB cable, which connects the PC and SDR is USB2 type. I removed and now I have USB3 connection, but still setting 1800MHz fails. Here is the result of LimeQuickTest

[ TESTING STARTED ] ->Start time: Mon Sep 21 11:43:55 2020

->Device: LimeSDR-USB, media=USB 3.0, module=FX3, addr=1d50:6108, serial=0009081C05C1361B, HW=4, GW=2.23 Serial Number: 0009081C05C1361B Chip temperature: 25 C

[ Clock Network Test ] ->FX3 GPIF clock test Test results: 35090; 38846; 42602 - PASSED ->Si5351C test CLK0: 17554 / 17554 - PASSED CLK1: 17554 / 17554 - PASSED CLK2: 17554 / 17554 - PASSED CLK3: 17554 / 17554 - PASSED CLK4: 17554 / 17554 - PASSED CLK5: 17554 / 17554 - PASSED CLK6: 17554 / 17554 - PASSED ->ADF4002 Test Result: 10 - PASSED ->VCTCXO test Results : 5112939 (min); 5113075 (max) - PASSED ->Clock Network Test PASSED

[ FPGA EEPROM Test ] ->Read EEPROM ->Read data: 13 01 18 13 01 19 03 ->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 ] Note: The test should be run without anything connected to RF ports ->Configure LMS CGEN: Freq=80 MHz, VCO=2.4 GHz, INT=77, FRAC=131072, DIV_OUTCH_CGEN=14 CGEN: Freq=80 MHz, VCO=2.4 GHz, INT=77, FRAC=131072, DIV_OUTCH_CGEN=14 CGEN: Freq=491.52 MHz, VCO=1.96608 GHz, INT=63, FRAC=0, DIV_OUTCH_CGEN=1 CGEN: Freq=491.52 MHz, VCO=1.96608 GHz, INT=63, FRAC=0, DIV_OUTCH_CGEN=1 ->Run Tests (TX_2-> LNA_L): CH0 (SXR=800.0MHz, SXT=805.0MHz): Result:(-14.2 dBFS, 5.00 MHz) - PASSED CH1 (SXR=800.0MHz, SXT=805.0MHz): Result:(-16.0 dBFS, 5.00 MHz) - PASSED ->Run Tests (TX_1 -> LNA_W): SetFrequencySXR(1800 MHz) - cannot deliver frequency ->Run Tests (TX_2-> LNA_H): CH0 (SXR=2500.0MHz, SXT=2505.0MHz): Result:(-29.3 dBFS, 5.00 MHz) - FAILED CH1 (SXR=2500.0MHz, SXT=2505.0MHz): Result:(-12.3 dBFS, 5.00 MHz) - PASSED ->RF Loopback Test FAILED

=> Board tests FAILED <=

Elapsed time: 1.68 seconds

[ztamosevicius]

Could you share your register ini file, please.

[nedsana]

Please check this file, I hope this is what you requested. I got it from LimeSuiteGUI, simply by pressing Save button. LimeSDR_USB.txt

[ztamosevicius]

Could you try this using LimeSuiteGUI:

1. Connect to the board;
2. Push Default button;
3. Try to lock SXR to 1812.5 MHz;

Let me know the result.

[nedsana]

[15:05:21] DEBUG: INT 114, FRAC 1365, DIV_LOCH 1, EN_DIV2_DIVPROG 1 [15:05:21] DEBUG: VCO 7250.00 MHz, RefClk 30.72 MHz [15:05:21] DEBUG: ICT_VCO: 192 [15:05:21] DEBUG: TuneVCO(SXR) - VCO too low [15:05:21] DEBUG: VCOL : csw=0 tune fail [15:05:21] DEBUG: ICT_VCO: 192 [15:05:21] DEBUG: TuneVCO(SXR) - VCO too low [15:05:21] DEBUG: VCOM : csw=0 tune fail [15:05:21] DEBUG: ICT_VCO: 192 [15:05:21] DEBUG: TuneVCO(SXR) - VCO too low [15:05:21] DEBUG: VCOH : csw=0 tune fail [15:05:21] DEBUG: ICT_VCO: 224 [15:05:21] DEBUG: TuneVCO(SXR) - VCO too low [15:05:21] DEBUG: VCOL : csw=0 tune fail [15:05:21] DEBUG: ICT_VCO: 224 [15:05:21] DEBUG: TuneVCO(SXR) - VCO too low [15:05:21] DEBUG: VCOM : csw=0 tune fail [15:05:21] DEBUG: ICT_VCO: 224 [15:05:21] DEBUG: TuneVCO(SXR) - VCO too low [15:05:21] DEBUG: VCOH : csw=0 tune fail [15:05:21] DEBUG: ICT_VCO: 255 [15:05:21] DEBUG: TuneVCO(SXR) - VCO too low [15:05:21] DEBUG: VCOL : csw=0 tune fail [15:05:21] DEBUG: ICT_VCO: 255 [15:05:21] DEBUG: TuneVCO(SXR) - VCO too low [15:05:21] DEBUG: VCOM : csw=0 tune fail [15:05:21] DEBUG: ICT_VCO: 255 [15:05:21] DEBUG: TuneVCO(SXR) - VCO too low [15:05:21] DEBUG: VCOH : csw=0 tune fail [15:05:21] DEBUG: Selected: VCOH [15:05:21] ERROR: SetFrequencySXR(1812.5 MHz) - cannot deliver frequency

[ztamosevicius]

This is a hardware problem. Contact Crowd supply for RMA, sorry for inconvenience.

[nedsana]

OK, but in the initial description, I mentioned that to make LimeSDR accept the 1800MHz, I had to set the Reference Clock from 30.72MHz to 36.0MHz or 40.0MHz. So, I am able to use the frequency range around 1800Mhz. What I don't know is whether it is correct to play with the reference clock and what consequences this can have. Could you please comment on this? Thank you.

[ztamosevicius]

In this case you may get other dead regions in the spectrum.

[nedsana]

Yes, I observe indeed dead regions in my current experiments. But apart from this, can I expect problems with sampling and data transfer? Because, if sampling and data transfer are fine, I could use the Reference Clock toggling as a workaround.

[ztamosevicius]

Data sampling is fine, while DACs and ADCs are running from a separate clock PLL - CGEN.

[nedsana]

Today I also tried the suggestion from @mindfocus for the 2 USB cable - did not help with my SDR. But I happened to get for a few moments another LimeSDR-USB. And it is working fine with the 1800MHz. So indeed I was fighting a hardware issue. Thanks a lot for the support.