Rig control
VFO A and B, band and mode, tuning by step or typed frequency, RIT and XIT with the offset shown, antenna selection, filter width, AGC, preamp, attenuator, noise blanker and reduction, notch, split.
HAMDECK
FTDX-101MP
Remote station control · open source
HamDeck puts your rig's front panel on a laptop and carries real two-way audio with it. Full CAT control, receiver and transmit audio, a system-wide PTT key — over your own network or the open internet, with nothing between you and the radio but software you own.
What it does
Everything you reach for while operating is on the panel. Everything you reach for occasionally is one click behind a group. Nothing important is buried.
VFO A and B, band and mode, tuning by step or typed frequency, RIT and XIT with the offset shown, antenna selection, filter width, AGC, preamp, attenuator, noise blanker and reduction, notch, split.
Receiver audio and microphone over WebSocket — no plugins, no UDP, so it crosses a tunnel that only carries TCP. Pick your speaker and microphone independently of what Windows has set as default.
A system-wide key that works while the panel sits behind your logging software. Map it to a keyboard, a macro pad, or a footswitch. The receiver mutes while you transmit, so you never hear yourself delayed.
Tuner control with live status — you can see it tuning and see it finish. The station's external tuner and the rig's internal ATU stay separate and clearly named, so neither gets hit by mistake.
Keep several stations — a live rig and a test server — and pick one at login. The client remembers hosts, callsign, audio devices and window position. It never stores a password.
Memory recall, frequency presets, CW send with the host sanitising the text, voice memories, recording, and DX cluster spots — each appearing only when the host you are connected to actually provides it.
How it works
The host lives with the radio and owns the serial port and the sound card. The client owns nothing but the screen. Everything between them is a documented HTTP and WebSocket API — which is why a browser, a command line and a native panel can all drive the same station.
At the rig
CAT over serial, USB codec for audio, REST + WebSocket API. Runs on Linux or Windows; a small always-on machine is enough.
In between
TCP only — a LAN, a VPN, or a tunnel with a real certificate. Sessions are authenticated; control and audio both require a login.
Wherever you are
A native Windows panel, x64 and ARM64. A headless CLI exists for scripting, and the host serves an admin page in the browser.
The client asks the host what it can do when it connects, and controls the host doesn't provide are greyed out with the reason. A capability that isn't there is never a button that quietly does nothing.
Measured, not estimated
Audio latency is the thing that decides whether remote operating feels like operating. These are figures read off a live FTDX-101MP, not targets.
| Property | Value |
|---|---|
| Transmit audio latency, steady state | 202–233 ms |
| Adaptive buffer range | 80–600 ms |
| Receiver audio | 22 050 Hz · 16-bit · mono |
| Transmit audio | 48 000 Hz · 16-bit · mono |
| Rig state refresh | every 200 ms |
| Host-side transmit timeout | 180 s, configurable |
| Client installer | 63 MB · x64 and ARM64 |
A cell link needs more cushion than a LAN, and a fixed buffer is wrong for one of them. The host watches for audio underruns and raises its target when the link is rough, easing it back down when things settle. It only trims between overs — never while you're talking.
Dropping PTT the instant you release it cuts off whatever audio is still queued — always the end of a word. The host asks the kernel exactly how much is left, waits that long, then unkeys. A hard ceiling means a stuck buffer can never hold the transmitter open.
Where the project is
HamDeck was built for one station and is being opened up. It runs a real FTDX-101MP every day. It is not yet a polished product for every shack, and this page would rather say so.