LimeSDR: Failed to receive stream

[romeojulietthotel]

Expected Behavior

Capture signals and display them.

Actual Behavior

No signals captured. Here's the error on stdout:

[WARNING::LimeSDR.py::receive_sync] LimeSDR: Failed to receive stream

I can access the board fine with LimeSuiteGui

Steps to Reproduce the Problem

1. build limesuite from git
2. python3 setup.py install --without-hackrf --without-rtlsdr --without-airspy --without-usrp
3. urh
4. try to record on a known strong freq.

Platform Specifications

• Python Version: 3.6.0
• Operating System: linux
• Version of URH: git master (1.8.4)
• URH was installed
  [X] from source

I think this may be related to issue #297 but I'm not sure. Filing this in case it's unrelated.

[jopohl]

Thanks for testing the most recent version of LimeSuite @romeojulietthotel . For a more detailed analysis from URH you could do

cd tests
python TestLimeSDR.py

But I fear the LimeSuite API keeps changing in non backward compatible way. Not sure how to deal with this.

[romeojulietthotel]

Couple of things, I had to modify TestLimeSDR.py and move the from urh.dev.native.lib import limesdr due to some kind of namespace clobbering (or something). I placed it after import sys and before import os.

But maybe this is all due to python3.6.0?? Or have I done something wrong and it's revealed in the output?

I do not know how to reset the build environment between invocations of

python3 setup.py install --without-hackrf --without-rtlsdr --without-airspy --without-usrp

so possibly that is part of the issue here?? e.g. I noticed urh/tmp/ does not get cleaned out

======================================================================
ERROR: test_cython_wrapper (__main__.TestLimeSDR)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./TestLimeSDR.py", line 87, in test_cython_wrapper
    print("RX 0 current antenna BW", limesdr.get_antenna_bw(limesdr.get_antenna()))
  File "src/urh/dev/native/lib/limesdr.pyx", line 308, in src.urh.dev.native.lib.limesdr.get_antenna_bw (src/urh/dev/native/lib/limesdr.cpp:5419)
OverflowError: can't convert negative value to size_t

[jopohl]

You can build / rebuild the device extensions by calling

python src/urh/cythonext/build.py

right from inside the cloned repo. This way, there is also no need to install it, you can directly call the tests from the tests directory.

The error is pretty interesting indeed. It indicates, that the output of limesdr.get_antenna() is negative, probably -1, so LimeSDR did not set the antenna properly. Could the post the full output of the test run? I guess the root of this problem lies somewhere before.

[romeojulietthotel]

You're right about the problem coming before. I didn't scroll back far enough (I thought I had).
It was a usb device permissions problem. I resolved that and now get this:

Looks very similar to issue #233 which I'll look at and try the FIFO sizes. This starts to feel like whack-a-mole in that a problem is fixed here but it was actually because there was a subtle bug in limesuite, then the limesuite bug is fixed and our fix is no longer working.

TuneVCO(SXR) - VCO too low
Setup stream 0
Start stream 0
Stop stream 0
Destroy stream 0
b'\x00\x00\x00\x00\x00\x01\x00\xba [...] (more hex bytes not displayed)'
TuneVCO(SXR) - VCO too low
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted

[jopohl]

Thanks for your effort so far! Did you have any success with tuning the FIFO sizes? In fact, lowering the FIFO size may help here, because a quick

$ grep "bad_alloc" src/ConnectionSTREAM/ConnectionSTREAMing.cpp 
    catch (const std::bad_alloc &ex)
    catch (const std::bad_alloc& ex) //not enough memory for buffers

indicates, that it may run out of memory somehow.

[mntnmn]

I have a similar problem except after two blocks of hex bytes I get a dtype error on line 416 of limesdr.pyx for "expected 'float' but got 'complex float'" for 'samples'. I have tried a few things to recast 'samples' but I am not familiar with cython and the internet has not been much help. I have yet to get a meaningful signal from URH, even hooked to a signal generator. Many other programs are working on my LimeSDR.

[jopohl]

@mntnmn that is a pretty weird error indeed! Could you try to change urh/dev/native/LimeSDR.py:133 from

return complex_samples.view(np.float32) 

to

return complex_samples.astype(np.float32) 

just to be absolutely sure we pass a float array to Lime API.

[mntnmn]

I'm back at the SDR and tried the edit. Still the same. Exact message

...
E

ERROR: test_cython_wrapper (main.TestLimeSDR)

Traceback (most recent call last):
File "tests/TestLimeSDR.py", line 106, in test_cython_wrapper
print("Send samples", limesdr.send_stream(samples_to_send, 100))
File "src/urh/dev/native/lib/limesdr.pyx", line 416, in src.urh.dev.native.lib.limesdr.send_stream (src/urh/dev/native/lib/limesdr.cpp:6797)
cpdef int send_stream(float[::1] samples, unsigned timeout_ms):
ValueError: Buffer dtype mismatch, expected 'float' but got 'complex float'

---

[jopohl]

Oh so you are running the unit test. I just had a look and added a cast to the test data in 571cd68. However, as you could receive during tests your LimeSDR should work in the main application, doesn't it?

[mntnmn]

The received signal is meaningless. Like noise that is amplified and digitally distorted. It jumps when I touch the board in the receive area. But not the way I see it in other programs. That is why I ran the test mentioned in this thread. It seemed like the same problem until I got a different error. I am just trying to find out what is and is not working so I can describe the problem better. Poking around at the application has turned up a few symptoms. Some are from the Lime, such as it gets locked up when changing sample rates and bandwidth while it 's streaming. But I can not see any modulated signal or even a plain carrier on URH spectrum display.
Could it be related to that 'vco too low' message? I notice this causes me problems when I am using LimeSuiteGUI to the point of quitting the program and restarting.

[jopohl]

Just performed a grep -r "too low" in LimeSuite Code and found this in src/lms7002m/LMS7002M.cpp:1263-1268:

cmphl = (uint8_t)Get_SPI_Reg_bits(addrCMP, 13, 12, true);
if(cmphl == 0) //VCO too low
{
    this->SetActiveChannel(ch); //restore previously used channel
    return ReportError(-1, "TuneVCO(%s) - VCO too low", moduleName);
} 

so it may definitely be a cause of the problem, because it restores the previously used channel and therefore won't tune to the channel that URH wants. Any idea what we can do about that?

[mntnmn]

I think this is one for dicourse.myriadrf.org. I sometimes make a change in LimeSuiteGui that gives this error or 'too high' and I am unable to even get back to where I was before. But if I start over from the beginning I may be able to make the change I wanted. I think this is causing errors in other programs, too, but is not output to see.
The test routine is still not working. I think it really is getting a complex. It complains about the recast but continues, then segfaults.

[jopohl]

@mntnmn you are right, there was another error at the bottom of the test. This is fixed now. Just got hands on my LimeSDR and could verify the test is working now.

[mntnmn]

After looking through the test code and the output I think the TuneVCO message is unrelated. Just the last thing in the error message queue.
Two things:

1. You are using the LNA_H input because it was selected by power up default. This is better for over 1GHz.
2. You are not setting the Tx frequency so it stays at 1904.655, also default. No print for this but it probably keeps Tx band 2 output also.
   I still get a segfault, after the 'Close: 0' message.

In the application I can get a meaningful signal by changing the frequency and sampling rates to something significantly different, then back. It seems there is something wrong with the initial settings.

[jopohl]

Thanks for this hint, I just had a deeper look on that.

It seems that in recent driver versions the channel of limesdr needs to be activated at first or no other settings will take effect. I fixed this in 4e98ef3. I could verify this is working on Arch Linux with LimeSuite 17.09 and Ubuntu 16.04 with LimeSuite 17.06.

[jopohl]

I will close here, as the issue should be fixed with 4e98ef3. Drop a comment here or simply create a new issue if there are still problems with LimeSDR.

[romeojulietthotel]

Will try this out as soon as I can. Thanks for all your efforts. I have been doing a clean up of my environment since it was getting too fragmented and so nothing's as it was.

I was successful building gnuradio.git/soapy/limesuite and that is the hard part, so next I will work on urh.

[romeojulietthotel]

I did a git pull and re-ran what I always (see my comment above) use but get a failure not finding pyqt5.
I installed all the packages following the instructions.

Maybe I'll file a new issue....

[jopohl]

As you mentioned that you reset your environment, maybe a pip3 install pyqt5 will help here? Just a shot in the dark.

[romeojulietthotel]

Yes, I did do that. But I also installed that first via the OS. I also built python3 from source, installed that and then created a virtualenv from that. I have some other things to try.