Request preparation

• I used an AI assistant to help structure this request
• I checked for existing issues covering the same feature

What would you like?

Problem

AetherSDR already integrates two amplifier families: the FlexRadio-relayed PGXL (AmpModel/AmpApplet) and the direct-connected ACOM S-series (AcomConnection/AcomApplet, per docs/architecture/acom-600s-amplifier-design.md). SPE Expert amplifiers (1.3K-FA / 1.5K-FA / 2K-FA) are very common companions to FlexRadio stations, but today they require a separate control application — there is no way to see the amplifier's power/SWR/temperatures or switch Operate/Standby from inside AetherSDR.

Related: #1109 / #1170 asked for a general amplifier plugin ecosystem (both closed). This is the narrower, concrete thing the ACOM integration already set the precedent for: one more in-core peripheral accessory.

Proposal

Add SPE Expert support as a peripheral accessory following the ACOM precedent exactly (no IRadioBackend involvement — the SPE has no FlexRadio awareness):

• src/core/SpeProtocol.h/.cpp — pure protocol layer (framing, checksums, keystroke command set, 67-char CSV status decode), unit-tested against the spec's own literal byte examples.
• src/core/SpeConnection.h/.cpp — serial (115200 8N1) or ser2net TCP transport (raw or telnet mode) with a 100 ms status poll (the SPE never pushes — it only answers), poll-silence detection, auto-reconnect.
• src/gui/SpeApplet.h/.cpp — dedicated applet: Power / antenna-SWR / ATU-SWR gauges (the power gauge rescales with the selected LOW/MID/HIGH level, like the amp's own display), V/I/temperature readouts, warning+alarm banner, front-panel keystroke buttons (OPER/STBY, power level, TUNE, OFF, INPUT, ANT, drive-power arrows), plus a hardware power-ON pulse (RFC 2217 DTR/RTS over ser2net telnet, or the local serial lines on a COM connection).
• Radio Setup → Peripherals row (Serial ⇄ Network), same pattern as the ACOM row; settings nested under PeripheralSettings device "SpeExpert".
• Design note at docs/architecture/spe-expert-amplifier-design.md, touchpoint tag peripheral(spe), provenance in THIRD_PARTY_LICENSES.

Protocol authority is SPE's own published Application Programmer's Guide (Rev 1.1, 2015) — clean-room, no third-party code. Model identification is trivial for this family: the amplifier reports its ID (13K/15K/20K) in every status reply, so gauge scales follow it with no heuristics.

Scope deliberately excludes menu navigation (SET/DISPLAY), manual L/C ATU stepping, and firmware/settings operations — SPE reserves those for their own KTerm application.

Hardware validation

I own a 1.5K-FA connected via ser2net (telnet mode) and previously controlled it with my own Python application implementing this same protocol. The branch has already been tested against the real amplifier: model identification, telemetry/gauges, OPERATE/STANDBY, power-level cycling with gauge rescaling, warnings, poll-silence detection, and the RFC 2217 power-ON pulse all verified working. Several real-hardware facts not in the spec are folded in: commands need a trailing CR LF in practice, the per-level display thresholds for the 1.5K-FA, and ser2net telnet mode working fine alongside raw.

Cross-platform impact

None beyond the existing peripheral pattern — Qt6 QSerialPort (behind HAVE_SERIALPORT) and QTcpSocket only, no new dependencies. Per GOVERNANCE.md this should not need an RFC (new applet, no existing-UX changes, no new external dependencies) — happy to convert this issue to an [RFC] if you prefer.

Alternatives considered

• Extending AmpApplet/AcomApplet — rejected; the ACOM design note §2 documents exactly why shared amp applets were reverted.
• A generic "serial amplifier" abstraction over ACOM+SPE — premature with two very different wire protocols (binary push vs. ASCII poll); revisit if a third serial amp family arrives.

I have a working, hardware-validated branch implementing all of the above and will open a PR referencing this issue.

73, Miguel (EC5W)