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

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+

Property	Details
Manufacturer	RF-Power (rf-power.eu)
Models	RF2K+ (kit), RF2K-S (assembled)
Controller	Raspberry Pi 4 (internal), running Linux
Display	7" touchscreen (HDMI)
Network	Ethernet + WiFi (via RPi)

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.

Start by reviewing the existing TgxlApplet pattern, SliceModel::txFrequency, and current QUdpSocket usage. Confirm with maintainers whether Phase 1 should be implemented separately from the telemetry applet and whether a generic PaController is preferred. Done should be an agreed scope followed by working RF2K configuration, frequency integration, and any selected applet functionality.