Also known as: WebSDR, Web SDR, OpenWebRX, KiwiSDR, online SDR
A Web SDR is a remote software-defined radio receiver whose tuning, waterfall, and audio are delivered to an ordinary web browser, so anyone with a URL can listen without owning hardware.1 The server sits at an antenna, digitizes a slice of spectrum, and streams it out; each connected browser opens its own virtual receiver inside that slice, tuning and demodulating independently. Popular implementations include OpenWebRX, the KiwiSDR appliance, and the long-running university WebSDR network, which together put thousands of receivers online worldwide.
How it works
A Web SDR is three cooperating pieces: a front end, a DSP/streaming server, and a browser client. The front end is a physical receiver — a KiwiSDR-class direct-sampling board, an RTL-SDR, or a wideband SDR — that hands the server a block of spectrum as IQ samples. The server runs the heavy signal processing: it computes an FFT for the waterfall, and for each connected user it spins up an independent virtual receiver that digitally down-converts, filters, and demodulates the user’s chosen channel. OpenWebRX, for instance, leans on the csdr DSP library for these per-client chains.
The browser side is deliberately thin. The client renders the scrolling waterfall on a canvas, captures tuning gestures, and plays back audio, but it does the demodulation on the server and receives only the finished product. Two streams flow over WebSockets: a compressed waterfall/spectrum feed and a low-bitrate audio feed (often Opus- or ADPCM-coded). When you drag the tuning cursor, the browser sends the new center frequency and mode back up the socket, and the server re-points that user’s virtual receiver. Because every listener has a private DSP chain but shares one FFT and one antenna, a single modest server can serve dozens of simultaneous, independently tuned users across the whole captured band.
Some deployments instead stream raw IQ to the client and demodulate in JavaScript or WebAssembly, trading bandwidth for a richer client and offloading the server. The SpyServer protocol takes a related but non-browser approach: it streams IQ over TCP to a native client such as SDR#. Web SDRs are the pure-web sibling of that idea, requiring nothing but a browser.
Relevance to SDR
Web SDRs are how most people first touch SDR without buying hardware, and they are a genuinely useful engineering tool. Shortwave listeners use them to check propagation from another continent; amateurs monitor their own transmissions from a distant receiver; and signal hunters compare how a mode looks on antennas spread across the globe. For someone building SDR software, a public Web SDR is a live, always-on source of real signals and a reference implementation of the hard parts of remote radio: many-user channelization, bandwidth-frugal waterfall coding, and latency-tolerant audio streaming over lossy links.
GopherTrunk is not a Web SDR — it is a headless trunking scanner/decoder that turns IQ into decoded traffic, not a multi-user browser receiver, and it has no built-in web tuning UI. The relationship is complementary and architectural. A Web SDR and GopherTrunk both begin by channelizing wideband IQ into per-signal streams, and both must handle sample flow without dropping data, so the streaming and buffering lessons carry across. In a larger monitoring rig the two can even chain: a networked SDR front end (SpyServer- or IQ-streaming-style) feeds GopherTrunk for decoding while a Web SDR on the same antenna gives humans a browser view of the same spectrum. GopherTrunk stays focused on the decode side and leaves the browser-facing receiver to purpose-built projects like OpenWebRX and KiwiSDR.
Sources
-
WebSDR — Wikipedia, on browser-accessible remote SDR receivers and the shared-antenna, per-user virtual-receiver model. See also the OpenWebRX project site for a concrete multi-user, csdr-backed implementation. ↩