Is there any chance that you could include LimeSDR support in your next build of gqrx for the RPi3?
I’ve run the current build using a generic RTL dongle and the pi works well enough for some
things (as you recommended to somebody else, turning demod off helps).
I did the installation described in the gqrx link. When I plugged in my lime [both connectors :-)] [nice that
the RPi3 has 4 USB’s even if they’re only 2.0], lsusb found it okay, but SoapySDRUtil --find
and SoapySDRUtil --find=“driver=lime,soapy=0”
both reported No devices found!
…and follow section 3.2 to install LimeSuite and make sure to do the Linux step at the end.
Once you have both installed, you’ll have all the resources for GQRX including SopaySDRUtil that you can do a quick check to see if it can see your LimeSDR:
SoapySDRUtil --find
It should come back with your LimeSDR found and provide some into on where it’s indexed, etc…If it comes back ‘NOT FOUND’ then get back with me…
The Gqrx v2.6 binary for the RPI2 and RPI3 is from last year and does not include LimeSDR support. It will have to be rebuilt or added by user as a SoapySDR plugin.
Technically, if you build SoapySDR and Limesuite on the PI, then put the SoapyLMS7 plugin into the /home/pi/gqrx-2.6-rpi3-2/lib/SoapySDR/modules0.6-dev/ directory, and install the udev rule, it should work.
I will include it later when the driver and the integration has matured.
Am I the only person thinking that trying to support the LimeSDR on the RPi line of hardware (with one real USB 2.0 port shared with an internal hub between Network, keyboard, mouse and LimeSDR) is a bit like buying a jet engine and trying to superglue it to the back of a tricycle. You can probably do it, but … yea.
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.
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
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.
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.
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:
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.
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: