Self-Hosted Signal Processing for SDR: GNU Radio vs Liquid-DSP vs SoapySDR

Introduction

Software-Defined Radio (SDR) has revolutionized RF engineering by moving signal processing from specialized hardware into software. Whether you’re decoding satellite telemetry, analyzing cellular signals, building a DIY radar, or just listening to amateur radio bands, the core of every SDR application is the signal processing pipeline — the chain of filters, demodulators, decoders, and synchronizers that turn raw IQ samples into meaningful data.

Three open-source frameworks dominate the self-hosted SDR signal processing landscape: GNU Radio, the visual flowgraph-based powerhouse; Liquid-DSP, a lightweight C library optimized for embedded and resource-constrained systems; and SoapySDR, the hardware abstraction layer that lets any SDR application talk to any SDR device.

Why Self-Host Your SDR Signal Processing?

Cloud-based SDR services exist, but they’re expensive, high-latency, and limit you to pre-built processing pipelines. Self-hosting puts the entire signal chain under your control — you decide the sample rate, the processing stages, and where the output goes. This matters for applications like satellite ground stations (covered in our SDR receiver guide), RF signal analysis (see our URH and Inspectrum comparison), and amateur radio digital modes (detailed in our ham radio digital voice guide).

A self-hosted SDR processing server can run 24/7, recording spectrum to disk and running automated signal classification. Paired with a remote SDR receiver accessible over the network, you can monitor bands from anywhere. The processing server doesn’t need to be near the antenna — stream IQ samples over your LAN and process them on a more powerful machine.

Comparison Table

GNU Radio: The Flowgraph Powerhouse

GNU Radio (6,117 stars, GPLv3) is the most comprehensive signal processing framework in the open-source world. Its block-based architecture lets you build signal processing pipelines visually in GNU Radio Companion (GRC), connecting blocks for filters, demodulators, synchronizers, and sinks by drawing lines between them. Under the hood, blocks are implemented in C++ for performance, with Python bindings for rapid prototyping.

GNU Radio is ideal for self-hosted SDR servers because you can design a flowgraph in GRC on your desktop, then deploy the generated Python script headlessly on a server. The flowgraph scheduler handles real-time constraints, buffer management, and multi-threading automatically — you focus on the signal processing logic, not the plumbing.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# GNU Radio Python flowgraph — FM receiver
from gnuradio import gr, analog, audio, blocks, filter
from gnuradio.filter import firdes

class fm_receiver(gr.top_block):
    def __init__(self):
        gr.top_block.__init__(self, "FM Receiver")
        
        # Parameters
        samp_rate = 2.4e6
        audio_rate = 48e3
        fm_deviation = 75e3
        
        # Source (RTL-SDR via SoapySDR)
        self.src = analog.sig_source_c(samp_rate, analog.GR_COS_WAVE, 100e6, 1)
        
        # Low-pass filter
        taps = firdes.low_pass(1, samp_rate, 200e3, 50e3)
        self.lpf = filter.fir_filter_ccf(1, taps)
        
        # FM demodulator
        self.fm_demod = analog.quadrature_demod_cf(fm_deviation / samp_rate)
        
        # Audio sink
        self.audio_sink = audio.sink(int(audio_rate), "default", True)
        
        # Connect blocks
        self.connect(self.src, self.lpf, self.fm_demod, self.audio_sink)

if __name__ == "__main__":
    tb = fm_receiver()
    tb.start()
    tb.wait()

Docker Compose for a headless GNU Radio server:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

version: "3.8"
services:
  gnuradio-server:
    image: ghcr.io/gnuradio/gnuradio:latest
    container_name: gnuradio
    devices:
      - /dev/bus/usb:/dev/bus/usb
    volumes:
      - ./flowgraphs:/flowgraphs
      - ./recordings:/recordings
    working_dir: /flowgraphs
    command: python3 fm_scanner.py
    restart: unless-stopped
    network_mode: host

Liquid-DSP: Lightweight & Embeddable

Liquid-DSP (2,240 stars, MIT license) is a standalone C library for software-defined radio signal processing. Unlike GNU Radio’s heavyweight framework, Liquid-DSP is a single shared library that you link into your application. It provides a complete modem toolkit — modulation (BPSK through 256-QAM, OFDM, GMSK), forward error correction (convolutional, Reed-Solomon, LDPC, turbo codes), synchronization (Costas loop, Gardner, polyphase filterbank), and filter design.

Liquid-DSP shines in embedded and resource-constrained environments. It compiles to a few hundred kilobytes and runs on ARM Cortex-M microcontrollers as well as Raspberry Pi and x86 servers. If you’re building a dedicated SDR application (e.g., a satellite telemetry decoder, a pager demodulator, or a custom digital mode transceiver), Liquid-DSP gives you maximum control with minimal overhead.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

// Liquid-DSP: FM demodulator in C
#include <liquid/liquid.h>

int main() {
    // Create modem objects
    freqdem dem = freqdem_create(0.5);  // FM demodulator
    firhilbf hilbert = firhilbf_create(7, 60.0f);
    
    // Create filter (low-pass, 200 kHz from 2.4 MHz)
    unsigned int h_len = 64;
    float fc = 200e3f / 2.4e6f;
    float h[h_len];
    liquid_firdes_kaiser(h_len, fc, 60.0f, 0.0f, h);
    firfilt_crcf lpf = firfilt_crcf_create(h, h_len);
    
    // Process samples in a loop
    while (running) {
        // Read IQ samples from SDR hardware
        float complex x = read_sample();
        
        // Filter -> demodulate -> output
        float complex y;
        firfilt_crcf_push(lpf, x);
        firfilt_crcf_execute(lpf, &y);
        
        float audio;
        freqdem_demodulate(dem, y, &audio);
        write_audio(audio);
    }
    
    // Cleanup
    freqdem_destroy(dem);
    firfilt_crcf_destroy(lpf);
    return 0;
}

SoapySDR: Hardware Abstraction

SoapySDR (1,453 stars, Boost license) solves a practical problem: every SDR manufacturer provides its own driver API. RTLSDR uses librtlsdr, HackRF uses libhackrf, USRP uses UHD, LimeSDR uses LimeSuite, and so on. SoapySDR provides a unified API that works with all of them — write your application once, and it works with any supported SDR hardware.

SoapySDR is the glue between GNU Radio and your SDR hardware. It’s also the foundation for tools like SoapySDRPlay, SoapyRemote (networked SDR access), and SoapyPower (RF spectrum recording). If you’re building a self-hosted SDR server that needs to support multiple hardware types, SoapySDR is essential infrastructure.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Install SoapySDR and device drivers
sudo apt-get install soapysdr-module-all
soapysdr-module-rtlsdr soapysdr-module-hackrf

# List available SDR devices
SoapySDRUtil --find
# Expected output: found device 0, driver=rtlsdr, label=Generic RTL2832U

# Stream IQ samples to stdout
SoapySDRUtil --rate=2.4e6 --freq=100e6 --gain=20 --format=CF32

Deployment Architecture

A complete self-hosted SDR processing pipeline:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Antenna
    │
    ▼
SDR Hardware (RTL-SDR / HackRF / LimeSDR / USRP)
    │  └─ SoapySDR Hardware Abstraction
    ▼
IQ Sample Stream (via local USB or network)
    │
    ▼
Signal Processing Engine
    │  ├─ GNU Radio (flowgraph-based processing)
    │  └─ Liquid-DSP (custom C/C++ processing)
    ▼
Output ──► Audio / Decoded Data / Spectrum Display / Recording

For multi-band monitoring, run multiple GNU Radio flowgraphs in parallel, each tuned to a different frequency. Containerize each flowgraph as a separate Docker service, with shared storage for recordings. Our RF signal analysis guide covers tools for analyzing the captured signals offline.

Choosing the Right Framework

Choose GNU Radio if you want a visual, block-based workflow, need rapid prototyping capabilities, or are building complex multi-stage receivers. The out-of-the-box block library covers most common modulation schemes and filter types, and the community-maintained out-of-tree (OOT) modules add support for everything from ADS-B to LTE.

Choose Liquid-DSP if you’re building a dedicated, resource-efficient SDR application that needs to run on embedded hardware, you want fine-grained control over buffer management and timing, or you’re implementing a custom protocol that doesn’t fit GNU Radio’s block model. The MIT license is also more permissive for commercial products.

Use SoapySDR regardless — it’s not an alternative to GNU Radio or Liquid-DSP, but complementary infrastructure. Any serious SDR setup should use SoapySDR for hardware abstraction, then choose GNU Radio or Liquid-DSP (or both) for signal processing.

FAQ

Can I run GNU Radio headlessly on a server?

Yes. GNU Radio Companion generates Python scripts that run without a GUI. Design your flowgraph on a desktop, export the Python file, and deploy it on your server with Docker. The Python script handles all signal processing — the GUI is only needed for design.

What SDR hardware should I start with?

The RTL-SDR Blog V4 ($35) is the best entry point — it covers 24 MHz to 1.7 GHz with 2.4 MHz bandwidth. For transmit capability, the HackRF One ($300) or LimeSDR Mini ($199) are excellent choices. All three work with SoapySDR out of the box and have mature GNU Radio support. For serious satellite work, the USRP B210 ($1,100) offers 56 MHz instantaneous bandwidth and a more stable clock.

How much CPU does real-time SDR processing need?

For basic FM demodulation at 2.4 MSPS, a Raspberry Pi 4 handles it comfortably (30-40% CPU). Processing 20 MSPS of LTE signals with GNU Radio requires a modern x86 desktop (Ryzen 5 or better). Liquid-DSP’s C implementation is about 2-3x more CPU-efficient than GNU Radio for equivalent processing, making it better suited for embedded systems and high-bandwidth applications.

How do I access my SDR hardware remotely?

SoapyRemote lets you stream IQ samples over TCP/IP — connect the SDR hardware to a Raspberry Pi near your antenna, run SoapySDRServer on the Pi, and configure your GNU Radio flowgraph to use the remote device. This is the standard architecture for self-hosted SDR receivers. For ham radio digital modes that need real-time decoding, check our ham radio and digital voice guide.

What’s the difference between GNU Radio blocks and Liquid-DSP functions?

GNU Radio blocks are autonomous processing units with their own buffers, thread scheduling, and message passing — they’re designed for a dataflow programming model. Liquid-DSP functions are traditional library calls that process buffers synchronously — you’re responsible for buffer management, threading, and timing. GNU Radio is easier to prototype with; Liquid-DSP gives you more control and better performance for production systems.

💰 想测试你的市场判断力？我用 Polymarket 做预测市场交易——这是全球最大的预测市场平台，从大选结果到技术监管时间线，什么都可以押注。和赌博不同，这是真正的信息市场：你懂的信息越多，胜率越高。我靠预测技术相关事件的走向已经赚了不少。用我的邀请链接注册：Polymarket.com