Gqrx for limeSDR on RPI3

Projects LimeSDR
#23

@robertkb,

I’ve been reading your threads, but you’ve done a lot of other work. Let me ask this:

1.) Were you able to install SopaySDR from source, compile/install it, and perform a successful SoapySDRUtil --find with your LimeSDR?

2.) Were you able to install LimeSuite (except for the 3G video driver support that cannot be supported on RPi3)?

Let me know the answers to the above, because I have all Lime and Soapy resources installed…My LimeSDR cannot be ‘discovered’ using pihpsdr. So just trying to figure out if you had successful installs of LimeSuite and SoapySDR.

Please advise - 73 de Marty, KN0CK

#24

Hi Marty,

  1. yes, these were the steps:

pi@kleio ~ $ git clone https://github.com/pothosware/SoapySDR.git
pi@kleio ~ $ cd SoapySDR/
pi@kleio ~/SoapySDR $ mkdir build
pi@kleio ~/SoapySDR $ cd build
pi@kleio ~/SoapySDR/build $ cmake …
pi@kleio ~/SoapySDR/build $ make -j4
pi@kleio ~/SoapySDR/build $ sudo make install
pi@kleio ~/SoapySDR/build $ sudo ldconfig
pi@kleio ~ $ SoapySDRUtil --find
######################################################

Soapy SDR – the SDR abstraction library

######################################################

Found device 0
addr = 1d50:6108
driver = lime
label = LimeSDR-USB [USB 2.0] 9060B00472212
media = USB 2.0
module = STREAM
name = LimeSDR-USB
serial = 0009060B00472212

  1. yes again, as follows:

pi@kleio ~ $ sudo apt-get install cmake g++ libusb-1.0 libgtk2.0-dev libsqlite3-dev libi2c-dev freeglut3-dev
pi@kleio ~ $ sudo apt-get install git [was not necessary]
pi@kleio ~ $ git clone https://github.com/myriadrf/LimeSuite
pi@kleio ~ $ cd LimeSuite/build
pi@kleio ~/LimeSuite/build $ cmake …
pi@kleio ~/LimeSuite/build $ make
pi@kleio ~/LimeSuite/build $ sudo make install
pi@kleio ~/LimeSuite $ cd udev-rules/
pi@kleio ~/LimeSuite/udev-rules $ sudo ./install.sh
pi@kleio ~/LimeSuite/build $ sudo ldconfig
pi@kleio ~/LimeSuite/build $ LimeUtil --info
######################################################

LimeSuite information summary

######################################################

Version information:
Library version: v17.02.0-g88c275b5
Build timestamp: 2017-03-10
Interface version: v2017.2.0
Binary interface: 17.02-1

System resources:
Installation root: /usr/local
User home directory: /home/pi
App data directory: /home/pi/.local/share/LimeSuite
Config directory: /home/pi/.limesuite
Image search paths:
- /home/pi/.local/share/LimeSuite/images
- /usr/local/share/LimeSuite/images

Supported connections:

  • NovenaRF7
  • PCIEXillybus
  • STREAM
  • uLimeSDR

Sorry I don’t know anything about pihdsdr (not a ham, but did radio astronomy in grad school long long long ago).
Good luck!

1 Like
#25

@robertkb,

Okay - then it looks like you’re fully set for any apps that can be used with the LimeSDR when they arrive for the Pi3. Actually, pihpsdr has a dual receive capability that John Melton (G0ORX) is accommodating in the LimeSDR build he’s working on now. When it’s released, you should be able to tune from HF to SHF using those receivers on the Pi3. Keep your ear to the ground on that one…And that’s not to say that @csete may rebuild GQRX for the Pi3, too…But we’ll have to wait until Alex can make that happen.

73 de Marty, KN0CK

#26

I made a new package for RPI3 that includes the LimeSDR driver. Sadly, it is not working for me but fails when trying to set the bandwidth. Perhaps the LimeSDR needs more power than what the RPI3 can deliver, so I am making the package available for others to try:

https://github.com/csete/gqrx/releases/download/v2.6/gqrx-2.6-rpi3-3.tar.xz

You will need to install libsqlite3.

Sorry, but this is all I can do for now.

#27

What’s the resource load showing for the cpu’s

#28

Thanks Alex! I was able to get it to run via ssh -X from my Mac, starting it from the command line. The
window saying it was unhappy with the settings, do I want to edit them, popped up and I said Yes, then the
device IO settings window popped up and I was able to modify the BW from the default 0.0 to 5.0 MHz, left
the sample rate at 1.8 MHz, and the main window popped up, I chose the LNAL antenna, and now have a
waterfall of a portion of the USA commercial FM band. Linux top in another window says gqrx represents ~41%
of the CPU load; sshd, sending the pretty waterfall over to my Mac, is using 11%. When I turn the demodulator
back on (wideband stereo) the gqrx load goes up to ~275% but the water keeps pouring down.

BTW this was the second time I started it. The first time it crashed trying to set the bandwidth, just as you said
happened to you. I am not going to press my luck and try to start it up again tonight!

#29

Don’t forget that on Raspberry Pi Ethernet is hung off the USB, so you’re sharing the bandwidth of a single USB 2.0 port between the LimeSDR and network. This sounds like a recipe for disaster, sadly :frowning:

#30

I wrote that it is not working for me, so the CPU load is 0% :wink:

#31

That’s cool! Do you have it connected through a powered USB hub or directly to the PIs USB connector?

For me it didn’t matter how many times I started it, it kept giving me an error, but not crashing. It just didn’t work.

#32

I wonder what is the difference between Odroid and RaspBerry that make GQRX not work … OS? Kernel ?

Later today i will get a CPU load level – sample of 3000000 and BW of 60mhz using SSB on 7.2685Mhz

#33

A little bit of everything. I think the biggest drawbacks of even the latest Raspberry Pi are:

  1. USB bandwidth shared between USB and Ethernet.
  2. Raspbian keeps binary compatibility with the first generation Raspberry Pis so that the software does not take proper advantage of the CPU features. So sure, you get 4 cores and more MHz but there are useful instructions that are not being taken advantage of.

The last point above is why I started with building my own compiler then build all critical gqrx dependencies from source. Eventually, this lead to gqrx running on the RPI2 and RPI3 whereas the gnuradio and gqrx packages distributed with Raspbian are quite useless.

All that said I’d like to point out that I think they did a really good job with the Rapsberry Pi 3 and Raspbian OS. It’s just that gqrx comes with a lot of bloat and difficult to distribute in a target specific binary form.

#34

I think thats true with any software that is not built by the owners … Quisk is in the same boat.
In the repository of Ubuntu 16.04, Quisk version is 3.7.6 – about 2 years old i think …

#35

Yes, sounds like a train wreck in the making, but I ultimately plan only to control the board remotely (not transport
gobs of data), and it looks as though SoapyRemote will work like a charm for this.

#36

I didn’t use a hub, just the pi usb ports (no other peripherals).

Have not tried it today. Basking in the warm glow of seeing it run last night. Seriously, gqrx does not have
bloat, it has features!

#37

Same as Quisk …

I used a twin lead for power about 7inch long from a 13.8V—>5V@3A switching power supply … it was 5 foot but i was getting crashes from the LimeSDR (i think all LED’s went red – not 100% sure i remember correctly) from low voltage at the LimeSDR.

#38

@robertkb
Perhaps you can run SSH over Wifi instead, to liberate ETH bandwidth?
Also, IIRC you may benefit from installing watchdog and make sure to enable ARMv8.

To tell the RPi3B to start in ARMv8-mode you have to add a new line to config.txt :

arm_control=0x200

But perhaps this is already done in later rpi firmwares… It was a good 6 months ago I last looked at this.

#39

Should work with a 3Ms/s sample with no decimation … as long as drivers for GPU are installed

for a 3 megs of displayed bandwidth …

#40

Hello,

yes it is a problem I have on a different application (SDRdaemon) running on the RPi3. Basically it takes an I/Q flow from the network via UDP and sends it to a HackRF connected to one of the USB ports for RF transmission. I am not able to run the HackRF at more than a sample rate of ~1.2 MS/s reliably. Which is theoretically lower than the minimum but it still works. I suppose this is also a side effect of the sharing of the Ethernet port with the USB.

Best regards,
Edouard.

#41

If data is arriving through the 10/100 Mbit/sec ethernet port, via the one and only real USB 2.0 HS port (on all RPi hardware), then yes. But if you were using a RPi3 with builtin WiFi (~12Mbit/sec) you may be able to increase that a little bit since the builtin WiFi is not via USB.
https://www.element14.com/community/servlet/JiveServlet/downloadImage/38-24733-365232/1259-900/pi3-block-diagram-rev4.png

But if I was trying to move large amounts of data about fast, the RPi would be near the bottom of my list for that function.

Raspberry Tx / LimeMini : throuput not reliable above 2MS
#42

I thought of using WiFi as I supposed it was not using the USB+Ethernet path thanks to confirm this. I haven’t tried it yet but it looks like an interesting workaround.