LimeSDR-USB v1.4 can no longer lock at frequency

Hi, for some time now we are using LimeSDR-USB for radio reception and it was working fine.
But yesterday a colleague told me that the device stared reporting messages like:
[ERROR] SetFrequencySXT(1732.5 MHz) - cannot deliver frequency
[ERROR] setFrequency(Tx, 0, 1732.5 MHz) Failed

I have seen such issues earlier and I have fixed them by setting “Default” configuration from LimeSuiteGUI. But this does not seem to help with the current case. I have tried several things:

  • re-flashed the device - passed successfully, but the issue persists
  • got an *.ini file from a working LimeSDR-USB device and tried to load it to the broken device. I got the follwing messages:
    "
    [16:15:03] DEBUG: INT 115, FRAC 1000789, DIV_LOCH 1, EN_DIV2_DIVPROG 1
    [16:15:03] DEBUG: VCO 7370.00 MHz, RefClk 30.72 MHz
    [16:15:03] DEBUG: ICT_VCO: 192
    [16:15:03] DEBUG: TuneVCO(SXR) - VCO too low
    [16:15:03] DEBUG: VCOL : csw=0 tune fail
    [16:15:03] DEBUG: ICT_VCO: 192
    [16:15:03] DEBUG: TuneVCO(SXR) - VCO too low
    [16:15:03] DEBUG: VCOM : csw=0 tune fail
    [16:15:03] DEBUG: ICT_VCO: 192
    [16:15:03] DEBUG: csw=64 cmphl=0
    [16:15:03] DEBUG: csw=96 cmphl=0
    [16:15:03] DEBUG: csw=112 cmphl=0
    [16:15:03] DEBUG: csw=120 cmphl=0
    [16:15:03] DEBUG: csw=124 cmphl=0
    [16:15:03] DEBUG: csw=126 cmphl=0
    [16:15:03] DEBUG: csw=127 cmphl=0
    [16:15:03] DEBUG: Failed to lock
    [16:15:03] DEBUG: csw=192 cmphl=2
    [16:15:03] DEBUG: csw=224 cmphl=3
    [16:15:03] DEBUG: csw=208 cmphl=3
    [16:15:03] DEBUG: csw=200 cmphl=3
    [16:15:03] DEBUG: csw=196 cmphl=2
    [16:15:03] DEBUG: csw=198 cmphl=2
    [16:15:03] DEBUG: csw=199 cmphl=2
    [16:15:03] DEBUG: CSW: lowest=178, highest=199, selected=188
    [16:15:03] DEBUG: cmphl=2
    [16:15:03] DEBUG: VCOH : csw=188 tune ok
    [16:15:03] DEBUG: Selected: VCOH
    [16:15:03] DEBUG: INT 109, FRAC 806912, DIV_LOCH 1, EN_DIV2_DIVPROG 1
    [16:15:03] DEBUG: VCO 6990.00 MHz, RefClk 30.72 MHz
    [16:15:03] DEBUG: ICT_VCO: 192
    [16:15:03] DEBUG: TuneVCO(SXT) - VCO too high
    [16:15:03] DEBUG: VCOL : csw=0 tune fail
    [16:15:03] DEBUG: ICT_VCO: 192
    [16:15:03] DEBUG: TuneVCO(SXT) - VCO too high
    [16:15:03] DEBUG: VCOM : csw=0 tune fail
    [16:15:03] DEBUG: ICT_VCO: 192
    [16:15:03] DEBUG: TuneVCO(SXT) - VCO too high
    [16:15:03] DEBUG: VCOH : csw=0 tune fail
    [16:15:03] DEBUG: ICT_VCO: 224
    [16:15:03] DEBUG: TuneVCO(SXT) - VCO too high
    [16:15:03] DEBUG: VCOL : csw=0 tune fail
    [16:15:03] DEBUG: ICT_VCO: 224
    [16:15:03] DEBUG: TuneVCO(SXT) - VCO too high
    [16:15:03] DEBUG: VCOM : csw=0 tune fail
    [16:15:03] DEBUG: ICT_VCO: 224
    [16:15:03] DEBUG: TuneVCO(SXT) - VCO too high
    [16:15:03] DEBUG: VCOH : csw=0 tune fail
    [16:15:03] DEBUG: ICT_VCO: 255
    [16:15:03] DEBUG: TuneVCO(SXT) - VCO too high
    [16:15:03] DEBUG: VCOL : csw=0 tune fail
    [16:15:03] DEBUG: ICT_VCO: 255
    [16:15:03] DEBUG: TuneVCO(SXT) - VCO too high
    [16:15:03] DEBUG: VCOM : csw=0 tune fail
    [16:15:03] DEBUG: ICT_VCO: 255
    [16:15:03] DEBUG: TuneVCO(SXT) - VCO too high
    [16:15:03] DEBUG: VCOH : csw=0 tune fail
    [16:15:03] DEBUG: Selected: VCOH
    [16:15:03] ERROR: SetFrequencySXT(1747.5 MHz) - cannot deliver frequency
    [16:15:03] DEBUG: ICT_VCO_CGEN: 16
    [16:15:03] DEBUG: csw 60; interval [56, 65]
    "

I understood that my colleagues had connected attenuators (as far as I know 30dB/10W) to the antenna ports.
And I wander is it possible that these attenuators had killed the PLLs or something else on the board?

If so, do you think it is possible to recover the board? Or at least the Rx part of it, as we don’t need Tx for now?

Thank you,
Greetings.

I don’t know anything about the hardware issues.

But from the log, Rx PLL is working and should be usable to receive signals. I guess it depends on the software that you’re using, if it can just ignore the error regarding Tx PLL.

Well, the software seems to handle the issue, as it keeps running. But apparently the data it receives from the SDR is not correct. Because if I replace the broken SDR with another one and run it in the same conditions, I get the expected data.

And again the question, I wander if I can do something to recover Rx?