Summary

While validating the Transverter (XVTR) settings for safe transmit on a FLEX-8600 (fw 4.2.18, protocol v1.4.0.0), three distinct XVTR issues surfaced. One is upstream firmware behavior; two are client-side bugs in AetherSDR. Filing them together as a single tracking issue per request.

Operator context: transverter rated for 1 mW (0 dBm) max IF drive — these issues are tracked specifically to avoid damaging it / transmitting out of band.

Environment

• Radio: FLEX-8600, firmware 4.2.18, SmartSDR protocol v1.4.0.0
• Reference API: FlexLib_API_v4.2.18.41174 (Xvtr.cs, Slice.cs, Radio.cs)

1. CW AutoTune (Loop/Once) ignores XVTR boundaries, jumps out-of-band (~170 MHz) — UPSTREAM (firmware)

Severity: high — out-of-band TX on a transverter band.

Observed: On 2 m in CW through a transverter, enabling Autotune → Loop immediately retunes the slice to ~170 MHz, ignoring the transverter's RF range.

Validation (code-traced against FlexLib):

• AetherSDR sends slice auto_tune <id> int=1 (loop) / int=0 (stop) / slice auto_tune <id> (once) — src/models/RadioModel.cpp:1327-1341.
• This is byte-for-byte identical to FlexLib Slice.SendCWAutotuneCommand() — FlexLib/Slice.cs:958-967.
• AetherSDR does no client-side frequency computation for autotune and applies no XVTR translation in the slice frequency path (SliceModel has no transverter offset). The radio reports the already-translated RF_frequency; the client just displays it.

Conclusion: The ~170 MHz retune is produced by the radio's SmartSDR+ autotune engine, which does not constrain itself to the transverter's RF range. Since the command matches SmartSDR exactly, root cause is most likely FlexRadio firmware.

Open question (needs pcap): Does stock SmartSDR (a) reproduce the same jump, or (b) guard autotune on transverter slices client-side? A wireshark capture of SmartSDR running CW autotune on an XVTR slice would settle this.

Proposed actions:

• Capture SmartSDR behavior (pcap) on an XVTR CW slice to confirm upstream vs client-guard.
• Defensive client mitigation (UX — needs maintainer sign-off): disable/guard the "Once" and "Loop" autotune controls in VfoWidget when the active slice is on a transverter. The buttons are currently gated only on CW/CWL + SmartSDR+ (src/gui/VfoWidget.cpp:3560-3608) with no XVTR guard.

2. XVTR "LO Error" labeled (Hz) but value is MHz; no conversion — CLIENT BUG

Severity: medium-high — off-frequency TX.

• FlexLib: Xvtr.LOError is in MHz, sent as xvtr set <i> lo_error=<MHz> with f6 — FlexLib/Xvtr.cs:124-137.
• AetherSDR labels the field "LO Error (Hz):" and shows loError with 0 decimals (src/gui/RadioSetupDialog.cpp:2406), and sends the raw text back as lo_error=<text> (src/gui/RadioSetupDialog.cpp:2465-2468). Status is read straight into loError with no scaling (src/models/RadioModel.cpp:3445).
• Effect: (a) a real 2 kHz (0.002 MHz) error displays as 0; (b) entering 2000 while trusting the "Hz" label sends lo_error=2000 = 2000 MHz → wildly off-frequency TX.

Fix options (UX decision — maintainer to pick):

• (A) Relabel to "LO Error (MHz)", display 6 decimals (protocol-exact, lowest risk).
• (B) Keep "Hz" label, convert: display loError × 1e6; on send divide by 1e6 → f6 MHz.

3. XVTR "Max Power" (dBm) has no clamp — CLIENT BUG (safety)

Severity: high — transverter overdrive / equipment damage.

• Unit is correct (dBm) — matches FlexLib Xvtr.MaxPower // in dBm.
• FlexLib clamps before sending — FlexLib/Xvtr.cs:169-209:
  • IF < 80 MHz: 6400/6600 family → ≤ +10 dBm; all others (incl. FLEX-8600) → ≤ +15 dBm
  • IF ≥ 80 MHz: ≤ +8 dBm
  • floor: ≥ −10 dBm
• AetherSDR sends the raw text with no validator/clamp — src/gui/RadioSetupDialog.cpp:2429 and :2473-2476. Typing e.g. 100 sends max_power=100 (100 dBm ≈ 10 MW request). SmartSDR clamps client-side, so the radio is not relied upon to protect the transverter.

Fix: clamp the entered value to the FlexLib model/IF-dependent range before sending (mirror Xvtr.cs logic) and add a QDoubleValidator. For a 1 mW transverter: 0 dBm = 1 mW; recommended operating point −3 dBm (0.5 mW) for margin.

Classification / next steps

Per CLAUDE.md autonomous-agent boundaries: #2 and #3 are protocol-compliance/safety fixes suitable for agent implementation; the LO Error display unit (A vs B) and the autotune button guard are UX choices that need maintainer sign-off.

Filed by Claude Code (Opus 4.8) during an XVTR transmit-safety review, against FlexLib 4.2.18 reference.