Limesdr on odroid xu3

I am setting up a limesdr board, but I want to use the Odroid XU3 to host ubuntu 16.04, so I need armhf binaries, not x86 ones

I have limesuite and soapysdr installed, and they see the limesdr board.

I have gqrx, and this will start, however the ubuntu binaries are not compiled for soapysdr. Thus neither gqrx nor osmocom_fft can see the limesdr.

Can anyone tell me either
1 where there is a ppa with gr-osmosdr compiled for armhf, and with soapysdr enabled, or
2 the exact location and branch for the source of gr-osmosdr WITH soapysdr in the codebase (so I can git clone it and compile locally)

I think I’m very close to having the limesdr board doing useful work - I just wanted to try to avoid needing another PC just to have ubuntu available
sadly reports it cannot compile armhf binaries, and the listed site doesn’t seem to have any either

Thanks in advance


Hey Dave …

I think iv posted else where about how to go about getting LimeSuite and gqrx working …

in short …

Add the PPA’s to the repository list …

but dont install …


sudo apt-get build-dep gqrx-sdr

"""                         LimeSuite  (follow the case for install)
 ""                          SoapySDR ..... etc

dont forget to run volk to optimise for FFT …

then use either SVN or git to D/L and build/install …

kc7noa - many thanks - I have rebuilt gr-osmosdr, now with soapysdr enabled

gqrx almost works - you have to select “other” input device, then soapy=0,driver=lime and it sees the limesdr board

however there are no entries in the sample rate pulldown list - the only one I’ve had work is 30.12 M. I can’t find any bandwidth that works , and I get

Rx: 30.12 MB/s, Fs: 0.000 MHz, overrun: 0, loss: 0

Fs =0 make me suspicious…

Does any know the magic values for sample rate, bandwidth etc to go in the gqrx I/O device box, so that gqrx works?

Many thanks


I set samp rate at 1*10^6 and BW to 60MHz. no decimation.

But if you have no entries in the pulldown you might have some problem you need to fix first.

I was trying too hard.

When I just set 2.5 or 5 M sps, decimation none, bandwidth 0 (unset), then select antenna LNAL, I can detect a signal from a tracking generator around 93 MHz.

Thus gqrx does work on odroid xu3, at least for low sample rates! (CPU is 83% of one core at 2.5 Msps, onto a remote X server. 270% at 10 Msps) It is very delicate - you cannot restore the settings from a saved setup file, but the hardware works, and the little ARM processor has enough oomph to do useful work

You can do higher sample rates … but you will need to determine what throughput on the USB buss you can do …

I cant go much over 600Kps

I can do 3Msps with 60bandwidth, decimation of 8 … if i go higher than 3msps then i need to use decimation …

stay away from 2.5Msps, on my system (odroid-c2) i get bery large spikes at 6mhz,… i think also 12mhz and 18mhz …

build sopaysdr , limesuite gqrx from git … im not 100% sure you actually need gr-osmosdr – im not 100% sure anymore …

I also have built pihpsdr – but not working all that well yet …

I just rebuilt gqrx, but no different - it still needs type = other etc.

I tried running gqrx displaying on the XU3’s display (not remotely), and it is totally useless. I hit the well known “black screen bug” - hardkernel have failed to fix this in well over a year, so I am abandoning the XU3 - and I strongly recommend no-one purchases the XU4 either, unless you have no need for local graphics.

Now time to find a spare, fairly powerful Intel PC - great pity, but the Mali GPU simply does not work reliably, and I want a dedicated machine to go with the LimeSDR.

Good thinking. I guess this is why there’s a PCI version of the LimeSDR.


I’m using one of these MSI Cube PCs on my LimeSDR (it’s black in color but the same) and it works EXCELLENT and has Win10 installed. You can outfit these with solid state drives, too, and they’re incredibly fast - - here’s the link:

Just a suggestion of a PC in a small form factor for you that has 4 USB 3.0 ports.

73 de Marty, KN0CK

1 Like

Remember that kc7noa is using the odroid C2, which only has USB 2, and hence an absolute maximum of 480 Mbits/s download from the LimeSDR. I was using the XU3, and using its USB 3 connection. I don’t know the LimeSDR’s ADC resolution, but the 10 Msamples/s I was running is at least 21.58*10 or 240 Mbits/s (assuming 12 bit data).

My data was going to gqrx, and the limit was the CPU on the XU3 - which was running FFT over the whole band. If your processing needed less CPU I suspect the XU3 could handle more than 10 Msamples/s - certainly there is no reason to doubt USB 3 could

Where PCI may be useful is in removing the variable latency between data being captured, and arriving over the USB. I don’t know if the LimeSDR can take a 1 PPS feed from GPS and use this to timestamp the received packet - there’s an FPGA and spare pins, so might be possible. IIRC the USRP can stamp against 1 PPS if exact reception time matters to you.


That’s a cute little machine. Over in England they run over $500, so I’ll look first for something a bit cheaper, but still a nice looking machine, and more powerful than my XU3

Thanks for the info


1 Like

That will not change … but should only need to do that once …

The samples per second and Rx bandwidth should also be remembered …

I can run 3Ms/s with no decimation on an Odroid-X2 AND Odroid-C2 …

The C2 has lower CPU useage — because the X2 has a blown HDMI and the CPU’s are also doing video rendering …

I jusr uploaded another video of the Odroid-X2/LimeSDR-USB on 10Ghz Rxing a BH-100 modulated with a CD player set up to be real close to narrow band FM.

I am curious about the Mali. Is the driver on Linux a proprietary blob? Not clear to me what you mean by the black screen bug and remote vs “XU3’s display”. I was looking at these boards and considering buying one. And who hasn’t fixed the black screen bug?

If the Mali is a proprietary GPU I will stay away. Been burned by that before. But Intel is not much better with their CPU’s microcode.


I still use X windows under linux (rather than wayland), and unlike Windows there is a clear separation between the machine with the screen (the X server), and the machine requesting graphical services (the X client)

When I execute gqrx on the XU3, with the LimeSDR plugged into its USB3, it works ok if I use another Linux machine (MMM) as the X server (that is, on the XU3 I type

export DISPLAY=MMM:0

Performance will be limited by the XU3 only having 100 MBits/s ethernet - over which all the graphical output must flow. On the XU4 there is a 1G ethernet driven from USB3 not USB2, so shouldn’t be a bottleneck

If I attempt to use the local screen (connected via HDMI), then sometimes the screen goes black for several seconds - I suspect a GPU stall and reload. Unfortunately whatever gqrx does triggers this immediately, and the display never recovers until X is restarted. or google ‘Mali black screen bug’ to confirm it’s well known, and not fixed in many months. Whose job to fix?

The machine is by hardkernel in south korea, who supply the customised kernel and X server
The processor by Samsung
The GPU silicon design may be from ARM

The chance of you or I having any influence on companies of this size is probably almost zero. So I recommend avoiding the XU3 and XU4, unless you can find someone else who has succeeded in running whatever you want to run, AND who is prepared to tell you the exact versions of the software that work for them. (Real pity- a great little machine - but I wanted to use the local display, and it simply is too unstable)

The Mali GPU is still under valued in Linux/Ubuntu — Samsung is very non surportive is this regard and they are more interested in Android (phone anyone?) – but there is code out that uses all 4 cores and such.

One cavet — and im not sure if its still true … that they use opengl-ES2 drivers that main stream isnt exactly up to speed in using …

The Driver for the Odroid-X2 was best when video was full screen … not so much windowed or in a browser – but plenty usable …

after all … i AM using an X2 with a blown HDMI , so i dont get any benefit from the Mali400 quad core – and i can see 3Mhz of spectrum on displaylink152(162??) USB Touchscreen.

100% with ya there … i no longer suggest the Odroid line – but refer to the Rasp3 – least they use mainline kernel (or close to it) and GPU is much better supported …

Wish i had one to try/use …


I think it can get there, but Alex Csete mentioned that it has to be on a Debian distro because Raspbian doesn’t support PPAs…But it should be possible even if the RPi3 is hobbled by USB 2.0…

73 de Marty, KN0CK

Given a choice between a dedicated USB 3.0 port (with gigabit ethernet) and RPi hardware with a single USB 2.0 port shared by pretty much everything you connect to it including the 10/100 networking, I choose Odroid everytime. But then again I do use them headless, and was totally unaware of any “black screen bug”.

So it’s the HDMI interface you’re using. That’s what was unclear.
I see hardkernel in the linux kernel git master. So hardkernel is not custom. Don’t know about the Mali xorg driver.

Yeah I think the HDMI port falls into the category of “nice to have”. i.e. it’s not the most important feature.

But I do wonder about the state of the HDMI support for odroid since there seems to be missing information here and there.

The kernel mainline seems to have all the support for odroid. Don’t know the state of the X graphics driver.

Having a working HDMI display would be nice for a mobile solution using LimeSDR.


tldr;graphics driver support is a mess