Thanks @sblanchard — this is a well-reasoned change with a clear constitution writeup. Wiring up the radio's per-tile AutoBlackLevel instead of clamping it to 0–125 and throwing it away is the right call (Principle I), and the implementation is clean: the new m_radioAutoBlackRaw member is kept distinct from m_wfBlackLevel, the renderer path is null-guarded (if (auto* sw = m_panStack->spectrum(...))), the per-tile update() is gated behind a change check, and the client estimate is correctly preserved as a fallback. CI is green across all six checks (build/mac/win/CodeQL/cpp/a11y).

A couple of substantive points, plus confirmation of two open questions you already flagged:

1. lowRaw can go negative; black point and range then derive from different lows. In the radio-authoritative branch:

const float lowRaw = m_radioAutoBlackRaw + (50 - m_wfAutoBlackOffset) * 0.5f * 128.0f;  // ±3200 raw at offset 0/100
const float highRaw = wfHighThresholdRaw(lowRaw, m_wfColorGain);  // internally qBound(0, lowRaw, 65535)
blackThresh = lowRaw / 128.0f;                       // uses the *unbounded* lowRaw
rangeWidth  = std::max(1.0f, (highRaw - lowRaw) / 128.0f);  // also unbounded lowRaw

With a low radio level and offset pushed toward 100, lowRaw goes negative. wfHighThresholdRaw clamps it to 0 for the white-point math, but blackThresh and rangeWidth use the raw negative value — so the black point and the range width are computed against two different low points. No crash, but the mapping is internally inconsistent at the extremes. Suggest clamping once up front (lowRaw = qBound(0.0f, lowRaw, 65535.0f);) and feeding the clamped value to all three.

2. Confirming your open question on unconditional auto_black=1. configureWaterfall() now enables radio auto-black at session start regardless of the persisted client auto-black state. If the user has client auto-black off, the radio is in auto_black=1 mode embedding a level the renderer ignores (it takes the !m_wfAutoBlack fallback). It's harmless since the native path colours client-side, but it's a state mismatch — I'd reflect the persisted client state here as you suggested, so the radio and renderer agree.

3. Maintainer sign-off on the visual default. You've correctly flagged this (Principle XIII) — it reverses a deliberate client-side decision and changes the floor rendering for all colour schemes, not just Purple. That's a feel call I can't make from code review; leaving it for the maintainer to validate on hardware.

Conventions all check out — no QSettings/flat-key AppSettings added, RAII intact, no meter UI touched. Nice work.

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

Thanks for this — the diagnosis is genuinely good work (tracing WaterfallTile.AutoBlackLevel through PanadapterStream, the live-FLEX verification, and the clean second commit fixing the lowRaw clamp ordering), and Principle I does favor the radio's authoritative black level over our client-side estimate. I want to be straight with you about why I'm not comfortable merging it as-is, because it's about rollout, not the idea.

Blast radius. Auto-black is on by default, and this rewrites the shared intensity→t mapping that every color scheme renders through. So for most users it silently changes the look of all six schemes (Default, Grayscale, Blue-Green, Fire, Plasma, Purple) at once — and by your own reviewer note the defaults (Color Gain / offset 50) aren't the sweet spot; the good look is at ~30/30. Practically, merging this obligates a re-validation of all six schemes on live hardware to confirm none regressed, for what the PR itself flags as a subjective design reversal (Principle XIII). That's a lot of untestable surface.

Coupling with #3583. This PR notes it pairs with the new Purple scheme, but Purple merged separately in #3583 with no declared dependency on this one — so right now Purple is in main rendering through the old pipeline, i.e. not the look it was tuned for. Coupled visual work like this should land together (or the dependent piece should wait), so reviewers can judge the intended result in one place.

Concrete path forward, if you're up for it: make the radio-authoritative mapping opt-in rather than the new default — a distinct mode/toggle (or fold it in alongside a re-tuned Purple) so existing users keep their current look and only people who choose it take on the retune. Bundle the per-scheme tuning so a reviewer can validate the look scheme-by-scheme. That shrinks the review from "re-test everything" to "evaluate one new path," and it gives the Principle I improvement a home without a forced global change.

Happy to talk through the design if you want to take it that direction — and thanks again for digging into the protocol layer rather than papering over it client-side.

Works well with commit revisions from @ten9876. Approving.

Approving. (Transparency: I pushed the opt-in 3-way-toggle commit 4f8ae02f to this branch via maintainer-can-modify, so this approval is maintainer-side sign-off on the resolved design, not an independent third review of my own change.)

The PR now lands the right way:

• Principle I is honored — the radio's authoritative per-tile AutoBlackLevel is wired in instead of being clamped away.
• The blast-radius concern is resolved — radio-side auto-black is opt-in (HW) with the default unchanged (SW = today's client-side look), so no silent change to any of the six color schemes and no forced re-validation.
• The radio receives auto_black=1 only in HW mode (no state mismatch), the HW render path degrades gracefully to SW until a tile arrives, and the lowRaw single-clamp fix is retained.
• CI is green across all six checks (build / macOS / Windows / CodeQL / analyze / a11y).

Nice work @sblanchard — the protocol-layer diagnosis and the radio-authoritative mapping are the substance here; the toggle just makes it opt-in.