Page 1 of 1

gr-sdrplay for SDRplay API 3.01

Posted: Wed Jan 16, 2019 3:02 am
by fventuri
I just created a new git repository ( that has a new version of the gr-sdrplay Gnu Radio OOT module with the changes needed to use the new SDRplay version 3.01 (see here
The original GNU Radio module by HB9FXQ is here

To compile and install this new version, you can roughly follow the instructions here; the only change is that the 'git clone ...' command will be:

Code: Select all

git clone

To be able to use this new version you have to have the sdrplay_api service up and running.

I tested and ran this GNU Radio module only under Linux (Fedora 29, to be exact); I am not sure if it will compile or run on Windows/Mac.
Also I was able only to test it with my RSP2; since I don't have an RSPduo, I don't know for sure if it can see both tuners (it should, since I tried to follow the same code in the sample app listed at the end of the 3.01 API specifications document); I would definitely be very interested if anyone can give it a try using an RSPduo and perhaps running the tuners in master/slave configuration.

Let me know if you have any problems building and running this GNU Radio module.

Re: gr-sdrplay for SDRplay API 3.01

Posted: Wed Jan 16, 2019 5:13 pm
by DK7OB
Hi Franco,

this is a bit off topic but I would like to know if the gr-sdrplay with the 2.x and/or the 3.x API brings latency improvements over the Soapy SDRPlay approach which is commonly used on Linux.

For me, Soapy SDRplay is working fine with gqrx, only issue being the quite high latency. So I don't want to invest too much work in gr-sdrplay (and probably gqrx to make it work properly with gr-sdrplay) without getting an advantage over my current setup.

Did you compare both approaches?

Wolf, DK7OB

Re: gr-sdrplay for SDRplay API 3.01

Posted: Thu Jan 17, 2019 1:10 am
by fventuri
no, I haven't run any latency test with my RSP and different software.
Unfortunately I don't have an external antenna here because of HOA (home owner association) limitations, and therefore I can only receive a few strong BC stations and not much else due to the high levels of RFI inside the house.

I do have a few thoughts on your note though:
  • the only software that I know of that uses the gr-sdrplay module is GNU Radio
  • gqrx uses another module called 'gr-osmosdr' (according to this page:
  • the gr-sdrplay module is somewhat based on the rsp_dev class from the gr-osmosdr module for SDRplay that Jeff Long wrote, according to this comment in the code (
  • therefore when you ran gqrx with your SDRplay RSP, you were probably using Jeff Long's SDRplay gr-osmosdr module (
  • on the other hand the Soapy SDRplay module ( is used mostly by CubicSDR AFAIK (not sure if you tried that)
  • finally I suspect that the newer SDRplay API 3.X might have a higher latency than the older SDRplay API 2.X because of the different architecture: the new SDRplay API 3.X uses a server ('sdrplay_api') to connect to the actual RSP device, while the old SDRplay API 2.X connects to the RSP device directly via USB. I wouldn't be surprised if having to go through this service introduces additional latency; I don't have any data to show if this is true, but I would too be very interested if anyone has actually tested this and is able to add more information to prove (or disprove) this idea.


Re: gr-sdrplay for SDRplay API 3.01

Posted: Thu Jan 17, 2019 9:21 am
by DK7OB
Hi Franco,

I am running gqrx with gr-osmosdr, but not with the SDRPlay module but with the standard "soapy" module, which then uses the soapysdrplay driver. This is because when I started with SDR, the existing gr-osmosdr module for SDRPlay was incomplete and seemed to be unmaintained.

I also tested cubicsdr, but I didn't like it, and the latency was even worse than gqrx.

I think gqrx would basically work with gr-sdrplay, because it is using gnuradio, but I am running a heavily modified version of gqrx which uses some unique features of the soapysdr driver and would have to modify gqrx and probably also gr-sdrplay to get the same functionality.