Field Guide · technology

Also known as: Pothos, Pothos SDR, Pothos framework

Pothos is a graph-based data-flow framework for building signal-processing and software-defined-radio applications by wiring reusable blocks into a streaming graph, positioned as an alternative runtime to GNU Radio.1 Like GNU Radio it lets you compose a system from small units — a source, filters, a demodulator, a sink — but it uses its own scheduler, block API, and design tool, and it is the project that also produced SoapySDR.

SDR source FIR filter demod sink a scheduler streams sample buffers along each connected port
A Pothos application is a graph of processing blocks connected by streaming ports; the runtime scheduler moves sample buffers from block to block.

How it works

The core abstraction is the block — an object with typed input and output ports plus a work() method that consumes samples on its inputs and produces samples on its outputs. A flowgraph is built by connecting one block’s output port to another’s input port, and a runtime scheduler (part of PothosCore) decides when each block runs, hands it buffers, and propagates back-pressure so a slow downstream block throttles the whole chain. Buffers are passed by reference and pooled, and blocks that need it can attach metadata “labels” to positions in the stream — closely analogous to GNU Radio’s stream tags — for events like a retune or a burst boundary.

Two design choices distinguish Pothos from GNU Radio. First, blocks can be written in C++ or Python and are described by a JSON block-registry entry, which the tooling reads to auto-generate GUI widgets and parameter fields. Second, the graph can be distributed: because blocks communicate through a serialization layer, a flowgraph can span multiple processes or even multiple machines, with the scheduler stitching remote blocks into the same logical graph.

Variants

Pothos is a small ecosystem of packages rather than a single binary. PothosCore is the runtime and block API; Pothos Flow is the graphical designer where you drag blocks onto a canvas and connect them, comparable in role to GNU Radio Companion; toolkits add DSP primitives, an SDR source/sink built on SoapySDR, plotting widgets, and network transport. A gr-pothos bridge lets existing GNU Radio blocks run inside a Pothos graph, easing migration between the two worlds. On Windows the “Pothos SDR” installer bundles the framework together with a large collection of SDR tools and drivers.

Relevance to SDR

Pothos matters as a demonstration that GNU Radio’s block-and-flowgraph model is a general architecture, not a single implementation — the same “wire blocks into a streaming graph” idea can be built with a different scheduler, a different block API, and first-class distribution across machines. Its lasting practical contribution to the wider ecosystem is SoapySDR, which came out of the Pothos project and is now the vendor-neutral hardware layer that many unrelated applications depend on.

GopherTrunk is not built on Pothos or on any general data-flow framework; it is a purpose-built pure-Go trunking decoder with a fixed software-defined-radio pipeline rather than a user-editable graph. But the underlying pattern is the same one GT implements by hand: sources, filters, a channelizer, and demodulators connected by buffered streams, with back-pressure and overrun handling between stages. Understanding the block/scheduler model clarifies what a fixed-pipeline decoder like GT trades away (graph flexibility) in exchange for a simpler, dependency-free, statically compiled runtime.

Sources

  1. PothosCore wiki — Pothosware, documentation of the Pothos block API, scheduler, Pothos Flow designer, and the framework’s relationship to SoapySDR and GNU Radio. ↩

See also