health meter swr reporting high swr into dummy load upon keying and unkeying while the main meter reports normal swr.

[marknewbill15-wq]

Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

health meter swr reporting high swr into dummy load upon keying and unkeying while the main meter reports normal swr. I suspect the power changes such as in ssb are not giving enough time to calibrate the swr and shows artificially high.

What did you expect?

expect health meter swr and applet meter swr to agree, its the same source. I suspect the power changes such as in ssb are not giving enough time to calibrate the swr and shows artificially high.

Steps to reproduce

tx in ssb in dummy load. the main swr meter on top stays normal, under 1.5; the health meter turns red and shows an error with suggestions like grounding, etc. this should not happen into a dummy load.

AetherSDR version

26.7.2

Radio model & firmware

8400 4.2.20

Operating system

Windows

OS version and hardware

windows 11

[aethersdr-agent]

Triage: confirmed client-side bug in the HLTH applet (not a real high-SWR condition)

Thanks for the clear report — the "into a dummy load, main meter stays under 1.5, HLTH goes red" detail is exactly what pins this down. Your instinct is right: this is a transient/settling artifact, and it's a bug in how the health applet models SWR, not a real antenna problem.

Why the top gauge stays calm but HLTH goes red — they don't compute the same thing.

Both meters read the same raw radio SWR meter (MeterModel::m_swr, emitted via txMetersChanged, src/models/MeterModel.cpp:483-486, 543). FlexLib passes SWR through raw with no power gating (Radio.cs SWR_DataReady just forwards the value), so any transient spike is the client's responsibility to handle.

• The top gauge (TxApplet::updateMeters, src/gui/TxApplet.cpp:586-591) just displays the instantaneous smoothed value on an HGauge. During a keying/unkeying spike it may flick up for a frame or two and settle back to ~1.2 — nothing latches, so you read the settled value.
• The HLTH applet derives a severity score from far more than the raw value. In HealthApplet::computeSeverity (src/gui/HealthApplet.cpp:771-791), severity = max() of five penalties, and two of them are history-based:
  • swrSpanPenalty = smoothStep(0.12, 0.42, m_swrSpan) — max−min of SWR over the recent window
  • swrDeltaPenalty = smoothStep(0.08, 0.30, swrDelta) — deviation from the running average

The transient poisons a ~3.5 s window. The recent window is kRecentWindow = 70 samples at kTickMs = 50 ms = 3.5 seconds (HealthApplet.cpp:26-28). A single keying/unkeying frame where SWR reads high (physics: reflected/forward is numerically meaningless while forward power is a fraction of a watt during the ramp) inflates m_swrSpan/swrDelta for the entire 3.5 s window. Because severity is a max(), that alone drives it to ≥0.34 (WATCH) or ≥0.72 (GROUND? red pill, HealthApplet.cpp:824-835) with the grounding/counterpoise tooltip (HealthApplet.cpp:384), and latches an incident marker with an 80-frame cooldown (HealthApplet.cpp:644-663).

The existing power gate doesn't catch it. computeSeverity only zeroes out below kActivePowerWatts = 0.75 W (HealthApplet.cpp:773). The keying/unkeying spike happens while power ramps through 0.75 W toward full and back — squarely inside the "active" band — so the gate never suppresses it. Worse, on the first active frame m_baselineReady initializes m_swrAverage straight from the (possibly spiked) m_displaySwr (HealthApplet.cpp:598-602), poisoning the baseline so subsequent normal readings register as a large swrDelta.

Proposed fix (all in src/gui/HealthApplet.cpp)

Gate SWR trust on adequate, settled forward power before it feeds the variance/delta/severity model:

1. Raise + settle the SWR-validity threshold. Treat SWR as meaningful only when forward power is above a real floor (well above 0.75 W) and has been sustained for a short settle window (a few frames after crossing active). During the ramp/settle window, hold m_displaySwr at 1.0 (or its last stable value) and skip pushRecent (HealthApplet.cpp:608) so transient spikes never enter m_recentSwr and can't inflate m_swrSpan.
2. Don't seed the baseline from the first frame. Delay m_baselineReady/m_swrAverage seeding until power has been settled for the settle window, so keying doesn't poison the average.
3. Debounce incidents. Require elevated severity to persist for N consecutive settled frames before raising a GROUND?/WATCH incident, so a 1–2 frame spike can't trip it.

This is not upstream — the radio and main meter behave correctly; only the applet's history model over-reacts.

Handoff summary

• Symptom: HLTH shows red "GROUND?" (grounding/counterpoise) on key/unkey into a dummy load; top SWR gauge stays <1.5.
• Root cause: HealthApplet::computeSeverity derives severity from m_swrSpan/swrDelta over a 3.5 s window; a low-power keying/unkeying SWR transient (which the 0.75 W gate lets through) poisons that window and latches an incident.
• Fix locus: src/gui/HealthApplet.cpp — gate SWR sampling/baseline/severity on settled forward power + debounce incidents. No protocol or firmware change needed.

---

_{🤖 aethersdr-agent · cost: $2.7277 · model: claude-opus-4-8}

---

_{📍 Citation health check (Foundry Constitution Principle I): 3 resolved, 7 unresolved against /Users/aetherclaude/workspace/AetherSDR at origin/main.}

Unresolved citations (7)

Citation	Reason
HealthApplet.cpp:26-28	file not found in workspace
HealthApplet.cpp:384	file not found in workspace
HealthApplet.cpp:598-602	file not found in workspace
HealthApplet.cpp:608	file not found in workspace
HealthApplet.cpp:644-663	file not found in workspace
HealthApplet.cpp:773	file not found in workspace
HealthApplet.cpp:824-835	file not found in workspace