SDRPlay device notes
The OpenWebRX Raspberry Pi images and the OpenWebRX docker images come with the driver preloaded. If you're installing from the Debian or Ubuntu repository, or are following the manual installation process, you will need to install both the driver and the SoapySDRPlay3 module manually.
SDRPlay currently provide their driver ("API") for Linux on their website exclusively.
The SoapySDR module for SDRPlay devices is available here: https://github.com/pothosware/SoapySDRPlay3
Important note: When installing from packages, please avoid any instructions or scripts that compile SoapySDR itself from source. The packages rely on the SoapySDR installation provided by the distribution's packages, and a second installation will not be used by the connector, but prevent proper installation of the SoapySDRPlay3 module instead. If you encounter errors while compiling, please check if the package libsoapysdr-dev is installed.
Like other Soapy supported devices, SDRPlay devices can take a single gain value. However, since the way the underlying gains are set up, this usually results in unpredicted results. See: https://github.com/pothosware/SoapySDRPlay/issues/60
SDRPlay devices export two gain controls via the SoapySDR layer: IFGR and RFGR. Both of them are gain reduction values, so the higher the value you set, the lower your signal levels will be. This is important to understand since it is counter-intuitive and pretty much opposite to the behavior of other devices.
RFGR is set in steps starting at 0, the maximum depends on the device and input used. Each step equals approximately 6dB of attenuation. IFGR is set in dB, with a minimum of 20.
Some examples:
AGC is also supported, to enable set "Device Gain" to "Enable hardware AGC".
There has been various reports of SDRPlay devices "failing" out of the blue on certain setups, without any obvious problems. Typically, the problem can be resolved temporarily by a restart of OpenWebRX, but will re-appear at a later point. The analysis shows that for reasons unknown to us, the startup of SDRPlay devices seems to be somewhat unpredictably unreliable, and since OpenWebRX will shut down SDR devices when they are not in use, this can occur pretty much at any time.
The workaround to this issue is to add and enable the "Keep device running at all times" option for your SDRPlay device in the web config.
SDRPlay devices seem to re-initialize their USB connection upon first initialization, which in turns results in the kernel creating new USB device files in the /dev/bus/usb filesystem. Docker does not currently handle these changes, so the new device does not show up in the running container.
There is currently no solution available to this problem. The only workaround is to restart the OpenWebRX container after the initial setup of the device has occured.
This is in theory possible with API version 3, the process is complicated and requires strict sequencing and use of the correct device selector strings.
Sample rates in dual tuner mode are limited to 2MS/s.
Dual tuner mode consumes so much CPU that it cannot be used on any Raspberry Pi model (tested up to RPi 4 as of writing).
The SDRPlay API comes with a dedicated SDRPlay API service that manages interaction with the hardware. It is installed as a systemd unit and must be running to be able to access any SDRPlay devices.
The process sdrplay_apiService has been seen consuming noticable amounts of CPU (especially on SBCs like the Raspberry Pi) during normal operation. This seems to be expected, so please don't be alarmed if it does.
If your device stops working and cannot be detected, the API service may have stopped working. You can restart it using the command sudo systemctl restart sdrplay.
From observation, it seems like some (if not all) SDRPlay devices will re-register on the host USB bus on their first, "cold" init. This suggests that the SDRPlay software needs to perform some kind of firmware upload to the device.
The docker device forwarding unfortunately does not handle newly added USB devices once the container has been started. This means that the USB re-registration only shows up as a device removal from the perspective of the docker container. The new device that is created during the re-registration never becomes visible inside the docker container.
These two behaviours combined result in the first startup of an SDRPlay device from inside a docker container to fail, always.
The only currently known way to work around this is by restarting the docker container. This will initiate a fresh scan of devices to forward, and luckily the software does not attempt another re-initialization of the device.