[Bug] no sdrplay device found when connected

JackStromberg commented 3 years ago

When using a Raspberry Pi 4 + SoapySDRPlay3 + another USB device (connected to USB 3.0 port (bottom blue port if looking at the Pi)), SoapySDRUtil is unable to locate SDRplay devices. Once I remove the secondary USB device, reboot the machine, and execute SoapySDRUtil, it's able to find the SDRplay. Interestingly, applications that interface with SoapySDRPlay3 are still able to function properly, so it seems like only SoapySDRUtil --probe flag is running into this issue specifically.

Version info:

pi@raspberrypi:~ $ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=raspbian ID_LIKE=debian

pi@raspberrypi:~ $ SoapySDRUtil --info ######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Lib Version: v0.8.0-unknown API Version: v0.8.0 ABI Version: v0.8 Install root: /usr/local Search path: /usr/local/lib/SoapySDR/modules0.8 Module found: /usr/local/lib/SoapySDR/modules0.8/libsdrPlaySupport.so (0.3.0) Available factories... sdrplay Available converters...

CF32 -> [CF32, CS16, CS8, CU16, CU8]
CS16 -> [CF32, CS16, CS8, CU16, CU8]
CS32 -> [CS32]
CS8 -> [CF32, CS16, CS8, CU16, CU8]
CU16 -> [CF32, CS16, CS8]
CU8 -> [CF32, CS16, CS8]
F32 -> [F32, S16, S8, U16, U8]
S16 -> [F32, S16, S8, U16, U8]
S32 -> [S32]
S8 -> [F32, S16, S8, U16, U8]
U16 -> [F32, S16, S8]
U8 -> [F32, S16, S8]

Error:

pi@raspberrypi:~ $ SoapySDRUtil --probe="driver=sdrplay" ######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device driver=sdrplay Error probing device: no sdrplay device found

Troubleshooting:

When running the following commands I can see the SDR via lsusb as well as dmesg: pi@raspberrypi:~ $ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP2102/CP2109 UART Bridge Controller [CP210x family] Bus 001 Device 005: ID 1df7:3020 Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub pi@raspberrypi:~ $ dmesg | grep 1df7 [ 3.654142] usb 1-1.1: New USB device found, idVendor=1df7, idProduct=3020, bcdDevice= 2.00 [ 87.554668] usb 1-1.1: New USB device found, idVendor=1df7, idProduct=3020, bcdDevice= 2.08

Additional evidence:

I found another person that reported similar behavior on the SDRplay forums a year back: https://sdrplayusers.net/forums/topic/pi-4-anyone-have-a-rspdx-working/

fventuri commented 3 years ago

@JackStromberg - thanks for reporting the problem.

Next time it happens, instead of rebooting the Raspberry Pi, can you try to just restart the service sdrplay_api as follows:

systemctl stop sdrplay_api

wait for the service to completely stop; to make sure the service is stopped, please run:

ps -ef | grep sdrplay_api

and if the service is still running, please stop the process with the command kill -KILL <PID>

Next, please check under /dev/shm that there are no files with names like Glbl\sdrSrvComShMem or similar names. To remove them you can run something like this:

rm /dev/shm/Glbl\\sdrSrv*

After everything is completely clean, you can restart the service sdrplay_api with the command:

systemctl start sdrplay_api

Finally, please re-run the command SoapSDRUtil as follows:

SoapySDRUtil --probe="driver=sdrplay"

If this last command does find the RSPduo, then we can try to figure out what could be the problem with the sdrplay_api service.

Franco

JackStromberg commented 3 years ago

I think I actually may have actually reported the wrong root cause on this (adding another USB device). I've found if I have RTLSDR-Airband (https://github.com/szpajder/RTLSDR-Airband) running (which uses the SoapySDR api) then I see this behavior where the SDRplay device isn't found. Once I stop the service, I can find the SDRplay device.

Not sure if this is intended behavior that the device is hidden while it is in use, but I think that's what is going on. I'm not sure how I originally got it to correlate with plugging in a USB device and unplugging it, but it seems I can no longer repro this again with plugging / unplugging another USB device; only via starting/stopping the rtlsdr-airband service.

fventuri commented 3 years ago

@JackStromberg - good point about RTLSDR-Airband

If an SDR client application connects to the RSPduo in Single Tuner (or Dual Tuner) mode, then it is granted exclusive access to that device, and therefore the SDRplay API does not show the same device as available to other SDR applications.

This said, the RSPduo model also offers the Master/Slave modes where two independent SDR applications can each use a tuner of the RSPduo (with some limitations on the sample rate and other parameters); in your case you may want to start RTLSDR-Airband first, and select the so called 'Master' mode for the RSPduo. After that you should be able to still see the RSPduo from another SDR application as 'Slave' (if you run it in this configuration, make sure you stop the slave SDR application first, and then the master one, otherwise you might have problems with the slave application if the master is not running).

Of course this all applies only with the RSPduo since it has two tuners internally; with all the other RSP models you only have a single tuner and therefore, after an SDR application is connected to them, they are not available for use by other applications (to share the RSP in that case you may want to look at something like SoapySDRRemote).

Franco

JackStromberg commented 3 years ago

Should SoapySDRUtil --find switch still list the device even though another resource may have exclusive access to it or should that return no devices found as well (it returns no devices found as well)?

Also, do you have any documentation on setting the Master/Slave mode? Haven't seen that in any of the RTLSDR-Airband documentation/wiki. Do you mean specifying the different antenna for each "device" I want to add within RTLSDR-Airband?

Thank you for the clarifications, really appreciate it!

SDRplay commented 3 years ago

The RSP API will only list devices that are found and available to be used. That's how the API works and not something that the SoapySDRPlay library can circumvent. Maybe the messaging could be clearer (no available RSP devices found)?

fventuri commented 3 years ago

@SDRplay - thanks for the suggestion; I just pushed this commit: https://github.com/pothosware/SoapySDRPlay3/commit/0d84f1c1a521dd603a1e6087a21cc2db92a65aab to change the wording of that message as you proposed.

@JackStromberg - in order to use your RSPduo in 'Master' mode, you have to just append 'mode=MA' (for 'Master') to the device_string parameter in the RTLSDR-Airband configuration file. For instance the sdrplay example from here: https://github.com/szpajder/RTLSDR-Airband/wiki/Configuring-SoapySDR-devices#device-string-examples would become something like this for an RSPduo in master mode:

device_string = "driver=sdrplay,serial=46493836302,mode=MA,rfgain_sel=3";

The easiest way to find out the possible values for the RSPduo modes is to just connect the RSPduo and run the command SoapySDRUtil --find=driver=sdrplay (with no SDR client applications running).

Franco

JackStromberg commented 3 years ago

Will give the master mode a shot, thank you! Aside, can you submit an update to the wiki (I don't have access to submit an edit)?

In addition to changing the verbiage per the commit, I think it could be beneficial to add a note that devices will not be shown if actively in use. https://github.com/pothosware/SoapySDRPlay3/wiki#troubleshooting

fventuri commented 3 years ago

@JackStromberg - thanks for the suggestion; I added a note about that to the Wiki page.

Franco

JackStromberg commented 3 years ago

Thanks everyone! Closing this one out.

pothosware / SoapySDRPlay3