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,
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,
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?
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?
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.
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 As I say, the locations of the SDR driver infrastructure software is not application specific — unless delivered packaged via Docker or a Snap etc.
Perhaps you can clarify how you installed soapysdr on your present setup. In any case, the generic advice is:
If you install from PPA / .deb => need to install the -dev package
If you install from source in default location => Need to do nothing
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).
As I say, the locations of the SDR driver infrastructure software is not application specific — unless delivered packaged via Docker or a Snap etc.
