the detect portion is not corectly detecting my Lime – and the Lime is working, iv updated to current images with the LimeSuiteUtil …

ime_discovery: length=2 devs->size=5
lime_discovery:device key=default_input val=True
lime_discovery:device key=default_output val=True
lime_discovery:device key=device_id val=0
lime_discovery:device key=driver val=audio
lime_discovery:device key=label val=PulseAudio
lime_discovery found 2 devices

SoapySDRutil detected it fine too …

kc7noaodroid@odroid:~/Downloads/pihpsdr$ SoapySDRUtil --find=lime

Soapy SDR – the SDR abstraction library


Found device 0
default_input = True
default_output = True
device_id = 0
driver = audio
label = PulseAudio

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


What else did you do / change to get Lime detected in pihpsdr?

Never mind …
pihpsdr cant handle more than one device using the same driver … after removing the SoapyAudio.so module , it detected and ran. pihpsdr even ran — over a wireless network —

I would not of thought pihpsdr could show FFT/waterfall info over a wireless network, –


Are you using the package that John just put up there? If you are, send me, or post, the Makefile for that and let me know if there are any SoapySDR resources that have to be installed to make pihpsdr operate with the Lime. Right now, I can’t get it to compile with the current Makefile without the compiler griping that it can’t fine Device.h and then stops compiling altogether. I’d like to beta the app, but the compilation has been less than stellar when I uncomment the LimeSDR in the Makefile.

Lemme know how you’re doing it when you have a chance - thanks,

73 de Marty, KN0CK


I’m having problems getting mine to compile with the current Makefile…When I uncomment the LimeSDR portion in the Makefile, the compiler whines that I don’t have SoapySDR/Device.h and I have a SoapySDR subdirectory in the pihpsdr subdirecrory with a file called Device.h and Constats.h in there to make it happy…No joy. What’s the strategy to making this compile for pihpsdr for the Lime? Lemme know when you have time - thanks,

73 de Marty, KN0CK

Indeed, you have to tell the Makefile how to find the headers. Here is my diff, I have marked the place I think you need to modify in bold. Can you read it?

alc@atlantis:~/sdr/limesdr/pihpsdr.git$ git diff Makefile
diff --git a/Makefile b/Makefile
index f6d25ab…0a3ae45 100644
— a/Makefile
+++ b/Makefile
@@ -4,7 +4,7 @@ GIT_DATE := $(firstword $(shell git --no-pager show --date=short --format=“%ai”
GIT_VERSION := $(shell git describe --abbrev=0 --tags)

uncomment the line below to include GPIO


uncomment the line below to include USB Ozy support


@@ -49,7 +49,7 @@ ozyio.o

uncomment the line below for LimeSDR (uncomment line below)


uncomment the line below when Radioberry radio cape is plugged in

@@ -69,8 +69,9 @@ endif

+LIMESDR_OPTIONS=-D LIMESDR `pkg-config --cflags SoapySDR`
+SOAPYSDRLIBS=`pkg-config --libs SoapySDR`

Note the back-ticks surrounding the pkg-config.

Im not installing in custom locations … so dont need to export anything …

Marty … did you build SoapySDR / LimeSuite etc … or use PPA ?

So far …im trying to keep to building from git as much as possible …

Does SoapySDRUtil --find=“driver=lime” find more than one device?(ie did you try out Soapyaudio too?)

I didint have any issue with Device.h and Constats.h … and i build pihpsdr in my Downloads folder

Humm … just now …

kc7noaodroid@odroid:~/Downloads/SoapySDR$ git pull
remote: Counting objects: 186, done.
remote: Compressing objects: 100% (184/184), done.
remote: Total 186 (delta 153), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (186/186), 223.34 KiB | 0 bytes/s, done.
Resolving deltas: 100% (153/153), done.
From https://github.com/pothosware/SoapySDR
b0d6e6a…b0ebaec master -> origin/master
ed68de5…32293dc gh-pages -> origin/gh-pages
Updating b0d6e6a…b0ebaec
include/SoapySDR/Device.h | 67 ++++++++++++++++++++++++++++++++++++++++++±-----------------------
include/SoapySDR/Device.hpp | 64 +++++++++++++++++++++++++++++++++++++++±-----------------------
lib/DeviceC.cpp | 4 +±-
3 files changed, 85 insertions(+), 50 deletions(-)

For me it only detects the LimeSDR because I don’t have soapyaudio installed and no other devices were attached when I tried.

I too have everything built from git.

cant seem to control the VFO as of yet …


Modified the PiHPSDR Makefile to yours and the complier is still griping about not seeing the SoapySDR resources - especially Device.h. How are you handling the SoapySDR resources?

Thanks in advance, Alex,

73 de Marty, KN0CK

If you installed soapysdr into a custom path you have to set the PKG_CONFIG_PATH accordingly


where PREFIX is the prefix you used during installation.

@martywittrock I would strongly discourage installing stuff into custom locations — this is just going to make support far more difficult.


Andrew, I’m not putting files in custom areas - I’M ASKING FOR GUIDANCE because, like every other development program, there is no guidance being documented that anyone can follow - that’s why I ask…!


That’s great to hear! Looks as though previously you were, e.g.:

If you install stuff into non-standard locations, that means that when you then subsequently build additional software that depends on it, you will need to tell it where you installed it to. This just makes for headaches… The standard approach is to not specify custom install prefixes and then applications which depend on certain components know where to look for them.


Andrew…That’s a post from May of 2016 in terms of GQRX…Context, please? I am asking for guidance from those that are working on PiHPSDR to provide the information on the paths for SoapySDR and what SoapySDR resources are present…A completely different development effort. Please stop, okay? It’s fair game to ask on a forum for guidance - I’m not blazing a new trail.


Hi Marty,

The context is that SoapySDR and Lime Suite etc. always get installed into standard locations, unless you specify your own custom prefixes. So if you didn’t do this, any software, whether Gqrx or PiHPSDR, should find them. The standard prefixes are /usr if you install from packages and /usr/local if you install from source.

They’re not application-specific, or at least shouldn’t be unless they are distributed with it. So when attempting to load a library, applications should look under /usr/lib and /usr/local/lib.

Apologies if I have caused offence. I’m just trying to provide guidance :slight_smile: As I say, the locations of the SDR driver infrastructure software is not application specific — unless delivered packaged via Docker or a Snap etc.

Now I’m confused too :relaxed:

Perhaps you can clarify how you installed soapysdr on your present setup. In any case, the generic advice is:

  1. If you install from PPA / .deb => need to install the -dev package
  2. If you install from source in default location => Need to do nothing
  3. If you install from source in custom location => Need to set PKG_CONFIG_PATH (along with PATH and LD_LIBRARY_PATH)

Installing from source to custom location is a very powerful tool when testing multiple versions of a software package, but it does require a proper understanding of the build process. It is also useful when testing software that does not implement the “make uninstall” target.

Marty …
Go back into the folder that you used to build SoapySDR

re-issue a sudo make install and see where its getting installed at … (then go to that folder and see if its actually there.
Or just re-build SoapySDR after a git pull …

If this does not change anything … then you might need to make a link from where pihpsdr is trying to look to where SoapySDR installed it …

It should have been in default locations – but that does not mean they will always find stuff – case in note, Codec2 on Arm/Ubuntu14 was not quite in the same place – kinda depended on who’s default you were talking about !!!

Do you get any errors or warnings when issueing a sudo ldconfig (twice)


So as I am so apt to say ‘Taking matter into my own hands…’ I finally installed SoapySDR (again) and LimeSuite (the pieces you need for PiHPSDR to compile right) and here are the results:

Soapy works because I can interrogate it by itself and it’s seeing the Lime doing a ‘Find’ and ‘Probe’ (see pics), but it’s just not seeing it in the PiHPSDR app when it hunts for the attached devices (see the PiHPSDR screen and the setup). I JUST had the Lime plugged in since I didn’t want it to hunt for my Red Pitaya - so the Lime was the only active device on USB 2.0 (Pi3 has no USB 3.0 resources - but Soapy still finds it as a USB 2.0 device).

Did a clean compile of PiHPSDR, too, and it compiles fine with all the resources there and installed in their proper locations (nothing custom here, okay?). So I’m not sure why PiHPSDR isn’t seeing the Lime - the Make file has been de-commented for the LimeSDR so it will compile. Compiler didn’t whine once about anything - compiled perfect. So I’m not sure how mature PiHPSDR is unless anyone else has it working on their setup (I know John’s working on it and since last July has the Lime receiving on one antenna port on PiHPSDR).


73 de Marty, KN0CK