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.
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.
Now I’m confused too
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.
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
I notice that you are running SoapySDRUtil as root. Not sure why but you should also run pihpsdr as root then. Better yet, install the udev rule to /etc/udev/rules.d/ and run it as a regular user.
Also note the libusb warning, which may result in failure the next time something is trying to open the device. I have that problem with gqrx too.
Thanks for the tips - I’ll make that happen sometime this morning. Is the libusb issue something that will be persistent or is it fixable? Lemme know, and thanks again for the info, Alex -
73 de Marty, KN0CK
I’m not sure, I would think either the liblimesuite or the SoapyLMS7 library does not close the device on exit. Maybe @joshblum can say more about it.
Alex - just tried running SoapySDRUtil --find as a regular user and the app whined about the libusb issue. So I tried it again two consecutive times as root and it worked fine - saw my Lime. I then launched pihpsdr as root and in the discovery mode - - no joy. Still can’t see my Lime.
Can you refresh my crumbling memory on the UDEV rules again - - I want to make that change.
Thanks for the info as I roll along here, Alex -
73 de Marty, KN0CK
there is a script in the LimeSuite directory tree to install the udev rules
called udev-rules of all things …
I would also recommend to power cycle the device after the udev rule is installed because the --reload-rules does not always work.
Nor does sudo ldconfig …
I have had that not be 100% … with installing cmake 3.8
reboot linked it in … what a pain, Linux is not supposed to be reboot dependent i thought …
No OS is reboot independent, though the Unix derivatives are way better about it than MacOS or Win ever were.
You can usually avoid it by updating the paths (LD_LIBRARY and PATH) by hand as that is usually why the reboot. Most times just logging out and back in again or opening up another xterm and running it from there will cover it.
Mike / Alex,
Ran the shell script for UDEV-RULES and rebooted the Pi…Then launched pihpsdr but during the discovery phase it’s only looking at Ethernet to discover devices - it’s like it doesn’t know (or it’s not configured) to look on the USB resources. I looked in the terminal window after it performed a discover and it just searches the ETH0 port…Doesn’t even touch USB for some reason - I have to think this is either a makefile selection or that the functionality isn’t mature yet…
Comments or suggestions will be greatly appreciated… …Because I thought pihpsdr was setup for USB, too…?
73 de Marty, KN0CK