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.

CubicSDR and Arch Linux (Again…)

Again quick note if installing CubicSDR in Arch Linux:

Arch Linux LiquidDSP package current version on the repository is 1.3.2.

Using this version of liquiddsp or liquiddsp-git breaks CubicSDR compilation, and hence if installing CubicSDR from AUR fails:

cannot convert ‘double’ to ‘liquid_ampmodem_type’

The solution to solve this issue is to use the package manager to remove the offending 1.3.2 version and manually install the 1.3.1 version, and then also install manually the CubicSDR according to the CubicSDR install instructions..

Not ideal, but it will get things done.

Simple instructions:

pacman -R liquiddsp liquiddsp-git
mkdir liquid
cd liquid
wget https://github.com/jgaeddert/liquid-dsp/archive/v1.3.1.tar.gz
tar xvzf v1.3.1.tar.gz
cd liquid-dsp-1.3.1/
./bootstrap.sh
make -j4
sudo make install
sudo ldconfig

Until CubicSDR upgrades to use LiquidDSP version 1.3.2, this is the interim solution.

fldigi slow startup on Linux

I’ve installed fldigi on an Arch Linux laptop computer, and I’ve hit an issue right away from the start: The startup time of fldigi on this computer was around 130s from the start command until the UI (User interface) display showed up. During this time one of the CPU cores hit 100% and stayed there while “starting”…
On my desktop computer, that is much older and has at least less than half the processing power of the new laptop, fldigi started up right away and had no issues with CPU occupation.

It took me a while to find out the cause, and with the source code available (yay for open source) I’ve found the issue at the confdialog.cxx file specifically here:

Fl_Double_Window* ConfigureDialog() {
  Fl_Double_Window* w; 
  font_browser = new Font_Browser;
  ....

A lot of the time was lost inside the call to the new Font_Browser.

So I’ve checked the fonts installed on my new computer, and low and behold: 1248 more or less fonts !!! compared to 234 installed fonts on my desktop computer.

Comparing the Arch Linux packages that I had installed on one computer and on the other, the laptop had the ttf-google-fonts-git AUR package installed which added the bulk of all the fonts.

Removing this package solved the issue with fldigi startup delay. With the fonts removed fldigi started right away as soon I execute the command to start it up.

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.