Also known as: SpyServer, spyserver
The SpyServer protocol is Airspy’s network SDR streaming protocol: a server attached to the radio ships a decimated, retunable slice of the captured spectrum to remote SDR# and compatible clients over TCP, rather than the whole wideband stream.1 That server-side channelization is its defining trick — it lets many users share one radio, or one user work over a modest internet link, without moving the radio’s full sample rate across the wire.
How it works
The client opens a TCP connection and negotiates a session: it queries the device (tuner range, maximum sample rate, gain stages) and then subscribes to an IQ stream at a chosen centre frequency and a chosen decimation stage. The server, which is continuously digitizing a wide band, runs a digital down-converter and decimator to extract just the requested channel and sends that reduced-rate IQ down the socket. Because the heavy lifting happens on the server, the client only ever receives the bandwidth it asked for — a few hundred kHz of a several-MHz capture — which is what makes it usable over the public internet where rtl_tcp’s full-rate raw stream would not fit.
The protocol also offers a separate low-rate FFT/spectrum stream so a client can render a waterfall of the whole band while pulling audio-bandwidth IQ from one spot within it, and it can hand different clients different slices of the same radio simultaneously. Streams can be sent as reduced bit-depth IQ to shave bandwidth further. The wire format is Airspy’s own binary framing — richer than rtl_tcp’s one-byte commands, because it has to convey the decimation state and dual streams — and it is the transport behind many public Airspy-based receivers.
Relevance to SDR
SpyServer is the standard way to put an Airspy (or Airspy HF+) on the network and the backbone of a large public network of shared receivers browsable from SDR#. Conceptually it sits between the dumb-pipe network IQ streaming of rtl_tcp and a full browser-based WebSDR: like WebSDR it serves many users a narrow slice each, but it streams IQ to a native client for local demodulation rather than delivering finished audio in a web page.
GopherTrunk does not speak the SpyServer protocol. Its network sources are the raw-IQ servers, and an Airspy is used locally through GopherTrunk’s own Airspy support, feeding the decode chain from the device directly rather than over SpyServer. The protocol is relevant here as the model of server-side channelization — pushing the down-conversion to the radio end — which is exactly the operation GopherTrunk performs internally on a local wideband capture to isolate each control channel. Where SpyServer decimates for the network, GopherTrunk decimates for the decoder.
In practice
A SpyServer instance is configured with a device, a maximum bandwidth to expose, and per-client limits,
then advertised so clients connect by spyserver://host:port. Because the server can cap the maximum
decimation a client may request, an operator running a public receiver can guarantee that no single user
consumes the whole radio or saturates the uplink. For a trunking listener the trade-off matters: a P25
or DMR control channel is only a handful of kHz wide, so the decimated slice SpyServer sends is tiny and
comfortably fits a home internet connection — but following voice grants that hop across a wide band can
demand retuning or a second stream, which is where a locally attached radio feeding a decoder directly,
as GopherTrunk uses it, avoids the round-trip latency of asking a remote server to move.
Sources
-
Airspy Quickstart — Airspy’s documentation, covering the SpyServer network protocol, server-side decimation of a tunable slice, and the SDR# client ecosystem. ↩