adcRmsDbfs sits at −18.0 dBFS invariant across 19 dB of analog gain — analog limit, or decode defect?

[on8st]

Asking rather than asserting: I cannot separate the two candidates from outside the app, and the answer changes whether this is a bug at all.

The observation

On an HL2 with the antenna port terminated in a 50 Ω dummy load, adcRmsDbfs is immovable. Pooling every reading from four runs over roughly 40 minutes:

readings within −17.90 … −18.05 dBFS	16
spread	0.15 dB
across LNA gain	0 dB and +19 dB — a 19 dB analog change
across bank	0x42, 0x48, 0x60
across frequency	3.775, 14.100, 28.400 MHz
adcPeakDbfs over the same set	pinned, −14.1 … −14.8

A 19 dB change of analog gain moved the statistic 0.15 dB. Nothing that is RF behaves like that — and the same runs show adcSlicePeakDbfs0 (the WDSP-side surface) tracking gain at 0.76–0.91 dB/dB over exactly the same commands, so the gain was demonstrably applied.

Two candidates, and why I cannot choose

1. An analog stage limiting roughly 14.5 dB below converter full scale, upstream of where EP4 samples are taken.
2. A defect in the EP4 decode or statistics path — the value is computed, not measured, at some point in MetisProtocol's EP4 handling.

I could not separate them through the automation bridge: it exposes bandscope on|off and the scalars, but no EP4 samples. bandscope.frame is reachable only from the GUI dialog. The tool that would settle it, an independent EP4 decode, refuses unless the radio is idle, which means disconnecting the app from the radio — not something I wanted to do unannounced on someone's station.

What would answer it

Anyone who can capture raw EP4 samples alongside the reported scalars on any HL2 can settle it in one run: if the raw samples move with LNA gain while adcRmsDbfs does not, it is (2); if neither moves, it is (1).

Related, but not the same thing

#5802 reports that Ep4Stats::rmsDbfs measures about zero rather than about the mean, so DC inflates it. That is a real defect and it is not an explanation for this: a fixed DC pedestal would raise the reading by a constant, it would not make it invariant under 19 dB of gain. They may interact — if the ceiling is a DC-dominated reading, both are in play — but fixing #5802 would not by itself explain what is seen here.

Why it is worth knowing either way

bandscopeHeadroom() and the overload/clip surfaces are built on these statistics. If a stage really does limit 14.5 dB below full scale, headroom reporting is systematically optimistic by that amount. If instead the number is computed wrongly, everything derived from it inherits the error. We wasted a measurement on it — characterising the reading as an RF observation before noticing it was a rail.

Provenance

HL2, gateware 74, receive-only throughout, dummy load verified at the switch. Observed on a build carrying #5752 and #5753; the relevant EP4 statistics path is unchanged on current main. I have deliberately not diagnosed this further than the evidence supports.

🤖 Generated with Claude Code

[on8st]

Measured, on the same radio and the same dummy load. I think this issue's own peak column answers it: the gain never moved. Detail below, including the hypothesis I went in with, which was wrong.

What I measured

LNA baseline swept −12 / 0 / +10 / +19 dB, six samples per rung, auto RF gain disarmed, EP4 wideband on, receive only. Two independent runs, and the numbers below are the second — the first agrees to a few tenths.

LNA baseline	adcRmsDbfs	adcPeakDbfs
−12 dB	−44.55	−40.21
0 dB	−38.91	−32.78
+10 dB	−24.16	−20.52
+19 dB	−17.87	−14.21

Travel: 26.68 dB of RMS across the axis. On merged main, with no fix applied.

So neither candidate in the title is what happened

Not an analog limit: the statistic moves 26.7 dB here. Not a decode defect: this is the same unfixed Ep4Stats::rmsDbfs this issue was measured against, and it tracks.

This issue's own peak column is the tell

It records adcPeakDbfs "pinned, −14.1 … −14.8" across the whole set — across both gains, three banks and three frequencies.

On this bench the peak moves with the gain, one-for-one: −40.21, −32.78, −20.52, −14.21. And that pinned −14.1…−14.8 is exactly this bench's +19 dB value.

The simplest reading is that the whole dataset was taken at one gain — +19 dB — and the 19 dB analog change never reached the converter. Then an invariant RMS is not a defect at all, it is the correct answer to a question that was not actually asked; and the peak being equally invariant, which the issue records as corroboration, is the same fact told twice rather than a second witness.

I cannot prove what that bench did, only that its two recorded columns are consistent with the gain not moving and inconsistent with it moving 19 dB. If a run of it recorded lnaBaselineDb alongside lnaGainDb, that would settle it in one line.

A likely mechanism, because we hit it here this afternoon. healthSnapshot publishes two rows: lnaGainDb is lnaEffectiveDb() — baseline plus the auto-gain offset — while the value the operator sets and the profile persists is lnaBaselineDb. A bench reading the first while setting the second draws exactly this picture. It cost us a standing "the LNA set does not take" belief that turned out to be our own instrument.

The hypothesis I went in with, and why it failed

I expected the mechanism to be converter DC. rmsDbfs measured about zero, so a DC pedestal is carried at full weight; a pedestal does not scale with the LNA, so a DC-dominated RMS would be immovable across analog gain by construction, and its crest would read ~3 dB because a pedestal has peak ≈ rms. That is a tidy fit to everything this issue records.

It is wrong, and I only know that because the "before" leg was measured rather than quoted from this issue. Had I cited these −18.0 readings as the before state and measured only the fixed build, I would have had a clean story and a false one.

For completeness, #5832 does remove a real DC component — the RMS drops 8 to 13 dB at every rung, while the peak is bit-identical between the two builds, which is the internal control that both legs saw the same signal. It just is not what made this reading flat.

I also ran a third leg with the auto RF gain armed, on the theory that a loop holding effective gain constant would flatten the axis. That leg proves nothing and I am not offering it as evidence: autoRfGain read true, but lnaAutoOffsetDb stayed 0 at every rung and effective equalled baseline throughout. The loop armed and never acted — correctly, since maxOffsetDb is a bound on how much attenuation it may apply, not a headroom target, and a quiet dummy load gives it nothing to do. Which means this experiment cannot test that hypothesis on a dummy load at all.

🤖 Generated with Claude Code