Also known as: SoapyRemote, remote.soapy
SoapyRemote is a SoapySDR module that makes any locally-attached SDR usable over a network as if it were plugged into the remote machine — it forwards the entire SoapySDR device API and the IQ sample stream across the link.1 Where rtl_tcp is a fixed protocol for one family of dongles, SoapyRemote is a general transparent bridge: whatever radio SoapySDR supports locally, SoapyRemote exports remotely with the same interface applications already use.
How it works
On the machine with the radio you run SoapySDRServer, which advertises the device on the LAN
(via mDNS/Avahi) and listens for clients. On the application side, SoapySDR is told to open a device
with a driver=remote argument naming the server; the SoapyRemote client module connects, discovers
the remote device’s channels, gain elements, sample rates and tuning ranges, and presents them
upward exactly as a local driver would. Every API call — setFrequency, setSampleRate, setGain,
readStream — is marshalled across the link, so the application cannot tell it is talking to a radio
in another room.
Two channels carry the traffic: a reliable control connection for the API calls and a separate, latency-optimised path for the bulk sample stream, which can use UDP so a late packet is dropped rather than stalling the pipeline. SoapyRemote can apply a lightweight sample-format conversion to trim bandwidth — for example forwarding CS8 or CS16 instead of CF32 — and lets the client pick the sample format it wants. Because the abstraction is complete, the same GNU Radio flowgraph or SDR application runs unchanged against a local or a remote device; only the device string changes.
Relevance to SDR
SoapyRemote is the modern, device-agnostic answer to remote SDR. It is the natural choice when the radio is not an RTL dongle — a HackRF, LimeSDR, Airspy, or SDRplay — because rtl_tcp only speaks RTL and SpyServer only serves Airspy, whereas SoapyRemote inherits SoapySDR’s broad hardware support. In the GNU Radio and Pothos world it is the standard way to keep the radio at the antenna and the flowgraph on a workstation, a common network IQ streaming topology.
GopherTrunk has its own hardware backends rather than a SoapySDR dependency, so it does not consume a SoapyRemote device directly; its remote-radio story is the raw-IQ network sources it supports and its offline replay of captured files. SoapyRemote matters to a GopherTrunk user as the way to relay a non-RTL radio’s stream to a host that a GopherTrunk-supported input can read, and as the clearest example of the abstraction SoapySDR provides — a single device interface that a network transport can slot underneath without the application noticing.
In practice
A typical setup runs SoapySDRServer --bind on the antenna-side machine and opens
driver=remote,remote=192.168.1.50,remote:driver=hackrf on the client. Discovery over mDNS means the
server often appears automatically in SoapySDR device enumeration on the same LAN, so tools list it
without a hand-typed address. The two failure modes to watch are bandwidth — SoapyRemote forwards the
full negotiated sample rate, so a high-rate radio still needs a gigabit link unless you decimate first —
and clock domain: the samples are timed by the server’s radio, so a saturated network manifests as
overruns at the source rather than smooth degradation. Keeping the bulk stream on UDP and the same
subnet, as with any network IQ streaming, is the reliable
configuration.
Sources
-
SoapyRemote wiki — the Pothos project documentation for the SoapyRemote module and SoapySDRServer, describing transparent network access to any SoapySDR device. ↩