"[ERROR] Read(64 bytes) failed" and "cannot deliver frequency" after receiving for some time


#1

Hi all,

I have a program using the C Soapy interface. I configure and start streaming on the 2 channels at the beginning, then I keep on receiving. I noticed that after some time (can be a few minutes or several hours), I get an error, then everything stops working.

Here’s the logs I get at startup

[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_106300; UHD_3.11.0.1-37-g2c9087d1
[INFO] Make connection: 'LimeSDR-USB [USB 3.0] xxx'
[INFO] Reference clock 30.72 MHz
[INFO] Device name: LimeSDR-USB
[INFO] Reference: 3.072e+07 MHz
[INFO] LMS7002M calibration values caching Disable
Setup RX0
[INFO] RX LPF configured
Setup RX1
[INFO] RX LPF configured
[INFO] Rx calibration finished
e[1me[31m[ERROR] Rx calibration: MCU error 5 (Loopback signal weak: not connected/insufficient gain?)e[0m

Then I keep on receiving (in this case for about 11 minutes) without any error, until I get

e[1me[31m[ERROR] Read(64 bytes) failede[0m
[INFO] Rx calibration finished
[INFO] Rx calibration finished
e[1me[31m[ERROR] SetFrequencySXR(450 MHz) - cannot deliver frequencye[0m
e[1me[33m[WARNING] Channel alignment failede[0m
e[1me[31m[ERROR] SetFrequencySXT(496.32 MHz) - cannot deliver frequencye[0m
e[1me[33m[WARNING] Channel alignment failede[0m
e[1me[33m[WARNING] Channel alignment failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
... 119 times the same message
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[31m[ERROR] SetFrequencySXR(450 MHz) - cannot deliver frequencye[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
... 16 times the same message
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[33m[WARNING] Channel alignment failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
... 26 times the same message
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[31m[ERROR] SetFrequencySXT(450.12 MHz) - cannot deliver frequencye[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[33m[WARNING] Channel alignment failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[33m[WARNING] Channel alignment failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
... 119 times the same message
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[31m[ERROR] SetFrequencySXR(450 MHz) - cannot deliver frequencye[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
... 16 times the same message
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[33m[WARNING] Channel alignment failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
... 26 times the same message
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[31m[ERROR] SetFrequencySXT(450.12 MHz) - cannot deliver frequencye[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
e[1me[33m[WARNING] Channel alignment failede[0m
e[1me[31m[ERROR] Write(64 bytes) failede[0m
...

I’m listening around 2450MHz in dual channel at 55MS/s.

Any idea what’s happening @andrewback @Zack ?


LimeSDR Made Simple series
How to reset the USB connection to the LimeSDR
#2

Can you run the LimeQuickTest after it fails?


#3

Might be power related. I get similar problems when running on a battery powered laptop that has multiple power consumers on the USB ports. Never happens when plugged in. You could try to feed your Lime from the DC input.


#4

I’m not 100% convinced about power issue …

I do also get this many times with also a report of the wrong firmware version – that i can get to show as the correct loaded version WITHOUT UPDATEING

I do use Laptop on battery, laptop powered and also a Desktop with a USB3.0 PCIe port …

All exhibit the same random problem …

But the process to getting to see and get operation always seems to be the same …

Plug in power to LimeSDR-USB, then the Data line – ie the thicker USB cable – depending on your setup. Check to see if LimeSuiteUtil when apon connecting to the LimeSDR-USB –

Ie click on the second from top left “options” , then “connectionssettings”, then click on your Lime Device and then click on “connect” – watch the bottom left window of LimeSuiteUtil for information … if it shows the version 2/16 or 2/17 for the LimeSDR-USB then go through the connectionsettings again but click disconnect to detatch from the LimeSDR-USB.

If it was something other than what you exspected – go through the connectionsettings again but click disconnect to detatch from the LimeSDR-USB , unplug the data line … then power, wait a sec or two then plug in again … power, then data – check again.

I have had to do that up to 5 times before the correct version shown – usually version 0 or what is loaded …

Run the next program that you want to use with the Lime …

If you see the dreaded [ERROR] Write(64 bytes) again … close out of the program that shown the error and repeat the unplug data then power routine again … give time for the onboard voltages to get to “dead” (no power) before plugging in again … .

i feel that you don’t want any fuzzy states of logic on the board … due to brown condition when plunging in/out fast …

try LimeSuiteUtil or your favorite program again …

keep trying … i 100% believe that no one needs to reload the firmware over and over again … if it gets confirmed as loaded into flash and no bit errors detected then the save of the firmware into read-only state is good and you are just reducing the life (though it is long time ) of the flash …


#5

I also feel that there is some onboard timing issue that shows its self more with USB2.0 than 3.0 …

Why would the Firmware eventually be reported as correct if it was actually trashed … ?

I think that the “Read (64bytes) failed” and firmware report issue may be related …


#6

@gasparka I’m using a desktop computer, not a laptop.

@sven Today I’ve been using Pothos Flow (I don’t use GRC as it seems to hang more often) and I’ve seen some errors.

Opening the flow works:

SoapySDR: Make connection: 'LimeSDR-USB [USB 3.0] 987654321ABCD'
SoapySDR: Reference clock 30.72 MHz
SoapySDR: Device name: LimeSDR-USB
SoapySDR: Reference: 30.72 MHz
SoapySDR: LMS7002M calibration values caching Disable
SoapySDR: RX LPF configured
SoapySDR: RX LPF configured
SoapySDR: Rx calibration finished
SoapySDR: Rx calibration finished

Starting it though often does not:

Pothos.Block.work: SoapySDRSource0: Exception: SDRSource::work(): readStream TIME_ERROR

After starting/stopping the flow several times, it finally works. Then after some time I get

SoapySDR: Read(64 bytes) failed

Running the LimeQuickTest gives me the following:

[ TESTING STARTED ]
->Start time: Fri Oct  5 10:57:51 2018

Gateware version mismatch!
  Expected gateware version 2, revision 17
  But found version 0, revision 0
  Follow the FW and FPGA upgrade instructions:
  http://wiki.myriadrf.org/Lime_Suite#Flashing_images
  Or run update on the command line: LimeUtil --update

->Device: LimeSDR-USB, media=USB 3.0, module=FX3, serial=000987654321ABCD, index=0
  Serial Number: 000987654321ABCD

[ Clock Network Test ]
->FX3 GPIF clock test
  Test results: 1; 0; 0 - PASSED
->Si5351C test
  CLK0: 2 / 17554 - FAILED
  CLK1: 2 / 17554 - FAILED
  CLK2: 2 / 17554 - FAILED
  CLK3: 2 / 17554 - FAILED
  CLK4: 2 / 17554 - FAILED
  CLK5: 2 / 17554 - FAILED
  CLK6: 2 / 17554 - FAILED
  FAILED
->ADF4002 Test
  Result: 0 - FAILED
  FAILED
->VCTCXO test
  Results : 4 (min); 4 (max) - FAILED
  FAILED
->Clock Network Test FAILED

[ FPGA EEPROM Test ]
->Read EEPROM
->Read data: 12 03 02 12 03 02 02
->FPGA EEPROM Test PASSED

[ LMS7002M Test ]
->Perform Registers Test
RegistersTestInterval(startAddr=0x82, endAddr=0x82) - failed
RegistersTestInterval(startAddr=0x82, endAddr=0x82) - failed
RegistersTestInterval(startAddr=0x84, endAddr=0x84) - failed
RegistersTestInterval(startAddr=0x84, endAddr=0x84) - failed
RegistersTestInterval(startAddr=0x85, endAddr=0x85) - failed
RegistersTestInterval(startAddr=0x85, endAddr=0x85) - failed
RegistersTestInterval(startAddr=0x86, endAddr=0x8c) - failed
RegistersTestInterval(startAddr=0x86, endAddr=0x8c) - failed
RegistersTestInterval(startAddr=0xa8, endAddr=0xac) - failed
RegistersTestInterval(startAddr=0xa8, endAddr=0xac) - failed
RegistersTestInterval(startAddr=0xad, endAddr=0xae) - failed
RegistersTestInterval(startAddr=0xad, endAddr=0xae) - failed
RegistersTestInterval(startAddr=0x100, endAddr=0x104) - failed
RegistersTestInterval(startAddr=0x100, endAddr=0x104) - failed
RegistersTestInterval(startAddr=0x100, endAddr=0x104) - failed
RegistersTestInterval(startAddr=0x100, endAddr=0x104) - failed
RegistersTestInterval(startAddr=0x105, endAddr=0x10b) - failed
RegistersTestInterval(startAddr=0x105, endAddr=0x10b) - failed
RegistersTestInterval(startAddr=0x105, endAddr=0x10b) - failed
RegistersTestInterval(startAddr=0x105, endAddr=0x10b) - failed
RegistersTestInterval(startAddr=0x10c, endAddr=0x114) - failed
RegistersTestInterval(startAddr=0x10c, endAddr=0x114) - failed
RegistersTestInterval(startAddr=0x10c, endAddr=0x114) - failed
RegistersTestInterval(startAddr=0x10c, endAddr=0x114) - failed
RegistersTestInterval(startAddr=0x115, endAddr=0x11a) - failed
RegistersTestInterval(startAddr=0x115, endAddr=0x11a) - failed
RegistersTestInterval(startAddr=0x115, endAddr=0x11a) - failed
RegistersTestInterval(startAddr=0x115, endAddr=0x11a) - failed
RegistersTestInterval(startAddr=0x11c, endAddr=0x124) - failed
RegistersTestInterval(startAddr=0x11c, endAddr=0x124) - failed
RegistersTestInterval(startAddr=0x11c, endAddr=0x124) - failed
RegistersTestInterval(startAddr=0x11c, endAddr=0x124) - failed
RegistersTestInterval(startAddr=0x200, endAddr=0x20c) - failed
RegistersTestInterval(startAddr=0x200, endAddr=0x20c) - failed
RegistersTestInterval(startAddr=0x200, endAddr=0x20c) - failed
RegistersTestInterval(startAddr=0x200, endAddr=0x20c) - failed
RegistersTestInterval(startAddr=0x240, endAddr=0x261) - failed
RegistersTestInterval(startAddr=0x240, endAddr=0x261) - failed
RegistersTestInterval(startAddr=0x240, endAddr=0x261) - failed
RegistersTestInterval(startAddr=0x240, endAddr=0x261) - failed
RegistersTestInterval(startAddr=0x280, endAddr=0x2a7) - failed
RegistersTestInterval(startAddr=0x280, endAddr=0x2a7) - failed
RegistersTestInterval(startAddr=0x280, endAddr=0x2a7) - failed
RegistersTestInterval(startAddr=0x280, endAddr=0x2a7) - failed
RegistersTestInterval(startAddr=0x2c0, endAddr=0x2e7) - failed
RegistersTestInterval(startAddr=0x2c0, endAddr=0x2e7) - failed
RegistersTestInterval(startAddr=0x2c0, endAddr=0x2e7) - failed
RegistersTestInterval(startAddr=0x2c0, endAddr=0x2e7) - failed
RegistersTestInterval(startAddr=0x300, endAddr=0x327) - failed
RegistersTestInterval(startAddr=0x300, endAddr=0x327) - failed
RegistersTestInterval(startAddr=0x300, endAddr=0x327) - failed
RegistersTestInterval(startAddr=0x300, endAddr=0x327) - failed
RegistersTestInterval(startAddr=0x340, endAddr=0x367) - failed
RegistersTestInterval(startAddr=0x340, endAddr=0x367) - failed
RegistersTestInterval(startAddr=0x340, endAddr=0x367) - failed
RegistersTestInterval(startAddr=0x340, endAddr=0x367) - failed
RegistersTestInterval(startAddr=0x380, endAddr=0x3a7) - failed
RegistersTestInterval(startAddr=0x380, endAddr=0x3a7) - failed
RegistersTestInterval(startAddr=0x380, endAddr=0x3a7) - failed
RegistersTestInterval(startAddr=0x380, endAddr=0x3a7) - failed
RegistersTestInterval(startAddr=0x400, endAddr=0x40f) - failed
RegistersTestInterval(startAddr=0x400, endAddr=0x40f) - failed
RegistersTestInterval(startAddr=0x400, endAddr=0x40f) - failed
RegistersTestInterval(startAddr=0x400, endAddr=0x40f) - failed
RegistersTestInterval(startAddr=0x440, endAddr=0x461) - failed
RegistersTestInterval(startAddr=0x440, endAddr=0x461) - failed
RegistersTestInterval(startAddr=0x440, endAddr=0x461) - failed
RegistersTestInterval(startAddr=0x440, endAddr=0x461) - failed
RegistersTestInterval(startAddr=0x480, endAddr=0x4a7) - failed
RegistersTestInterval(startAddr=0x480, endAddr=0x4a7) - failed
RegistersTestInterval(startAddr=0x480, endAddr=0x4a7) - failed
RegistersTestInterval(startAddr=0x480, endAddr=0x4a7) - failed
RegistersTestInterval(startAddr=0x4c0, endAddr=0x4e7) - failed
RegistersTestInterval(startAddr=0x4c0, endAddr=0x4e7) - failed
RegistersTestInterval(startAddr=0x4c0, endAddr=0x4e7) - failed
RegistersTestInterval(startAddr=0x4c0, endAddr=0x4e7) - failed
RegistersTestInterval(startAddr=0x500, endAddr=0x527) - failed
RegistersTestInterval(startAddr=0x500, endAddr=0x527) - failed
RegistersTestInterval(startAddr=0x500, endAddr=0x527) - failed
RegistersTestInterval(startAddr=0x500, endAddr=0x527) - failed
RegistersTestInterval(startAddr=0x540, endAddr=0x567) - failed
RegistersTestInterval(startAddr=0x540, endAddr=0x567) - failed
RegistersTestInterval(startAddr=0x540, endAddr=0x567) - failed
RegistersTestInterval(startAddr=0x540, endAddr=0x567) - failed
RegistersTestInterval(startAddr=0x580, endAddr=0x5a7) - failed
RegistersTestInterval(startAddr=0x580, endAddr=0x5a7) - failed
RegistersTestInterval(startAddr=0x580, endAddr=0x5a7) - failed
RegistersTestInterval(startAddr=0x580, endAddr=0x5a7) - failed
RegistersTestInterval(startAddr=0x20, endAddr=0x2f) - failed
RegistersTestInterval(startAddr=0x20, endAddr=0x2f) - failed
RegistersTestInterval(startAddr=0x92, endAddr=0xa7) - failed
RegistersTestInterval(startAddr=0x92, endAddr=0xa7) - failed
RegistersTest() failed
->LMS7002M Test FAILED

[ RF Loopback Test ]
->Configure LMS
SetFrequencySXT(1250 MHz) - cannot deliver frequency
TuneVCO(CGEN) - failed to lock (cmphl!=0)
SetFrequencyCGEN(491.52 MHz) failed
Failed to set sample rate
->RF Loopback Test FAILED

=> Board tests FAILED <=

Elapsed time: 1.40 seconds

You’ll have noticed at the beginning the

Expected gateware version 2, revision 17 But found version 0, revision 0.

After reprogramming the FPGA I can again access the Lime, and the LimeQuickTest runs fine.

I tried the same with a 2nd Lime. I also get the same Pothos.Block.work: SoapySDRSource0: Exception: SDRSource::work(): readStream TIME_ERROR when trying to start the flow (@joshblum any idea what the cause might be?), but it seems to happen less frequently than with the 1st Lime. I haven’t been able to get the same error as the 1st Lime through Pothos yet.

@Zack Can this be an issue with the Lime itself? FYI previously I was using an older version of FPGA (2.16) and was able to get that “cannot deliver frequency” on the 2 boards (but more often on the 1st one).


#7

@KarlL
did you see this note?
“Note that, at present, the LimeQuickTest utility does not support the LimeSDR USB or LimeSDR PCIe.”
https://wiki.myriadrf.org/Testing_the_LimeSDR#Testing_the_LimeSDR_USB_and_PCIe

Can you clear “SoapySDRSource0: Exception: SDRSource::work(): readStream TIME_ERROR” by running limesdr_stopchannel from https://github.com/emvivre/limesdr_toolbox ?


#8

Thanks, actually I thought LimeQuickTest was a new simpler tool than going through LimeSuiteGUI for the test. I’ll have to redo it then.

I was finally able to compile limesdr_stopchannel (just trying to compile through VS 2017 didn’t work, it seems VSNet was trying to compile it as C++ not C, judging from the compilation error ; also I didn’t manage to compile it through cmake either). It doesn’t seem to help though.

Through Pothos I have a simple flow: a Soapy SDR Source with Periodogram and Spectrogram. I try to start the flow, I get the TIME_ERROR.

I disable the source in the flow and then run limesdr_stopchannel. I just see Reference clock 30.72 MHz. Then I enable the source again, start the flow, and get again the TIME_ERROR. I also tried without disabling / enabling the source. Usually after several stop, disable, enable, start, I finally stop getting the TIME_ERROR anymore.

Below is what I currently get with the self test. I didn’t get the [ERROR] Read(64 bytes) failed though, I only got the TIME_ERROR, so I don’t know if the self test would have worked or not.


#9

self test results look good to me.

I am also frustrated by TIME_ERROR. I don’t have a better fix than destroying and creating the channel, which are the functions being called by limesdr_stopchannel.


#11

it does work for me …
kc7noa@kc7noa-AP8B75-M:~$ LimeQuickTest
[ TESTING STARTED ]
->Start time: Thu Oct 18 17:37:56 2018

->Device: LimeSDR-USB, media=USB 3.0, module=FX3, addr=1d50:6108, serial=0009060B00473825
Serial Number: 0009060B00473825

[ Clock Network Test ]
->FX3 GPIF clock test
Test results: 28168; 31924; 35680 - 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 : 5112961 (min); 5113097 (max) - PASSED
->Clock Network Test PASSED

[ FPGA EEPROM Test ]
->Read EEPROM
->Read data: 11 01 13 11 01 13 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

[ RF Loopback Test ]
->Configure LMS
->Run Tests (TX_2-> LNA_L):
CH0 (SXR=800.0MHz, SXT=805.0MHz): Result:(-13.8 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):
CH0 (SXR=1800.0MHz, SXT=1805.0MHz): Result:(-18.0 dBFS, 5.00 MHz) - PASSED
CH1 (SXR=1800.0MHz, SXT=1805.0MHz): Result:(-17.6 dBFS, 5.00 MHz) - PASSED
->Run Tests (TX_2-> LNA_H):
CH0 (SXR=2500.0MHz, SXT=2505.0MHz): Result:(-17.7 dBFS, 5.00 MHz) - PASSED
CH1 (SXR=2500.0MHz, SXT=2505.0MHz): Result:(-13.3 dBFS, 5.00 MHz) - PASSED
->RF Loopback Test PASSED

=> Board tests PASSED <=

Elapsed time: 1.50 seconds

kc7noa@kc7noa-AP8B75-M:~$

seems to be heat related … ie after it warms up it works fine for days… as long as it is left pluged in


#12

In my case I feel things end up in a wrong state. My program runs fine then for unknown reasons after minutes or hours I get that error. Sometimes restarting the program works (that stops the connection with the Lime then establishes it again), sometimes it seems the only thing I can do is unplug then replug it for it to work again.


#13

After debugging some code, and not closing the device in code properly, I get

e[1me[31m[ERROR] TuneVCO(CGEN) - failed to lock (cmphl!=0)e[0m
e[1me[31m[ERROR] SetFrequencyCGEN(440 MHz) failede[0m
e[1me[31m[ERROR] SetFrequencySXR(2427 MHz) - cannot deliver frequencye[0m

In Lime Suite GUI I see that the gateware is version 0 revision 0

[08:32:43] WARNING: Gateware version mismatch!
  Expected gateware version 2, revision 17
  But found version 0, revision 0
  Follow the FW and FPGA upgrade instructions:
  http://wiki.myriadrf.org/Lime_Suite#Flashing_images
  Or run update on the command line: LimeUtil --update

Trying the self test doesn’t work at all. Just loading the self_test.ini shows some errors, as well as other steps:

[08:33:36] ERROR: TuneVCO(CGEN) - failed to lock (cmphl!=0)
[08:33:36] ERROR: SetFrequencyCGEN(60.9751 MHz) failed

So 2 questions:

  • How can I make the LimeSDR usable again (so similar to How to reset the USB connection to the LimeSDR)?
  • How can I detect that kind of problem? The issue is that when I call SoapySDRDevice_setFrequency it returns 0 as if everything went fine, SoapySDRDevice_getFrequency shows the requested frequency, but I see in the console e[1me[31m[ERROR] SetFrequencySXR(2450 MHz) - cannot deliver frequencye[0m

This time I was able to make the Lime usable again by uploading the gateware again. The problem is that it does not always work.


#14

The LimeSDR-USB’s FX3 chip does go into a weird state sometimes. To reset the FX3 chip you can either un-plug and re-plug the LimeSDR-USB from the USB port (this power cycles the device), or you can press the SW1 FX3 Reset button, or you can reset it programmatically by running limesdr_stopchannel from limesdr_toolbox.

Sometimes Gateway version 0 revision 0 is the result of a bad solder joint, that fixes itself when the board warms up.


#15

Exactly, have seen this for multiple boards…


#16

how do we fix this?
on my lime mini i ghave same problem
64byte read error and gateway firmware 0.0 etc…
i did use a volt meter on both edge connectors with holes and the holes with 1.8v measured .14v
i checked both voltage regulators (i think IC 12 and IC 13 and they “feel” warm
on the edge connectors i measure 5.0v , 3.3v and i also found 2.5v
its just the 1.8v edge connector holes are measuring .14v
please advise
thanks


#17

In my case the board works then after some times it stops working, so I guess it’s a different problem as it should have had time to warm up?

Does this happen just after plugging the board, or after using the board for some time?


#18

it happens all the time so far


#19

What kind of bad solder joint is this about?

I still wonder if this has been introduced by a newer Gateway version or time.


#20

Can you elaborate on this suggested bad solder joint – location etc …


#21

I tried with at least 2 versions, gateware 2.16 and 2.17.

I just got that error again. I keep the stream open and change frequency every 1/4s (but that also happens when I stay on the same frequency).

...receiving at 1852.5 MHz...
>>> Error SoapySDRDevice_readStream returned -1
e[1me[31m[ERROR] Read(64 bytes) failede[0m
e[1me[31m[ERROR] SetFrequencySXR(1852.5 MHz) - cannot deliver frequencye[0m
>>> Call SoapySDRDevice_unmake
>>> Call SoapySDRDevice_make
[INFO] Make connection: 'LimeSDR-USB [USB 3.0] 987654321'
e[0m
[INFO] Reference clock 30.72 MHz
[INFO] Device name: LimeSDR-USB
[INFO] Reference: 3.072e+07 MHz
e[1me[31m[ERROR] SetFrequencySXT(1250 MHz) - cannot deliver frequencye[0m
[INFO] LMS7002M calibration values caching Disable
e[1me[31m[ERROR] TuneVCO(CGEN) - failed to lock (cmphl!=0)e[0m
e[1me[31m[ERROR] SetFrequencyCGEN(80 MHz) failede[0m
e[1me[31m[ERROR] TuneVCO(CGEN) - failed to lock (cmphl!=0)e[0m
e[1me[31m[ERROR] SetFrequencyCGEN(440 MHz) failede[0m
>>> Call SoapySDRDevice_setFrequency at 1757.5 MHz
e[1me[31m[ERROR] SetFrequencySXR(1757.5 MHz) - cannot deliver frequencye[0m
[INFO] Rx calibration finished
>>> Call SoapySDRDevice_readStream
>>> Error SoapySDRDevice_readStream returned -1