Gr-limesdr source block stops outputting samples when FIFO is empty


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 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.

Thank you,

How long do you have before the TX/RX stop?

You can reset the LimeSDR-USB by either pressing the SW1 - FX3 reset push-button or by running limesdr_stopchannel from this code:


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

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.

My system is heavy modified and I have a LimeSDR-Mini. However, I have two recommendations:

  • Change chip mode on LimeSuite Sink to SISO. It appears you are only sending data out of one channel.
  • Change Oversample to default for both Sink and Source.

I am able to run this flow graph but my system is under-powered. I had to make many modifications so that gnuradio-companion would stop freezing.

  • I changed analog filter bandwidth to 5e6 for both channels and then I disabled analog filter for both channels.
  • i changed the sample rate to 2.5e6

Thanks for your help. I tried using only SISO and changing the oversample value to default, however the problem still persists.

I will just continue with my work and hope that for my final measurements, the RX FIFO won’t get empty this often.

Hi, @maschi01

What gateware are you using?


The newest one with LimeUtil:
version 2, revision 17


What about your GNU Radio version? I’ll just try to reproduce this issue.


The versions:

~/Desktop$ gnuradio-config-info -v
Screenshot from 2018-10-01 09-50-02

LimeSuite, as stated, 18.06.
gr-limesdr commit 3234d2638359e0b2ff27a7bfca0544dad2de885f from 2018-06-18


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.

1 Like

Thanks @Osvald, I will update and try to reduce system load.

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 am using Ubuntu 64 bit 18.04 LTS

not too many people report success with Ubuntu 18.04 LTS. Most are running either Ubuntu 16.04 LTS or Windows.

Thanks for this info, I was just about to set my system up new. Also found this:

I will try it with 16.04 and give an update tomorrow.


There could be various reasons you keep seeing what you see. Even damaged cables/ports could be a part of your problem.

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)

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 :slight_smile: