Short Wave Listening with Software Defined Radio

Background

My interest and career in technology originated with a gift from an adult cousin when I was a child. That gift was a Hallicrafters S-120A Shortwave Radio Receiver. My cousin setup a 50 feet long end fed wire antenna down the length of my backyard tacked against a couple of trees about 12 feet up in the air. The wire fed straight into my bedroom snaked through the window jam. My cousin then showed me how to use the radio, tuned in a few stations, and before I knew I had the  Short Wave Listening (SWL) bug. It was the early 1970’s and there were plenty of stations to tune into – broadcast, utility, amateur radio, aviation, etc.

I had a couple of years of fun with that radio until one night I was woken up by the flash of an early summer lightening storm and then the sight and smell of smoke coming out of the back of my beloved Hallicrafters radio. Fortunately my uncle who was an avid collector of all things gave me a circa 1958  Philco Trans-World Portable T-9 which kept me going with my SWL activities – as long as I had enough batteries. Then I found a 1937 Philco model 37-610 Table radio from a local antique store which served me well. All the time I still missed my S-120A which I kept for a longtime hoping I could get it fixed.

But when the 80’s arrived I got into computers, got my Amateur Radio license, went to college, built a career in technology, and live life. My SWL activities faded into memories and my Amateur Radio activity was largely in hiatus into the early ’00s. Then about five years ago I began playing with early software defined radios (SDR) available as kits and projects that re-purposed DVB TV Tuners into VHF/UHF receivers. But it was too bleeding edge for me and I was losing patience with all the tweaking required and lack of information available. Plus VHF/UHF listening didn’t hold much interest for me.

It wasn’t until I attended an annual SWL festival in nearby Pennsylvania this year (recommended by a friend) that my interest in SWL was rekindled and inspired me to revisit SWL using SDR options available today.

RTL-SDR Dongle

When I returned home from the SWL festival, I decided to do research on the current state of SDR focusing on solutions that use RTL-SDR dongles. What immediately caught my attention was people were using RTL-SDR dongles to listen to HF without the need of an upconverter. An upconverter is a device that converts HF radio reception into VHF/UHF frequencies the RTL-SDR dongle can hear. One example of a upconverter is the Noelec “Ham it Up“which you insert in-line to the antenna and the dongle.

The RTL-SDR dongle I went with was the RTL-SDR Blog V3 Dongle. I ordered it from Amazon order. which included some small antennas. Getting this specific version was critical to do HF reception through software configuration only and without hardware additions or changes.

To connect the dongle to my coax that leads to my G5RV HF antenna, I ordered an adapter cable that goes from SMA male to SO-239 connector.

Which platform do I use – Linux or Windows?

Those re-purposed DVB TV Tuners I mentioned in my early days of SDR were the predecessor to the RTL-SDR dongles of today. Largely the same devices just optimized for SDR use. Anyhow I had great frustration in setting up USB driver persistence on Windows to use the dongles. But since the easiest to use and widely supported SDR application at the time was SDR# (aka SDR Sharp) and only available on Windows one must suffer the pain before pleasure. For Linux the pain was in the lack of stable SDR applications though installing libraries was painless.

In my research I learned improvements included the ability to have a RTL-SDR dongle installed on one machine and have the raw data streamed via network to another machine for subsequent processing by an SDR application. Since I wanted to try out a range of SDR applications across operating systems and multiple machines, I went with the SDR client/server approach using wired connectivity throughout.

Why Wired over Wireless connectivity?

Streaming raw data to “view” 8 MHz of spectrum uses about 40 MB/s of network bandwidth. If the SDR server and client are wired to the same physical 100MB or 1GB switch and there are no other streaming media servers or clients (any Netflix users out there?) on that network you should have few issues if any (especially with 1GB switch.)

For 802.11g and 802.11n wireless networks to be viable for SDR clients you you would have to reduce the spectrum size under view considerably.This also assumes the wireless network is served by the same physical switch the SDR server is connected to. 802.11b networks simply do not provide enough bandwidth for SDR data streams.

I use multiple 1GB managed switches on my network that give me the ability to network controls such as VLANS, QoS, and jumbo frames to manage the streaming services I consume (Netflix) and run (SDR.) A good switch that meets spec at a reasonable price is the NETGEAR GS108TV2.

SDR Server

The server is a Raspberry Pi 2 with RTL_TCP as the application serving up the raw data stream. To insure I have the latest feature sets available for the RTL-SDR software, I compiled the RTL-SDR drivers from source as pulled from GitHub. rather than use the software package available from the distribution repository.

I know some of you may be groaning but I found the “direct sample” feature I need for HF reception was not included on the RTL-SDR builds from the distribution repositories at the time of this posting. Have no fear, I’ve documented the steps to retriev and compile RTL-SDR below

Compiling RTL-SDR 

1. Let’s insure your Raspberry Pi install is up to date. Log into your Pi and execute the following:

sudo apt-get update
sudo apt-get upgrade

2. Next let’s install the dependencies required in order to build the RTL-SDR software on the Pi:

sudo apt-get install git-core git
sudo apt-get install cmake
sudo apt-get install libusb-1.0-0-dev
sudo apt-get install build-essential

3. Insuring you are in the Pi home directory, we now download, compile, and install the RTL-SDR drivers with the following:

cd /home/pi
git clone git://git.osmocom.org/rtl-sdr.git
cd rtl-sdr/
mkdir build
cd build
cmake ../ -DINSTALL_UDEV_RULES=ON
make
sudo make install
sudo ldconfig
cd ~
sudo cp ./rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/

4. Finally let’s go ahead and reboot:

sudo reboot​

Note when compiling and installing RTL-SDR from the GitHub repository, RTL-SDR software will installed in the /usr/local/bin directory whereas installs from the distribution repository are installed in the /usr/bin directory.

Running RTL_TCP

With the drivers installed, plug the RTLSDR v3 dongle (with an attached antenna)  into a USB slot on the Pi and test whether it is recognized and working by typing the following:

rtl_test

You should see output similar to the following:

Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
[R82XX] PLL not locked!
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode…

With the RTL-SDR installed and working, now we can go ahead and start the RTL_TCP server software with the following command (replace the IP address below withthe IP address of your Pi)

rtl_tcp -a 192.168.1.73

You should see the following output

Found 1 device(s):Why Wired over Wireless connectivity?
0: Realtek, RTL2838UHIDIR, SN: 00000001

​_Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Tuned to 100000000 Hz.
listening…
Use the device argument ‘rtl_tcp=192.168.1.73:1234’ in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, …).

At this point you have a running SDR server waiting for a client to connect to it. You can go one step further and configure the Pi to run RTL_TCP on startup or run on demand using systemd service and systemd socket activation respectively. For now I’ve opted just to SSH into the Pi and manually start RTL_TCP when needed.

SDR Clients

As mentioned, I want to try out a range of SDR applications across operating systems and multiple machines so going with the SDR server and client approach gives me that flexibility. Client configurations I tested include:

• GQRX running on Ubuntu Linux 16.04
• HDSDR running on Windows 7

Always be sure the SDR server and RTL_TCP application are running before starting the SDR clients.

GQRX on Ubuntu 16.04

Install GQRX from the Ubuntu repository and run it. Once started, click on the Configure I/O Devices button in the menu bar.

The I/O input menu will pop-up. Here we tell GQRX to use other device and provide information on where to connect to our SDR server (RTL_TCP with IP address and Port.) We also need to pass the direct_samp=2 parameter to switch from listening to VHF/UHF and allow us to receive 500 Khz to 28,800 KHz on HF.

From there you click the Start DSP button on the menubar. You are all set to start scanning the HF bands and do some SWL. I typically start with listening to time stations like CHU on 3330 KHz and WWV on 5000 KHz to insure all is in order.

HDSDR running on Windows 7

Since we are not connecting a RTLSDR dongle directly to the machines, we skip the USB configuration hell and download and install HDSDR. After HDSDR is installed, we download and install ExtIO_RTLTCP.DLL into the same directory as HDSDR is installed in. This DLL allows us to connect to RTL_TCP running on the Raspberry Pi serving as a SDR server.Entire 80 Meter Ham Band

Once that is done, you start HDSDR, selection Options, then Select Input, and select ExtIO_RTLTCP.

Once that is done, click on the blue ExtIO button and enter your SDR server’s IP address for Hostname, 1234 for Port, and enter 2 for Direct Sampling and then click OK.  Go ahead and click Start.

You are all set to start scanning the HF bands and do some SWL. As mentioned to insure all is in order I typically start with listening to time stations like CHU on 3330 KHz and WWV on 5000 KHz to insure all is in order.

Final Notes

The state of the art cheap SDR solution has improved much since my early days of experimentation thanks to many persistent pioneers out there. So when playing around with SDR on cheap RTLSDR dongles keep the spirit of experimentation in mind because you will run into idiosyncrasies if not fully documented bugs. To help you keep your sanity here are some notes

• Besides the agility to experiment with a range of SDR applications across operating systems and multiple machines, going the SDR server/client model helps troubleshoot and partition problems between those with the SDR applications themselves (GQRX, HDSDR, etc) on the client and problems with the RTLSDR drivers on the server. Having the network in-between gave me ready visual where to begin troubleshooting.
• While I leave the SDR server running all the time, I do not start the RTL_TCP process until I plan on doing some SWL. I login via SSH, run RTL_TCP -a IP ADDRESS, and leave the terminal window open. The I start my SDR client and connect to the server – in that order. The client may give you an error or not work at all if the server is not running first.
• If you are going to switch to a different client, close the current client, kill the RTL_TCP process on the server and restart RTL_TCP, then fire up the new client. This is especially important if you are going to switch from HF to VHF/UHF listening and vice-versa. For some reason I’ve seen RTL_TCP retain the direct sampling configuration from the last client and not accept from a new client. Advanced topic for next time.
• For HDSDR on Windows client I actually was running it as a virtual machine with 4G RAM on a Ubuntu 16.04 Linux Desktop host with 16GB RAM using VMware Workstation 12 Pro. This abstraction has an advantage that on the host operating system I can tap the audio and demod Amateur Radio digital modes such as RTTY, PSK31, etc with Fldigi. Another advanced topic.
• I wanted to add Mac OSX to the list of clients to test but native OSX SDR applications are few. I tried SdrDx but it did not support a network setup with RTL_TCP as the server. But I did have success with CubicSDR which runs on OSX and Windows natively. How, using SoapySDR which is the subject of a  follow-up post.

For what its worth,

– Joe, NE2Z