I have to initially connect then disconnect a SDRconnect client after a reboot on the target to allow the gnuradio graph to work for a RSPdx-R2.

[JoeTester1965]

Hi,

I get an an invalid device or antenna error (have a RSPdx-R2) in the source block after a rebbot.

This stays the case until I start and the stop a SDRconnect client.

Any ideas as to why this might happen, have looked at the API and all looks good to me.

[JoeTester1965]

P.S. thanks again for your module - have had fun doing this:

https://github.com/JoeTester1965/SDRPlayBatDetector

[fventuri]

Joe, thanks for the link to your interesting project. I just watched that video by Tech Minds on YouTube, and I was amazed that it is possible to hear the ultrasounds from bats with an SDR! That is a really neat idea for another SDR use case!

Regarding your specific question about the SDRplay API not seeing your RSPdx-R2 right after a reboot, next time it happens, instead of using the SDRConnect client, can you try to simply restart the SDRplay API service with this command?

sudo systemctl restart sdrplay

Please let me know if the API is able to see your RSPdx-R2 after you run that command.

Franco

[JoeTester1965]

'sudo systemctl restart sdrplay' does not fix this, still get the following until I connect a SDRPlay client:

pi@ShedPi:~/Documents/OLD $ ./SDRPlayBatDetector.py
rspdxr2 :error: SDRplay device not found:
Traceback (most recent call last):
  File "/home/pi/Documents/OLD/./SDRPlayBatDetector.py", line 198, in <module>
    main()
  File "/home/pi/Documents/OLD/./SDRPlayBatDetector.py", line 181, in main
    tb = top_block_cls()
         ^^^^^^^^^^^^^^^
  File "/home/pi/Documents/OLD/./SDRPlayBatDetector.py", line 74, in __init__
    self.sdrplay3_rspdxr2_0 = sdrplay3.rspdxr2(
                              ^^^^^^^^^^^^^^^^^
RuntimeError: sdrplay device not found or invalid mode/antenna selection

As an aside can also recreate a similar but different issue without rebooting, just need to run the application multiple times after the initial connect of a SDRPlay client.

However 'sudo systemctl restart sdrplay' did the trick, after a 'kill -9' when things go wrong that way:

 ./SDRPlayBatDetector.py
^Crspdxr2 :warning: overload corrected
rspdxr2 :info: total samples: [4871160,0]
^C

pi@ShedPi:~/Documents/OLD $ ./SDRPlayBatDetector.py
gr::vmcircbuf :error: shmat (3): Invalid argument
^Crspdxr2 :warning: overload corrected

pi@ShedPi:~/Documents/OLD $ ./SDRPlayBatDetector.py
rspdxr2 :error: SDRplay device not found:
Traceback (most recent call last):
  File "/home/pi/Documents/OLD/./SDRPlayBatDetector.py", line 198, in <module>
    main()
  File "/home/pi/Documents/OLD/./SDRPlayBatDetector.py", line 181, in main
    tb = top_block_cls()
         ^^^^^^^^^^^^^^^
  File "/home/pi/Documents/OLD/./SDRPlayBatDetector.py", line 74, in __init__
    self.sdrplay3_rspdxr2_0 = sdrplay3.rspdxr2(
                              ^^^^^^^^^^^^^^^^^
RuntimeError: sdrplay device not found or invalid mode/antenna selection

 sudo systemctl restart sdrplay
pi@ShedPi:~/Documents/OLD $ ./SDRPlayBatDetector.py
gr::vmcircbuf :error: shmat (3): Invalid argument
gr::vmcircbuf :error: shmat (3): Invalid argument
gr::vmcircbuf :error: shmat (3): Invalid argument
buffer_double_mapped :error: gr::buffer::allocate_buffer: failed to allocate buffer of size 5752 KB
thread_body_wrapper :error: ERROR thread[thread-per-block[7]: <block udp_sink(5)>]: std::bad_alloc

pi@ShedPi:~/Documents/OLD $ kill -9 SDRPlayBatDetector.py

pi@ShedPi:~/Documents/OLD $ ./SDRPlayBatDetector.py
gr::vmcircbuf :error: shmat (3): Invalid argument
^Crspdxr2 :warning: overload corrected
rspdxr2 :info: total samples: [969696,0]

[JoeTester1965]

I think that there must something missing in the API calls for a a RSPdx-R2 on initialisation?

[fventuri]

@JoeTester1965 - I wonder if we can reproduce the problem outside of GNU Radio.

This message from a few years ago: https://github.com/pothosware/SoapySDRPlay3/issues/41#issuecomment-882114787 has the source code of the example that comes with SDRplay API specification guide.

If you don't mind, could you run build it and run it right after a reboot to see if it is able to see your RSPdx-R2?

Franco

[JoeTester1965]

This program runs but terminates immediately seeing no devices:

requested TunerA Mode=Single_Tuner
MaxDevs=6 NumDevs=0

[JoeTester1965]

However after connecting SDRConnect and then disconnecting, get this:

requested TunerA Mode=Single_Tuner
MaxDevs=6 NumDevs=1
Dev0: SerNo=24020B0770 hwVer=7 tuner=0x01
chosenDevice = 0
sdrplay_api_EventCb: sdrplay_api_GainChange, tuner=sdrplay_api_Tuner_A gRdB=40 lnaGRdB=15 systemGain=68.20
sdrplay_api_StreamACallback: numSamples=1344

[JoeTester1965]

There seems to be an additional exchange between the RSP device and the driver ...

[fventuri]

@JoeTester1965 - thanks for running the test with the example code from the SDRplay API Specification guide.

Based on your results I suspect that once we figure out the problem with that very simple example, we can probably figure out what's wrong with the GNU Radio RSPdx-R2 block.

@SDRplay - do you know why the example code from the specification guide can't initially see the RSPdx-R2, but after he connects and disconnects SDRconnect, the API sees it?

Franco

[SDRplay]

I've never come across that before, I would need some details of what OS/hardware platform is being used, what versions of the API and SDRconnect are installed.

[JoeTester1965]

OK:

Raspberry Pi 4 - 8Mb RAM

Debian Bookwork 64bit 2024-03-15 (i.e. latest)

Linux x64 SDRPlay API 3.15 (i.e latest)

Latest gr-sdrplay3 from main

SDRConnect PREVIEW 3 (not used on target only remotely to get the gr-sdrplay3 API to work!)

[SDRplay]

So you started SDRconnect in server mode and then killed it?

I've been running the latest API on RPi without a problem, sounds very odd. I'll burn a new SD card and then just install the API and check that again.

Best regards,

Andy

[JoeTester1965]

Yes, connect to remote over virtualhere then disconnect it.

I suspect may be due to some RSPdx-R2 specific element in the API.

[JoeTester1965]

Or something needed by the RSPdx-R2 that is not in the API example / gr-sdrplay.

[JoeTester1965]

Reran the API source code sample with my gr-sdrplay application up and running fine using the steps outlined above.

The output from sdrplay_api_GetDevices() seems to be borked:

[SDRplay]

wait, are you stepping through the code? If so you need to disable the heartbeat otherwise you can get rubbish from the API as it's probably timed out and done it's clean up.

[SDRplay]

To step through any code that uses the API you must make a call to disable the API heartbeat...

sdrplay_api_DisableHeartbeat(); // must be called before sdrplay_api_SelectDevice but must not be called in production code.

[JoeTester1965]

No was a breakpoint!

[JoeTester1965]

I think the heartbeat may be in AF.

Running the API test program multiple times in succession gives indeterminate results:

pi@ShedPi:~/Downloads/sdrplay_example $ ./sdrplay_api_example
requested TunerA Mode=Single_Tuner
MaxDevs=6 NumDevs=1
Dev0: SerNo=24020B0770 hwVer=7 tuner=0x01
chosenDevice = 0
sdrplay_api_EventCb: sdrplay_api_GainChange, tuner=sdrplay_api_Tuner_A gRdB=40 lnaGRdB=15 systemGain=6                                                            8.20
sdrplay_api_StreamACallback: numSamples=1344

pi@ShedPi:~/Downloads/sdrplay_example $ ^C
pi@ShedPi:~/Downloads/sdrplay_example $ ./sdrplay_api_example
requested TunerA Mode=Single_Tuner
MaxDevs=6 NumDevs=0
pi@ShedPi:~/Downloads/sdrplay_example $ ./sdrplay_api_example
requested TunerA Mode=Single_Tuner
MaxDevs=6 NumDevs=0
pi@ShedPi:~/Downloads/sdrplay_example $ ./sdrplay_api_example
requested TunerA Mode=Single_Tuner
MaxDevs=6 NumDevs=1
Dev0: SerNo=24020B0770 hwVer=7 tuner=0x01
chosenDevice = 0
sdrplay_api_EventCb: sdrplay_api_GainChange, tuner=sdrplay_api_Tuner_A gRdB=40 lnaGRdB=15 systemGain=68.20
sdrplay_api_StreamACallback: numSamples=1344

[SDRplay]

sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_sample_app.exe
requested TunerA Mode=Single_Tuner
MaxDevs=6 NumDevs=1
Dev0: SerNo=2108006870 hwVer=7 tuner=0x01
chosenDevice = 0
sdrplay_api_EventCb: sdrplay_api_GainChange, tuner=sdrplay_api_Tuner_A gRdB=40 lnaGRdB=15 systemGain=68.20
sdrplay_api_StreamACallback: numSamples=1344
sdrplay_api_PowerOverloadChange: tuner=sdrplay_api_Tuner_A powerOverloadChangeType=sdrplay_api_Overload_Corrected
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_sample_app.exe
requested TunerA Mode=Single_Tuner
MaxDevs=6 NumDevs=1
Dev0: SerNo=2108006870 hwVer=7 tuner=0x01
chosenDevice = 0
sdrplay_api_EventCb: sdrplay_api_GainChange, tuner=sdrplay_api_Tuner_A gRdB=40 lnaGRdB=15 systemGain=68.20
sdrplay_api_StreamACallback: numSamples=1344
sdrplay_api_PowerOverloadChange: tuner=sdrplay_api_Tuner_A powerOverloadChangeType=sdrplay_api_Overload_Corrected
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_sample_app.exe
requested TunerA Mode=Single_Tuner
MaxDevs=6 NumDevs=1
Dev0: SerNo=2108006870 hwVer=7 tuner=0x01
chosenDevice = 0
sdrplay_api_EventCb: sdrplay_api_GainChange, tuner=sdrplay_api_Tuner_A gRdB=40 lnaGRdB=15 systemGain=68.20
sdrplay_api_StreamACallback: numSamples=1344
sdrplay_api_PowerOverloadChange: tuner=sdrplay_api_Tuner_A powerOverloadChangeType=sdrplay_api_Overload_Corrected
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_sample_app.exe
requested TunerA Mode=Single_Tuner
MaxDevs=6 NumDevs=1
Dev0: SerNo=2108006870 hwVer=7 tuner=0x01
chosenDevice = 0
sdrplay_api_EventCb: sdrplay_api_GainChange, tuner=sdrplay_api_Tuner_A gRdB=40 lnaGRdB=15 systemGain=68.20
sdrplay_api_StreamACallback: numSamples=1344
sdrplay_api_PowerOverloadChange: tuner=sdrplay_api_Tuner_A powerOverloadChangeType=sdrplay_api_Overload_Corrected
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_sample_app.exe
requested TunerA Mode=Single_Tuner
MaxDevs=6 NumDevs=1
Dev0: SerNo=2108006870 hwVer=7 tuner=0x01
chosenDevice = 0
sdrplay_api_EventCb: sdrplay_api_GainChange, tuner=sdrplay_api_Tuner_A gRdB=40 lnaGRdB=15 systemGain=68.20
sdrplay_api_StreamACallback: numSamples=1344
sdrplay_api_PowerOverloadChange: tuner=sdrplay_api_Tuner_A powerOverloadChangeType=sdrplay_api_Overload_Corrected

[SDRplay]

I downloaded the same OS and put it onto a new SD card. Booted it up and waited for it to update, etc. - then downloaded the API 3.15 - copy/pasted the API sample code, built it and ran it several times - I can't reproduce the problem

[SDRplay]

if you are using ctrl-C to stop the program, you're not closing the API correctly - the sample code accepts key inputs and so I'm just pressing q each time to cleanly close the API and exit the program - maybe that's the difference?

[fventuri]

I just wrote a simplified version of the example program that just enumerates the RSPs seen by sdrplay_api_GetDevices() and exits.

@JoeTester1965 - can you build it and then run it on your Raspberry Pi right after a reboot?

Franco

sdrplay_api_enumerate_devices.zip

[JoeTester1965]

Thanks Franco, did that and got:

./sdrplay_api_enumerate_devices
found 0 RSPs

And after running then stopping SDRConnect:

found 1 RSPs
1 - model=7 S/N=24020B0770

[JoeTester1965]

@SDRplay - Why not send Franco a RSPdx-R2 to see if he sees the same thing, being able to interoperate with GNURadio must be important for the product line?

[JoeTester1965]

Have included a strace of the sdrplay driver starting up and responding to the api enumeration code in case that helps. strace.txt

[SDRplay]

We always offer Franco a unit when they are released - it's up to Franco as to whether he wants them or not and I totally understand that Franco has his own stuff to be doing and we don't see Franco as some free support resource. He does an amazing job for the community with both this library and the SoapySDRPlay library.

I ran Franco's test code and it's working here on my newly built RPi4 64bit image with just the API 3.15 download...

sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_enumerate_devices
found 1 RSPs
1 - model=7 S/N=2108006870
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_enumerate_devices
found 1 RSPs
1 - model=7 S/N=2108006870
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_enumerate_devices
found 1 RSPs
1 - model=7 S/N=2108006870
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_enumerate_devices
found 1 RSPs
1 - model=7 S/N=2108006870
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_enumerate_devices
found 1 RSPs
1 - model=7 S/N=2108006870
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_enumerate_devices
found 1 RSPs
1 - model=7 S/N=2108006870
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_enumerate_devices
found 1 RSPs
1 - model=7 S/N=2108006870
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_enumerate_devices
found 1 RSPs
1 - model=7 S/N=2108006870
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_enumerate_devices
found 1 RSPs
1 - model=7 S/N=2108006870
sdrplay@raspberrypi:~/Dev/APITest $ ./sdrplay_api_enumerate_devices
found 1 RSPs
1 - model=7 S/N=2108006870

[SDRplay]

Have you checked that the API service is running before using the API for the first time after reboot? Have you also tried a different USB port. I would also check the contents of /etc/udev/rules.d/66-sdrplay.rules looks like the following...

SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1df7",ATTRS{idProduct}=="2500",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1df7",ATTRS{idProduct}=="3000",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1df7",ATTRS{idProduct}=="3010",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1df7",ATTRS{idProduct}=="3020",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1df7",ATTRS{idProduct}=="3030",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1df7",ATTRS{idProduct}=="3050",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1df7",ATTRS{idProduct}=="3060",MODE:="0666"

I would also check what the dmesg output says about the RSP

[SDRplay]

this is my dmesg output...

sdrplay@raspberrypi:~/Dev/APITest $ dmesg | grep usb
[    0.084792] usbcore: registered new interface driver usbfs
[    0.084832] usbcore: registered new interface driver hub
[    0.084879] usbcore: registered new device driver usb
[    1.496091] usbcore: registered new device driver r8152-cfgselector
[    1.496133] usbcore: registered new interface driver r8152
[    1.496168] usbcore: registered new interface driver lan78xx
[    1.496200] usbcore: registered new interface driver smsc95xx
[    1.500734] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.06
[    1.500751] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.500761] usb usb1: Product: xHCI Host Controller
[    1.500771] usb usb1: Manufacturer: Linux 6.6.31+rpt-rpi-v8 xhci-hcd
[    1.500779] usb usb1: SerialNumber: 0000:01:00.0
[    1.501947] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.06
[    1.501963] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.501973] usb usb2: Product: xHCI Host Controller
[    1.501982] usb usb2: Manufacturer: Linux 6.6.31+rpt-rpi-v8 xhci-hcd
[    1.501991] usb usb2: SerialNumber: 0000:01:00.0
[    1.504368] usbcore: registered new interface driver uas
[    1.504429] usbcore: registered new interface driver usb-storage
[    1.511705] usbcore: registered new interface driver usbhid
[    1.511715] usbhid: USB HID core driver
[    1.758963] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[    1.909672] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.21
[    1.909708] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    1.909720] usb 1-1: Product: USB2.0 Hub
[    2.226990] usb 1-1.2: new high-speed USB device number 3 using xhci_hcd
[    2.327737] usb 1-1.2: New USB device found, idVendor=1df7, idProduct=3060, bcdDevice= 2.00
[    2.327778] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.410989] usb 1-1.3: new low-speed USB device number 4 using xhci_hcd
[    2.519347] usb 1-1.3: New USB device found, idVendor=0461, idProduct=0010, bcdDevice= 1.04
[    2.519377] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.519389] usb 1-1.3: Product: USB Keyboard
[    2.519399] usb 1-1.3: Manufacturer: NOVATEK
[    2.530826] input: NOVATEK USB Keyboard as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:0461:0010.0001/input/input4
[    2.592077] hid-generic 0003:0461:0010.0001: input,hidraw0: USB HID v1.10 Keyboard [NOVATEK USB Keyboard] on usb-0000:01:00.0-1.3/input0
[    2.600971] input: NOVATEK USB Keyboard System Control as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.1/0003:0461:0010.0002/input/input5
[    2.659232] input: NOVATEK USB Keyboard Consumer Control as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.1/0003:0461:0010.0002/input/input6
[    2.659886] hid-generic 0003:0461:0010.0002: input,hidraw1: USB HID v1.10 Device [NOVATEK USB Keyboard] on usb-0000:01:00.0-1.3/input1
[    2.738913] usb 1-1.4: new low-speed USB device number 5 using xhci_hcd
[    2.847265] usb 1-1.4: New USB device found, idVendor=046d, idProduct=c05a, bcdDevice=54.00
[    2.847283] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.847294] usb 1-1.4: Product: USB Optical Mouse
[    2.847304] usb 1-1.4: Manufacturer: Logitech
[    2.856817] input: Logitech USB Optical Mouse as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4:1.0/0003:046D:C05A.0003/input/input7
[    2.857606] hid-generic 0003:046D:C05A.0003: input,hidraw2: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:01:00.0-1.4/input0
[   23.666381] usbcore: registered new interface driver brcmfmac
[  213.119093] usb 1-1.2: USB disconnect, device number 3
[  213.347447] usb 1-1.2: new high-speed USB device number 6 using xhci_hcd
[  213.448143] usb 1-1.2: New USB device found, idVendor=1df7, idProduct=3060, bcdDevice= 2.07
[  213.448161] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[  213.448167] usb 1-1.2: SerialNumber: 2108006870

[JoeTester1965]

Glad to hear about support for API community.

1. Yes is running.
2. /etc/udev/rules.d/66-sdrplay.rules is the same.
3. dmesg is DIFFERENT with the 'Product', is 1 in your output but 0 in mine. 2.974860] usb 1-1.1: New USB device found, idVendor=1df7, idProduct=3060, bcdDevice= 2.00 [ 2.974890] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 3.055776] usb 1-1.2: new high-speed USB device number 4 using xhci_hcd

[SDRplay]

you should have two entries in the dmesg output - one when the system first finds the device - the bcdDevice will be 2.00 then you should have another entry the first time the API is used and then the bcdDevice will be 2.07, if you don't see this then that's the problem. You should see...

[    2.226990] usb 1-1.2: new high-speed USB device number 3 using xhci_hcd
[    2.327737] usb 1-1.2: New USB device found, idVendor=1df7, idProduct=3060, bcdDevice= 2.00
[    2.327778] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0

and then when the API is used...

[  213.119093] usb 1-1.2: USB disconnect, device number 3
[  213.347447] usb 1-1.2: new high-speed USB device number 6 using xhci_hcd
[  213.448143] usb 1-1.2: New USB device found, idVendor=1df7, idProduct=3060, bcdDevice= 2.07
[  213.448161] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[  213.448167] usb 1-1.2: SerialNumber: 2108006870

[JoeTester1965]

Oh boy. Tried changing usb port and now calling the API creates an error and the sdrplay service moans:

pi@ShedPi:~/Downloads/sdrplay_example_enumerate $ ./sdrplay_api_enumerate_devices
sdrplay_api_GetDevices failed sdrplay_api_Fail

 sdrplay.service - SDRplay API Service
     Loaded: loaded (/etc/systemd/system/sdrplay.service; enabled; preset: enabled)
     Active: active (running) since Fri 2024-07-05 13:23:23 BST; 2min 2s ago
   Main PID: 782 (sdrplay_apiServ)
      Tasks: 3 (limit: 8731)
        CPU: 462ms
     CGroup: /system.slice/sdrplay.service
             └─782 /opt/sdrplay_api/sdrplay_apiService

Jul 05 13:23:23 ShedPi systemd[1]: Started sdrplay.service - SDRplay API Service.
Jul 05 13:23:23 ShedPi sdrplay_apiService[782]: [782]: sdrplay_apiService: sdrplay_apiServiceWorkerThread: Entry
Jul 05 13:23:23 ShedPi sdrplay_apiService[782]: [823]: sdrplay_apiService_device: heartBeatThread: Entry
Jul 05 13:23:23 ShedPi sdrplay_apiService[782]: [824]: sdrplay_apiService_device: registerDevThread: Entry
Jul 05 13:25:10 ShedPi sdrplay_apiService[782]: [782]: sdrplay_apiService: UpdateDevicesL: ERROR: libusb_claim_interface() -5
Jul 05 13:25:10 ShedPi sdrplay_apiService[782]: [782]: sdrplay_apiService: sdrplay_apiServiceWorkerThread: ERROR: UpdateDevices() >
Jul 05 13:25:10 ShedPi sdrplay_apiService[782]: libusb: warning [libusb_exit] device 1.7 still referenced
Jul 05 13:25:10 ShedPi sdrplay_apiService[782]: libusb: warning [libusb_exit] device 1.2 still referenced
Jul 05 13:25:10 ShedPi sdrplay_apiService[782]: libusb: warning [libusb_exit] device 1.1 still referenced
Jul 05 13:25:10 ShedPi sdrplay_apiService[782]: libusb: warning [libusb_exit] application left some devices open

Am approaching a sense of humour failure!

[fventuri]

A few notes:

• SDRplay offered to send me a RSPdx-R2 when they first came out, but they already gave me a RSPdx a while back, and from the point of view of the SDRplay API they are exactly the same (plus I already a few other RSP models from SDRplay, and I don't have much room in my office for a lot of radios, even if I would love to LOL)
• the problem is definitely not in the GNU Radio gr-sdrplay3 module itself since @JoeTester1965 is able to reproduce it with the SDRplay API example code, and lately with the simplified code that just enumerates the available RSPs
• last night I thought that perhaps @JoeTester1965 has a systemd service that starts the SDRconnect server automatically at reboot; the SDRconnect server perhaps grabs the RSPdx-R2 since it is the only RSP connected to the Raspberry Pi, and because of that the RSPdx-R2 is no longer available to other applications using the SDRplay API.
• a simple way to confirm this assumption would be to reboot the Raspberry Pi and run this command right afterwards:

  ps -ef | grep -i connect

  and see if it returns anything.

Franco

[SDRplay]

libusb claim interface error code 5 means the device is already in use - so it looks like something else has grabbed the RSP before the API can get it - that would make sense with the problem you're seeing.

If you build a new OS image on a SD card from scratch, just install the API and run the test code, this should prove it.

[JoeTester1965]

Will give that a go, fingers crossed ...

[JoeTester1965]

Thanks for all the support, appreciated, am now having a Victor Meldrew moment.

The issue is with VirtualHere, even though on reboot the client says that the remote USB interface is not claimed, it is!

Have run 'sudo systemctl disable virtualhere' so that it does not autostart.

P.S. This may also be an issue-> SDRplay_RSP_API-Linux-3.15.2.run says you can run it as a normal user and will request root, but it never does ask for root or complain about not having it. I never noticed that before in my previous install so used sudo on that this time.

[SDRplay]

Unfortunately Raspbian (as it used to be called) has been so dumbed down, it no longer requires a password to be provided to sudo and you're not asked for a root password when you install the OS, so that's why there's no password prompt in the installer - you get one on Linux/x64 though. So running the installer as a regular user is absolutely fine.