SDRPlay RSP1A

[m0lmk]

Is there support for the RSP1A?

I'm building on Debian 10 and have tried the manual install as well as using both the full and sdrplay docker images but am having no luck.

My end goal is to run the RSP1A and 2 RTLSDR stick on a single machine.

I get different errors with each method; with the manual install, Soapy can't find the device whe I access the web interface but it does show when using:

SoapySDRUtil --probe=sdrplay

With the docker images, the -full image shows the SDRPlay as not available, the -sdrplay image loads and shows the RSP2 as available then gives this error:

ERROR - Exception during postStart()

when I try and access the web interface.

What am I missing here?

[mihaifireball]

I am using the RPi image with an MSi.SDR (SDRPlay RSP1 clone) and it's working properly. I'm getting from time to time kernel panic... And I don't know why... Any help is appreciated! 🙂

[jketterl]

The RSP1A is supported as much as it is supported by the driver and the SoapySDRplay module. SDRplay themselves list it as supported, and the soapy module doesn't really list any restrictions to that.

I have had an RSP1 for testing a few weeks back (not sure if it was an RSP1 or RSP1A), and I can confirm that it is working as expected.

For the manual installation: Please check if you have run into the "double soapy installation" trap. I've seen this on a few occassions, and it will produce exactly the kind of confusing result that SoapySDRUtil lists the RSP, whereas the connector won't find it. Simply check if you have both /usr/bin/SoapySDRUtil and /usr/local/bin/SoapySDRUtil, and crosscheck which of the two installations your soapy_connector is linked against (ldd /usr/local/bin/soapy_connector). While you're at it, please make sure that there's no second soapy_connector binary in /usr/bin, too.

For the docker: First I'd like to know which version you're on. The :latest tag represents the development builds and may be unstable, so I'd recommend going with the :0.18.0 which has been tested.

Other than that, the exception you posted only shows that the connector failed in some way, but you didn't include the actual error from the connector itself, so I have no idea what went wrong.

As for the kernel panic: The software I provide doesn't interface with the kernel or hardware directly, so I find it highly unlikely that I can provide a fix for that. If you had an original device, I'd suggest contacting SDRplay, but since it's a clone your best bet is to contact the manufacturer of that device. You could ask for other people's suggestions on the mailing list.

[m0lmk]

Thanks @jketterl . I'll do a clean manual install this afternoon and see how it goes.

I was using the line from the guide to pull in the docker images and just added -full:

docker run --device /dev/bus/usb -p 8073:8073 -v openwebrx-config:/etc/openwebrx jketterl/openwebrx-full

I also blacklisted the modules in /etc/modprobe.d/.

I'll check for the double soapy install and post my results.

[jketterl]

OK, that's using the :latest, that's the docker default if no tag is specified. The openwebrx-full should be equivalent to openwebrx.

I cannot reproduce the unavailability of SDRplay with the full images, I just tested the latest images from the docker hub and they are listing SDRplay as available from the start. There is problems with certain CPU features being required, specifically sse4 and avx. From evidence, this is affecting older CPUs or Celerons.

[jketterl]

Any updates on this?

[m0lmk]

Sorry! Just seen this in my inbox. Turns out the PC that I am using has a CPU that's not supported. I have an i5 on order that should work!

[jketterl]

there has been progress on that, so if you pull :latest again, it may work. see #38 for progress on that :)

[m0lmk]

Great. I'll take a look at that and give it a try.

[m0lmk]

Rubuilt the Debian box to give it a clean start. Installed Docker and did

sudo docker run --device /dev/bus/usb -p 8073:8073 -v openwebrx-config:/etc/openwebrx jketterl/openwebrx-full:latest

Same issue:

2020-05-28 16:50:32,953 - owrx.__main__ - INFO - OpenWebRX version v0.19 starting up...
2020-05-28 16:50:33,011 - owrx.sdr - ERROR - The SDR source type "airspyhf" is not available. please check requirements.
2020-05-28 16:50:33,036 - owrx.sdr - ERROR - The SDR source type "sdrplay" is not available. please check requirements.
2020-05-28 16:50:33,037 - owrx.sdr - INFO - SDR sources loaded. Available SDRs: RTL-SDR USB Stick

RSP1A is plugged in.

Any suggestions?

[jketterl]

No suggestions yet, but I'd like to understand it. The error messages indicate that one of the required components for the sdrplay has failed, and it's not immediatly obvious which one it is. So the first thing you could do is, while the above command is running, direct your browser to the /features url of the webserver, e.g. http://localhost:8073/features. You should find a section for the sdrplay there, I'd like to know the state of the two entries, "soapy_connector" and "soapy_sdrplay".

There's two checks behind that based on the following commands. They'll do some more with the output, but would you mind running them like this and post the output?

docker run --rm -it jketterl/openwebrx-full:latest SoapySDRUtil --info docker run --rm -it jketterl/openwebrx-full:latest soapy_connector --version

[m0lmk]

soapy_connector: Yes soapy_sdrplay: No

sudo docker run --rm -it jketterl/openwebrx-full:latest SoapySDRUtil --info
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.8.0-gf722f9ce
API Version: v0.8.0
ABI Version: v0.8
Install root: /usr/local
Search path:  /usr/local/lib/SoapySDR/modules0.8
[cmd] SoapySDRUtil exited 260
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] syncing disks.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

sudo docker run --rm -it jketterl/openwebrx-full:latest soapy_connector --version
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
owrx-connector version 0.2-SNAPSHOT
[cmd] soapy_connector exited 0
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] syncing disks.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

[jketterl]

ok thank you. well, the good news is that it's not the connector anymore. the bad news is that it's now probably one of seven soapy modules that's playing foul. the first one in the list is the limesdr one, but i won't immediately put the blame on that.

Would you to try this last one, please? Just trying to figure out if the sdrplay would work.

docker run --rm -it jketterl/openwebrx-full:latest SoapySDRUtil --probe=driver=sdrplay

If this one is fine, you should be fine using the jketterl/openwebrx-soapysdr:latest for now.

[m0lmk]

sudo docker run --rm -it jketterl/openwebrx-full:latest SoapySDRUtil --probe=driver=sdrplay
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device driver=sdrplay
[cmd] SoapySDRUtil exited 260
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] syncing disks.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

I attempted to pull jketterl/openwebrx-soapysdr:latest but get repository does not exist.

[jketterl]

sorry, wrong image. it should be jketterl/openwebrx-sdrplay:latest. chances that it's going to work have become slim, now that i've seen the latest output. but you can still try, i'm curious.

other than that... looks like either soapy itself is broken, the soapysdrplay module, or maybe the sdrplay api. at this point, however, we won't be able to debug any deeper...

[jketterl]

scratch that. it's too late... jketterl/openwebrx-sdrplay:latest is the right one.

[m0lmk]

Great. That seems to be working fine. Top job!

[jketterl]

well, at least so much. that means at least some parts are working as expected.

I just did some digging, this may actually be overly agressive optimization on the part of cmake. There's a lot of soapy modules that set their build type to "Release" by default, and the default compiler options for a release build are set to "-O3 -DNDEBUG". The "-O3" part enables vector optimizations using the build system's architecture. That's exactly what made csdr and owrx_connector unusable before, the resulting binary is not portable.

I will need to think some more about this. Takeaway for me is: at least csdr and owrx_connector are now in the clear :) Thanks for testing :)