fix(hl2): run the CW RX bandpass at 4096 taps until a notch needs 8192 — 43 ms sooner. Principle VIII.

[on8st]

Fixes #5578 (thanks to W5TSU for the report and the 64 ms arithmetic), together with #5954, which already removed the delay outside CW with minimum phase — this is the CW half. Also closes the CW half of row 4.1 of #5678. CW keeps linear phase by design, so there the 8192-tap RX bandpass still delays by (taps − 1)/2.

What changes

Hl2RxDsp::rxFilterTapsFor() now picks the filter length:

case	taps
CW	4096
CW with any notch, or a passband under 100 Hz	8192
every mode outside CW	8192 (unchanged)

• The length is raised before WDSP sees the first notch, so the 50 Hz notch floor holds.
• Switching uses WdspChannel::setFilterTaps (feat(dsp): runtime setters for the RX filter length and phase mode. Principle VIII. #5878).
• Dropping back to 4096 needs 20 Hz of margin above the threshold, so dragging a filter edge doesn't flip the length on every step. A rebuild (sample-rate change) measures that margin from the outgoing chain's length, so the length at the same settings is the same before and after.
• No hysteresis on the notch transition, by design. Adding the first notch or removing the last costs one filter refill each way, but each one happens at a moment the operator caused, by a discrete action, not on every step of a drag. Holding the long filter after the last notch would keep CW at the longer latency with nothing needing it.
• If the raise to 8192 is refused (WdspChannel::setFilterTaps() losing beginControlOperation()), addNotch() refuses the notch the same way it handles a notch WDSP refuses, so a 50 Hz notch is never realised at 100 Hz on the 4096 filter. The next notch, mode or filter change retries.
• setFilterTaps() holds g_setupMutex (the process-global FFTW planner lock) on the hl2-io thread for the six FIR re-plans only; the channel stop stays outside it. That is the same class of cost setMode() already pays for the phase change.

Why 4096 and not the 2048 in row 4.1

Measured through a real WdspChannel, 2048 taps leave a signal 50 Hz outside the CW filter edge at −33 dB, against −109 dB at 4096 and −114 dB at 8192. That holds at every CW width, because the skirt is a fixed number of Hz. 2048 would let a CW neighbour through about 80 dB louder than today.

Measured (offline, AGC off)

• CW onset (on8st's HL2: RX bandpass FIR runs at 8192 taps unconditionally, costing every receiver +64ms of group delay #5578 method): 128.00 → 85.33 ms (exactly 2048 samples less).
• CW return after unkey: 128 → 86 ms.
• 4096 vs 8192 for widths ≥ 100 Hz: same centre gain and −6 dB width, ≥ 109 dB down from 50 Hz outside the edges. At the threshold width itself (100 Hz) 4096 taps lose −0.00 dB at the centre (98 Hz −6 dB width at both lengths); at 50 Hz 4096 would lose 0.40 dB, which is why narrower passbands stay at 8192.
• Live 4096 → 8192 switch under a steady tone: no NaN and no spike (peak 1.00× steady), level unchanged, and a 155 ms refill during which audio is more than 6 dB down. The operator hears that once when adding the first notch, removing the last, or crossing 100 Hz.
• Notch across the switch: −103.4 dB, against −103.5 dB on a chain already at 8192.
• Outside CW: 8192 vs 2048 differs by 0.3 ms at minimum phase, so those modes are untouched.

Tests

New hl2_rxdsp_adaptive_taps_test (socket-free, ~10.5 s wall clock). It includes a negative control asserting that 2048 fails the skirt criterion. The exact 2048-sample latency delta is asserted on the impulse response's centre of energy (within 2 samples); the half-amplitude onset is checked within 3 ms. Live legs cover the refused raise, a rebuild where the mode moved mid-build (both directions) and a rebuild that keeps the width hysteresis; each goes red when its line in Hl2RxDsp.cpp is mutated.

hl2_rxdsp_unmute_return_test's CW-vs-USB margin goes from 60 to 30 ms, because CW without a notch now delays (4096−1)/2 samples (42.7 ms) instead of 85 ms. The check still catches the regression it exists for: with minimum phase dropped outside CW, usbReturn goes to ~128 ms, the CW−USB gap goes negative, and both that check and usbReturn < 80 ms fail (mutation-checked).

Listening test (2026-09-30, at bf9fe0a5): on the air, receive only: an HL2 on 40 m CW at 500/250/100 Hz, with this PR's head in an integration build. It was clean, with no ringing, clicks or smearing heard. This is one operator's ear, not a side-by-side comparison against main.

Update against main: merged current main into this branch (no rebase). The conflicts were comment condensation from #6072 against this branch's comment edits, the private declarations beside #5982's pushSquelchToChannel(), and adjacent tests.cmake registrations; both sides were kept. A length change does not disturb #5982's squelch: RXASetNC resizes the filter cores (including fmsq's noise filter) but leaves every squelch stage's run flag and threshold alone, and CW has no squelch stage.

🤖 Generated with Claude Code

[aethersdr-agent]

Issue fit

Yes, with one substitution the maintainer should sign off on. #5578 asks for the RX bandpass to stop paying 8192 taps unconditionally and to buy the long length only while a notch exists. The triage comment on that issue listed three things an implementation has to get right, and I checked each against the diff:

#5578 triage item	Status
1. "the switch is not free… whether repeated add/remove should hysteresis rather than thrash"	Partly. Hysteresis exists for the passband width (kRxTapsHysteresisHz), not for the notch transition — see nit 2
2. "taps must go long before the notch is added"	✅ Hl2RxDsp.cpp:609-610, before m_channel->addNotch(), and before installChannel()'s replay
3. "kMinNotchWidthHz should be derived from the long-length constant, capability pinned"	✅ kRxFilterTaps stays the long length, kMinNotchWidthHz still derives from it, Hl2Backend.cpp:2502 still advertises 50 Hz. I grepped for a runtime consumer of WdspChannel::minimumNotchWidthHz() that could see the 100 Hz short-state floor — there is none outside the new test, so the divergence the triage worried about is not reachable in production

The substitution: #5578's letter proposes 2048 taps / 200 Hz floor. This PR ships 4096, and the test carries a negative control (tests/hl2_rxdsp_adaptive_taps_test.cpp:390-395) asserting 2048 realises no CW width because its skirt 50 Hz outside the edge is ~−33 dB. That is the right way to refuse a proposal, but it does mean the issue's stated fix is not what landed — worth a maintainer nod rather than an implicit close. The commit message references #5578 without a closing keyword, which reads correctly to me.

Also correct in my reading: leaving every non-CW mode long. #5954 already took those to minimum phase, and on8st's own corrected measurements in the #5578 thread (11.95 ms at 8192 minimum phase) support the header's claim that length buys nothing there.

Scope

File	What it changes	Claimed?	Verdict
src/core/backends/hl2/Hl2RxDsp.h	rxFilterTapsFor() policy + 3 constants + two read-back accessors + comment rewrites	Yes	In scope
src/core/backends/hl2/Hl2RxDsp.cpp	tapsForBlock(), applyFilterTaps(), five call sites, armMeterSettle() comment	Yes	In scope
tests/hl2_rxdsp_adaptive_taps_test.cpp	New test (583 lines)	Yes	In scope
tests/hl2_rxdsp_unmute_return_test.cpp	Threshold >60 ms → >30 ms + comment	Implied, not spelled out	In scope — but it is a loosened assertion, see nit 5
tests/tests.cmake	Registers the new target	Yes	In scope

Everything in the diff is explained by the issue. No new protocol verb, wire message, settings key, capability field or CLI flag — notchMinWidthHz is unchanged at 50 Hz, and the two new accessors are read-only test surface on an internal class. No CHANGELOG.md entry (correct). No UI default moved, so §6 does not bite: this is a fix against an open, maintainer-review-labelled issue with measured evidence, not a preference.

I read the - lines for removed guards. The only deletions are the two comment blocks and the one relaxed test threshold; wc.filterTaps = kRxFilterTaps is replaced, not dropped. Nothing that names a symptom was removed.

Socket tests: none. The new test is socket-free (no QTcpServer/QUdpSocket/bind/listen/connectToHost, no Fake* peer) — it drives a real WdspChannel and a real Hl2RxDsp in-process. Correct layer per AGENTS.md's test-layer boundary (DSP → socket-free CTest).

Blockers

None.

Nits (all non-blocking)

1. addNotch() proceeds when the length raise fails — Hl2RxDsp.cpp:609-611. Inline comment below. The header's claim that a widened notch "never exists at all" holds on the success path only.
2. No hysteresis on the notch transition, which is exactly what #5578's triage item 1 asked to be weighed. Toggling the last notch on and off repeatedly costs a channel stop + six FIR re-plans under the process-global FFTW lock + one filter refill each way. The applyFilterTaps() comment argues each change is "at a moment they caused", which is a defensible answer — it just isn't stated against that ask. One line in the body would close it.
3. The installChannel() raise is not pinned by any check — inline comment at Hl2RxDsp.cpp:340.
4. 1.0 ms tolerance on the onset delta — inline at hl2_rxdsp_adaptive_taps_test.cpp:400.
5. The relaxed unmute_return threshold is still mutation-resistant, and worth saying so in the body. I walked it: if minimum phase were dropped outside CW, usbReturn goes to ~128 ms and cwReturn - usbReturn goes negative, so > 30.0 still fails. The usbReturn < 80.0 check is untouched. The loosening is honest, but a reader of the diff can't tell that without doing the walk.
6. The rate-change path silently discards the width hysteresis. buildChannel() calls rxFilterTapsFor(..., 0) with currentTaps defaulted to 0, so shortening && currentTaps > 0 is false and the 20 Hz margin is skipped. A CW passband of 110 Hz that hysteresis was holding at 8192 opens at 4096 after a sample-rate change, and installChannel()'s applyFilterTaps (now current == 4096) keeps it there. Both lengths are legal at 110 Hz by the policy, so this is cosmetic — but the length at identical operator settings differs before and after a rate change.
7. The body should quote the measured centre loss at the threshold width. kGainTolDb is 0.5 dB and the header records 0.4 dB of centre loss at a 50 Hz passband. The first width the policy does hand to 4096 is 100 Hz, and its margin against that 0.5 dB gate is not stated anywhere — the printed table has it, but it should be in the record alongside the −114/−109/−33 dB skirt figures.
8. Runtime. magnitude() is an O(bins × taps) naive DFT — 3001 bins over ~24k-sample impulse responses, 24 times, plus 5 onset runs and 4 live Hl2RxDsp legs. Worth stating the wall-clock figure; no HL2 test appears in any ctest -R filter in ci.yml, so whoever runs ctest -R hl2 locally is the only one who will find out.

What I tried to break

• tapsForBlock()'s divisibility claim. filterTapsArePartitionable() needs taps % dspBlockSize == 0, not merely taps >= dspBlockSize, so the loop is only safe if the block is a power of two. Traced it: Hl2RxDsp.cpp:149 computes wc.dspBlockSize = 1024 * 48000 / inputRate, which is 1024/512/256/128 at the HL2's 48/96/192/384 ksps. The comment's "at most 1024 and this never fires" holds, and create() would have refused 8192 on a non-power-of-two block before this PR too. No new failure.
• A path that leaves a notch on the short filter. Every call site passes the live m_notches.size(), and rxFilterTapsFor returns kRxFilterTaps unconditionally for notchCount > 0. editNotch() is the one notch verb with no raise, and it is unreachable with an empty set (bounds-checked first), so the length is always already long. buildChannel() hardcodes 0, but installChannel() raises before the replay and nothing is processed between them (same thread, synchronous). clearNotches() deliberately holds the long length; I confirmed Hl2Backend::seedNotches() (Hl2Backend.cpp:3969-3995) is its only caller and that it always ends in setNotchesEnabled, so the "stranded long filter" the comment reasons about can't happen on that path.
• Hysteresis arithmetic, all four table rows. At currentTaps == kShort the shortening flag is false so needed is 100 and width 100 stays short; from kLong it is 120, so 100 stays long and 120 shortens; at width 99 even from short it returns long. The test's four assertions match. The highHz >= lowHz guard makes the negative-sideband CWL passband work.
• Bounds ordering in the notch verbs. addNotch and removeNotch both range-check before touching the length, so an out-of-range index can't re-plan the filter for a notch that never lands.
• Whether the new test could pass against unfixed code. It can't: section 2 references rxFilterTapsFor (doesn't exist on main) and section 3 asserts rxFilterTapsInForce() == kShort right after configure(). The no2048 negative control also makes realises() provably falsifiable, which is what stops the honesty loop from being a tautology — though note that for every width the policy hands to kLong, realises() compares shapes[w][2] against itself and the only live assertion is the stopband, duplicating the longOk control. The real content is the short-picked widths.
• Whether armMeterSettle() needed more than a comment. MeterTap::arm() takes only the rates and the block, so the settle window is independent of tap length; halving the CW filter makes the existing window conservative, not wrong. Comment-only was the right change.
• The FFTW-lock exposure on the EP2-pacing thread. setFilterTaps() holds g_setupMutex for the six FIR re-plans (1.8–28.8 ms measured, per WdspChannel.cpp), and Hl2RxDsp lives on the I/O thread that paces EP2. So setFilter() — a filter drag — can now stall that thread where before it was a cheap SetRXABandpassFreqs. I did not raise this as a finding because setMode() → applyMinimumPhaseForMode() → setMinimumPhase() already pays exactly the same cost on exactly that thread today, and the pre-stop trick in setFilterTaps() keeps the 155–227 ms nanosleep out of the locked region. Worth a maintainer eye if EP2 jitter is ever traced back to filter drags.
• Reentrancy during installChannel(). applyFilterTaps() runs with m_installing true, so if a further background build holds g_setupMutex, setFilterTaps() blocks the DSP thread on it. Same class of exposure as the setMode/setFilter/setAgc/addNotch calls already in that function, so not new — but it does add a longer lock acquisition to that list.
• Regression risk in the sibling test I expected to break. hl2_rxdsp_unmute_staleness_test.cpp prints and sizes its detector from kRxFilterTaps and predicts a 170.667 ms frozen history. It configures Mode::Usb, 150–3000 Hz (line 457), so it still runs at 8192 and needs no change. Its header block explicitly says it does not assert against the constant.

Everything above is reasoned from the head checkout at /tmp/aetherclaude/pr-5981, not reproduced at runtime. I have no build and no radio, so I could not run the new test, could not check the measured figures in the header (−114/−109/−33 dB, 128.00/85.33 ms, 44.19/43.92 ms) against a real WdspChannel, and could not verify the 0.4 dB centre loss at 50 Hz. Those are the load-bearing numbers in the design and they are self-asserted by the test that also prints them; the negative control is what makes that arrangement trustworthy rather than circular. CI is green on e610bb5 (build, check-macos, check-windows, Static checks, sanitizer-configures) — but no ctest -R step in ci.yml selects any hl2_* target, so neither this test nor the one it amends gated that green.

Recommendation

Approve with nits. The mechanism is right, the ordering hazard #5578's triage flagged is handled in the one place it matters, and the 2048→4096 deviation is refused with a control rather than an assertion. Nit 1 is the only one with a real (if narrow) failure mode; nits 3, 4 and 5 are about the test being able to prove what it claims. The one thing I'd route to a maintainer is the substitution itself: #5578 asked for 2048, this ships 4096 on measured grounds, and that deserves an explicit yes before the issue is treated as closed. Next step: address nit 1, add the rebuild-with-moved-mode leg from nit 3, and state the onset-delta and runtime figures in the body.

Nice work on the negative control — "2048 realises no CW width, so the criterion can fail" is the check that makes the rest of section 1 mean something, and it is the part most PRs leave out.

---

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

[on8st]

The listening test from the "Not verified" line is now done, on the air, receive only.

• Build: an integration build that contains this PR at its current head bf9fe0a5.
• Radio: the Hermes-Lite 2, on a 40 m fan dipole.
• Signals: live CW around 7.010–7.030 MHz.
• Filter widths: 500, 250 and 100 Hz.

I listened for ringing or a hollow tail on the dits at the narrow widths, for clicks when the width changes, and for fast CW smearing. It was clean at all three widths.

What this does not cover:

• It is one operator's ear, with no side-by-side comparison against main.
• It says nothing about the latency figure itself, which the description measures offline.

73, ON8ST

[ten9876]

Ruling: the 4096-tap substitution is accepted. #5578's letter asked for 2048, but the measured skirt (−33 dB 50 Hz outside the CW edge, against −109 dB at 4096) and the negative-control test are the right grounds to refuse it. Your on-air listening test covers the rest. #5578 closes on 4096.

[ten9876]

We're updating this branch against main and landing it (maintainer pass); please don't push to it meanwhile. New commits go on top, with no rebase or force-push.

[ten9876]

Approving at 499a7c26 (maintainer landing pass). The 4096-tap substitution was accepted by maintainer ruling on 2026-10-02 (comment above); #5578 closes on 4096.

Branch update (Wave 3, maintainer decision): merged main into the branch twice, with no rebase or force-push. The first merge (a3ea493c) had conflicts from #6072's comment condensation against this branch's comment edits, from the private declarations beside #5982's pushSquelchToChannel(), and from adjacent tests.cmake registrations (beside wdsp_minphase_workspace_test). Both sides were kept, and the addNotch() raise guard is unchanged. The second merge (499a7c26) brought in #6019 (another tests.cmake registration) cleanly.

Review findings (aethersdr-agent, 2026-09-27):

1. Unchecked raise in addNotch(): fixed by on8st in bf9fe0a5. Verified by mutation in this pass: an unchecked raise turns both refused-raise checks red.
2. No hysteresis on the notch transition: by design. The body now states the rationale: one refill each way, only at a moment the operator caused.
3. The installChannel() re-apply was unpinned: on8st added rebuild legs in both directions in bf9fe0a5. Deleting the line turns them red (re-verified in this pass).
4. 1 ms onset tolerance: on8st moved the exact assertion to the impulse centre of energy. It measures 2048.00 samples here on Linux, the same as on8st's macOS run.
5. The relaxed unmute_return threshold is still mutation-resistant. The body now says why. Re-verified: with minimum phase dropped outside CW, all three ruling/fix checks fail.
6. The rate-change path discarded the width hysteresis: fixed in d1c2017e. installChannel() measures the hysteresis from the outgoing chain's length, and a new leg pins it (passing 0 turns it red).
7. Centre loss at the threshold width: now in the body (−0.00 dB at 100 Hz/4096, against 0.40 dB at 50 Hz).
8. Runtime: about 10.5 s wall clock, stated in the body.

The comments this branch added are condensed to AGENTS.md § Comments (d1c2017e). The measurements stay in the test and the body.

g_setupMutex on hl2-io: confirmed that nothing widened it. Main's changes to WdspChannel::setFilterTaps() since the merge base are comment-only. The pre-stop is still outside the lock, and the lock covers RXASetNC alone. #5965's workspace free doesn't touch that path.

Verified empirically (Arch Linux, RelWithDebInfo, at 499a7c26): full build. Non-socket ctest 544/545; the one failure is connection_panel_size_test, which fails locally (#5811). Socket-owning tests were excluded per operator direction. ctest -R 'hl2|wdsp' passes 72/72. Static gates (engine boundary, touchpoint manifest, capability records, command plane, test registration, CI test gate, qsettings, network timeouts) all pass, with findings identical to main's. Reasoned, not driven: the on-air behaviour, which rests on on8st's receive-only listening test at bf9fe0a5 (40 m CW, 500/250/100 Hz, clean). No live radio was used in this pass, and nothing was transmitted.

Green freshness: CI and Static Checks on 499a7c26 were created at 2026-10-03T01:09:17Z. Main's tip is 75d00ae26 (#6019, 00:58:47Z), which is older, so the green covers current main.