Gqrx for limeSDR on RPI3

Thanks again. The catch is that apt-get install fails because it does not know how to find limesuite et al.;
the previous step in &3.2 of http://wiki.myriadrf.org/Lime_Suite,
sudo add-apt-repository -y ppa:myriadrf/drivers
does not work because it could not find a distribution template for Raspbian/jessie.
So, will need to build everything from source without repository access.

I have to guess that the RPi is usable for something since people are building the software. And sometimes just making different combinations work is the motivation and no more. But certainly there are other uses for this combo.

Nope …

Works with reduced displayed bandwidth … but can still tune entire spectrum

Dosent Rasp use PPA’s too ?
Kinda sucks not being able to pull most pre-req’s with apt-get build-dep

PPAs are for Ubuntu where as the official Raspbian OS is based on Debian. Theoretically, a PPA might still work but neither Gqrx nor GNU Radio is available for ARM from the PPA. So all you get a bunch of potential conflicts when trying to install gqrx and GNU Radio from the official repository and some available driver packages from the PPA.

I thought we were last talking about LimeSuite, SoapySDR, GnuRadio and drivers for PPA and not being able to use build-dep to down load most of the needed pre-req’s … before building LimeSuite, SoapySDR(pothos) then gqrx or pihpsdr

@robertkb,

I should have been more specific with the installation, but yes it does have to be compiled from source and it’s not terribly hard to do with the Unix instructions they provide (that also work with the Pi for compiling). I have the LimeSuite and SoapySDR environments installed on my RPi3 and they are functional (except LimeSuiteGUI that needs higher horsepower video drivers that aren’t for the RPI3). I’m justing waiting for John (G0ORX) to mature this a little more such that discovery of the Lime is capable so it can be launched. It works like a charm with my Red Pitaya SDR. THEN we would have a transceive app for the LimeSDR way ahead of the planned finalization of SDRConsole.

73 de Marty, KN0CK

Thanks Marty. Yeah, I had originally installed soapy&lime on Ubuntu using “step 2.1”, but
later realized that to have access to the source and libraries so I could roll my own C/C++ apps using
the soapy API, I needed to install via “step 3.1.1” and “3.2”; so I did that today, and after cleaning
up some debris left over from the original installation (using tips offered by you and others in the
forum, thank you all very much), I now have the whole enchilada in Ubuntu (actually in a VM on a 5
year old MacBook Pro, so no USB 3.0 for me just yet), and gqrx works there just fine too.

So next I hope to build it all from GIT on the RPi3, and I will be then able to develop apps for that,
which will be running headless; but it would still be great to have gqrx there too, as a “what’s
out there” monitor and debugging aid when I feel like plugging a monitor in.

-robertkb

1 Like

Finally got back to this again. Built soapy and lime on the RPi3 from GIT; a revelation was that after sudo install
you need to enter sudo ldconfig; this is not necessary for Ubuntu, but it is for Debian/Raspian.

I copied the new libLMS7Support.so to gqrx-2.6-rpi3-2/lib/SoapySDR/modules0.6-dev/ and updated the
udev entries.

The newly compiled version of SoapySDRUtil works okay with –find and –probe, but when I start gqrx
(driver=lime,soapy=0), the result is:

[ERROR] SoapySDR::loadModule(/home/pi/gqrx-2.6-rpi3-2/lib/SoapySDR/modules0.6-dev/libLMS7Support.so)
_ dlopen() failed: /home/pi/gqrx-2.6-rpi3-2/lib/SoapySDR/modules0.6-dev/libLMS7Support.so: undefined symbol: ZN8SoapySDR6Device18setFrontendMappingEiRKSs

FATAL: SoapySDR::Device::make() no match

I get the same error message if I run the distribution version bin/SoapySDRUtil.

So, I’m wondering if I missed a flag or setting somewhere…

I don’t think you missed anything. It looks like that the compiler I used to create the gqrx binary and the one on Raspbian do not generate compatible binaries. Bad luck. :disappointed:

I came up with a plan B, which was to install SoapyRemote on both machines and run the server on the RPi3
with the board attached. Running gqrx on the Linux machine, I was able to connect to the board using the
device string device=“soapy=0,driver=remote,remote=tcp://IP:port,remote:driver=lime” However, when I hit the DSP arrow, I got a stream of these errors:

[ERROR] StreamEndpoint::sendACK(), FAILED send() [111: Connection refused]
and
[ERROR] StreamEndpoint::acquireRecv(), FAILED recv() [111: Connection refused]

which looks like a buffering issue of some kind.

btw cmake on the raspberry says:

– The CXX compiler identification is GNU 4.9.2
– The C compiler identification is GNU 4.9.2

@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

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

@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

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.

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

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!

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:

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

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.