Remote access tools for SDR receivers

This post lists some of the most common tools that can be used to access software-defined radio (SDR) receivers remotely over a network connection and takes a closer look on how to install and use SoapyRemote.

Table of Contents

Solutions for SDR remote access

Solutions for SDR remote access

The physical location of SDR equipment is usually fixed because of antenna placement and cabling, so a number of tools have been developed to allow use of SDRs over a network connection. The most commonly used open-source SDR server applications seem to be SoapyRemote and rtl_tcp (with its forks). In this post, I will be covering installation and use of SoapyRemote server on Linux, since it is a general-purpose solution for SDR remote access. It is built on top of SoapySDR, which is a hardware abstraction layer API that supports different types of SDR hardware devices.

The extraction of raw IQ data, which is what the remote access tools output, does not require much processing power, so all of the open-source software listed here (SoapyRemote, rtl_tcp and rtl_rpcd) can be installed and run on single-board computers, such as Raspberry Pi 2/3 or PINE64, which I’ve both personally tested. A 50-100 Mbit/s network connection is enough for most use and in case of slower connections the SDR receiver can be configured to use a lower sampling rate to make it output fewer bytes per second.

SoapyRemote

SoapyRemote provides access to SoapySDR hardware-abstraction API through a TCP/UDP server. It runs on Linux and requires installing the SoapySDR library and drivers for at least one of the supported SDR hardware devices.

Installing and running SoapyRemote server

Compiling SoapySDR and SoapyRemote requires installing git, gcc, g++, make and cmake:

        
# Debian / Ubuntu:
apt-get install git gcc g++ make cmake

# Red Hat / Fedora:
dnf install git gcc gcc-c++ make cmake

Compile and install SoapySDR library and utilities:

        
git clone https://github.com/pothosware/SoapySDR.git
cd SoapySDR
mkdir build
cd build
cmake ..
make -j4
sudo make install
sudo ldconfig #needed on debian systems

Install SDR hardware drivers for your SDR: (RTL-SDR in this example)

        
# Debian / Ubuntu:
apt-get install rtl-sdr librtlsdr-dev

# Red Hat / Fedora:
dnf install rtl-sdr rtl-sdr-devel

Compile and install SoapySDR adapter module for your SDR hardware: (RTL-SDR in this example, each module is in a separate repository, see the list of GitHub repositories for Pothosware)

        
git clone https://github.com/pothosware/SoapyRTLSDR.git
cd SoapyRTLSDR
mkdir build
cd build
cmake ..
make
sudo make install

Check that SoapySDR can find and access your SDR hardware:

        
SoapySDRUtil --probe

The output looks like this for an RTL-SDR device:

        
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

Probe device

----------------------------------------------------
-- Device identification
----------------------------------------------------
  driver=RTLSDR
  hardware=RTLSDR
  origin=https://github.com/pothosware/SoapyRTLSDR
  rtl=0

----------------------------------------------------
-- Peripheral summary
----------------------------------------------------
  Channels: 1 Rx, 0 Tx
  Timestamps: NO
  Other Settings:
     * Direct Sampling - RTL-SDR Direct Sampling Mode
       [key=direct_samp, default=0, type=string, options=(0, 1, 2)]
     * Offset Tune - RTL-SDR Offset Tuning Mode
       [key=offset_tune, default=false, type=bool]
     * I/Q Swap - RTL-SDR I/Q Swap Mode
       [key=iq_swap, default=false, type=bool]

----------------------------------------------------
-- RX Channel 0
----------------------------------------------------
  Full-duplex: YES
  Supports AGC: YES
  Stream formats: CS8, CS16, CF32
  Native format: CS8 [full-scale=128]
  Stream args:
     * Buffer Size - Number of bytes per buffer, multiples of 512 only.
       [key=bufflen, units=bytes, default=262144, type=int]
     * Ring buffers - Number of buffers in the ring.
       [key=buffers, units=buffers, default=15, type=int]
     * Async buffers - Number of async usb buffers (advanced).
       [key=asyncBuffs, units=buffers, default=0, type=int]
  Antennas: RX
  Full gain range: [0, 49.6] dB
    TUNER gain range: [0, 49.6] dB
  Full freq range: [23.999, 1764] MHz
    RF freq range: [24, 1764] MHz
    CORR freq range: [-0.001, 0.001] MHz
  Sample rates: 0.25, 1.024, 1.536, 1.792, 1.92, 2.048, 2.16, 2.56, 2.88, 3.2 MSps

Compile and install SoapyRemote:

        
git clone https://github.com/pothosware/SoapyRemote.git
cd SoapyRemote
mkdir build
cd build
cmake ..
make
sudo make install

Start SoapyRemote server:

        
# Bind to all interfaces in default port 55132
SoapySDRServer --bind

# Bind to a specific IP address and port
SoapySDRServer --bind="0.0.0.0:1234"

Configuring SoapyRemote client applications

SoapyRemote access is supported by many SDR applications, such as Gqrx, CubicSDR and the rx_tools command-line tools. Additionally, there is support for Pothosware data processing framework, and for GNU Radio through the GrOsmoSDR component.

Client applications using SoapySDR and SoapyRemote are usually configured using a device string that provides configuration parameters to use a remote driver and to locate the SoapyRemote server:

        
driver=remote,remote=tcp://192.168.0.111:55132

NOTE: To use SoapyRemote over TCP port forwarding, like with SSH, you need to get the latest code from master branch and use device parameter remote:prot=tcp, because SoapyRemote defaults to using UDP packets.

See the SoapyRemote wiki for full documentation of all configuration parameters.

Configuring Gqrx:

Gqrx must be built with support for GrOsmoSDR
Use device string: soapy=0,driver=remote,remote=tcp://192.168.0.111:55132 where 192.168.0.111:55132 is the IP address and port of your SoapyRemote server

Configuring CubicSDR:

Add new Remote device of type SoapyRemote and enter the IP address and port of your SoapyRemote server

Using rx_fm from rx_tools to listen to FM radio:

        
rx_fm -f 92.3M -M wbfm -r 32k -g 35 -d driver=remote,remote=tcp://192.168.0.111:55132 | play -t s16 -c 1 -r 32k -b 16 -

Using rx_fm from rx_tools and direwolf to decode APRS packets:

        
rx_fm -f 144.8M -M fm -s 250k -r 32k -g 40 -d driver=remote,remote=tcp://192.168.0.111:55132 - | direwolf -t 0 -n 1 -r 32000 -b 16 -

Using rx_sdr from rx_tools to dump raw IQ data for analysis or decoding later:

        
rx_sdr -f 144.8M -g 40 -d driver=remote,remote=tcp://192.168.0.111:55132 -s 2048000 - > aprs-dump.iq

RTL-SDR remote access

RTL-SDR-based devices can be accessed also with the following tools:

rtl_tcp - server software from rtl-sdr tools enabling remote access
rtl_rpcd - a fork of rtl-sdr tools and librtlsdr with extended support for remote access

I’ve tested use of both rtl_tcp and the fork rtl_rpcd and while they both work, they only support RTL-SDR hardware and have some shortcomings. rtl_tcp allows remote access of SDR hardware, but the command-line tools with the original rtl-sdr distribution can only use local devices. rtl_rpcd is a fork of librtlsdr that provides an additional server tool to work around this, so that any application that links to the forked version of the library can be configured to connect to the rtl_rpcd server using environment variables. It does work, but configuration is a bit cumbersome.

There is another design issue present in both rtl_tcp and rtl_rpcd: it keeps the SDR hardware device active and receiving even when no client is connected to the server. In addition to wasting system resources, I noticed that my NooElec NESDR SMArt dongle started to warm up getting quite hot after being accidentally left active for a day or two, especially when using high LNA gain levels. This should not be a problem, but is worth knowing, as some SDR dongles may require additional cooling.

Other tools for remote access

There are several other tools for SDR remote access, but I have not used these personally:

sdrdaemon - provides remote access for GNU Radio and sdrangel SDR analyzer with support for multiple types of SDR hardware

Proprietary solutions:

SPY Server - Multi-client SDR Server for SDR# and Airspy (with support for RTL-SDR added recently)
Cloud-SDR - Streams raw IQ samples from SDR receivers to clients through a cloud platform

You can follow me on Twitter at @mikaelnou where I will tweet about new blog posts when they are published.