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

Projects LimeSDR
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 ?

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.

SelfTest
SelfTest.JPG986×693 121 KB

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