Introduction
Over the past two days, after provisioning [ICT Blog] ham-sdr01.jdj, I researched and experimented with my two latest hobby purchases: Two SDR USB Dongles, the Nooelec NESDR SMArt v4 SDR and the RTL-SDR Blog V3. I also got myself a telescopic antenna.
My main objective was to deploy ham-sdr01.jdj as an (first) “SDR Hub” on the Zolder [attick] and a user facing application to control the SDR Dongles from more or less any client machine on gvl14lan.
Testing on ham-sdr01.jdj
I first started testing on ham-sdr01.jdj with the Nooelec NESDR SMArt v4 SDR dongle. Pictures of the setup are here [local]. I installed:
[root@ham-sdr01 ~] # dnf list sdr
Last metadata expiration check: 0:04:19 ago on Thu 12 Jan 2023 09:13:17 PM CET.
Installed Packages
CubicSDR.x86_64 0.2.7-8.fc37 @updates
SoapySDR.x86_64 0.8.1-6.fc37 @fedora
rtl-sdr.x86_64 0.6.0-12.fc37 @fedora
soapy-rtlsdr.x86_64 0.3.2-3.fc37 @fedoraThe way I understand it is that
- SoapySDR is a “framework” that provides a uniform interface to various SDR devices. (And I already found out that the interface can be exported on a LAN like gvl14lan.)
- rtl-sdr provides low-level device drives and utilities for Realtek RTL2832 based dongles like the Nooelec NESDR SMArt v4 SDR.
- soapy-rtlsdr is a plugin for SoapySDR that adds support for RTL-SDR hardware like the Nooelec NESDR SMArt v4 SDR. I’m not really sure if both rtl-sdr and soapy-rtlsdr are needed, but I seem to remember they do.
- CubicSDR is an SDR GUI application that supports SoapySDR devices.
I then started CubicSDR on ham-sdr01.jdj over an ‘SSH -X session’ from mmc2.jdj, and it seems to work, but there’s [obviously] no audio. The device is recognized, I can dial the center frequency, bandwidth, etc., so all is looking good. Note that there was apparently no need to blacklist the various [installed] DVB-T drivers, as suggested here…
Testing on mmc2.jdj
After the successes on ham-sdr01.jdj, I decided to more or less repeat the experiment on mmc2.jdj; a machine with proper sound, video, and GUI setup. Pictures of the setup are here [local]. The result of the experiment was a mixed bag, but mostly bad. Although the Nooelec NESDR SMArt v4 SDR was still recognized, there was simply no way to get audio output from CubicSDR.
I struggled with this problem for several hours, but all of a sudden I got it to work by running CubicSDR as root. It was at that point that I realized the CubicSDR, through its use of RtAudio, was actually chasing my ALSA sound devices for direct use.
Are you F’n kidding me?
This is Bl*dy 2023: On Linux, use pulseaudio, firewire or jack for (real-time) audio, but stay away from my ALSA devices.
Now I started looking for alternative applications:
- SDR++/SDRpp core-dumped even before I got to admire its user interface.
- With my gqrx attempt, however, I hit the jackpot: It works, supports Soapy devices like Nooelec NESDR SMArt v4 SDR and has decent audio implementation. The application pops up in pavucontrol, and, yes, even in Carla (does gqrx use Jack?). All lights turn green now…
Building and Deploying SoapyRemote
The one thing left to do was to install SoapyRemote on both client (mmc2.jdj) and server (ham-sdr01.jdj). Unfortunately, SoapyRemote is not in the Fedora/RPMFusion/Copr repositories, so I had to build and install it myself, but that went well. Note that SoapyRemote uses or benefits from Avahi auto-discovery, I installed and activated that as well.
Funny enough, there are spec and sprm files for SoapyRemote flying around, but somehow it never made it to a Fedora Release.
I tested the setup and it made me happy: On ham-sdr01.jdj, I could use the systemd unit file to start SoapyRemote. No configuration required. Then, on mmc2.jdj, I simply started gqrx and it already popped up a dialog with the (remote) Nooelec NESDR SMArt v4 SDR shown as option. Some Avahi magic going on here.
I tested the setup again, and everything worked well.
Final Installation and Initial Deployment
As a final step, I moved ham-sdr01 to Zolder [attick], stripped it of unnecessary hardware [GPS/WLAN] [pictures – local], and reconnected it to the Ethernet infrastructure [gvl14lan] there. The telescopic antenna obtained the greatest indoor spot in the house and I started exploring and enjoying my “first” SDR setup. Pictures of the initial deployment are here [local].
Conclusions
Well, needless to say I consider my first step into Linux/Fedora/SDR land a big success. Sure there were hurdles, but with Linux/Fedora, I’ve had far worse.
I guess time they are changin’… What is different nowadays is that in the Linux Ecosystem (TM) there are multiple options even for niche applications like spectrum monitoring, spectrum analysis or listening to (HAM) radio. If one does not work (well enough), you can try one of the alternatives. That’s so much more efficient than keep trying to get to work that single application you found for your specific purpose.