Thanks for the thorough write-up, @dsocha — the "as-built vs. RFC" section and the explicit flagging of UX decisions for the maintainer made this much easier to review. The end-to-end extension (selector → persistence → config → wiring) is clean and faithfully follows the existing MicLevel path, Principle V is honored (token-serialized nested JSON, graceful fallback to None), and all 6 CI checks are green (build / check-windows / check-macos / CodeQL / accessibility).

I verified the parts most prone to silent breakage:

• Signal wiring is correct. micMetersChanged(micLevel, compLevel, micPeak, compPeak) — the lambda picks the 4th arg (compPeak) for compression and the 3rd (micPeak) for mic, both right. txMetersChanged(fwdPower, swr) — setTxPower(fwd) / setTxSwr(swr) order matches.
• Power scale parity holds. txPowerFullScaleW() → barefoot 100×1.2 = 120 (red @100) and Aurora 500×1.2 = 600 (red @500) matches TxApplet::setPowerScale exactly, and the AU- bump mirrors the maxW <= 100 rule in MainWindow_Wiring.
• Null guards on m_txModel / m_radioModel are present; cache invalidation correctly gains m_cacheMin/Max so a radio swap re-rasters the radio-aware power markers even when the kind is unchanged.

A few things worth a maintainer's eye — mostly questions, not blockers:

1. Undisclosed scope: the scale-label rendering rewrite. Three of the five commits (ff8e69f, 811a211, ce45808) replace the marker-label positioning (AlignVCenter box → declared capHeight baseline) and add a Windows QFont::Medium/Normal #ifdef. drawMarkers() runs for every kind, so this changes how the existing Signal and Mic meter labels render on all three platforms — yet it isn't in the PR's divergences list. The rationale (backend-independent metric) is sound, but please call it out explicitly and eyeball the Signal/Mic labels on macOS/Linux/Windows so a regression there doesn't ride in under a TX-meter PR.

2. Compression bar source. The bar value uses compPeak (negated), while the mic meter uses the instantaneous micLevel for the bar and reserves micPeak for the marker. compLevel (the 2nd micMetersChanged arg) is the instantaneous analog. Was compPeak-for-the-bar deliberate? Using compLevel for the bar + compPeak as an external peak marker would mirror the mic meter exactly; as written, the bar and the window-derived peak both track the peak.

3. Power scale for non-AU rigs >100 W (minor). TxApplet treats any maxWatts > 100 as the 600/500 Aurora scale, whereas txPowerFullScaleW() returns ratedW × 1.2. For a hypothetical non-AU rig reporting, say, 200 W these diverge — your version is arguably more correct, but the "mirroring TxApplet" claim isn't exact at that edge. Probably fine; just noting it.

Nice work, and good call opening this for review while #3774 is still gated rather than pushing for merge.

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

Re-reviewed after the 4 follow-up commits (now +574/-77, CI green). The end-to-end extension remains clean and faithful to the existing MicLevel path, Principle V is honored (token-serialized nested JSON, graceful fallback to None), and I re-verified the load-bearing wiring: micMetersChanged 4th arg → compPeak, 3rd → micPeak; txMetersChanged → setTxPower(fwd)/setTxSwr(swr); txPowerFullScaleW() parity (barefoot 100×1.2=120, Aurora 500×1.2=600); and the m_cacheMin/Max invalidation that re-rasters the radio-aware power markers on a radio swap. Thanks for the thorough as-built write-up, @dsocha.

I read the 3 scale-label commits (ff8e69f, 811a211, ce45808) in full. The change is sound — anchoring the baseline on the declared capHeight() instead of AlignVCenter over measured ink is the right way to get backend-consistent vertical centering (FreeType/Core Text/DirectWrite report tight-ink inconsistently, which is what left S9 top-aligned on Linux/Windows), and horizontal centering is preserved. Two asks and one design question before this is sign-off-ready:

1. Disclose the label-rendering change + confirm no regression on the existing meters. drawMarkers() runs for every MeterKind, so the cap-height re-anchoring and the Windows QFont::Medium/Normal #ifdef change how the existing Signal and Mic labels render on all three platforms — not just the new TX meters. It's an improvement, not a likely regression, but it's currently absent from the "as-built vs. RFC" list. Please add it there and eyeball the Signal/Mic tick labels on macOS/Linux/Windows so a regression can't ride in under a TX-meter PR.

2. Compression bar source — intended? The bar uses compPeak (negated), while the mic meter uses the instantaneous micLevel for the bar and reserves micPeak for the marker. The 2nd micMetersChanged arg (compLevel) is the instantaneous analog. As written, the compression bar and its window-derived peak both track the held peak; exact mic-mirroring would use compLevel for the bar + compPeak as the external peak marker. Was the peak-for-the-bar choice deliberate (it does read as a steadier gain-reduction needle), or should the bar track compLevel?

3. (Minor) txPowerFullScaleW() returns ratedW × 1.2 whereas TxApplet treats any maxWatts > 100 as the fixed 600/500 Aurora scale — these diverge only for a hypothetical non-AU rig reporting >100 W, where your version is arguably more correct. Non-blocking; just noting the "mirrors TxApplet" claim isn't exact at that edge.

On the design itself (compression-as-reversed-gain-reduction mirroring PhoneCwApplet, radio-aware exciter power, nonlinear SWR, the optional meter-type label): I read these as improvements over the RFC, grounded in existing in-app conventions. Final design sign-off + the #3774 maintainer-review gate are the maintainer's call — flagging item 2 as the one new technical decision to fold into that. Good call keeping this open for review rather than pushing for merge while gated.

Thanks @dsocha — this is a careful, well-documented PR. The "as-built vs RFC" writeup and the inline comments make the design intent easy to follow, and the as-built honesty about the visual/UX divergences is exactly right given the maintainer-review gate. Nothing here blocks; a few notes below, plus one question for the maintainer's design sign-off. CI is green across all six checks (build, macOS, Windows, CodeQL, accessibility).

Convention / correctness — verified, looks good:

• Principle V honored as claimed. Both txMeter and the new showTxMeterType persist as token-serialized nested JSON under the single DisplaySettings key, with unknown tokens falling back to None/False. No new flat-key AppSettings calls. Appended enum ordinals keep old configs/downgrades safe.
• Signal wiring matches. txMetersChanged(fwdPower, swr) → setTxPower(fwd)/setTxSwr(swr) (correct order), and micMetersChanged(micLevel, compLevel, micPeak, compPeak) → the lambda grabs micLevel and compPeak. Receiver context is vfo, so the connections tear down with the widget.
• Null safety. m_txModel/m_radioModel are both guarded in txPowerFullScaleW() and the compression gate.
• Power-scale parity. txPowerFullScaleW()'s maxPowerLevel() + AU-/<=100 → 500 bump mirrors MainWindow_Wiring::updatePowerScale, and kPowerHeadroom = 1.2 reproduces TxApplet's barefoot 100→120 (red@100) and Aurora 500→600 (red@500). One minor divergence worth noting (not a fix request): TxApplet keys off maxWatts > 100 to pick the 600 W arc, whereas this scales rated × 1.2 continuously — so a rig reporting, say, 200 W rated lands on a 240 W scale here vs TxApplet's 600 W. The continuous version is arguably more correct; just flagging that the two power displays won't be pixel-identical for non-standard rated values.
• Cache invalidation. Adding m_input.min/max to the rebuild key correctly handles a Power radio-swap re-raster, and the Signal branch uses constant min/max (−127/−13) so no spurious rebuilds. m_activeCfg seeded in the ctor before the first applyBallistics — good catch on the ordering.

One question for design sign-off (Compression): the compression bar value is driven by compPeak (the 4th micMetersChanged arg), and compLevel (the 2nd arg) goes unused. By analogy with the mic meter — which uses micLevel for the bar and micPeak only for the peak marker — I'd have expected compLevel to drive the bar and compPeak the held marker. Here the bar tracks peak gain-reduction directly while the window envelope synthesizes the marker. That's a defensible choice for a GR meter (peak GR is the conventional read), but since it's one of the UX decisions you flagged for review, worth confirming it's intentional rather than an oversight — and the compLevel-unused detail is easy to miss.

Net: clean generalizations (the != Signal / hasPeak guards read well, not parallel code paths), solid persistence and null handling. The remaining open items are the hardware/sim behavioral pass you already called out and the maintainer's UX sign-off on the flagged divergences.

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

Approved. Reviewed the full diff (incl. the shared drawMarkers() label-rendering rework) and the changes are confined to the VFO-flag meter subsystem — no applets touched, no keying/invoke() path, so Principle VI doesn't apply. Principle V honored (token-serialized nested JSON under DisplaySettings, appended ordinals, safe fallback). Maintainer design sign-off on the four RFC divergences: Compression (reversed −25→0 GR, compPeak-driven, speech-processor gated), Power (radio-aware exciter rated×1.2), SWR (nonlinear knee@2.0), and the "Show meter type" in-hole label — all approved as built. Tested locally on a FLEX-8600. Thanks @dsocha — clean, well-documented work.