Ham radio control software for Linux.
Open the app, see your radio, operate. RigPlane Pro is a native Linux desktop app for IP-connected ham transceivers — Icom, Yaesu, Xiegu, Lab599 — with audio, CW, and digital-mode integration that works on PipeWire or PulseAudio without virtual cables or Wine.
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, targeting common distros so you do not have to assemble a Python environment to operate.
The current Linux 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 the integrations needed for WSJT-X, JS8Call, and fldigi to see RigPlane as a normal 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 multi-vendor IP control, 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. Production-grade backends today include the Icom IC-7610, IC-7300, IC-705, and IC-9700, plus Yaesu FTX-1, Xiegu X6100, and Lab599 TX-500. Profile-based support extends to additional Icom and Yaesu rigs that share the same control surface.
Per-radio setup notes live on the downloads page today. Dedicated per-rig pages are landing alongside the rest of the SEO build-out.
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 speaks to PipeWire on modern distros (Fedora 34+, recent Ubuntu, Debian 12, Arch), falls back to PulseAudio on systems that still run it, and uses ALSA directly where neither daemon is installed.
- PipeWire and PulseAudio. The bridge auto-detects which sound server is running and registers RigPlane as a regular source and sink. No
pavucontroljuggling, no manualpw-linkcommands — though both still work if you want to wire things by hand. - ALSA legacy. 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. Local keyer, decoder, and CW tools live inside the Pro app — paddle and straight-key input handled in the desktop, not over a roundtrip to the browser tab.
- 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. Opus over UDP, tight buffers, no resampling round-trips. Tuned for headphone monitoring and CW operation.
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 — the post-Q5 page lists macOS, Linux, and Windows builds, with packaging targeted at common desktop distros (Debian/Ubuntu and Fedora are the primary tested targets). 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-05-19.