Thanks for this contribution, @jensenpat — really well-thought-out feature. The safety preconditions are thorough, the TGXL bypass/restore state machine is carefully sequenced, and the overall design of stopping tune before restoring state is exactly right for this kind of RF-driving workflow. A few observations:

Looks good

• Safety checks: The precondition gauntlet in startSwrSweep() covers all the right cases — connected radio, no split, TX slice visible/unlocked, no active transmit, non-zero tune power, 60m exclusion, band edge guards. Solid.
• State machine: The phased approach (WaitingForTgxlBypass → TgxlBypassSettle → Sweeping → StoppingTune → RestoringTgxl) with timeouts at each stage is clean. The "stop tune carrier before restoring frequency/TGXL state" ordering is correct.
• Meter freshness: Requiring both SWR and forward power timestamps to be ≥ sampleNotBeforeMs prevents stale readings. The fwdPowerInstant addition to MeterModel (un-smoothed watts) is the right call for per-step validation — the smoothed fwdPower() would lag.
• MeterModel changes: The new timestamp accessors and fwdPowerInstant are well-placed. Using the existing packetUpdatedMs for the new timestamps is consistent with the compression meter pattern already in place. The clear() / removeMeter() / setTgxlHandle() updates correctly reset the new fields.

Items worth a second look

1. AppletPanel.cpp include removal — Removing <QMenu> and <QContextMenuEvent> is unrelated to SWR sweep and could break if another open PR adds a context menu to AppletPanel. I'd suggest dropping this hunk or splitting it into its own commit to keep the PR scope clean.

2. advanceSwrSweep() — tunerModel() returns a non-const ref via const polling — advanceSwrSweep() grabs auto& tuner = m_radioModel.tunerModel() to check isPresent() / isOperate() / isBypass(). This works because tunerModel() returns a non-const ref, but since the sweep code only reads tuner state here (the one setBypass() call is elsewhere), consider using const auto& to signal read-only intent. Minor.

3. finishSwrSweep() re-entrancy — finishSwrSweep(true, ...) is called from many places (Escape key, disconnect, slice disappear, meter timeout, TGXL state change). The early returns for StoppingTune/RestoringTgxl phases are correct. However, completeSwrSweepFinish() accesses m_panStack->allApplets() in the clearPlot path — if the radio disconnects while in RestoringTgxl phase and onConnectionStateChanged(false) fires again, the !m_swrSweep.running guard at the top protects against this, which is good. Just noting this was verified.

4. Pan restore on abort only — After a successful (non-aborted) sweep, the panadapter stays zoomed to the full band. This seems intentional per the UX description (the user wants to compare SWR against the active frequency). Worth confirming this is the desired behavior, since on abort the original pan center/bandwidth is restored but on success it isn't.

5. drawSwrSweep() — minor edge case — If m_swrSweepRunning is true but m_swrSweepPoints is empty (the sweep just started, no samples yet), the function still enters and draws the label/background. This is fine — the label shows "SWR Sweep RUN" — but the plotRect background rectangle gets drawn with no curve data. This is a cosmetic choice, not a bug, but you might want the "RUN" indicator to wait until the first sample arrives.

Overall this is clean, well-guarded code. The feature is well-scoped and the abort paths are thorough. Nice work.

🤖 Reviewed by AetherClaude