Ham radio control software for Linux.

What runs on Linux today

RigPlane ships on Linux in two complementary forms. The open-core rigplane Python library is pip install rigplane on any modern distro — headless engine, browser UI, MIT-licensed. RigPlane Pro is the packaged desktop client on top of that: a Flatpak for AMD64 and ARM64, so you do not have to assemble a Python environment to operate. It is meant to work out of the box on any distribution with PipeWire or PulseAudio.

The Linux desktop build covers the radio-control engine, the operator console (dual-VFO, panadapter, waterfall, S-meter), the local audio bridge for receiving from and transmitting to the radio, the CW console, and an audio path WSJT-X can use as a soundcard. Linux already has strong native ham tooling — hamlib, fldigi, WSJT-X, JS8Call, and wfview all run natively here — and RigPlane is happy to coexist with them. The differentiation is one console for Icom radios (LAN or USB) and the Yaesu FTX-1 (USB), an audio bridge that does not require manual JACK or PulseAudio plumbing, and the same UI you get on macOS and Windows.

Supported radios

RigPlane talks to your transceiver directly — UDP for IP-connected radios, USB / serial where applicable — with no third-party daemon, no vendor app, and no hamlib bridge in the loop. Supported radios: Icom IC-7610, IC-7300, IC-705 and Yaesu FTX-1. The IC-9700 has a rig profile and backend, and its satellite mode is not implemented. The Xiegu X6100 is profile only — the serial backend refuses it, so control is not available today. The Lab599 TX-500 is profile only; its Kenwood CAT backend is not implemented, so control is not available today. The Lab599 TX-500 is profile only; its Kenwood CAT backend is not implemented, so control is not available today.

Per-radio setup pages are live for IC-7610, IC-7300, IC-705, IC-9700, Yaesu FTX-1, Xiegu X6100, and Lab599 TX-500, with radio-side checklists in the RigPlane docs.

Audio, CW, and digital-mode integration on Linux

Linux audio is in the middle of a generational transition from PulseAudio to PipeWire, with ALSA still living underneath both. RigPlane Pro targets that stack honestly: the audio bridge creates a PipeWire loopback on modern distros and falls back to a PulseAudio null sink on systems that still run PulseAudio. Systems with neither are not covered by the Pro app.

• PipeWire and PulseAudio. The bridge auto-detects which sound server is running and registers RigPlane as a regular source and sink. No pavucontrol juggling, no manual pw-link commands — though both still work if you want to wire things by hand.
• ALSA (open-core library only). For headless or minimal-install boxes, the open-core library talks to ALSA directly. The Pro desktop is built for a normal desktop session.
• CW console. CW console with sending and a decoder in the Pro app. RigPlane has no paddle or straight-key input of its own.
• WSJT-X, JS8Call, fldigi. These see RigPlane as a normal soundcard via the bridge. FT8 and FT4 work through WSJT-X the way they do with any conventional soundcard interface.
• Latency. The radio delivers PCM (or μ-law, or USB audio on USB radios); over the network RigPlane sends audio as Opus with small buffers.

Install in 5 minutes

For the open-core library, pip install rigplane in a Python 3.11+ virtual environment is enough to bring up the headless engine and the browser UI on any modern Linux distro. The Pro desktop client is on the downloads page, which lists which platforms each beta release covers — check it for the current stream before planning a Linux install (Linux Flatpaks first shipped in beta.5). The Pro app is a Flatpak for AMD64 and ARM64 and is meant to work out of the box on any distribution with PipeWire or PulseAudio. Setup walk-throughs for each supported radio backend live in the rigplane.dev guide.

Why a Linux-native experience matters

Plenty of ham-radio control software targets Windows first and reaches Linux only via Wine, a Docker container, or a half-maintained port. RigPlane Pro is a native Linux desktop application — the same engine that runs on macOS and Windows, compiled for Linux and packaged for normal desktop distros. The open-core library underneath is platform-agnostic Python; you can run the engine on a headless server and connect the UI from anywhere on your network.

That matters most for the audio path. Linux audio works fine, but it is built out of layers — ALSA, PulseAudio, PipeWire, JACK — and a Windows-port-via-Wine solution typically does not understand any of them well. A native client that auto-provisions a PipeWire or PulseAudio sink avoids the whole class of "where did my soundcard go" problems and keeps your existing WSJT-X / JS8Call / fldigi setup intact.

What to do next

Last reviewed 2026-10-22.