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?

Feature Request: RF2K+ / RF2K-S Power Amplifier Integration

Summary

Add native support for the RF-Power RF2K+ and RF2K-S solid-state HF power amplifiers (~2 kW LDMOS). These amplifiers are widely used alongside FlexRadio transceivers in the DX and contesting community, and already ship with multiple network-accessible control interfaces that map cleanly onto AetherSDR's existing architecture.

The goal is to replicate — and extend — the kind of integration that the 4o3a Tuner Genius XL (TGXL) applet already provides, offering automatic band switching, telemetry display, and remote control directly from AetherSDR.

About the RF2K-S / RF2K+

The amplifier is currently controlled remotely only via VNC to the internal RPi screen — there is no dedicated desktop or web client. This is a known gap in the ecosystem.

Available Control Interfaces

The RF2K-S firmware exposes four independent control interfaces, all accessible over the network:

1. UDP Frequency Broadcast (simplest — recommended for Phase 1)

The amplifier listens for UDP broadcast packets containing the TX frequency. Any software on the LAN can send these packets; the amplifier parses the frequency, selects the correct bandpass filter, and loads the appropriate ATU preset — no acknowledgment or authentication required.

• Protocol: UDP broadcast, LAN
• Payload: TX frequency in Hz (ASCII decimal string in JSON envelope)
• Use case in AetherSDR: When the active TX slice changes frequency, emit a UDP packet. The amplifier follows automatically.
• Existing AetherSDR hook: SliceModel::txFrequency is already tracked; a PaController UDP sender can attach here with minimal coupling.

Example packet:

{ "freq": 14225000, "source": "AetherSDR" }

2. TCI (Transceiver Control Interface) — bidirectional

The RF2K-S was the first power amplifier to implement TCI (open protocol by Expert Electronics). TCI is a WebSocket-based protocol that conveys frequency, mode, PTT, and optionally telemetry.

• Protocol: WebSocket (ws://), TCI v1.x
• Amplifier acts as TCI client — it connects to the TCI server exposed by the radio controller
• Relevant to AetherSDR: AetherSDR currently consumes SmartSDR natively; a lightweight TCI server shim listening on a local port could bridge the two ecosystems
• Reference: TCI Protocol Specification (open-source, MIT)

3. REST/JSON HTTP API (recommended for Phase 2 — telemetry + control)

The amplifier exposes a documented HTTP API (JSON) accessible on port 80 of the RPi. This API supports:

GET endpoints (polling or SSE):

• GET /api/status — full amplifier state snapshot
• GET /api/meters — real-time RF meters
• GET /api/band — current band and filter selection

POST endpoints (control):

• POST /api/operate — toggle Standby ↔ Operate
• POST /api/tune — activate ATU tune cycle
• POST /api/antenna — select antenna port (ANT1/ANT2)
• POST /api/band — force band selection

Telemetry fields available from /api/meters:

{
  "fwd_power_w":   1850,
  "ref_power_w":   12,
  "swr":           1.08,
  "supply_v":      50.2,
  "drain_current_a": 38.4,
  "temp_pa_c":     42,
  "temp_lpf_c":    38,
  "fault_code":    0
}

Full API reference: https://rf-power.eu/wp-content/uploads/2024/12/RFKIT_api_doc_0_9_0.html

4. CAT / Serial (USB)

Classic serial CAT interface, lower priority for software integration. Suitable as fallback if network is unavailable.

Proposed Implementation

Phase 1 — Automatic Band Switching via UDP

Scope: New class Rf2kController (or PaController if designed generically).

Behavior:

• User configures RF2K IP address and UDP port in Settings → Radio → PA
• When SliceModel::txFrequency changes on the active TX slice, Rf2kController emits a UDP frequency packet
• The amplifier handles all band/filter selection internally — no round-trip needed

Files to modify/create:

• src/core/rf2kcontroller.{h,cpp} — new class
• src/settings/radiosetupdialog.{h,cpp,.ui} — add PA tab (IP, UDP port, enable toggle)
• src/core/slicemodel.cpp — connect txFrequencyChanged signal to Rf2kController

Complexity: Low — ~200 LOC, no new dependencies (QUdpSocket already used in project)

Phase 2 — RF2K Applet with Telemetry and Control

Scope: New dockable applet Rf2kApplet, modeled after the existing TgxlApplet.

UI elements:

• Forward power bar (0–2000 W) with numeric readout
• Reflected power + SWR display
• PA temperature (°C) with color warning (green/yellow/red)
• Drain current readout
• Operate / Standby toggle button (maps to POST /api/operate)
• TUNE button (maps to POST /api/tune)
• Antenna selector: ANT1 / ANT2 (maps to POST /api/antenna)
• Fault indicator with fault code

Polling: HTTP GET /api/meters every 500 ms via QNetworkAccessManager (already a project dependency).

Files to create:

• src/widgets/rf2kapplet.{h,cpp} — applet widget
• src/models/rf2kmodel.{h,cpp} — data model + HTTP polling
• Integrate into main window dock system alongside TGXL applet

Complexity: Medium — ~600–800 LOC, no new dependencies

Phase 3 (Optional) — TCI Bridge for SO2R

For multi-operator or SO2R scenarios, a local TCI server that the RF2K-S connects to could provide richer integration (PTT interlock, automatic TX-follows-active-slice). This is lower priority but architecturally feasible given AetherSDR's existing multi-slice PTT logic.

Why This Matters

1. No dedicated remote client exists — the only current option is VNC to the amplifier's internal RPi. A native AetherSDR applet would be the first proper headless client.
2. Natural pairing — RF2K-S is commonly used with FlexRadio 6000/8000 series; AetherSDR users overlap heavily with RF2K-S owners.
3. Follows existing patterns — the TGXL applet proves the architecture works. RF2K integration would follow the same model.
4. Enables full remote station — combined with SmartLink, AetherSDR + RF2K applet = complete remote HF station control with no VNC dependency.
5. SO2R use case — automatic band switching per active TX slice is critical for contest operating with a shared amplifier.

References

• RF2K-S Product page: https://rf-power.eu/rf2k-s/
• API Documentation v0.9.0: https://rf-power.eu/wp-content/uploads/2024/12/RFKIT_api_doc_0_9_0.html
• RF2K-S User Manual (June 2025): https://rf-power.eu/wp-content/uploads/2025/06/RF2K-S_User_Manual_EN_06_25.pdf
• Node-RED integration example (RF-Power official): https://rf-power.eu/documentation/
• TCI Protocol specification: https://github.com/maksimus1210/TCI
• Existing precedent — RF2K-S TCI announcement: https://rf-kit.de/index.php/news/16-software-release-g91c109
• YouTube: Remote ON via network + Flex SDR: https://www.youtube.com/watch?v=Avh7ic4Z9Ow

Requesting Feedback On

1. Is a generic PaController abstraction preferred over an RF2K-specific class (to allow future PA integrations)?
2. Should Phase 1 (UDP) and Phase 2 (applet) be separate PRs or a single feature branch?
3. Preference for polling interval on /api/meters — 500 ms seems reasonable but open to guidance.
4. Should the PA tab live in the existing Radio Setup dialog, or as a separate PA Setup dialog?

This feature request was prepared with reference to the RF-Power API documentation and AetherSDR's existing architecture (TGXL applet pattern, SliceModel signals, QNetworkAccessManager usage). Ready to contribute implementation if the approach is approved.