|
| 1 | +# Roadmap — AetherSDR |
| 2 | + |
| 3 | +> What AetherSDR has shipped, what is being built now, and why new radio families are deliberately paused until the headless engine split is finished. |
| 4 | +
|
| 5 | +Source: <https://www.aethersdr.com/roadmap> |
| 6 | + |
| 7 | +Roadmap |
| 8 | + |
| 9 | +## One engine, many front ends |
| 10 | + |
| 11 | +AetherSDR is being split in two: an engine that owns the radio, and a user interface that talks to it over a versioned protocol. Everything below either builds toward that split or waits for it. Phases are an order of work, not dates — we ship when a piece is right rather than when a calendar says so. |
| 12 | + |
| 13 | +### Why the split is worth doing |
| 14 | + |
| 15 | +Today the interface and the radio engine are one program, so the engine cannot run without a screen and the interface cannot be replaced without rebuilding everything. Separating them means the engine can run headless on the machine next to the radio, a second device can drive it across the network, and a browser or a text interface becomes possible without touching radio code. It also means every transmit safeguard lives in one place, below the boundary, where no client can talk its way past it. |
| 16 | + |
| 17 | +6 |
| 18 | + |
| 19 | +Radio families behind one interface |
| 20 | + |
| 21 | +3 |
| 22 | + |
| 23 | +Native platforms, no emulation |
| 24 | + |
| 25 | +1 |
| 26 | + |
| 27 | +Engine, once the split lands |
| 28 | + |
| 29 | +GPL |
| 30 | + |
| 31 | +v3, all of it |
| 32 | + |
| 33 | +#### Shipped |
| 34 | + |
| 35 | +available now |
| 36 | + |
| 37 | +##### The radio boundary v26.7.4 |
| 38 | + |
| 39 | +Every radio now sits behind one internal interface, so support for a new model is a self-contained piece of work rather than a change threaded through the whole application. The engine also became a library in its own right, which is what makes a headless build possible at all. |
| 40 | + |
| 41 | +##### Hermes-Lite 2 v26.7.4 |
| 42 | + |
| 43 | +Direct-sampling receive and transmit with the signal processing running on your computer, including the noise reduction, filters and transmit chain you already use on a FlexRadio. |
| 44 | + |
| 45 | +##### Networked Icom v26.8.2 |
| 46 | + |
| 47 | +Control and audio over the network for Icom transceivers that speak it, with each model's real capabilities read from the radio rather than assumed. |
| 48 | + |
| 49 | +##### ANAN-G2 and RTL-SDR receive |
| 50 | + |
| 51 | +Receive support for Apache Labs ANAN over openHPSDR Protocol 2, and for RTL-SDR dongles. Both demodulate on your computer through the same signal chain. |
| 52 | + |
| 53 | +##### Transmit safeguards, tightened |
| 54 | + |
| 55 | +Every intent that can key a transmitter — including the antenna tuner, which had slipped through — now passes the same refusal checks, and the engine reports a blocked control instead of silently doing nothing. |
| 56 | + |
| 57 | +#### Building now |
| 58 | + |
| 59 | +in progress |
| 60 | + |
| 61 | +##### The control protocol |
| 62 | + |
| 63 | +A versioned conversation between engine and interface: the engine describes what the connected radio can actually do, the interface subscribes to what it needs, and both sides can be upgraded independently. |
| 64 | + |
| 65 | +##### Transmit arbitration and per-client authorisation |
| 66 | + |
| 67 | +Once more than one client can reach the engine, exactly one of them may key the transmitter at a time, and each is authorised separately. This lands together with the protocol rather than after it — a scriptable interface that could reach the transmitter before the guard existed is not something we ship, even briefly. |
| 68 | + |
| 69 | +##### Honest capability reporting |
| 70 | + |
| 71 | +Radios revise what they can do mid-session, and a control that quietly stops matching the radio is worse than one that is plainly unavailable. Every backend is being made to announce its changes so the interface never shows a control the radio cannot honour. |
| 72 | + |
| 73 | +#### Next |
| 74 | + |
| 75 | +after the above |
| 76 | + |
| 77 | +##### Spectrum and audio across the network |
| 78 | + |
| 79 | +A dedicated path for the heavy data, shared memory on the same machine and compressed frames over a network link, so a remote interface gets the same waterfall and audio as one sitting at the radio. |
| 80 | + |
| 81 | +##### A reference thin client |
| 82 | + |
| 83 | +Part of the existing desktop interface, ported to speak the protocol instead of calling the engine directly. It exists to prove the boundary is complete — if a real interface can be built on it, so can any other. |
| 84 | + |
| 85 | +#### Exploring |
| 86 | + |
| 87 | +designed before built |
| 88 | + |
| 89 | +##### A browser interface |
| 90 | + |
| 91 | +Once the protocol carries everything the desktop needs, a web client is an interface problem rather than a radio one. It follows the proven protocol rather than leading it. |
| 92 | + |
| 93 | +##### Two radios in one session |
| 94 | + |
| 95 | +Running a second receiver alongside your main radio — a remote antenna, a second site, a receive-only source — needs decisions about audio routing, settings separation and which radio a transmit request means, before any of it is code. |
| 96 | + |
| 97 | +### Why new radios are paused |
| 98 | + |
| 99 | +We are not adding support for new radio families until the engine split is finished. Each additional radio multiplies work on a boundary that is still moving: capability reporting is not yet consistent across the radios we already support, the original FlexRadio path still bypasses part of the new data route, and the conversion of the command path has not started. Adding a seventh and eighth radio now would mean doing each of those conversions twice more, against code that is changing underneath them. |
| 100 | + |
| 101 | +Finishing first makes every radio after it cheaper to add, safer to review, and less likely to arrive with the quiet gaps that are expensive to find later. |
| 102 | + |
| 103 | +ColibriNANO — parked Yaesu FT-991 — parked Expert Electronics SunSDR — queued ADALM-Pluto — queued |
| 104 | + |
| 105 | +Parked is not declined. Two of these are finished, reviewed contributions waiting on sequencing rather than quality, and the work is credited to the people who wrote it. Radios we already support keep getting fixes and improvements throughout. |
| 106 | + |
| 107 | +### Shaping what comes next |
| 108 | + |
| 109 | +This roadmap is written in public and argued about in public. Feature requests, radio support and design disagreements all live in the issue tracker, and the decisions behind them are written down rather than announced. If something here matters to your station, the discussion is the place to say so. |
| 110 | + |
| 111 | +[Issue tracker](https://github.com/aethersdr/AetherSDR/issues) [Discussions](https://github.com/aethersdr/AetherSDR/discussions) [Sponsor the work](https://opencollective.com/aethersdr) |
0 commit comments