I’m currently working with two LimeSDR boards to get a basic transmission going and do some measurements for my thesis. I’ve done a lot of programming by now using the API, but decided to switch to GRC to get my transmission set up quicker.
So I followed the GRC tutorials and, step-by-step, wanted to start my measurements. One of the first steps was:
signal or vector source => gr-limesdr tx (LimeSuite Sink) => gr-limesdr rx (LimeSuite Source) => GUI
I will attach a screenshot of the flow graph.
The TX spectrum looked just as expected on my spectrum analyzer. Then I’ve noticed that, after a random time, the RX GUI “freezes” (turns out later, it just stopped getting input). I’ve put a “Probe Rate” Block after the source, bc I expected the sample rate to be wrong. But it was correct, however as soon as the GUI froze, the Probe no longer debuged the sample rate, which meant that the RX stopped outputting samples.
I’ve changed the source_impl.cc of gr-limesdr to print out periodical stream status updates (setting stream_analyzer = true).
It turns out that as soon as the RX FIFO is at 0% the ret0=LMS_RecvStream(…) call of this implementation returns zero all the time, meaning it could not get any samples. You can also see it in the RX rate going to 0MB/s in the screenshot. Interestingly the TX FIFO is always full.
This concludes that the thread in the ReceivePacketsLoop either exits or gets blocked.
My question is, could I be right with this? Or am I missing something? How can I fix this?
I am relatively new to this topic and in this case I can’t debug the LimeSuite code to see what’s wrong.
You can reset the LimeSDR-USB by either pressing the SW1 - FX3 reset push-button or by running limesdr_stopchannel from this code: https://github.com/emvivre/limesdr_toolbox
The time is random, ranging from a few seconds to ~2 minutes. But it always happens when RX FIFO buffer is at 0%.
The device does not really stop. I still get the periodical status updates from both devices.
A small update:
I’ve ran “ps -o nlwp” on the python process that get’s created by gnuradio companion to get the number of threads for this process. The number was the same before and after the freeze.
So maybe no thread exits or gets cancelled?
I’ve tried a lot of configurations, it always happens sooner or later.
Starting to think the problem is in my software & to reinstall some things.
Would someone be willing to try the flowgraph? You can find it here https://pastebin.com/NYmU7Cz1
The freezes might take some time. If it doesn’t freeze I guess I have some problems on my site.
Btw. I use LimeSuite 18.06, build date 2018-08-07.
Well for now I have to agree with @yindra. It looks like that it is not Lime related issue since I don’t see any dropped packets or other problems with data transmission on my PC. I tried disabling FFT Sink or Constellation Sink on RX side and it looks like reducing load on a system helps a lot (at least none of the GUIs freeze). It is generally hard to debug these kind of issues when they are system load related. You could try updating GNU Radio, since there is newer version. Maybe that could help for your system.
So I’ve just realized that the FFT viewer in the LimeSuiteGUI application shows very similar behaviour as the GUIs in the GRC.
So I must have messed something up in the Lime API / LimeSuite Library / …
Is there a nice way/tutorial to do a clean removal and a new install?
I’ve set up my system with 16.04. So far most things work, unfortunately gr-limesdr shows the same error as here:
The solution you proposed there @Osvald did not work for me. I’ve also tried to manually move all attributes in the .py file into one line, in case python doesn’t like the line breaks, as suggested here
with no success.
Not sure how to proceed now.
I’ve installed gnuradio via apt-get, the version is 3.7.9
Python is on version python3.5 (python --version yields 2.7.12)
EDIT:
This did it:
I’ve ran “sudo apt-get install python-swig” before, I thought that would be enough.
I kind of bypassed my original problem.
Using Ubuntu 16.04 LTS was not the solution - I still had the same freezes.
However, after thinking about what @Osvald said about HW specific problems: I ordered the LimeSDR with aluminum casing, which means that the order came with USB 3.0 cables that have an additional USB 2 connection for (more/better?) power supply. This was the first time I plugged them both in and now the RX FIFO never reached 0%, which meant that the GUI never froze.
I will order a externally powered USB 3 hub, this should definitely do the trick.
Thank you both @Osvald & @yindra for your help, now I can finally continue with my thesis