[on8st]

Closes row 2.1 of #5678 for the HL2, and partly row 2.2. It follows the ruling on RFC #5782: the HL2 implements setPanAverage / setPanWeightedAverage and engages backendPanAveraging in the same change, so SpectrumWidget's EMA is skipped and the two averages cannot stack. That stacking is the G2 bug #5814 found.

Design

• FFT AVG is a time constant, 10 ms per step (0–100 → 0–1 s). That's the ANAN/deskHPSDR unit, so one setting means the same smoothing on both families.
• Frame weight is 1 − exp(−dt/τ), with dt counted in IQ samples. The time constant no longer changes with the fps slider. The one thing still tied to fps is how much noise is averaged out, because only displayed frames are integrated; averaging every FFT would undo the CPU saving the fps cap exists for. The code says so.
• q1 (domain): power by default. The weighted toggle selects log-recursive, the same meaning as on the ANAN.
• q3 (shared helper): not yet. This is the only consumer; RTL would be the second, and that is the time to move it into src/core/dsp/. Recorded in Hl2Spectrum.h and on [RFC] Spectrum averaging on raw-spectrum backends: which layer owns it, and in which domain #5782.
• Persistence: the setting survives zoom rebuilds and reconnects, and is re-applied when a pan is added. fix(gui): the FFT average never reaches the model on a raw-spectrum backend, so it reverts on a pan rebuild #5754's stored FFT AVG now reaches the DSP at connect.
• Retune: an NCO move (pan drag, or tuning out of the window) drops the average and the partial window the frame-rate shaper holds, so the next frame is new-axis IQ only. A transport gap drops neither: the pre-gap estimate is held, and the gap does not advance the averaging clock.
• Visible change: at FFT AVG 0 the HL2 trace is now genuinely unaveraged. It used to get the widget's fixed EMA. The ANAN has behaved this way since feat(anan): compute the panadapter with WDSP's display analyzer #5814.

Row 2.2

Partly addressed. Waterfall rows are the same frames, so with FFT AVG above 0 each row is an exponentially weighted average of roughly the last AVG × 10 ms. It is not an integral over the row interval, and at AVG 0 nothing changes. A true per-row integral needs the waterfall rate passed to the backend plus a second accumulator, so it is left for its own change (the open question on #5782).

Tests

hl2_pan_averaging_test:

• Variance reduction matches theory: ratio 0.994 at τ = 100 ms and 0.996 at 300 ms; the unaveraged control reads 0.990.
• Step response at τ = 500 ms: 512 ms with 21 ms frames and 426 ms with 100 ms frames. A frame-count depth (the control) gives 536 ms and 2268 ms.
• Log mode reads the noise floor 2.43 dB below power mode.
• A retune drop forgets the average; a replayed setting keeps it.
• After a retune drop, the first frame Hl2RxDsp emits equals the raw new-axis frame (0.00 dB apart; 129 dB without discarding the held window).
• The setting survives an Hl2RxDsp rebuild.

hl2_backend_seam_test: backendPanAveraging engaged at 10 ms/step and the widget EMA skipped for a connected HL2 (control: disconnected, or a backend that does not average). setPanAverage / setPanWeightedAverage are held on the receiver and reach an injected live chain (FFT AVG 30 → 300 ms, weighted → log-recursive), clamp above range, and ignore an unknown pan id.

Mutations, each red: setPanAverage a no-op; the weighted flag not pushed; the smoothing gate inverted; setAverageTimeMs ignored; the log flag ignored in Hl2Spectrum; no re-apply in installChannel; the retune drop keeping the held window.

On the radio

Measured by @on8st on an HL2 (dummy load, noise only, frames read through the automation bridge):

• τ = AVG × 10 ms: 251 / 523 / 1005 ms at AVG 25 / 50 / 100 (power), 491 ms at AVG 50 (log). At AVG 50 it is 515 ms at 10 fps and 507 ms at 30 fps, so it is a time constant, not a frame count.
• Variance falls with AVG: frame-to-frame SD of the floor estimate 0.48 → 0.06 → 0.06 → 0.05 dB at AVG 0 / 25 / 50 / 100.
• AVG 0 is unaveraged: an LNA step lands in the first frame after the command, 99–100 % on both legs; weighted on and off agree at AVG 0 within 0.07 dB.
• Power − log: 2.64 / 2.62 dB at AVG 50 / 100, against 2.66 / 2.63 simulated.

Not covered on the radio: the trace by eye, a real signal under averaging, and the retune and persistence paths.

🤖 Generated with Claude Code

[aethersdr-agent]

1. Issue fit

Yes, and it closes the specific half that was left open. #5678 row 2.1's remaining work was "make the stored FFT AVG actually average". RFC #5782's ruling (ten9876, 2026-09-21) set three obligations for whoever wrote the HL2 change, and all three are met in this diff:

• q2 seam — the two defaulted verbs setPanAverage(panId, int) / setPanWeightedAverage(panId, bool). Signatures match IRadioBackend.h:427/436 exactly; RadioModel::requestPanAverage (RadioModel.cpp:6383-6391) and requestLocalPanWeightedAverage (:6404-6421) already route to them through shapesDisplayRatesLocally(), so no new plumbing was needed and none was added.
• §8, the load-bearing one — "HL2 will need to engage that record at the same moment it gains backend-side averaging, not afterwards, or it reproduces the stacking on the G2 that #5814 found." c.backendPanAveraging = BackendPanAveraging{kMsPerAverageStep} lands in the same commit as the averaging. Pinned by the new hl2_backend_test check.
• q1 domain — power by default, log only behind the weighted toggle, which is #5794's arithmetic carried forward rather than re-litigated.

The one RFC question this PR answers silently is q3 — see Nits.

2. Scope

File / group	What it changes	Claimed?	Verdict
Hl2Spectrum.{h,cpp}	setAverageTimeMs / setLogAverage / dropAverage / blendAlpha, sample-rate ctor arg, m_samplesSinceFrame	Yes — the averaging itself	In scope
Hl2RxDsp.{h,cpp}	m_spectrumAverageMs/m_spectrumLogAverage members + re-apply in installChannel()	Yes — RFC §8 bullet 1 verbatim	In scope
Hl2Backend.{h,cpp}	the two seam overrides, kMsPerAverageStep, pushPanAveraging, dropPanAverage, the capability	Yes	In scope
RadioCapabilities engagement	backendPanAveraging for HL2	Yes — the §8 obligation	In scope
ClientFftSmoothingGate.h (new)	extracts the widget-EMA predicate MainWindow asked in two places	Implied by the gating test	In scope — see note below
MainWindow.cpp	both call sites route through the new gate	Yes	In scope, behaviour-identical (verified below)
docs/architecture/radio-capabilities-map.md, docs/theming/canonical-tokens.md	caps-map row + token doc	AGENTS.md requires the caps-map row	In scope
RadioModel.{h,cpp}	comment corrections only — no code	Yes (they were stale the moment this landed)	In scope
tests/hl2_pan_averaging_test.cpp, tests.cmake, hl2_backend_test.cpp	new test + gating checks	Yes	In scope

Nothing in the diff is unexplained by the issue and the RFC ruling. No CHANGELOG.md entry (correct). No new settings key, no new wire verb, no new dependency, no TX-path contact. ClientFftSmoothingGate.h is new source surface but not new public/protocol surface — a constexpr free function in AetherSDR, no Qt type, mirroring PanZoomModeGate.h in the same directory, and AGENTS.md's capability rule wants a gating test that can ask the predicate without linking the GUI. I'd have accepted the inline expression too, but this is not smuggled scope.

Preference check: no default moves. Hl2Spectrum still constructs at m_averageTimeMs = 0 / m_logAverage = false, the widget's weighted default is still false (SpectrumWidget.h:1620), and Receiver::panAverage = 0. A fresh HL2 connect looks exactly as it does today until the operator moves the slider. That is the property that makes this a feature and not a restyle.

3. Blockers

None.

4. Nits (non-blocking)

• RFC #5782 q3 is answered by deletion rather than by a decision. ten9876's ruling says q3 (a shared accumulator in src/core/dsp/, which the triage read as "src/core/dsp/ is right") is "genuinely the HL2 change's to answer." This PR answers it — keep it in Hl2Spectrum — and removes the paragraph in Hl2Spectrum.h that recorded q3 as open, but never states the call or its reasoning. With RadioModel.cpp:6376 now reading "a backend that does not override setPanAverage() (RTL) still does no averaging", the next RTL change writes this a third time, which is the duplication RFC §5 rejected Option B for. Worth one sentence in the header saying the accumulator stays HL2-private and why, plus a comment on #5782 closing q3 so it does not sit open against a PR that already decided it. This is a maintainer call, not a code defect.
• A transport gap's effect on dt is undocumented. reset() (the spectrumGapDiscards path, Hl2RxDsp.cpp:666) clears m_acc but touches neither the average nor m_samplesSinceFrame. So after a multi-second EP6 dropout the first frame back gets dt ≈ 21 ms, not the real gap length, and the pre-gap average survives the outage nearly intact. I think this is the right answer — the signal during a gap is unknown, so holding the last estimate beats inventing a decay — and "the stream is the clock" in setAverageTimeMs()'s block implies it. But the reset() paragraph argues at length about retune-vs-gap wanting opposite answers and then says nothing about what a gap does to the average's clock, which is the one question a reader arrives at that paragraph with.
• Neither new check runs in CI. grep ctest .github/workflows/ci.yml shows filters for only aether_dv_waveform_no_args|thumbdv_queue_test|dstar_model_test|digital_voice_waveform_process_test, cross_needle_meter_test, mac_nr_filter_test and asr_gpu_probe_test. hl2_pan_averaging_test and hl2_backend_test compile in CI and never execute there. That is the project's standing setup and not this PR's doing — recording it because the whole evidentiary weight of this change rests on the author's local run of a test no gate will re-run.

CodeGuard: all five CG-PATH-001 hits are refuted. MainWindow.cpp:9540-9542 is a QLabel string for the NR2 FFTW-wisdom dialog, :9654 a setText in its cancel handler, and :9773-9775 the macOS bundle walk QDir(QFileInfo(QCoreApplication::applicationFilePath()).dir()); d.cdUp(); d.cdUp();. None is attacker-influenced, none is within ~3000 lines of either hunk this PR touches in that file. Dropped.

Socket-test disclosure: none. hl2_pan_averaging_test opens no socket — it links Qt6::Network only because aethercore does, constructs a bare QCoreApplication, and drives Hl2Spectrum/Hl2RxDsp directly. No QTcpServer/QUdpSocket/bind/listen/connectToHost, no peer process, no Fake* radio class. Correct layer per AGENTS.md: DSP arithmetic → socket-free CTest.

5. What I tried to break

Findings below are reasoned from the head checkout at /tmp/aetherclaude/pr-5980; I have no build and ran nothing.

• Double-averaging, the failure #5814 hit on the G2. Chased every consumer of the operator's number above the seam. m_fftAverage is written by setFftAverage and read only by serialization (SpectrumWidget.cpp:1043, :1771) and menu re-sync (:2632, :3180, :3187) — no render path. The only client average is SMOOTH_ALPHA at SpectrumWidget.cpp:8449, gated by m_clientFftSmoothing at :8435, which is what the new gate turns off. So exactly one average survives. Held.
• The MainWindow refactor's equivalence. Old: !(connected && caps...has_value()). New: clientFftSmoothingEnabled(connected, has_value()) → !(connected && backendAveragesPan). The onConnectionStateChanged hunk drops connected && from the local, but the gate re-ANDs it. Identical truth table on all four inputs, and the disconnect fallback (widget smooths again) is preserved. Held.
• Retune ghosting — the one #5794 named as unhandled. Read both dropPanAverage call sites in full, not just the diff context. setPanCenter (Hl2Backend.cpp:4133) already early-returns on hz == r->ncoHz, so a 30 Hz drag pushes the drop only on frames where the NCO actually moved, and setSliceFrequency (:3520) drops only inside the std::abs(hz - r->ncoHz) > usableHz branch where the NCO re-centres. Neither fires on a re-push of an unchanged value, so a settings replay cannot silently wipe a running average. Held. I looked for a third NCO-moving site and found none — setPanBandwidth and every rate change go through configure() → buildChannel() → a fresh Hl2Spectrum, where there is nothing to drop.
• Survival across a zoom, RFC §8 bullet 1's exact trap. installChannel (Hl2RxDsp.cpp:270-276) re-applies from m_spectrumAverageMs/m_spectrumLogAverage, not from Config — and m_config is field-assigned right above, so a setting parked in Config would indeed have been lost. The no-op guards cooperate rather than fight: on a fresh object setAverageTimeMs(0) early-returns (nothing to drop) while setAverageTimeMs(300) applies, and the two setters clear each other's mode (setAverageFrames(1) still takes effect when a time is in force, because the guard also tests m_averageTimeMs == 0.0). I walked all four combinations of (time set / frames set) × (replay / change) looking for a state where averaging silently reverts to none, and found none.
• Log/power state contamination. setLogAverage drops on every flip, and logDomain = blending && m_logAverage means a m_logAverage = true left standing while averaging is off cannot leak a dB value into the non-blending path. m_haveAverage is set after the loop and only if (blending), so a pass with averaging off cannot leave a stale "we have a state". The continue in the log branch skips the power-domain log, correctly — that branch emits the dB state directly. Held.
• The parity claims in the header, which are the ones I most expected to be decorative. They are not. AnanBackend.cpp:39 is also kMsPerAverageStep = 10, so "10 ms on both" in the caps-map row is real. AnanBackend::setPanWeightedAverage (:1255-1265) maps on → setSpectrumLogAverage(true) = kAverageLogRecursive, off → linear-recursive — so "on = log, off = power, the same meaning as ANAN" is accurate. One wrinkle I chased: AnanPanAnalyzer::Settings::logAverage defaults to true, which would make ANAN's default log and HL2's power — but MainWindow_Wiring.cpp:3208 pushes requestLocalPanWeightedAverage(panId, sw->fftWeightedAvg()) (false) on every pan add, so the analyzer's internal default is overridden at connect and the two families do agree in practice. Held, though it holds because of that push rather than by construction.
• The caps-map row's columns. The table at docs/architecture/radio-capabilities-map.md:109 is | Field | Flex | HL2 | Sim |, so | absent | **10 ms** | absent | puts 10 ms on HL2 and leaves Flex/Sim untouched. ANAN appears in the prose, as it does on every other row. Correct.
• The test, attacked as an implementation mirror. It is not one. §1 is static_assert on pure arithmetic plus the composition identity (1-α_{dt/2})² == (1-α_dt), which is the property that makes the setting a time and would fail for any frame-count implementation. §2 checks measured per-bin CV² against α/(2-α) — the closed-form steady-state variance of an EMA of i.i.d. exponentials — with the un-averaged spectrum as a positive control at CV² ≈ 1, so a broken average shows up as a ratio miss, not as a hand-tuned threshold. §3's control is the decisive one: it runs the same step through setAverageFrames(depth) and asserts depthSlow > 3 × depthFast, i.e. it proves the fixture can see the fps coupling it claims the timed path removes. §4's ±2.5 dB target is γ·10/ln10 = 2.507 from E[ln X] = ln E[X] − γ, not a recorded output. §5's bins == raw bit-for-bit assertion is genuinely exact — I traced both paths and the blending branch's first frame computes state = power; power = state; then the identical 10·log10(power + 1e-24), same doubles, same float. Emptying dropAverage() breaks §5; emptying setAverageTimeMs() breaks §1, §2, §3 and §6. This test earns its conclusions.
• dt == 0. blendAlpha returns 0 for non-positive dt, which would freeze a bin. Can computeFrame ever see m_samplesSinceFrame == 0? process() increments before the == m_fftSize boundary test, so at least one sample is always counted, and back-to-back frames inside one oversized block each get fftSize. No reachable zero. Also checked m_samplesSinceFrame for unbounded growth at fps 0 (accumulate-only): uint64_t at 384 kHz is not a concern.
• What I could not check: anything on real hardware, and any claim about how this looks on a waterfall. The PR body's on-air / local-ctest numbers I could not reproduce — and per the nit above, no CI gate re-runs the new test either, so the maintainer is taking the author's local run on trust. The m_haveAverage/dropAverage allocation-free promise I verified by reading (assign on a construction-sized vector) rather than by measuring.

6. Recommendation

Approve with nits. This is the change RFC #5782's ruling asked for, it lands the §8 capability engagement in the same commit as the averaging it gates (the specific failure mode the ruling warned about), and the new test is theory-anchored with real controls rather than a mirror of the implementation. I attacked the double-average path, both retune sites, the zoom-survival trap the RFC named, the domain-contamination cases, and the cross-family parity claims, and all of them held.

Concrete next step: ask @on8st for one sentence in Hl2Spectrum.h recording the q3 call (accumulator stays HL2-private, and why) and a comment on #5782 closing q3, so the RFC's last open question isn't left looking unanswered against the PR that answered it. Neither needs to hold the merge.

Thanks for the honesty in the header about what the time constant doesn't fix — the "RESPONSE time is fps-invariant; NOISE REDUCTION is not" paragraph is the sentence a future reader will need, and it would have been easy to leave out.

---

_{🤖 aethersdr-agent · cost: $9.1873 · model: claude-opus-5}

[aethersdr-agent]

Cisco CodeGuard — static analysis of this PR (5 finding(s))

• [MEDIUM] CG-PATH-001 — Potential path traversal in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-5980/src/gui/MainWindow.cpp:9542
• [MEDIUM] CG-PATH-001 — Potential path traversal in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-5980/src/gui/MainWindow.cpp:9654
• [MEDIUM] CG-PATH-001 — Potential path traversal in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-5980/src/gui/MainWindow.cpp:9773
• [MEDIUM] CG-PATH-001 — Potential path traversal in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-5980/src/gui/MainWindow.cpp:9774
• [MEDIUM] CG-PATH-001 — Potential path traversal in src/gui/MainWindow.cpp /tmp/aetherclaude/pr-5980/src/gui/MainWindow.cpp:9775

_{Automated static scan by Cisco DefenseClaw CodeGuard on the changed files. Advisory — some may be false positives; the review above verifies them.}

---

_{🤖 aethersdr-agent · cost: $9.3674 · model: claude-opus-5}

[on8st]

Receive-side measurement on real hardware: the repaired HL2, this PR in an integration build (3e6c37f5), antenna input on a dummy load (noise only), frames read through the automation bridge.

Two expectations failed, first:

• Within-frame spread at AVG 100: it was 6.4 dB (power) and 6.9 dB (log) against the ≤ 6 dB I had set in advance, and slightly above AVG 50 (5.6 and 6.5 dB). It is marginal, but it is not the monotonic fall I expected.
• My control failed. An LNA gain step at AVG 0 took about 340 ms to settle, where I expected at most about 80 ms, i.e. two frames. So something other than FFT AVG smooths or settles after an LNA change. I have not explained it yet, and I do not attribute it to this PR. It does mean the step-response figures below measure averaging on top of that settling.

What holds:

• The time constant is AVG × 10 ms, as the PR states: τ was 251 / 523 / 1005 ms at AVG 25 / 50 / 100 (power), and 491 ms at AVG 50 (log). At AVG 50 it is the same at 10 fps and 30 fps (515 and 507 ms), so it is a time constant, not a frame count.
• Variance falls with AVG. The floor estimate's frame-to-frame SD went 0.48 → 0.06 → 0.06 → 0.05 dB (AVG 0/25/50/100, power), and similarly in log.
• AVG 0 is unaveraged. The floor SD and spread match an unaveraged simulation. Weighted on and off agree at AVG 0 (within 0.07 dB).
• Power minus log at AVG 50/100 is 2.64 / 2.62 dB, against 2.66 / 2.63 simulated. The PR's fixture reads 2.43.

Not covered: how the trace looks to an eye (the pan grabs came back identical, so that check was undetermined), a real signal under averaging, reset and persistence.

73, ON8ST

[on8st]

Correction to my measurement comment above. The failed AVG 0 control was my fitting script, not the
radio. At AVG 0 the LNA step is complete in the first frame after the command, 99–100 % on both legs, so
nothing else smooths or settles. My fit only looked at frames from 150 ms onward, where the step was
already over, and fitted a time constant to noise. The 5 s "down" value is the edge of its search grid.
Anchoring the fit to the pre-step level gives 5 and 14 ms. The AVG 25/50/100 time constants and the
10-vs-30 fps result stand as posted. Please disregard the sentence that they measure averaging on top of
other settling.

73, ON8ST

[ten9876]

Landing pass at 673d6275.

• CodeGuard CG-PATH-001 (5 hits): refuted. The review above already shows why. None of the flagged MainWindow.cpp lines is in this PR's hunks. Both of this PR's changes in that file route the existing predicate through clientFftSmoothingEnabled(), and no path touches it.
• @on8st's HL2 measurements (09-30, with the correction) are now the PR body's "On the radio" section. That section becomes the squash message. It covers τ = AVG × 10 ms, the same τ at 10 and 30 fps, the variance falling with AVG, AVG 0 being unaveraged, and power − log ≈ 2.6 dB. One measured miss stays open and does not block: the within-frame spread at AVG 100 (6.4 / 6.9 dB) was not below AVG 50. The spread across bins includes the floor's fixed shape, which no time average removes. The frame-to-frame SD, which averaging is meant to lower, did fall as predicted.

[ten9876]

Approving at cde3c37c. #5678 row 2.1 lands as RFC #5782 ruled. The q2 seam is the two defaulted verbs: RadioModel::requestPanAverage and requestLocalPanWeightedAverage reach them through shapesDisplayRatesLocally(). §8 is met: backendPanAveraging{10} is engaged in the same change, so the widget's EMA does not stack. q1 and q3 are answered and recorded.

Fixed in this pass

1. The retune drop seeded the new average from old-axis IQ (automated pass, verified). Hl2RxDsp::dropSpectrumAverage() kept the partial window that accumulate() holds between due frames. 642dfc86 adds Hl2Spectrum::reset() before dropAverage() (Hl2RxDsp.cpp). Proof: hl2_pan_averaging_test §7 compares the first frame after the drop with the raw new-axis frame. They were 129.49 dB apart before and 0.00 dB after. The frame stays at 1024 points, so a window is 2.7–21.3 ms (384k–48k), shorter than a drag's ~33 ms between moves, and frames keep flowing during a drag.
2. The backend half had no test. Nothing checked that setPanAverage / setPanWeightedAverage reach the chain. 642dfc86 adds a check to hl2_backend_seam_test that injects a receiver chain. It shows the values are held on the receiver, FFT AVG 30 reaches the chain as 300 ms, and weighted reaches it as log-recursive. It also shows FFT AVG clamps above range and an unknown pan id is ignored. The test binds nothing.
3. Comments condensed to AGENTS.md § Comments (Hl2Spectrum.h, the test header). The q3 decision (Hl2Spectrum.h:114) and the gap-clock sentence (:41) are kept. Both threads were answered and resolved with these lines.
4. Main merged (a20c66ae, 673d6275, 8f158618, 93acbd3b, cde3c37c; the last two after #6062 landed, as the landing order required). The conflict with #5982's squelch in Hl2Backend.{h,cpp} was adjacent lines only: both push calls and both struct fields are kept. The others merged cleanly.

Verified empirically

• Full ctest without socket-owning tests: 499/500 pass. The one failure is connection_panel_size_test, which fails locally on this machine (#5811). After the #6062 merge, the full socket-free ctest passed 501/502; the one failure is again connection_panel_size_test. After the final merge (#6094, #6087), the affected tests passed 18/18 and the static gates were rerun clean.
• Mutations, each red: setPanAverage a no-op; the weighted flag not pushed; clientFftSmoothingEnabled inverted; setAverageTimeMs ignored; the log flag ignored in Hl2Spectrum; no re-apply in installChannel; the retune drop keeping the held window.
• Static gates, main against head: engine-boundary, touchpoint manifest, capability records and command plane show no new findings, only line shifts. ClientFftSmoothingGate.h is a gui header, not a new gui→engine touchpoint.
• The tests/hl2_backend_test.cpp that #6075 deleted is not resurrected. Its assertions are in hl2_backend_seam_test unchanged.

Reasoned, not driven

• The Flex/Sim path is unchanged. Only ANAN and HL2 set backendPanAveraging, and the gate's truth table matches the old inline expression; the seam test pins it. The demo was not driven because no bridge readback exposes the widget's smoothing flag.
• Theme canon: docs/theming/canonical-tokens.md only says HL2 now engages the record. There is no new token and no colour change. The visible effect (an unaveraged HL2 trace at AVG 0) is the §8 consequence #5782's ruling specified.

Hardware evidence (@on8st, an HL2 on a dummy load): τ = 251 / 523 / 1005 ms at AVG 25 / 50 / 100; 515 vs 507 ms at 10 vs 30 fps; power − log 2.64 / 2.62 dB.

Not verified

• The retune path on a real radio. A few ms of IQ captured before the NCO changed can still sit at the leading edge of the first window after the drop. The Hann window weights those samples down, and there is no HL2 here to measure them.
• The trace by eye.