Discussing the multi-SDRPlay strategies under Linux
- one RTL-SDR
- two SDRPlay RSP1a's.
The operating system was Ubuntu 18.04 and the API version was 2.11.1 For transport (between the radio host and web host), SoapyRemote was used. Built in a naive way, it just worked.
During the winter I managed to build and install proper antennas. My hope was that this summer, I shall repeat the software installation and voilaa, yet another ham radio installation is there.
The sad news is related to the software. By now I have understood that in relation to Pothosware integration, SDRPlay is not supported on Linux to the extent other popular SDRs are. The precompiled (by pothosware guys) packages are available for aging Ubuntu 18.04 and Debian stretch (oldstable) but SDRPlay is missing from the set. That means, one has to compile it (plus rx_tools and csdr). I am not a developer thus unable to comment what was the difference btw 2.11 and 2.13, but just repeating the capabilities of the last year installation occurred impossible today (have spent all free time during last two weeks). What compiles, will just not work. The developers say that there is some generic ABI incompatibility risk and then, there are some new unsuitable libraries out there (like new versions of libusb-devel). As somebody said somewhere, API v 3.01 is not yet supporting Linux.
As someone on Pothosware commented today, the Pothosware SDRPlay module is unable to multithread. That means, two concurrent RSP1a's will create strong stability problems with Soapy (up to core dumps) - see SoapySDR, issues #232 and #233.
Can plz someone recommend a possible strategy to continue? The variants I see:
- a: trying to compile Soapy related modules from the old source around 2018-05-30 against API v 2.11
b: launching two SoapyRemoteServers on the radio host, one for either RSP1a (hinted by Pothosware guys)
c: look at the WebSDR (which I have so far strongly avoided for not being OSS)
d: something else (like 3x rtl_tcp servers) feeding the OpenWebRX
e: wait, do nothing until vendor makes the API v 3.01 Linux ready.
e: anything out of my scope but leading to the expected result.