Add support for SDRPlay v3 API

[ChazTuna]

Expected Behavior

The RSPdx is a great radio - very sensitive but... SDRplay has native support on URH, but the new RSPdx is not working correctly: Device seen as "RSP 3" Antenna A only is allowed (If I select B it reverts back to A) RF signals are MUCH weaker at the RF and IF gain settings than seen with SDRuno With the same settings RTL-SDR shows much stronger RF signals (Realtek RTL2838UHIDIR)

Actual Behavior

(see above)

Steps To Reproduce

Plug SDRdx in and run Spectrum Analyzer

Screenshots

Platform Specifications

• OS: Windows 10, 64 bit
• URH version: 2.8.8
• Python version: (not applicable: Python 3.8.3)
• Installed via Windows installer

[jopohl]

I do not own a RSPdx so I cannot provide support on this device. If you are in contact with the manufacturers and can organize a test device for me I could see what I can do.

Otherwise, you might try to fix this yourself; the relevant code is in src/urh/dev/native/lib/sdrplay.pyx. PR is welcome!

[alphafox02]

Which api are you using? I have sdrplay equipment here, but figured it was because I was using not only the api 3.x but also because gr-osmosdr doesn’t really support it stock from the repositories.

[ChazTuna]

? Not sure what you are referring to - My hardware is SDRPlay RSPdx (one of their newest). Software is the latest URH (Windows 10, 64 bit). jopohl suggests updating the code, but I'm not so good on understanding the code and how to update it to support the RSPdx version.

[alphafox02]

For sdrplay equipment to run, even in windows, there’s an api that’s installed. It used to be like 2.X but now they are up to 3.7 api which functions completely different than the older version.

I also think it requires changes to the gr-osmosdr. For example

https://github.com/dk2ro/gr-osmosdr-pluto-spyserver

I think URH used osmosdr and so unless that works with sdrplay then I don’t think URH will work. I have sdrplay equipment here so I can also test in Linux. I haven’t made any changes to osmosdr though so I probably have to start there.

[jopohl]

I think URH used osmosdr

No it does not. URH natively supports SDRPlay. But yes, it works with the 2.X API as Version 3 is still considered beta:

[alphafox02]

Thanks for the clarification. The site says 3.6 but it’s actually 3.7 when downloaded. It works really well and I have it and your URH preinstalled in my projects called DragonOS 10, LTS, and now Focal.

Could you consider adding 3.7 api support to a testing branch and I can test all my sdrplay equipment? I’d love to add this to the list of software supporting sdrplay.

[alphafox02]

With that said, for the original posted you’ll probably need the older windows installer. When using the windows api 3.x installer it removed the older 2.x api. At least that’s what I recall when trying it out in a windows vm. Of course you then lose some of the newer features like dual tuner with the rspduo.

[jopohl]

I am a bit hesitant to develop against a beta API which might introduce breaking changes in the future. Do you have an idea when they will declare the v3 API stable?

[alphafox02]

This is a good question. I’ll ask the sdrplay people. There’s another program called qt-dab, month ago he added support for 3.7 api. For the most part it works really well when I use soapy enabled programs like cubicsdr built from source and SigDigger as well. I can also use gr-soapy. I can use all of these because of a developer maintaining a soapysdrplay github page that is meant for the newer 3.x (3.7) api. The only issue I’ve ever really had is that I may have to restart the sdrplay service but as of late that’s not really happened at all. I would love to try it all in URH but I can understand your hesitation. If I can help at all I have all of there equipment and I’m sure other people who have the equipment would be eager o use it with the new api and URH.

I’ll say if you look at their downloads site the api 3 is not listed as “beta” for windows so I suspect a lot of windows users are using it vs the 2.x stuff because of new features added. It’s only the Linux build that says beta and it’s actually labeled wrong. It says 3.6 but when downloaded it’s actually 3.7 which made a difference when I pointed it out to the qt-dab developer.

[SDRplay]

The RSPdx is only supported in API 3.x - you will not get the correct functionality (if any) using API 2.x

[NoTan2]

Reviving this thread if that's OK.

I only discovered urh a couple of days ago. Gave up trying to get it going on a Pi 3B+ and installed Docker on one of my Debian 10 PCs and pulled the image from Docker Hub. It doesn't see my RSPdx at all. I plugged in a Realtek RTL2838 and it works beautifully.

I've never used Docker before but looking in the Dockerfile on Docker Hub, it appears to be using SDRPlay API v2.x.

"&& wget http://www.sdrplay.com/software/SDRplay_RSP_API-Linux-2.13.1.run -O /tmp/sdrplay/sdrplay.run "

Is this likely to be the issue?

I can get by with the RTL-SDR but it would be nice to get the RSPdx running.

Thanks.

[alphafox02]

@NoTan2

The RSPdx is only supported in API 3.x - you will not get the correct functionality (if any) using API 2.x

I do want to point out there's been discussion at the following two places about adding support, in fact one gentlemen @ Sammy1Am has created a wrapped for the API and added support to SDRTrunk for the SDRPlay + API 3.x

https://github.com/DSheirer/sdrtrunk/pull/972 https://github.com/DSheirer/sdrtrunk/issues/933

And more discussion here about adding it to SDRAngel

https://github.com/f4exb/sdrangel/issues/586

[milutz]

Adding on to comments above:

The dumpvdl2 project is C based and has support for both v2 and v3 nicely broken into two different (diffable) files. Specifically:

• https://github.com/szpajder/dumpvdl2/blob/master/src/sdrplay3.c
• https://github.com/szpajder/dumpvdl2/blob/master/src/sdrplay.c

(There are also matching header files)

I've been trying to wrap my head around the .pyx code inside of URH to see if I could attempt a similar change, but I also just realized that @jopohl opened a sdrplay3 branch in Nov 2020.

@jopohl do you recall where you were on that branch? All the changes seem to be in src/urh/dev/native/lib/csdrplay.pxd and I haven't wrapped my head around what csdrplay.pxd, as opposed to src/urh/dev/native/lib/sdrplay.pyx that you ref'ed above.

EDIT

From some googling on the file types:

• pyx are the main module/source files in the Cython if your writing the weird C/python hybrid
• pxd files are like C headers for the above pyx files

That roughly match the URH use?

[jopohl]

Correct pxd correspond to the headers (.h) and pyx to the actual implementation (.c).

I wrapped the SDRPlay API directly instead of relying on third-party libraries. I just stopped working on it when I realized that the v3 API of SDRPlay requires a daemon running.