What we're building, and why it isn't another console
The short answer: because there are already five good ones, they all have the same shape, and that shape was settled before the thing that matters most had happened.
The survey
Before building anything, we went and looked at what exists on Linux today. Three projects actually matter, and the picture moved twice in five months — so this is dated deliberately.
| Project | Licence | State as of 2026-09 |
|---|---|---|
| ramdor/Thetis | GPL-2.0 | Archived 2026-04-02, reactivated ~2026-07-02, commits as recent as 2026-09-09 |
| boydsoftprez/NereusSDR | GPL-3.0 | Alpha, solo developer, cross-platform rewrite |
| dl1ycf/pihpsdr | GPL-3.0 | Mature, maintained, utilitarian |
Thetis is the interesting one. It's Windows-only — .NET Framework 4.8, WinForms and SharpDX, and SharpDX is itself archived. The maintainer archived the project in April 2026 saying active development had stopped, naming the .NET 4.8 dependency as "increasingly outdated". It came back in July for remote-operation work.
That arc is worth sitting with. The most capable console in the ecosystem was parked because of its toolkit, not its radio code.
The thing they have in common
Every console since PowerSDR in 2003 has the same shape: one app, one radio, one operator, one screen — the application owning the hardware exclusively, the interface a skeuomorph of a front panel you turn by hand.
Thetis, SmartSDR, ExpertSDR3, SDR Console, NereusSDR: all of them are that same model, drawn better.
Three things changed underneath, and nobody has built for any of them.
1. The radio is a service
TCI is a WebSocket. HPSDR Protocol 2 is UDP. Both are multi-client by design, and every console still behaves as though it owns the radio alone. The shift is not technical, it is conceptual: the console stops being the owner and becomes one client among many — many clients, many devices, many operators, one radio.
2. The operator is anywhere
The phone in the garden. The laptop on the sofa. The seven-inch panel bolted to the radio itself. If the radio is a service, the console is just a view of it, and there is no reason that view should live on one machine in one room.
3. The band makes sense
Propagation, spotting and band conditions belong next to the radio, not in a separate browser tab you forget to open.
What came out of it: Elmer
An elmer, in ham radio, is the operator who shows a newcomer the ropes. This is one, in software: a local web console for any Linux ham station. Not an MB1 tool — the MB1 is simply the first station it runs on.
A local web app is the literal implementation of "the operator is anywhere", not a metaphor for it. The station machine runs the service; any device on the network is the console.
It also sidesteps the toolkit problem completely. No Qt version, no GTK theming, no Wayland-versus-X11, no "crashes on Linux at startup" — which is a real thing that happened to the ExpertSDR3 utilities at 1.3.1, and which we wrote up separately.
That last point is not a small one. The console that got parked for being tied to .NET 4.8, and the console that stopped launching because Qt 6.5 wanted one more xcb package, are the same failure wearing different clothes. A browser is the one runtime on a Linux station you can assume is current.
The hardware strand
Running alongside all of this is the MB1SDR bring-up: getting an RFspace-class MB1 onto the network and reachable remotely. It has been its own education — particularly the internal USB-LAN adapter the SDR module hangs off, which is the reason radio discovery is so brittle and why interface timing at boot matters more than it should.
The motto, since it earns its place
The radio is a service. The operator is anywhere. The band makes sense.
Short form, for a header: built after the network.