Where can I get Soapy modules, already built, for my users?

[fyngyrz]

I'm working on a server that I hope to provide my users with a Soapy-based interface between my SDR application and various Soapy supported SDRs. I have the build working, and it discovers the RTL module, which I managed to get built. I can use that to complete the server, presuming the following issue can be addressed:

The problem I'm having is, SDR module availability. What I've found so far requires being built via homebrew, and homebrew rarely runs properly / to completion on my 12/24-core, 64GB OSX 10.12.6 machine, as Apple declines to let me upgrade the OS any further, and the homebrew people have, for whatever reason, imposed some dependencies on their system for (a) later version(s) of MacOS. In this case, homebrew built the RTL module (so at least I can test with that), but it refuses to build the airspyhf module, for instance.

So: Is there a place where pre-built drivers for various SDRs are available, that can simply be installed in the proper folder and then are usable?

I'm particularly interested in functional SdrPlay and AirSpy driver binaries.

[zuckschwerdt]

MacPorts runs fine on Mac OS X 10.12 Sierra. They have the modules prebuilt also, e.g. http://packages.macports.org/SoapySDRPlay/ Maybe try: port install SoapySDR SoapyAirspy SoapyAirspyHF SoapyAudio SoapyBladeRF SoapyHackRF SoapyPlutoSDR SoapyRedPitaya SoapyRemote SoapyRTLSDR SoapySDRPlay SoapyUHD Using CMake to build the modules is working cleanly too. You would need to collect all the interesting modules and the base libraries that are wrapped.

Caveat: SoapySDR has a module lookup path and that would be specifc to the installation method, e.g. /usr/local/... when building yourself or /opt/local/... with MacPorts. You would likely want to customize that path to point to some resource folder in your application.

[fyngyrz]

They have the modules prebuilt also

Thank you so much for the link to the built modules.

So far, I've used MacPorts to install them; and a lot was installed, including a bunch of device-specific libraries. However, my application only finds the RTL SDR; and looking in /opt/local/ I didn't find anything but the .tgz files; I have both the SdrPlay and the AirSpyHF attached to the system as well as the RTL stick, so I would have expected them to be found by my app if the install had worked.

Next, I'll try downloading the modules directly and putting them wherever the RTL module ended up. Now all I have to do is find that - at least I know it's around and accessible, as my app does find it via SoapySDR.

So much to learn...

[fyngyrz]

Further... I found the modules, and I found all manner of libraries and commands scattered around (airspy-this-and-that, etc.), and I copied them from the macports locations to the same location as my rtlsdr lib and module files... still no joy

[fyngyrz]

Can you tell me if users install SoapySDR on their own, will it normally install everything they need? To put it another way, if I can get the RTL support, when selected, fully up and working with all the various antenna, gain, ranges, sample rates and so on, is it reasonable to expect SoapySDR will take care of the rest for them? I'm really worried about this, because the install here is being so uncooperative.

I'm really concerned with how difficult this is to get going on my end. There's no way I could expose my users (well over 20,000 of them) to this kind of thing — they'll outright bury me in requests for support.

[fyngyrz]

I'm getting the following...

...so it looks like the macports versions are behind the soapysdr in such a way as to be incompatible

The macports modules / libraries are behind the development version, I'm guessing.

[fyngyrz]

With the 0.8.0 library, I get this...

...Which, when I select the RTL SDR, allows my app to set it up and display whatever options there are...

..when I link with the 0.7.2 library, I get this...

...which at first thought "oh, it's giving me audio sources to do IQ streaming from", but then (a) the RTL SDR is now missing, which might be because that module is the wrong ABI now (I'll chase that next), but worse, (b), selecting one of those sources blows up the sdr selection code. Going to see if I can debug what's happening there, presuming that I should even be getting those audio devices...

[fyngyrz]

ok, utilizing the 0.7.2 Soapy lib, I'm doing the following once the item is selected (when picking Apple built-in line input):

str_list = sdr->listGains( SOAPY_SDR_RX, 0);
if (str_list.size() > 0)

str_list.size() is returning 6148914691236517205 (lol) which causes additem loop to crash when I try to load the drop-down with the details in the list. So I either shouldn't be calling this with audio devices (how would I know that? There's nothing in the sample code that indicates this) or the library is broken, either in that it's even showing me these items, or in that it's giving me an insane return when it really should give me zero if there are no selections to be made.

Do you have any tips for me here?

[fyngyrz]

I wrapped the above with...

if (sdr->hasGainMode(SOAPY_SDR_RX, 0))
{
}

...thinking that it might catch the issue, but no, it returns true and the returned length of the list continues to be absurd. More anon...

[fyngyrz]

yeah... if I remove the requests / enumerations for gains, frequency range, and samplerate range, selecting these audio items doesn't (at least) crash. In all cases, I'm getting invalid results.

[SDRplay]

I don't know if it will help you, but when you install the API from our website, we also install SoapySDR and SoapySDRPlay ready to go. - https://www.sdrplay.com/downloads

[fyngyrz]

I don't know if it will help you, but when you install the API from our website, we also install SoapySDR and SoapySDRPlay ready to go. - https://www.sdrplay.com/downloads

Hmm. Does your install set up all of the modules, or just your own?

I should also mention that at this point, I've built soapysdr 0.8.0 (worked, as far as the RTL sdr goes anyway), attempted to install using homebrew, which blew out during module builds but may have installed some portions of soapysdr of "some" version "somewhere", and installed using macports, which went to completion, but is the 0.7.2 version, and has the audio device problem I show above, and doesn't appear to have rtlsdr support at all.

[fyngyrz]

I've parsed the iteration of the device to see if the driver tag is "audio" and if so, I'm not asking for those three settings; that, at least, has made it conditionally skip the broken library calls.

Now if I can get the RTL driver up and running with the 0.7.2 version... have to find the 0.7.2 RTL driver...

[SDRplay]

We only provide and support the libraries for our own devices.

[guruofquality]

@fyngyrz you may want to read this: https://github.com/pothosware/SoapySDR/wiki/ConfigGuide#avoid-simultaneous-installs You need to be really attentive when it comes to dev environments, search paths, execution paths. I think this at least explains what you are seeing.

[fyngyrz]

We only provide and support the libraries for our own devices.

@SDRplay :: Okay, thank you.

Can you tell me what version your api bundle would install? 0.7.2, 0.8.0, or something else?

I have an RTL driver for 0.8.0 that works, and audio drivers that might work for 0.7.2; so I just want to know what I would be getting into with a fourth install of SoapySDR before I jump. :)

[fyngyrz]

You need to be really attentive when it comes to dev environments, search paths, execution paths. I think this at least explains what you are seeing.

@guruofquality :: I understand that.

Unfortunately, when the 0.8.0 dev version didn't install the available modules, and the porthos homebrew mechanism failed mid-install and left me with who-knows what, and macports installed 0.7.2 — that's a mess not of my own making, but now, there it is.

I can switch between them — the respective dylibs look at different filesystem locations to find modules and libraries — by switching which .dylib I link my app to. I want to get things settled down to one or the other, but I have yet to find a consistently working set of modules/libraries that matches either the macport 0.7.2 dylib or the dev 0.8.0 dylib.

The development environment should provide everything needed all at one fully compatible revision level and install it all properly; unfortunately, that is not the case. And then there are the bugs in the SoapySDR device enumeration calls complicating matters.

Another possibility — yet another install /sobs/ — lurks with the SdrPlay folk's downloadable API install, but I'm waiting to hear what version that installs before I jump into potentially deeper waters.

[SDRplay]

0.8

[fyngyrz]

@SDRplay :: Running OSX 10.12.6 here. Should I install V2.13 or V3.07 ?

The unit has the following on the back...

SDRPlay MODEL RSP Wideband USB Radio Receiver [FCC] [CE] [no-trash] [✔️RoHS] SN - RSP#121115#10#425

...black plastic case, one antenna connector, one USB Type-B connector.

[SDRplay]

API 2.13 version is almost 2 years old now so that will be SoapySDR 0.7

API 3.x is currently in beta testing. This is SoapySDR 0.8

We've had reports that on some versions of MacOS the 3.x API has some issues which we are looking at. I'm running it right now on El Capitan without a problem.

Hope that helps.

Andy

[fyngyrz]

@SDRplay :: Thank you. I downloaded your install, backed up the 0.8.0 level RTL stick module, uninstalled the macports and homebrew versions, installed yours, copied back the RTL stick module, and what do you know... it all works. :)