SDRplay RSP1 and GQRX on Mint 19.3

[g8kb...@googlemail.com]

Hi.

Mint 19.3 64 bit, all up-to-date.  GQRX v2.11.5-6-g94aef7 - miri=0

(Yes, I do know I'll need to update the OS in the not too distant future.)

Just been given a SDRplay RSP1, by a friend who "upgraded" to something else.

 

I had looked at these in the past, but couldn't find a definitive guide as to how to get it going with Linux, especially GQRX (that seems to work with just about everything else...)

I did find this page:-

https://dk3ml.de/2019/01/12/running-sdrplay-with-gqrx-on-ubuntu-18-10/

I found the exact same driver package as he documents by enabling the "legacy software" view on the SDRplay website.   All that went exactly as advertised.   Likewise the blacklist entries, but he doesn't explain why they are needed.

Following those instructions, I get a noise floor, the usual white noise in "demodulated" audio (USB mode) but not a lot else.  Not even if I "Tune" to the frequency of a known local signal generator that is connected, at about 5 microvolt input at 14MHz.

Also, the main tuning window and spectra is only a few kHz wide at best.

I sort of suspect, that the linkages between GQRX and the RSP1's hardware configuration is not correct, or broken, as the ALC/Gain and frequency controls do nothing to little at all.

Also, I have to launch GQRX from a terminal (or nothing happens) and that has millions of '0's (the zero character) printed to the terminal continuously, even with DSP 'Stopped'. unless you change something in GQRX, where something flies up the terminal and off the top lost forever.

One thing I don't get is a crash!   Unless I unplug the USB lead, even with GQRX's DSP "Stopped".

Also, the terminal screen says "Segmentation fault (core dumped)" when I exit GQRX in the normal way.  Even after 'stopping' the DSP functions.

When running (such as it is) the CPU is also thrashed (Intel i3 2.5GHz, 8G RAM) at up to 80% usage.   But other software (Fldigi of all things) carries on fine, monitoring some Olivia-16/500 I was "listening" to via a regular rig and sound-card.

Is this a settings "Finger Trouble" issue, or?     If so, some hints as to what to set, and importantly so I can learn, "why."

Or, is this a more fundamental basic hardware/software incompatibility issue?

I have absolutely no idea what to do with GNURadio Companion, or soapy whatever, so be patient with me.

I have had GQRX working with various RTL based devices very well, and one time with a SoftRock kit (less well.)

OK, so this thing has not cost me any money, but I would like to use it to survey the local area for VSDL QRM leakage, using an i8 based laptop and the Lelantos post acquisition software from the RSGB (installs & runs very well in WINE by the way, with the demo I/Q files.)   https://rsgb.org/main/technical/emc/vdsl-interference-reporting/

But first of course, I need to have a suitable I/Q recording made locally for that to be of any use..

Any pointers to get me going would be most welcome.

73.

Dave G8KBV.

[Chris Vine]

Google groups seems to have swallowed my response of yesterday so here is another try.

gqrx works fine for me with the RSP1A, but to get decent results I needed to use the soapy backend of the gr-osmosdr block.  Consequently I have soapySDR installed, and I use it with either SoapySDRPlay2 with the sdrplay-2.13.1 driver or SoapySDRPlay3 with the sdrplay-3.07.1 driver. I then use the gr-osmosdr block configured for the soapy backend, not the (non-free) native sdrplay backend which is pretty much broken.  This requires a device string in gqrx's i/o device settings which contains at least "soapy=0,driver=sdrplay" in the string (the order is not important).

I build gnuradio and gqrx myself, and for what it is worth I am using gnuradio-3.10.1.1 (although gnuradio-3.9 and gnuradio-3.8 should work OK), gqrx as at its commit of 2021-10-03, SoapySDR as at its commit of 2020-07-13, SoapySDRPlay2 as at its commit of 2021-11-21, gr-iqbal as at its commit of 2021-01-08 and gr-osmosdr as at its commit of 2021-01-28.

It seems probable that this would also work OK with the RSP1 but YMMV.  If your distribution supplies its own versions of the packages I have mentioned probably the best approach is to install whatever versions of these it provides and see if that works.  Otherwise you may have to build them yourself or upgrade your distribution.  For the RSP1 I would stick with the sdrplay-2.13.1 driver and SoapySDRPlay2.

Chris