Improving SDR reception

The next few lines won’t probably add nothing new to a seasoned user or ham operator, but might help some one that stumbles on this post. So anyway here are some tips that might help anyone that is in the same situation as I.

The issue of living an apartment with few options for deploying antennas can be challenging for receiving anything in the HF bands.
So for a long time I have an SDRPlay RSP1A that covers from low frequency bands to UHF bands and above. But while I’m more or less successful to receive UHF 430MHz bands, I hadn’t much luck in lower bands. With exceptions for the FM frequencies, where I have nearby 50Kw transmitters and can pick up FM without any issues, all spectrum below 200MHz is noise and more noise.

So some steps that I took to improve things up and their outcomes:

Ferrite beads on the USB cable:
I added two clip on ferrite beads to the USB cable, right at the connection point to the SDRPlay, to see if any USB noise was affecting reception, but no change. Anyway I just left the beads on the cable, since it seems that RSP1A is not affected but USB noise at the HF bands. Verdict: No measurable improvements.

Better RSP1A shielding:
The RSP1A comes within a plastic case, but according to some people (I didn’t open it to check it), the inner case has some shielding. I tried some sort of shielding either with an external metal case, tin foil wrapping (yes I know… 🙂 ), but no measurable influence. Verdict: No measurable improvements.

Ferrite Core at the antenna input:
This was a game changer. Adding a power cord ferrite core just before the antenna sma connector on the RSP1A cleared a lot of noise and some other artifacts:

Before connecting to the SMA connector the antenna cable makes some loops on the ferrite as shown above and then it connects to the RSP1A.
While I still am deaf at a lot of bands, including the 80, 40 a 2 meter bands, I can here now FT8 on the 20m band and decoding it. At night I can also hear some ham radio chatter, all this while using a simple 9:1 unun and a random lenght wire antenna. Verdict: Good measurable improvement!.
(This is wahat is supposed called a common mode choke.)

I did some other changes, but all of them are now antenna related which leads us to the conclusion:

Conclusion:
All this just points to a what is evident from the beginning: Better antennas are need to improve reception, and while some basic things can improve reception, such as the ferrite core at the antenna output, there is no escape to getting a better antenna.

GQRX and SDRPlay RSP1A

I’ve own a SDRPlay RSP1A SDR and since I use Linux I’ve never used SDRUno, just CubicSDR that works fine with the RSP1A.

Nevertheless one thing that annoys me on CubicSdr is that we can only pipe audio out from the application, while on GQRX we can pipe data out through UDP, and hence we can pipe it out to basically anywhere and not be dependent of the audio interface and audio routing on the local PC.

But the truth is that I never was able to make GQRX to work with SDRPlay. I’ve followed some tutorials around the net such as this: http://thomasns.io/gqrx.html and this http://dk3ml.de/2019/01/12/running-sdrplay-with-gqrx-on-ubuntu-18-10/ but at the end I always had this, even with the latest versions of GQRX that support SDRPlay:

GQRX SDRPlay

While I can hear the FM station at the above frequency the frequency panadapter has a hump at the middle and that’s it, not exactly what I was expecting.

Well the issue is that GQRX at startup does not setup SDRPlay RSP1A propertly and so it shows the above behavior.

So if we get the initial GQRX settings for the SDRPlay:

SDRPlay Settings

it looks fine, but as we’ve seen the end result is not as expected. So what we need to do is to re-enter the settings again in a certain order to make this work:

  1. Stop the data capture, without exiting GQRX (press the Play button)
  2. Edit the Device settings and choose any other than SDRPlay, and then choose again SDRPlay again. Make sure Bandwidth is set to 0.6Mhz.
  3. DEfault SDRPlay Settings
  4. As we can see the default Input rate is set to 2MBps.
  5. Press Apply, and if we start the capture it should work now, but we have a RSP1A,so…
  6. Open up again the settings and change the Input Rate to the maximum that RSP1A supports: 10MBps

The end result is this:

Proper SDRPlay on GQRX

And now it works as it should.

Conclusion:
While a bit annoying it’s good to see GQRX working fine with SDRPlay RSP1A. Still through GQRX we can’t control the FM and DAB notch filters, which CubicSDR can.

SDRPlay, CubicSDR on Arch Linux

This is just a simple post for writing the instructions for installing and using SDRPlay RSP1A (Should work for other versions) and CubicSDR on Arch Linux. I’ve previously installed most of the supporting software manually on my PC, and also had trouble installing the SDRPlay driver on Arch Linux with the SDRPlay installer on my PC. Since I have a lot of QRM (Noise) in my home, the next step was to use a portable computer to move the SDRPlay outside.

So, the following instructions are much more streamlined, since all the required software is on the AUR repositories, and so no “hacking” is needed.

Installing yay AUR package manager
If necessary we should install a AUR package manager. There are several ones, but as far as I’m aware, for now the yay is the currently maintained AUR package manager:

git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si

We can now use yay.

Installing CubicSDR with SDRPlay support:
If before installing CubicSDR we install HamLib support we will have a new menu on CubicSDR for rig control, otherwise it wont appear.
Then we need to install the SDRPlay driver, Soapy support and also CubicSDR.

yay -S hamlib
yay -S libsdrplay
yay -S soapysdr-git
yay -S soapysdrplay-git
yay -S soapyremote-git
yay -S soapyrtlsdr-git
yay -S cubicsdr-git

I’ve also added support for remote devices and the ubiquitous RTLSDR dongles.
CubicSDR will take a while (20 minutes, it will depend how fast is your computer) to compile, mainly because of the wxgtk widgets.

After it ends just connect the SDRPlay to the computer USB port, and execute CubicSDR. If the SdrPlay does not appear on the device list, press the Refresh button:

And that’s it, no fuss install, at least for me.

SdrPlay and ArchLinux

I’ve used the RTLSDR usb cheap dongles for a while for radio spectrum listening and scanning, but the fact is that in my case, they all are garbage. Yes they work fine for bands above 200/250Mhz (not too much noise there), but below that, my nearby powerful FM stations, overload the dongle and I can’t get much out of them (Even with a home made FM notch filter). Also in most cases, to hear HF bands (80m/40m/20) a hack (Q branch sampling) or an upconverter is needed, but still the FM stations blank out the other signals.

So for a bit of more money, I’ll give SDRPlay a go, since it is a full spectrum SDR (1.5Mz to 2GHz with a 10Mhz scope band) and also it can be used successfully as a pan adapter for Amateur band radios.

While waiting for my SDRPlay to arrive, and since the SDRUno program doesn’t run on Linux (I have Arch Linux), I started to get the software ready to use the SDR device with CubicSDR.

The software needed to access the SdrPlay devices in Linux is SoapySDR, the SDRPlay Driver for SoapySDR, and of course Cubic SDR. Also needed is the binary driver (yes I know… ) API/HW Driver – v2.13 to be installed.

While there are a lot of instructions to compile SoapySDR and Cubic SDR, including mine: Cubic SDR and SoapySDR, and a also very good video from SDRPlay I had a problem with the SoapySDRPlay component.

As we will se the problem is not with the SoapySDRPlay component but with the installation of the binary proprietary driver.

Basically during the binary driver installation I had the following output:

Press y and RETURN to accept the license agreement and continue with
the installation, or press n and RETURN to exit the installer [y/n] y
./install_lib.sh: line 17: arch: command not found
Architecture: 
API Version: 2.13
Remove old libraries...
Install /usr/local/lib/libmirsdrapi-rsp.so.2.13
cp: cannot stat '/libmirsdrapi-rsp.so.2.13': No such file or directory
chmod: cannot access '/usr/local/lib/libmirsdrapi-rsp.so.2.13': No such file or directory
Remove old header files...
Install /usr/local/include/mirsdrapi-rsp.h
Udev rules directory found, adding rules...
Libusb found, continuing...
Finished.

If we continue with this situation (the cp: cannot stat ‘/libmirsdrapi-rsp.so.2.13’: No such file or directory
chmod: cannot access ‘/usr/local/lib/libmirsdrapi-rsp.so.2.13’: No such file or directory
errors), the SoapySDRPlay compilation will fail:

[ 20%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Registation.cpp.o
[ 40%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Settings.cpp.o
[ 60%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Streaming.cpp.o
[ 80%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Version.cpp.o
make[2]: *** No rule to make target '/usr/local/lib/libmirsdrapi-rsp.so', needed by 'libsdrPlaySupport.so'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/sdrPlaySupport.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

To solve this we need to correcly install the driver, that in my case was the failure of copying the binary blob to the correct location.

So all we need is to go the directory where the binary installation is and create a working directory:

mkdir work
/SDRplay_RSP_API-Linux-2.13.1.run --target work

So the driver will install but in the working directory will be the missing driver to copy to the correct location:

sudo cp work/x86_64/libmirsdrapi-rsp.so.2.13 /usr/local/lib

Done.

I’ve also added to my home directory .bashrc file the following line to allow the new libraries to be found:

export LD_LIBRARY_PATH=/usr/local/lib/:$LD_LIBRARY_PATH

And then just do a source .bashrc so that changes take place.

We can now compile SoapySDRPlay with success:

Scanning dependencies of target sdrPlaySupport
[ 20%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Registation.cpp.o
[ 40%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Settings.cpp.o
[ 60%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Streaming.cpp.o
[ 80%] Linking CXX shared module libsdrPlaySupport.so
[100%] Built target sdrPlaySupport

Execute the usual sudo make install and running the SoapySDRUtil command, the new driver should be available:

SoapySDRUtil --info
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.7.0-g37429d89
API Version: v0.7.0
ABI Version: v0.7
Install root: /usr/local
Search path:  /usr/local/lib/SoapySDR/modules0.7
Module found: /usr/local/lib/SoapySDR/modules0.7/libremoteSupport.so  (0.5.0-6efb692)
Module found: /usr/local/lib/SoapySDR/modules0.7/librtlsdrSupport.so  (0.2.5-ad3d8e0)
Module found: /usr/local/lib/SoapySDR/modules0.7/libsdrPlaySupport.so (0.1.0-12c3db6)
Available factories... remote, rtlsdr, 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]

We can see now that the libsdrPlaySupport.so module is loaded.

So who ever encounters the issue that I had, hopefully this will be the solution since the sdrplay binary installation scripts might fail.