…X audio level (#2806)

WSJT-X's TCITransceiver applies a -6 dB amplitude scaling to TCI TX
audio when BOTH of these match the server's init burst:
  device  == "SunSDR2DX" or "SunSDR2PRO"
  protocol != starts-with "ExpertSDR3"
(reference: wsjtx/Transceiver/TCITransceiver.cpp:823 + .hpp:188-200,
K1=0.999/0x7FFF vs K2=0.499/0x7FFF.)

PR #2597 hit both conditions exactly — device=SunSDR2DX +
protocol=ExpertSDR2,1.9 — so WSJT-X halved every TX sample at the
source and TCI users measured ~70 W of 100 W expected.

Fix:
  - device: literal "AetherSDR" — avoids the SunSDR-specific gain trap
    AND avoids the leading-space bug in the older "<name> <model>"
    form when the radio nickname is empty.
  - protocol: "ExpertSDR3,1.5" — sets WSJT-X's ESDR3 flag, gating off
    the gain reduction and selecting command formats that AetherSDR
    already handles correctly (proven in v26.5.1).

Verified: WSJT-X TX output restored to 100 W of 100 W expected.

Everything else from #2597 (strict init-burst order, vfo_limits,
if_limits, channels_count plural-form, split_enable, post-READY audio
stream configuration) is preserved — that's the bulk of what the
RF2K-S TCI parser actually needs to engage. The amp's device/protocol
whitelist regresses, tracked separately in #2806.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…X audio level (#2806) (#2807)

PR #2597 changed TCI server identity from
  device: <flex name> <flex model>      protocol: ExpertSDR3,1.5
to
  device: SunSDR2DX                     protocol: ExpertSDR2,1.9
so RF2K-S amplifier firmware would whitelist AetherSDR. WSJT-X reads the
same fields to decide TX audio scaling: the SunSDR2DX/ExpertSDR2,1.9
pair drops TCI TX power by roughly 1 dB (measured 70 W vs 100 W
expected; reverting recovers to 88 W out of 100 W, the remaining
0.5 dB is within ALC/calibration variance).

Reverts only the device + protocol strings. Everything else from #2597
that the RF2K-S parser actually needs — strict init-burst order,
vfo_limits, if_limits, channels_count (plural-form), split_enable —
remains intact, so the amp interop work is mostly preserved.

A clean fix that keeps both clients happy (e.g. per-client adaptive
identity or a user-facing TCI Identity setting) is tracked in #2806.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Hotfix recommended for TCI digital-mode operators, Windows users with
MQTT or floating-panel windows, and Linux Ubuntu 22.04 builders.

- TCI TX audio level regression vs v26.5.1 (#2806/#2807) — restores
  WSJT-X / JTDX output to full level by reverting only the device +
  protocol identity strings from #2597 to a form that bypasses
  WSJT-X's TCITransceiver SunSDR2DX/non-ExpertSDR3 gain trap.
- Windows process lingering in Task Manager after close (#2802,
  chibondking) — three independent root causes addressed: Channel
  Strip + applet-panel float window WA_QuitOnClose, MqttClient
  destructor loop_stop.
- AppImage CI build failure on gcc 11 strict mode (#2799) — qualifies
  bitstream.h:192 member access with `this->` for two-phase name
  lookup. Restores the v26.5.2 x86_64 AppImage artifact.
- SSA (Sweden) band plan (#2805, NF0T) — Swedish national overlay
  with PTSFS 2025:1 constraints, Swedish labels, 89 spots.

Bumps version 26.5.2 → 26.5.2.1 in CMakeLists.txt, README.md,
CLAUDE.md; regenerates WhatsNewData.cpp from CHANGELOG.md.
CalVer scheme expanded to YY.M.patch[.hotfix] to document the
4th-component hotfix convention used historically.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Third Stream-Deck-style sibling alongside elgato-aethersdr (Elgato Stream
Deck) and streamcontroller-aethersdr (open-source Stream Deck alternative).
Drives AetherSDR over TCI WebSocket from Ulanzi-Studio-compatible macro
keypads / dials — Ulanzi D100H smoke-tested, D200H (14 keys) and D200X
(14 keys + 3 knobs) profile work in progress.

Action set (18 total):

  Encoder (dial):  VFO Tune
  TX:              MOX Toggle, TUNE / ATU, RIT Toggle
  Modes:           Mode Cycle + direct USB / LSB / CW / DIGU
  Bands:           Band Up, Band Down
  Slice:           Slice Cycle (A → … → H → A)
  Gain:            AF / RF / Mic × Up/Down (±5 per press,
                   TCI volume:, drive:, mic_level: verbs)

TCI command vocabulary is faithful to the existing elgato-aethersdr plugin
so the two behave identically against the same radio.  Port confirmed
40001; init burst handling and `protocol:ExpertSDR2,1.9;` lineage from PR
aethersdr#2597 already in place upstream.

Iconography is generated programmatically from a single source-of-truth
config (scripts/generate-icons.js — Node, zero npm deps).  18 action icons
+ 5 coordinated shack-app launcher tiles (AetherSDR / TCI Monitor /
ShackLog / IQ Capture / aether-pad) for use with Studio's built-in
System → Open action.  Palette deliberately mirrors AetherSDR's dark
theme so the keypad reads as a continuation of the desktop UI.

Bundled D100H default profile in profiles/ for one-click Studio import.

The independent public-facing release / marketplace path lives at
github.com/nigelfenton/aethersdr-ulanzi-plugin; this in-repo copy is
bundled context for AetherSDR developers — both repos stay alive (see
plugin's README for the relationship).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

)

## Problem

Reported by Yuri UT4LW (SDC / CW Skimmer ecosystem): AetherSDR's TCI
server sends `ready;` immediately after the `protocol:...` identity
command, before the state notifications and audio/IQ stream parameters:

```
...
protocol:ExpertSDR3,1.5;
ready;              ← too early
drive:0,100;
...
iq_samplerate:48000;
audio_start;
start;
```

`ready;` marks the end of the server's initial settings dump. Clients
that latch their cached settings the moment `ready;` arrives — notably
SDC / CW Skimmer — initialize from defaults instead of our actual
parameters (in particular `iq_samplerate`), causing incorrect client
initialization.

## Fix

Move `ready;` to after `iq_samplerate:...;` so it terminates the
complete settings dump, keeping `audio_start;` / `start;` as the
trailing stream-control commands. This matches real ExpertSDR3 behavior
(full state dump, then `ready;`) and the spec's READY definition ("sent
after the initialization commands").

## Why the early READY was there, and why it's safe to remove

The early placement came from #2597, which claimed strict clients
(RF2K-S amplifier) treat anything before READY that isn't one of the 9
spec-listed init commands as malformed. Verified against the reference
parser that claim was based on (`ars-ka0s/eesdr-tci`, the basis of the
RF2K-S TCI client):

- It aborts only on **unrecognized command names**, anywhere in the
stream — there is no pre-READY grammar check. Every command now sent
pre-READY was already present in the burst, so no new exposure.
- `READY` merely sets a "ready event" flag for the client app to await —
i.e. it means "initial sync complete", which is exactly why it must come
last.
- #2597's own bench notes concede the early READY never made the amp
engage; the actual fix was `split_enable` (still emitted, unchanged).

WSJT-X / JTDX parse every TCI command on arrival regardless of
ready-state and use `ready;` only to advance their init state machine
(verified in WSJT-X `Transceiver/TCITransceiver.cpp`: `Cmd_Ready` →
`tci_done7()`; state commands arriving earlier are cached). Since real
ExpertSDR3 sends the full state dump before `ready;`, every TCI client
in the wild already handles this ordering — it is the maximally
compatible choice.

## New burst order

1. Init/identity: `vfo_limits`, `if_limits`, `trx_count`,
`channels_count`, `device`, `receive_only`, `modulations_list`,
`protocol`
2. Per-slice + global state: `vfo`, `modulation`, `rx_enable`, filters,
RIT/XIT, `split_enable`, lock, SQL, AGC, NB/NR/ANF/APF, `tx_enable`,
`drive`, `tune_drive`, `mic_level`, `trx`, `volume`
3. Audio/IQ stream config: `audio_samplerate`,
`audio_stream_sample_type`, `audio_stream_channels`,
`audio_stream_samples`, `tx_stream_audio_buffering`, `iq_samplerate`
4. **`ready;`**
5. `audio_start;` `start;`

## Testing

- Builds clean (RelWithDebInfo, Ninja).
- Burst order verified in `generateInitBurst()`; no other call sites
changed.
- Interop analysis above for WSJT-X/JTDX, eesdr-tci/RF2K-S, SDC/CW
Skimmer.

💻 Generated with Claude Code (Fable 5.0) with architecture by @jensenpat

Co-authored-by: Codex <noreply@openai.com>

…thersdr#3498)

## Problem

Reported by Yuri UT4LW (SDC / CW Skimmer ecosystem): AetherSDR's TCI
server sends `ready;` immediately after the `protocol:...` identity
command, before the state notifications and audio/IQ stream parameters:

```
...
protocol:ExpertSDR3,1.5;
ready;              ← too early
drive:0,100;
...
iq_samplerate:48000;
audio_start;
start;
```

`ready;` marks the end of the server's initial settings dump. Clients
that latch their cached settings the moment `ready;` arrives — notably
SDC / CW Skimmer — initialize from defaults instead of our actual
parameters (in particular `iq_samplerate`), causing incorrect client
initialization.

## Fix

Move `ready;` to after `iq_samplerate:...;` so it terminates the
complete settings dump, keeping `audio_start;` / `start;` as the
trailing stream-control commands. This matches real ExpertSDR3 behavior
(full state dump, then `ready;`) and the spec's READY definition ("sent
after the initialization commands").

## Why the early READY was there, and why it's safe to remove

The early placement came from aethersdr#2597, which claimed strict clients
(RF2K-S amplifier) treat anything before READY that isn't one of the 9
spec-listed init commands as malformed. Verified against the reference
parser that claim was based on (`ars-ka0s/eesdr-tci`, the basis of the
RF2K-S TCI client):

- It aborts only on **unrecognized command names**, anywhere in the
stream — there is no pre-READY grammar check. Every command now sent
pre-READY was already present in the burst, so no new exposure.
- `READY` merely sets a "ready event" flag for the client app to await —
i.e. it means "initial sync complete", which is exactly why it must come
last.
- aethersdr#2597's own bench notes concede the early READY never made the amp
engage; the actual fix was `split_enable` (still emitted, unchanged).

WSJT-X / JTDX parse every TCI command on arrival regardless of
ready-state and use `ready;` only to advance their init state machine
(verified in WSJT-X `Transceiver/TCITransceiver.cpp`: `Cmd_Ready` →
`tci_done7()`; state commands arriving earlier are cached). Since real
ExpertSDR3 sends the full state dump before `ready;`, every TCI client
in the wild already handles this ordering — it is the maximally
compatible choice.

## New burst order

1. Init/identity: `vfo_limits`, `if_limits`, `trx_count`,
`channels_count`, `device`, `receive_only`, `modulations_list`,
`protocol`
2. Per-slice + global state: `vfo`, `modulation`, `rx_enable`, filters,
RIT/XIT, `split_enable`, lock, SQL, AGC, NB/NR/ANF/APF, `tx_enable`,
`drive`, `tune_drive`, `mic_level`, `trx`, `volume`
3. Audio/IQ stream config: `audio_samplerate`,
`audio_stream_sample_type`, `audio_stream_channels`,
`audio_stream_samples`, `tx_stream_audio_buffering`, `iq_samplerate`
4. **`ready;`**
5. `audio_start;` `start;`

## Testing

- Builds clean (RelWithDebInfo, Ninja).
- Burst order verified in `generateInitBurst()`; no other call sites
changed.
- Interop analysis above for WSJT-X/JTDX, eesdr-tci/RF2K-S, SDC/CW
Skimmer.

💻 Generated with Claude Code (Fable 5.0) with architecture by @jensenpat

Co-authored-by: Codex <noreply@openai.com>