[on8st]

The correction this PR has to lead with

#5678's go/no-go was answered, and the answer endorsed the build option this PR removes.
@ten9876 ruled on 2026-09-16, item 2 of that comment:

2. Build option, not a runtime switch — agreed, and for your reason. Two silent
transmit paths are worse than one, and Hl2TxDsp.cpp:29-51 documents that the prior
TXA failure was silent. A compile flag gives a way back without giving an operator a
way to be on the wrong one. The phasing modulator comes out of the runtime path in the
same commit that lands TXA.

That condition was met: Hl2TxDsp selects one modulator at compile time and there has
never been a runtime switch. So this is not a PR that finishes an unanswered question.
It asks the maintainer to revisit a ruling already made, on the strength of something that
changed two days after it — see the next section.

A second attribution needs fixing while I am here, because the CMakeLists.txt comment this
PR removes gets it wrong. That comment says "The approval on #5678 was conditional" and
quotes "until the TXA path passes the extended suite AND HAS HAD HARDWARE TIME". That
sentence is aethersdr-agent's triage recommendation of 2026-09-13, not the maintainer
response. @jensenpat already said so on #5779:

The actual maintainer response on #5678 approves the migration with
characterization-first sequencing and a compile-time fallback. The often-quoted
hardware-time sentence occurs in the triage recommendation; it should not be attributed
verbatim to that maintainer response.

Removing the option removes the mis-attributed paragraph with it, but the correction is
worth stating rather than deleting quietly.

The fact that changed

#5779 flipped the default to ON on 2026-09-18, and no CI job compiles the other side.
git grep -n 'AETHER_HL2_TX_TXA' -- .github/ on current main returns nothing at all —
not just no workflow, no file, and there is no CMakePresets.json either. Every workflow
job that configures this tree takes the CMake default: ci.yml's build, check-windows and
check-macos; full-suite; sanitizers and appimage and macos-dmg (two matrix legs
each); codeql; windows-installer; system-libs-canary; and static-checks's
sanitizer-option, which configures three times into /tmp and never builds.

So the default is the only configuration CI compiles — CMakeLists.txt's own wording.
While the default was OFF, the fallback was the compiled path for free. Since the flip:

• tests/hl2_txdsp_test.cpp's #if !AETHER_HL2_TX_TXA block compiles in no CI build;
• nor does the #else crest-factor assertion in the slider-top leg of the same file;
• and the phasing implementation in Hl2TxDsp.cpp — a preprocessor region, not a whole
  translation unit — is no longer preprocessed into any CI build, so nothing syntax-checks
  it there.

A fallback that no job compiles is not a fallback. The first thing an operator flipping
the flag after a bad TXA report would discover is whether the branch still builds.

And the honest counterweight, measured rather than assumed: it still does. Before
deleting anything I configured this branch's base with -DAETHER_HL2_TX_TXA=OFF and built
and tested it — 524/524 pass, zero failures (see Verification). The way back is intact
today. So this PR is not rescuing a path that has already rotted; it is arguing that a
path nothing guards will rot without anyone finding out, and that a way back which has to
be re-verified by hand before it can be trusted is not the reassurance the option was kept
for. A maintainer who weighs that differently has a real fact on their side, and it is
this paragraph.

This is disclosed, not discovered. aethersdr-agent raised it as finding 3 on #5779
and named the remedy — "Either add an OFF configure+build lane in this PR, or amend
155-156 to say plainly that the fallback is no longer built by any configuration" — and
the second option is what landed. CMakeLists.txt's comment block says it in its own
words today, including "THE WAY BACK EXISTS ONLY WHILE IT STILL COMPILES, AND NOTHING
WOULD NOTICE WHEN IT STOPPED." This PR takes the third option that comment does not
list: stop shipping a way back that nothing keeps open.

What the source shows

Derived at main 7c8fdf84, not quoted from notes. 42 references to the macro across
seven build/source/test files, plus 9 across three documents and 1 in CHANGELOG.md.
Those eleven files are the only ones on main that contain it.

file	refs	what goes
CMakeLists.txt	8	the option(), its ~65-line comment block, and the if/else that defines the macro PUBLIC on aethercore
src/core/backends/hl2/Hl2TxDsp.cpp	7	the #if !AETHER_HL2_TX_TXA blackman() anonymous namespace; the #else phasing implementation (buildModulator, applyModeAndFilter, resetModulatorState, modulate, modulatorName, wdspChannelId, channelConfig, both counters) — 137 lines; the guard in setFilter(); two comment blocks
src/core/backends/hl2/Hl2TxDsp.h	4	the MODULATION comment that documents the choice, and the #else member block (kTaps, m_bandpass, m_hilbert, m_hist, m_histPos)
src/core/backends/hl2/Hl2Backend.cpp	3	beginDspSetup's actualNumRx + (AETHER_HL2_TX_TXA ? 1 : 0); the guarded "Preparing the transmit chain…" stage emit; a readback comment
tests/hl2_txdsp_test.cpp	12	the pacing guard in feed() and in the reset regression; the kMinSuppDb / kMinLowEdgeSuppDb / kModulator #if; the plumbing-check block; the #if !AETHER_HL2_TX_TXA receive-only-modes block; the settledFloor ternary; the crest #if/#else
tests/hl2_dsp_readback_test.cpp	7	four ternaries, an if/else, a bare if and a comment, all over the hl2-tx readback shape
tests/wdsp_channel_test.cpp	1	a comment saying the phasing modulator is compiled out
docs/HERMES.md, docs/automation-bridge.md, docs/hl2-txa-configuration-diff.md	9	the modulator readback vocabulary and the configure-line guidance
CHANGELOG.md	1	not touched — it is inside the released v26.9.4 section and is a historical record of what shipped

Two comments elsewhere still describe the HL2 as running "a hand-written phasing
modulator on transmit" — src/core/AutomationServer.cpp (gatherDspChains doc) and
src/core/backends/IRadioBackend.h (the dspChains contract). They are already wrong on
main today and are corrected here.

backend.chains[].modulator stays in the readback and still reads wdsp-txa. The
field is a bridge contract and its purpose — making a transmit report name the chain that
produced the signal — does not depend on there being two answers.

The instrument this rests on

hl2_txdsp_test's binPower sideband gate is the instrument TXA's correctness is checked
against, and its history matters: #5810 fixed it after it was found measuring its own
epsilon guard rather than the modulator. It now discards the same 12288-sample settling
prefix in the sweep as in the asserted blocks, uses 1e-30 in place of an epsilon that
dominated small image bins, raises the TXA regression threshold from 100 to 140 dB, and
labels floor-limited figures UNRESOLVED, neither bound nor measurement.

It is now a sound regression gate, which is not the same as right. #5810 says so
itself — "This is a regression gate, not a guarantee of true suppression", and "Neither
the test nor these changes establish actual floor-limited TXA suppression" — and the file
repeats it beside the constant. It is also not the only instrument: wdsp_channel_test
runs the same fourteen tones against a raw TXA channel at the live geometry, sharing no
code with hl2_txdsp_test but the arithmetic, and the two agree at DIGU 150 Hz. That
agreement is worth more than either figure, and it survives this PR untouched.

What was NOT measured

Nothing in this PR ran on a radio, and removing a fallback is not measurable on one.
The argument is build-time plus the record that already exists:

• d109-txa-extended-suite (2026-09-17) is an off-air unit-test measurement — no
  transmitter, no dummy load, no antenna, no hpsdrsim, no socket. It ran
  hl2_txdsp_test in both configurations off one tree at 57b80ed4. At each of its four
  asserted DIGU points TXA's opposite-sideband image sat at or below the instrument's
  numerical floor and the incumbent's did not; the incumbent read 22.06 dB at DIGU
  150 Hz on {150, 3000}, reproducing test(hl2): characterise TX opposite-sideband suppression across the passband — 22 dB at 150 Hz, measured #5741's measured figure exactly. The TXA figures
  are floor-limited and are not suppression values — 180 dB / 292 dB must not be quoted
  as TXA's suppression. One run per configuration, no spread.
• And d109 predates test(hl2): the TX sideband gate was measuring itself, not the modulator #5810 by a day, which the argument has to concede. At 57b80ed4
  the TXA thresholds were kMinSuppDb = kMinLowEdgeSuppDb = 100.0; kFloorLimitedSuppDb,
  floorMark(), the 12288-sample sweep prefix and the 1e-30 epsilon did not exist.
  d109's TXA numbers therefore came off the instrument test(hl2): the TX sideband gate was measuring itself, not the modulator #5810 corrected, and have not
  been re-derived on the corrected one. The incumbent's side is unaffected — the
  phasing thresholds were 30.0 / 20.0 before and after, and test(hl2): the TX sideband gate was measuring itself, not the modulator #5810's own validation
  records DIGU 150 Hz still reading 22.06 dB — so the positive control survives and the
  TXA figures are the ones to treat as provisional.
• It is also not true of every row in the file that TXA's image is unresolvable.
  hl2_txdsp_test names the exception itself: at the {0, 4000} low edge "a TXA skirt
  is still resolvable and this sweep measures it" — 59.37 dB at 100 Hz on a wanted bin of
  4.995e-01 against an image of 5.372e-04, and 142.26 dB at 150 Hz. That row is asserted,
  against a 5.0 dB passband floor. It is the widest passband Hl2Backend::setTxFilter
  admits and it is where an operator who widens all the way would live. Removing the
  fallback does not change it, but a body that said "at every asserted point" without it
  would be claiming the universality the file spends a paragraph denying.
• Hardware exists for the TXA path but not for the low edge. The overs recorded in
  CMakeLists.txt (2026-09-17, board id 6, gateware 74) are a 1 kHz dummy-load tone and
  voice SSB on an antenna; the same comment says TXA's advantage at 1 kHz is below the
  EP2 wire and unusable. @jensenpat's approval of build(hl2): default AETHER_HL2_TX_TXA to ON — the volunteer keyed it, into a load and onto an antenna #5779 records the remaining gap in its
  own words — the CHANGES_REQUESTED review of 2026-09-18, not the approval that followed
  it 19 minutes later: the later handedness evidence at 150 Hz with the digital passband
  geometry is "not a DIGU/DIGL end-to-end run or a measured suppression floor." That limitation
  is unchanged by this PR and is not claimed closed — if anything, removing the fallback
  makes it matter more, which is a reason for a maintainer to weigh it rather than a
  reason to hide it.

What this costs, stated rather than lost

1. The crest-factor assertion keeps an equivalent. The #else arm asserts whole-run
crest < 1.05; the #if arm asserts crest(settledTail(...)) < 1.05. The window differs
for a documented reason — a TXA channel's create_slews mute ramp is deliberate T/R
shaping that raises whole-run crest legitimately (measured in the file: whole run 1.0684,
settled tail 1.0000) — and the fault the whole-run window guards, a key-on window of
flat-topped modulator input, is pinned in both builds by the whole-run clamp check
check(mx < 0.999, ...) beside it. Deleting the #else removes an assertion no
configuration compiles today and loses no coverage that runs.

2. The receive-only-modes evidence block is a real loss, and it is the one worth
reading. tests/hl2_txdsp_test.cpp's #if !AETHER_HL2_TX_TXA block is the evidence
behind Hl2Backend::capabilities()'s receiveOnlyModes: it proved AM, SAM, DSB, FM, WBFM
and DRM are bit-identical to USB through the modulator, which is stronger than
asserting that a list contains strings. It was written with a deliberate tripwire — "If
someone later teaches this chain a real AM or FM modulator, this block FAILS, which is the
point: the failure is the reminder to take that mode back off the receive-only list" —
and TXA is that modulator: Hl2TxDsp::applyModeAndFilter calls
WdspChannel::setMode(m_config.mode), so AM/SAM/FM/DSB take real WDSP transmit modes. The
block was guarded out rather than resolved when TXA landed — its own comment says "in the
TXA build every assertion here fails -- seven of them -- while nothing is wrong" and
"That reminder is hereby taken, and it is NOT this PR's to act on." So the tripwire has
already fired; what this PR deletes is the record of it having fired and been deferred.
That is a smaller loss than an armed trap and a real one: the record was in the one place
a future editor of the modulator would trip over it.

The concrete consequence is in a second file. tests/hl2_family_transition_test.cpp
asserts caps.receiveOnlyModes.size() == declared.size() under the message "HL2 declares
exactly the modes hl2_txdsp_test carries evidence for", and its comment above says "hl2_txdsp_test
proves the modulator half … What that test cannot see is the DECLARATION." After this PR
no test carries that evidence in any configuration, so the assertion cites something that
no longer exists. Both are corrected here to say what they now actually check — the
declaration, not the modulator — with the reason written in. That is a downgrade in
coverage, stated rather than papered over. The question it defers is a capability
decision belonging with #5678 rows 1.2 / 6.2 / 6.3, and it is not this PR's to make.

3. One stale claim fixed on the way past. Hl2TxDsp.cpp's rationale comment still
says "Every TXA figure above is a LOWER BOUND, not a value" and prints >= 180.6 dB.
#5810 retracted exactly that phrasing in hl2_txdsp_test.cpp — "AN EARLIER VERSION OF
THIS COMMENT CALLED THEM LOWER BOUNDS. That was wrong" — because the correlation error is
a complex vector and can oppose the image as easily as add to it. The correction never
reached Hl2TxDsp.cpp. This PR rewrites that comment anyway, so it is fixed here: the
figures are floor-limited and UNRESOLVED, neither bound nor measurement.

What this does not cover

This removes one instance of the class #5796 names, not the class. #5796 —
"No CI job builds the optional-dependency-OFF configuration — three build breaks on main
in one week", opened by @ten9876 — lists the phasing modulator third, after #5706
(ENABLE_DFNR=OFF) and #5767 (no HAVE_HIDAPI). Deleting one optional path closes
nothing about the other two or about the next one. This PR does not close #5796 and
should not be read as an answer to it.

This is a proposal, and it is one revert away

@ten9876 ruled for a compile-time fallback on #5678 and this removes it, so the decision
is not mine and not ON8ST's to take by merging. What I am asking for is a ruling on one
narrow question: is a way back that no configuration builds worth keeping, given that
nobody would learn it had stopped working until they needed it? There are three
defensible answers and only the first is this PR:

1. Remove it — one transmit path, and the tree stops claiming a fallback it does not
   exercise. This diff.
2. Keep it and build it — add an AETHER_HL2_TX_TXA=OFF configure+build lane to
   ci.yml or full-suite.yml, which is what aethersdr-agent asked for on build(hl2): default AETHER_HL2_TX_TXA to ON — the volunteer keyed it, into a load and onto an antenna #5779 and
   what ON8ST declined to do unilaterally because a workflow change is a maintainer's
   call. Close this PR and I will send that one instead.
3. Keep it and say so — leave both as they are, on the understanding that the option
   is documentation of a decision rather than a working escape hatch. That is roughly
   where main stands today, and it is a coherent position; it just deserves to be
   chosen rather than arrived at.

While this PR is open nothing is lost: the phasing modulator is one git revert away and
the base it is cut from is recorded below. If it merges and TXA then disappoints on the
air, the revert is still the remedy — the difference is that it becomes a deliberate act
with a review rather than a flag somebody flips alone.

Verification

Branched from origin/main at 7c8fdf84. macOS 15 / arm64, RelWithDebInfo, the
configure line AGENTS.md mandates:

cmake -B build -G Ninja \
  -DCMAKE_IGNORE_PREFIX_PATH="/opt/homebrew;/opt/local" \
  -DCMAKE_PREFIX_PATH=$QT/6.8.3/macos \
  -DENABLE_ASR=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo

Three full builds and three full ctest runs, in this order. The first two are the
baselines, taken before anything was deleted, because "the fallback no longer builds"
would have been a different PR and had to be ruled out rather than assumed:

#	tree	configuration	build	ctest (524 tests)	hl2_txdsp_test
1	7c8fdf84, untouched	-DAETHER_HL2_TX_TXA=OFF	OK	524 / 524, 0 failed	Passed, 2.21 s
2	7c8fdf84, untouched	-DAETHER_HL2_TX_TXA=ON	OK	524 / 524, 0 failed	Passed, 183.49 s
3	this branch	fresh default configure, flag gone	OK	524 / 524, 0 failed	Passed, 182.00 s

Run 1 is the one that matters to the argument, and it argues against me. The fallback
compiles today and passes the whole suite today. Nothing here is a rescue.

The hl2_txdsp_test durations are the pacing difference, not a regression: the TXA
modulator is driven at the configured audio rate because a blockForOutput = false
channel starves under an unpaced feed, which the file documents beside feed().

Run 3 was configured fresh — rm -rf build, no cache carried over — so the removed option
cannot be sitting in a cache entry: CMake prints no "HL2 transmit modulator" line and no
unused-variable warning, and the Build SHA: stamp was taken after the commit rather than
before it.

vkamp_connection_test and wdsp_channel_test are known to flake under -j4 on this
machine; neither did in any of the three runs, so no re-run at -j2 was needed.

Not run, and stated rather than implied: no radio was keyed, no antenna port was
touched, no hpsdrsim, no socket, and no bench cell was taken for this PR. The d109 run
cited above is quoted, not re-taken, and is flagged as predating #5810.

🤖 Generated with Claude Code

[aethersdr-agent]

Issue fit

No Fixes/Closes — the commit refs #5678, #5779, #5796. I read #5796: it documents "no CI job builds the optional-dependency-OFF configuration" and explicitly says "Whether this is worth a CI job, and what shape it takes … is a maintainer call." This PR takes the other branch of that decision for one flag — delete the configuration rather than build it — which is a defensible answer and, for AETHER_HL2_TX_TXA specifically, the one the removed CMake comment itself argued toward. It does what its title says, and the central factual claim checks out: git grep AETHER_HL2_TX_TXA over .github/ returns nothing on this tree, so the OFF arm has not been compiled by anything since #5779 flipped the default.

Verdict: Yes, with one governance question for the maintainer (below) and a documentation-accuracy finding the PR half-did.

Scope

File(s)	What it changes	Claimed by title/body	Verdict
CMakeLists.txt	removes option(AETHER_HL2_TX_TXA) + the PUBLIC target_compile_definitions pair	yes	in scope
src/core/backends/hl2/Hl2TxDsp.{h,cpp}	deletes the phasing implementation, its members, and the #if/#else guards	yes	in scope
src/core/backends/hl2/Hl2Backend.cpp	total = actualNumRx + 1; unconditional TX-step announcement; readback comments	yes	in scope
src/core/AutomationServer.cpp, src/core/backends/IRadioBackend.h	comment-only	yes	in scope
docs/HERMES.md, docs/automation-bridge.md, docs/hl2-txa-configuration-diff.md	readback/status prose	yes	in scope
tests/hl2_txdsp_test.cpp, hl2_dsp_readback_test.cpp, wdsp_channel_test.cpp	unguard the TXA arms, delete the #if !AETHER_HL2_TX_TXA blocks	yes	in scope
tests/hl2_family_transition_test.cpp	assertion message + comment; the assertion itself is unchanged	disclosed in the commit message	in scope, but see finding 1

Nothing in the diff is unexplained by the stated change. No new public surface: the modulator bridge field is retained and still emits wdsp-txa, so no client contract moves. No CHANGELOG.md edit — correct per AGENTS.md. No socket test is added, modified or removed by this PR.

Deleted behavior audit. I read the - lines for removed guards whose symptom could recur. The deleted CMake comment and the deleted #else arm both carried the conjugation warning ("every transmission went out on the wrong sideband … caught on the air, not on the bench"). That rule survives in Hl2TxDsp.h:40-52 and at Hl2TxDsp.cpp:252, with the falsifying mutation still recorded (167.31 dB → -175.64 dB). Nothing user-facing was gated on the flag, so nothing user-facing is deleted with it.

Blockers

None. Nothing here breaks a default build, and every test-threshold change is a no-op for the configuration CI actually compiles (see "What I tried to break").

Findings

1. The production rationale for receiveOnlyModes still asserts the premise this PR deletes. src/core/backends/hl2/Hl2Backend.cpp:1928-1937 reads: "The transmit chain is not WDSP. Hl2TxDsp is a hand-written phasing SSB modulator: setMode() stores the mode and the only reader is isLowerSideband() … So AM, SAM, DSB, FM, NFM, WBFM and DRM all take the upper-sideband branch and go on the air as SSB." Every clause of that is now false — setMode() also reaches applyModeAndFilter() → WdspChannel::setMode() → SetTXAMode. This PR writes the correction into hl2_family_transition_test.cpp:93-105 ("the bit-identity premise no longer holds") and leaves the source of truth uncorrected, so the one test that reads capabilities() now points at a rationale that contradicts it. The declaration itself stays conservative and safe, so there is no user-visible defect — but this is the exact drift class the PR invokes Principle VIII against, and it is one paragraph. Inline comment on the test hunk.

2. ~22 sibling comments in the same files still describe a two-build world. Not cosmetic in aggregate — several are load-bearing explanations a future editor will act on: Hl2TxDsp.h:129 ("In the PHASING build there is no WDSP channel behind this"), :153 ("or -1 when this build has none"), :162-165 ("ALWAYS 0 in the phasing build … the stated reason this is a build flag at all"), :238 ("THE TXA BUILD IS NOT RATE-FREE, and the phasing build is"), :295 ("A no-op in the phasing build"), Hl2TxDsp.cpp:358 ("per build"), Hl2Backend.cpp:5217 ("this build flag exists for"), and in the file this PR rewrote most heavily, hl2_txdsp_test.cpp:126, 255, 442, 452, 1799 ("Applied in BOTH builds", "this whole build flag exists to avoid", "runs on the whole run in BOTH builds"). Inline comment on the header hunk with the full list.

3. Nothing in the tree now records that WDSP TX has no WBFM mode, and the runtime path is unguarded. The deleted block was the only place that said TXA "refuses WBFM outright". That refusal is enforced only in create()-time config validation (WdspChannel.cpp:876); WdspChannel::setMode() (:589-605) does no direction/mode check and returns true, so SetTXAMode(id, wdspMode(Wbfm)) is issued on a live channel. It is reachable: Hl2Backend.cpp:3114 and :3324 push the TX slice's mode straight through on any TX-slice mode change or TX-slice move. WBFM is on receiveOnlyModes, so no emission can follow, and a return to USB re-pushes the mode — but an undefined TXA mode index does reach WDSP. Pre-existing since #5779, not introduced here; I raise it because this PR removes the only note of it. Reasoned from source; I have not run it.

4. The dsp-config fallback in gatherDspChains is now dead, and the doc states categorically what the code still hedges. Hl2Backend.cpp:5209-5212 keeps channel ? "channel-config" : "dsp-config" and the txChannelId >= 0 guard. configure() sets m_configured only after buildModulator() succeeds, and buildModulator() returns false when WdspChannel::create() yields null — so isConfigured() implies m_channel != nullptr, and the early-return on !isConfigured() means the else arms are unreachable. Harmless defensively, but the docs now assert the dead branch away; if they are going to, the code can say so too.

5. Minor, and explicitly not a request to edit a release file: CHANGELOG.md:61 still reads "the in-tree phasing modulator remains one flag away", which this PR makes false. Flagging it for whoever does release prep rather than asking for a change here.

6. Governance — maintainer decision, not a violation. GOVERNANCE.md §"What requires an RFC" lists "Architecture changes"; it also exempts "Build / CI fixes". This sits on the seam: mechanically it deletes an uncompiled build arm, but substantively it retires the fallback that #5678 was approved on ("keep the phasing modulator behind a switch until the TXA path passes the extended suite AND has had hardware time"). Both halves of that condition are now met and named — ON8ST's 2026-09-17 dummy-load and antenna runs, with the SWR corroboration — so the condition has expired on its own terms. I do not think this needs an RFC; I do think it needs a maintainer saying "yes, the way back is closed", because after this the only way back is a revert and the PR says so plainly.

Nits

• docs/automation-bridge.md:1502 — "On hl2-tx entries, level is channel-config" is unconditional, but the code emits "not-configured" and returns early when !isConfigured(). The very next bullet already says "on a configured hl2-tx entry"; matching that word here would make the two agree.
• docs/hl2-txa-configuration-diff.md:463-464 keeps both build rows in the suite table with "(since removed)" — correct as history, and I am not asking for it to change; noting I read it as deliberate rather than stale.
• tests/hl2_family_transition_test.cpp:129's new message, "HL2 declares exactly these modes receive-only", is honest about the weakened claim. The assertion still catches list drift; it no longer carries modulator evidence. Disclosed in the commit message, which is the right handling.

What I tried to break

• "No CI job sets the flag." Grepped the whole head checkout: AETHER_HL2_TX_TXA survives only in CHANGELOG.md:61 and two historical lines of docs/hl2-txa-configuration-diff.md. Nothing in .github/, no CMake preset, no source, no test. The claim holds.
• Dangling references after the deletion. Grepped for every removed symbol — kTaps, blackman, m_bandpass, m_hilbert, m_hist, m_histPos, Band::settledFloorDb, the settledFloor() lambda. Zero live references; the only survivors are two kTaps 255 -> 127 lines inside a mutation-table comment in hl2_txdsp_test.cpp:1001-1009, which are historical prose, not code.
• Did any assertion get loosened? This was the attack I expected to land and it did not. Every threshold the diff touches was already at the value it now hardcodes in the configuration CI compiles: kMinSuppDb/kMinLowEdgeSuppDb were both kFloorLimitedSuppDb (140.0) in the TXA arm; the settledFloor(b) lambda already returned kMinSuppDb, so dropping Band::settledFloorDb changes nothing; feed()'s pacing sleep and crest(settledTail(slam)) were already the TXA arms. The #if !AETHER_HL2_TX_TXA bit-identity block genuinely compiled nowhere. Net coverage loss for the built configuration: none.
• Can the newly-unconditional readback assertions go red? hl2_dsp_readback_test now asserts level == "channel-config" and wdspChannelId >= 0 without a guard. Walked the refusal path: WdspChannel::create() returns null → buildModulator() returns false → configure() leaves m_configured false → gatherDspChains emits level: "not-configured" and returns before either assertion's field exists. So a refused channel produces a different-shaped entry, not a failing one. The assertions are safe.
• Does the progress denominator stall at "N of N+1"? total = actualNumRx + 1 is now unconditional and the TX announcement fires on if (self) alone, while the work itself is still if (txDsp). Traced m_txDsp: constructed unconditionally at Hl2Backend.cpp:361, deleted only in the destructor, never nulled — so the counted step always runs and the if (txDsp) is defensive. No regression, and no change from main, where the flag was already ON.
• Removed-guard-whose-symptom-recurs check. The wrong-sideband bug the deleted phasing comment describes is a property of the deleted code; the TXA no-conjugation rule and its falsifying mutation are both retained. Nothing gated on the macro outside the two files that implement the modulator.
• CI. 5/5 green on 98d49fd8 (Static checks, build, check-macos, check-windows, Sanitizer option configures). Worth noting what that proves here: since no job ever set the flag, green on this PR is the same green the flag's presence always produced — it is not evidence the removal was safe, which is why I walked the deletions by hand instead.

Could not check: anything at runtime. No build, no ctest, no radio. Every finding above is reasoned from the source in /tmp/aetherclaude/pr-5906, with file:line given so each can be checked independently. In particular, finding 3's WBFM path is read from the call graph, not observed on hardware.

Recommendation

Approve with nits (review event stays COMMENT; the merge call is yours). The deletion is clean, the arithmetic of what CI actually compiled is correct, and the tests survive it without a single assertion being weakened for the built configuration — I looked hard for a loosened threshold and there isn't one. Finding 1 is the one I would fix before merge: the PR corrected the test comment and left the production comment asserting the dead premise, three files away from the change that killed it. Findings 2-5 are follow-up-sized. The one thing a maintainer should actively say yes to is finding 6 — this closes the way back that #5678's approval was conditioned on, and the condition expiring on its own terms is an argument, not a ratification.

Nice work, @on8st — the honesty about what the migration is not worth (the 1 kHz row against EP2's 16-bit wire) and the retraction of the ">= 180.6 dB" bound wording are the parts of this diff that will still be paying off in a year.

---

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

[on8st]

Four of the six are ours and all four are done, in dc6581c9. Before the findings, three corrections — two to your review and one to mine, and the one to mine is the reason the first two matter.

Your finding 6 quotes a sentence that is not @ten9876's, and this PR's own lead section is where I said so. The condition you cite — "keep the phasing modulator behind a switch until the TXA path passes the extended suite AND has had hardware time" — is aethersdr-agent's triage recommendation of 2026-09-13 on #5678, not the maintainer response. @jensenpat corrected exactly that attribution on #5779 on 2026-09-18: "The actual maintainer response on #5678 approves the migration with characterization-first sequencing and a compile-time fallback. The often-quoted hardware-time sentence occurs in the triage recommendation; it should not be attributed verbatim to that maintainer response." @ten9876's actual ruling, #5678 of 2026-09-16 item 2, is unconditional: "Build option, not a runtime switch — agreed, and for your reason … The phasing modulator comes out of the runtime path in the same commit that lands TXA." No expiry clause, no suite, no hardware time.

I have carried that sentence myself and it is worth naming why it is sticky: it reads like a ruling, it was quoted in CMakeLists.txt as one for two months, and it is the stricter reading, so repeating it feels like caution rather than error.

Which makes your conclusion stronger, not weaker, and I am adopting your framing over my own. I wrote this PR as "it asks the maintainer to revisit a ruling already made." Yours is better: this does not need an RFC, and it does need a maintainer saying "yes, the way back is closed." The correction only sharpens it — because the ruling carried no condition, nothing expires on its own terms, and a maintainer's yes is the only thing that can close it. There is no reading in which it closes itself. The three answers in the body stand unchanged.

And your finding 3 is reachable from three sites, not two. Alongside Hl2Backend::setSliceMode() and Hl2Backend::setTxSlice() there is a third in Hl2Backend::pushInitialState(), which re-pushes the TX receiver's remembered mode on every connect. It matters more than the count: the other two need an operator to touch the TX slice in this session, that one fires on reconnect into a session that was already in WBFM.

---

1 — the production rationale. Fixed.

Correct, and worse than you wrote it: the closing paragraph of the same block said "the WDSP TXA chain carries all of these", which is false for WBFM specifically, by your own finding 3.

Rewritten. The declaration does not move. What moves is the argument for it, from the dead premise to the one that actually holds: nothing has measured this chain in any of those modes. docs/hl2-txa-configuration-diff.md §7 states the gap in its own words — "Any mode but SSB. No AM, DSB, SAM, FM or CW channel was opened." — and the block now says that taking an entry off is a capability decision wanting a measurement first (#5678 rows 1.2 / 6.2 / 6.3), not a comment's to make.

docs/architecture/radio-capabilities-map.md carried the identical dead premise in its receiveOnlyModes row — "Hl2TxDsp is a phasing SSB modulator whose stored mode is read only by isLowerSideband()" — and is corrected with it. It was not on your list; it is the same drift, one file further out.

2 — the sibling comments. 42, not ~22.

I worked from my own grep rather than your list. All twelve sites you named are real — I checked each against 98d49fd8 at the line you gave, and every one is where you said it was, with the text you quoted. All twelve are fixed. The higher count is two files you did not sweep, plus a second pass over the ones you did.

file	sites
tests/hl2_txdsp_test.cpp	17
src/core/backends/hl2/Hl2TxDsp.h	10
tests/wdsp_channel_test.cpp	8
src/core/backends/hl2/Hl2TxDsp.cpp	5
src/core/backends/hl2/Hl2Backend.cpp	1
docs/architecture/radio-capabilities-map.md	1

The second pass is worth reporting because of what it caught. My first sweep keyed on the obvious phrasings — "phasing build", "TXA build", "BOTH builds". Re-reading the same files afterwards turned up five more that say the same thing without any of those words: Hl2TxDsp.h's "a property of which MODULATOR was compiled in" and "whichever modulator is compiled in", and three in wdsp_channel_test.cpp — "WHERE IT DIFFERS FROM THE PHASING MODULATOR'S SWEEP", "The phasing modulator's sweep runs with Hl2TxDsp's ALC off", "The phasing modulator has no such seam." Four of those five sat inside comment blocks my first pass had already edited, so the block's header had been corrected while its own body still contrasted two chains. That is a worse failure than missing a block outright, and it is the argument for grepping for the claim rather than for its vocabulary.

The two you did not sweep are where the load-bearing ones were.

tests/wdsp_channel_test.cpp's sweep header said "tests/hl2_txdsp_test.cpp carries a CHARACTERISATION SWEEP … that measures the PHASING MODULATOR's opposite-sideband suppression" — present tense, and false since #5779 flipped the default: that sweep runs against TXA and only its baseline table belongs to the old chain. That is the sentence that tells a reader which of the two agreeing instruments is which, and it named the wrong one.

Hl2Backend.cpp's TX/RX passband convention block said "TX (Hl2TxDsp): the MODE selects the sideband — isLowerSideband() negates Q". isLowerSideband() does not negate Q any more; it derives the sign of the passband, which is the one mechanism this whole file warns is catastrophic to get wrong. The same block closed "Read docs/HERMES.md section 5 before migrating transmit onto a WDSP TXA channel" — advice for a migration that happened.

What I did not change, deliberately: every comment that records what the removed modulator measured. Its 22.06 dB at DIGU 150 Hz and 87.15 dB at USB 1 kHz, the sweep's baseline table, and wdsp_channel_test's kSweepFloorDb = 100.0 — which is derived from that chain's best measured point and is the line that says the migration has lost the argument it was made on. Those are real measurements and the only reason this migration was worth doing; deleting them to tidy the tense would be the same mistake as deleting the WBFM note. They are re-tensed where they claimed the present, and kept where they claim history.

3 — the WBFM note. Restored, in WdspChannel. The guard is not small.

Note restored beside WdspChannel::validateConfig()'s check, which is where the refusal lives — you were right that it should not go back into a file that no longer exists. It records the refusal, that it is create-time only, that setMode() makes no check and returns true, the three call sites, and that Hl2Backend::modeFromString maps both "WBFM" and "WFM" onto Mode::Wbfm. A pointer sits on setMode() itself, so a reader arriving there is not told by silence that there is nothing to know.

On whether to guard it — no, and the reason is specific rather than budgetary. The three lines work in isolation. Mirroring create()'s validation at setMode() does not, because the two refusals land in different worlds:

• create() refuses the whole channel. Nothing is configured, isConfigured() stays false, the readback says not-configured. There is no half-state to be in.
• setMode() would refuse one half of a paired push on a live channel. Hl2TxDsp::applyModeAndFilter() calls setMode() and then setFilter(), and the passband it pushes is signed from the new mode — isLowerSideband() reads m_config.mode, which Hl2TxDsp::setMode() has already updated before calling it. Refuse only the mode half and the channel keeps its previous mode under a passband signed for the new one.

That is not a smaller version of the fault; it is the exact fault applyModeAndFilter()'s own comment exists to prevent — "A mode change from USB to LSB that pushed only the mode would leave the transmitter on the upper sideband with the mode readout saying LSB … just as invisible from inside this application, because the panadapter reads the same wire order." A guard that manufactures the condition its neighbour documents as catastrophic is not a two-line fix.

What it would actually take. The refusal has to be of the pair, above WdspChannel — either in Hl2TxDsp::setMode(), where the config being published lives, or by refusing the whole reconfigure. That needs a decision this PR should not take alone: what a refused transmit mode change leaves behind. The previous mode, silently? An invalidated chain? Today Hl2TxDsp::m_config.mode would say Wbfm over a channel that is not in it, and no readback field would show the split — gatherDspChains's hl2-tx entry publishes the channel's passband and rates but not its mode, so the divergence is invisible at exactly the seam built to expose divergence. Making it visible is probably the honest first step and it is a bridge-contract change.

Not filed, and not smuggled in here either. A separate issue is a new filing and that is not mine to open unilaterally — say the word and it goes up, with the call graph and the design question in it. In the meantime the risk is unchanged from main: pre-existing, nothing emitted, because both spellings are on receiveOnlyModes and refuseKeyInReceiveOnlyMode() runs for every TxActivity ahead of the per-activity capability checks (RadioModel_TxCoordinator.cpp). What this PR broke was findability, and that is what the restored note fixes.

4 — the dead dsp-config fallback. I made the code say what the docs say.

Your invariant holds and I re-derived it rather than taking it: configure() clears m_configured on entry and sets it only after buildModulator() returns true; buildModulator() returns false whenever WdspChannel::create() yields null; and that is the only assignment of m_channel in the class. m_configured is written in four places — three of them write false, and the one that writes true is the line after buildModulator() succeeded — so no state of this object is configured-with-no-channel. The txChannelId >= 0 guard is dead for a second reason — m_channelId is set at construction from an allocated id and never reassigned, so a live channel's id cannot be negative.

So: level is unconditionally channel-config, wdspChannelId and both counters are unconditional, and every channel ? … : t.… fallback to Hl2TxDsp's requested figures is gone.

Why that direction and not hedging the docs. A fallback nothing can reach is not defence. What it would have done on a broken invariant is answer with a plausible reading one level further from the DSP, labelled dsp-config as though that were a deliberate choice — a read-back certifying its own input, which is the one thing this object exists not to do. Hedging the docs would have meant writing a client contract around a state no code can produce.

One structural change so it cannot become a null dereference: the channel check folds into the existing !isConfigured() early return rather than becoming a new branch. if (!txDsp->isConfigured() || !channel) emits not-configured and returns. So there is still exactly one guard, there is no second entry shape, and docs/automation-bridge.md's "the modulator always has a WDSP channel behind it" is now true of the code as written rather than of the code as reasoned about.

dsp-config stays in the bridge vocabulary and is still exercised — tests/automation_dsp_backend_readback_test.cpp builds an entry with it directly — so removing HL2's dead emitter does not orphan the documented value.

5 — CHANGELOG.md. Agreed, not touched.

v26.9.4 is released. Correct call; it is release-prep's, and I have not edited it.

6 — governance.

Answered at the top: your framing adopted, attribution corrected, three answers intact.

---

Nits

• docs/automation-bridge.md — applied. Now "On a configured hl2-tx entry, level is channel-config", matching both the code and the next bullet.
• docs/hl2-txa-configuration-diff.md's "(since removed)" rows — left alone, as you asked. Deliberate history, and §7 is also where the hardware time your finding 6 rests on survives: the d104 dummy-load and d105 antenna runs, board id 6 / gateware 74, with the SWR corroboration. I checked that specifically, because this PR deletes the CMakeLists.txt copy of that record and I wanted to be sure it was not the only one. It is not — §7 carries it in fuller form, including the limits the shorter version dropped.
• hl2_family_transition_test.cpp's new message — thank you for reading the weakened claim as disclosed rather than hidden. It is the part of this diff I was least comfortable with.

---

Verification

Rebased check first: this branch is at origin/main with no divergence — git rev-list --count HEAD..origin/main is 0 — so the suite below ran against current upstream, not against the base the PR was cut from.

Same configure line as the body, on the same machine:

cmake -B build -G Ninja \
  -DCMAKE_IGNORE_PREFIX_PATH="/opt/homebrew;/opt/local" \
  -DCMAKE_PREFIX_PATH=$QT/6.8.3/macos \
  -DENABLE_ASR=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo

Three runs, and the two failures in them are both load starvation — shown rather than asserted.

#	tree	ctest	result
1	73d31cca	-j4, all 524	523 / 524 — vkamp_connection_test failed
2	dc6581c9 (this push)	-j4, all 524	523 / 524 — hl2_txdsp_test failed
3	dc6581c9	-j2, the five HL2/DSP tests + vkamp	5 / 5 pass, 0 underruns

Run 1's tree differs from the pushed commit by zero code lines — all 23 differing lines are // comments, checked mechanically rather than eyeballed. Run 2 is the pushed commit: configure and build clean, and no compiler warning in any file this commit touches.

Why both failures are the machine, and what would have changed my mind. They are different tests in the two runs, which is already the signature of load rather than a defect. Run 2's is the sharper case and it is worth quoting, because it names its own cause:

HL2 TXA modulator: block not placed on the wire (underrun), 1 of 82 blocks so far.
The caller is feeding faster than the channel can drain, or the channel has stalled.
FAIL: reset regression has no underruns

One block of 82. In the same run, the characterisation sweep hit the same starvation at 500 Hz and at 150 Hz, printed retrying (attempt 2 of 3) and recovered — hl2_txdsp_test's sweep has the retry wrapper this file's own comment argues for, and the reset-regression leg does not. Every substantive assertion in that run passed with the usual figures: USB 320.71 dB, LSB 320.51 dB, DIGU 150 Hz 180.62 dB. The machine was at load average 130–140 with the build at nice 5, which is the condition hl2_txdsp_test documents beside modulate(): "measured under a load average of 252, this file and wdsp_channel_test both starved, and the sideband assertions then failed saying the chain had regressed."

At -j2: zero underruns anywhere, hl2_txdsp_test green in 164.71 s, and vkamp_connection_test — run 1's failure — green too.

The check that actually rules my diff out, because "it's a known flake" is the answer I would distrust in someone else's comment: this commit changes zero code lines in hl2_txdsp_test.cpp, wdsp_channel_test.cpp, Hl2TxDsp.h and Hl2TxDsp.cpp — every edit in those four files is inside a // comment. The only executable change in the whole commit is in Hl2Backend::gatherDspChains, and the test that covers it, hl2_dsp_readback_test, passed in all three runs.

CI on dc6581c9: Static checks and Sanitizer option configures green; build, check-macos and check-windows still running at the time of writing. Worth saying plainly that CI green proves less here than usual, for the reason your review already gave about this PR: no job ever set the removed flag, so nothing in CI exercises what changed. hl2_dsp_readback_test is the job that does.

Not run, and stated rather than implied: no radio was keyed, no antenna port was touched, no hpsdrsim, no socket, no bench cell. Nothing in this follow-up is measurable on a radio — it is comments, one readback branch and one restored note. The WBFM path in finding 3 remains reasoned from source and not observed, exactly as you flagged it.

🤖 Generated with Claude Code

[on8st]

One dependency worth stating, having considered holding this PR and decided not to.

#5911 reports that v26.9.4's TXA default changed the character of transmitted audio — a sharper skirt and symmetric pre-ringing around the onset, from WdspChannel::Config's 2048-tap default replacing the phasing modulator's kTaps = 255. This PR deletes the only configuration that comparison can be made against. After it merges, AETHER_HL2_TX_TXA=OFF no longer builds anything, and nobody can put the two modulators side by side without reverting.

We are not asking for a hold. The comparison point is not a reason to keep dead code, the history carries it, and the TXA path measures cleanly on every distortion metric we could resolve. But a reviewer should decide that with the dependency in view rather than discover it afterwards, and if #5911's question — whether the 300–2700 passband is the intended shipped voice bandwidth now that the modulator actually enforces it — is one anyone wants measured both ways, that measurement gets harder the moment this lands.

🤖 Generated with Claude Code

[on8st]

Merged main at 33c0032c into this branch as b7854402 (a merge commit, not a rebase). The PR is mergeable again.

The conflict. There was one textual conflict: the receiveOnlyModes row of docs/architecture/radio-capabilities-map.md. This branch had rewritten the HL2 rationale because the phasing modulator is gone. The list stays because nothing has measured TXA in those modes, and because WDSP TX has no WBFM mode. Separately, ca29208b (#5879) had rewritten the alias sentence in the same row after setSliceMode and applyRestoredState started canonicalising. The resolution keeps both: this branch's rationale and main's alias wording.

Stale references from main. ca29208b added three places that still argued from AETHER_HL2_TX_TXA's two builds. I rewrote all three for the single TXA path; the option was not brought back:

• the fmTonePresentation comment in Hl2Backend::capabilities()
• the header of tests/hl2_fm_controls_declaration_test.cpp
• the fmTonePresentation row in radio-capabilities-map.md

The argument is unchanged. FM and NFM are refused by receiveOnlyModes, not by the modulator, and TXA's chain does carry fmmod. No executable line changed in the merge's own edits. After the merge, git grep AETHER_HL2_TX_TXA finds only CHANGELOG.md, which is released and untouched, and the two history rows in docs/hl2-txa-configuration-diff.md.

What was checked.

• Main's changes to WdspChannel.cpp (the power-of-two tap check, the FFTW planner lock and the feat(dsp): runtime setters for the RX filter length and phase mode. Principle VIII. #5878 RX setters) merged cleanly.
• The WBFM note beside validateConfig() still matches Hl2Backend after fix(hl2): withdraw the FM repeater-duplex and CTCSS-encode controls the HL2 has no verb for, and declare the DSB/CWU/CWL its demodulator already serves #5879's alias canonicalisation.

Verification was run on macOS / arm64 at b7854402, with the configure line from the body, re-configured after the commit so that Build SHA: b7854402 is correct:

• Build: clean. No compiler warning in any file the merge touched.
• ctest -j4: 546 / 546 passed, 0 failed. This includes hl2_txdsp_test (173.65 s), wdsp_channel_test, hl2_dsp_readback_test, hl2_family_transition_test and hl2_fm_controls_declaration_test.
• The static-checks.yml scripts, run locally, all pass: engine boundary, touchpoint manifest, seam probe table and its scanner test, test registration, capability records and their parser test, command plane, the per-PR test gate, network timeouts, theme seed and shader dialects. The colour ratchet is +0 on all three counters against the merge base. All three sanitizer-configure cases behave as that job expects.

No radio was keyed and no bench run was taken; nothing in this merge can be measured on a radio.

[on8st]

Force-pushed b7854402 → 3d895446 to drop a stray trailer from one commit message (dc6581c9 → 0ab048b2). The tree is byte-identical to the one CI passed at b7854402; both rewritten commits are signed, with the original author and dates.

[on8st]

Re-verified on repaired hardware. The keyed runs cited in #5779 and here came from my HL2 while it had a hardware fault: a bad joint at AD9866 pin 1 that corrupted TX DAC bits 11 and 5 (see the correction comments on #5354 and #5943). After the repair on 2026-09-27 I keyed TXA again, using v26.9.4, where TXA is the default, into a dummy load:

check	result
USB / LSB / CW at 40 %	keyed and held; forward power 844 / 842 / 842.5 raw, so CW now matches USB
sideband on the wire	USB tone at −1000 Hz and LSB at +1000 Hz; the other side is 91.5 / 96.2 dB down
drive 0 / 10 / 25 / 50 / 75 / 100 %	forward power 2 / 580.5 / 677 / 906.5 / 1224.5 / 1648 raw, monotone
TX passband 300/2700 vs 150/3000, 200 Hz tone	2 raw vs 763.5 raw, about 60 dB on the wire
two-tone through the radio (PureSignal loopback, correction off)	IMD3 −24 to −41 dBc, down from −9 to +3 dBc on the faulty radio

So TXA stands on healthy hardware, and nothing in this PR relied on the phasing modulator's figures from the faulty unit.

[on8st]

I ran the TX-path tests this PR touches under the sanitizers locally, at 3d895446. Bad news first.

wdsp_channel_test fails at this head under ASan, 4 runs of 5. No sanitizer report is involved: ASan and UBSan printed nothing. The test's own timing checks failed, FAIL: halving the transmit audio did not halve the emitted carrier; the TXA ALC is acting at this level in three runs and FAIL: sweep DIGU at 400 Hz was not starved (no underruns in the measured run) in one. That is #5962, fixed on main by #5967 (cf70b59f), and this branch does not have it: its last merge of main is 33c0032c. I checked that it is not this PR's doing rather than assuming it:

• this PR's changes to tests/wdsp_channel_test.cpp and src/core/dsp/WdspChannel.cpp are comments only: with comments and whitespace stripped, both files hash the same at 33c0032c and at 3d895446;
• wdsp_channel_test alone under ASan with 12 CPU spinners running: this head fails 3 of 3, its base 33c0032c fails 3 of 3, and main 25da98de passes 3 of 3;
• alone and idle: this head 1 of 3 failed, base 0 of 3, main 0 of 3. I put that difference down to background load and not to code, since the code is identical, but three runs a side do not prove it.

So this branch will show that test red in a sanitizer lane until it takes main. I have not merged main into it here, and I have not run the merged result; main alone passes, as shown above.

Three limits on everything below:

• Leaks were not checked. macOS with Apple clang 21: its ASan refuses to start with detect_leaks=1, so the run used detect_leaks=0. The weekly lane uses detect_leaks=1.
• TSan ran against a stock Qt, not the instrumented one in the :tsan image. On a stock Qt every cross-thread queued call reports as a race, and three of these tests make such calls. I classify those reports below from their stacks and by reproducing them on main; a clean run on an instrumented Qt would be the proof, and I do not have one.
• Eight tests on one machine (macOS arm64), five repetitions per sanitizer, up to eight tests running at once. Not the weekly lane.

Flags, from .github/workflows/sanitizers.yml at 25da98de, passed through CFLAGS/CXXFLAGS/LDFLAGS as the workflow does, so WDSP's C sources are instrumented:

lane	build type	compile	runtime
ASan + UBSan	Debug	-fsanitize=address,undefined -fno-sanitize-recover=undefined -fno-omit-frame-pointer	ASAN_OPTIONS=detect_leaks=0:abort_on_error=0:halt_on_error=0:strict_string_checks=1:detect_stack_use_after_return=1:print_summary=1, UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=0:print_summary=1
TSan	RelWithDebInfo	-fsanitize=thread -g3 -fno-omit-frame-pointer -O1	TSAN_OPTIONS=halt_on_error=0:second_deadlock_stack=1:history_size=7:print_summary=1:suppressions=tests/sanitizers/tsan.supp

Configured with -G Ninja -DAETHER_ENABLE_HL2_RECEIVER_CHURN_TEST=ON -DAETHER_ENABLE_HL2_TX_LOOPBACK_TEST=ON, Qt 6.8.3 (this head predates #6055), QT_QPA_PLATFORM=offscreen. Only the eight test targets were built; the churn and loopback tests were not built or run.

Results, five runs each:

test	ASan + UBSan	TSan
hl2_txdsp_test	5/5 pass, 0 reports	5/5 pass, 0 reports
wdsp_channel_reservation_test	5/5 pass, 0 reports	5/5 pass, 0 reports
hl2_fm_controls_declaration_test	5/5 pass, 0 reports	5/5 pass, 0 reports
hl2_tx_level_policy_test	5/5 pass, 0 reports	5/5 pass, 0 reports
hl2_dsp_readback_test	5/5 pass, 0 reports	TSan reports, stock-Qt class (below)
hl2_family_transition_test	5/5 pass, 0 reports	TSan reports, stock-Qt class (below)
hl2_tx_gate_test	5/5 pass, 0 reports	TSan reports, stock-Qt class (below)
wdsp_channel_test	1/5 pass, 0 reports (#5962, above)	own checks pass 5/5; 3 TSan reports per run, WDSP (below)

The TSan reports (132 to 136 per run, 28 distinct signatures):

1. wdsp_channel_test: data race TXA.c:822 (and :823, :824) in TXASetupBPFilters, against xbandpass bandpass.c:321 on the WDSP worker, reached through WdspChannel::setFilter. Not in this diff. It reproduces at 25da98de with the same three SUMMARY lines and is the report the weekly lane already tracks in [sanitizer] TSan weekly run failure (fp 4fd7a70228fc) #5831 (repeated in [sanitizer] TSan weekly run failure (fp 596465812892) #5959, taken at 33c0032, this branch's own base).

2. Everything else, 647 reports over the five runs: one side is a functor being run or destroyed by QObject::event on the I/O thread, the other is that functor being built in QMetaObject::invokeMethod on the caller, or the caller reading the result of a Qt::BlockingQueuedConnection call. 21 of the 25 signatures in this class reproduce at 25da98de after line numbers are stripped. The other four are specific to this head, and since Hl2Backend.cpp is a file this PR changes I looked at each:

   • hl2_dsp_readback_test, first access in QString::size() (50) and in the QArrayDataPointer<char16_t> move constructor (40): the test reading the list that Hl2Backend::dspChains() filled through its blocking queued call (Hl2Backend.cpp:5857). Main reports the same handoff under other accessor names. This PR changes what gatherDspChains puts in that list, which moves the first access TSan sees; it does not touch the invokeMethod call.
   • hl2_family_transition_test, Hl2Backend::connectRadio(...) lambda, 2 reports in 1 run of 5: the queued discovery call at Hl2Backend.cpp:2731, not in this diff.

   The weekly lane's failing list at 33c0032 ([sanitizer] TSan weekly run failure (fp 596465812892) #5959) contains none of these three tests, which is what an instrumented Qt would predict.

Positive control for the ASan + UBSan lane: a small program with a signed overflow and a heap use-after-free, built and run with the same flags and options, reports both.

Still not run: the weekly lane itself (Linux, instrumented Qt, leak detection on, whole suite).

73, ON8ST

[jensenpat]

Issue fit and purpose

Reviewed head 3d895446ac0f77161a0a15b46f9ce467a53113c4. This is a proposal to retire HL2's compile-time phasing-modulator fallback, not a fix for a presently broken fallback. #5779 made TXA the default, and no workflow explicitly builds AETHER_HL2_TX_TXA=OFF. The author reports that the OFF baseline still builds and passes. Deletion removes this one unexercised configuration; it does not solve #5796's general optional-dependency coverage problem.

The actual maintainer ruling on #5678 explicitly endorses a build option as the way back. The PR now correctly acknowledges that it asks Jeremy (@ten9876) to revisit that ruling. I found no subsequent maintainer approval of removal in this PR. #5911 remains open and describes changed TX audio after the TXA default flip; its comparison used the very OFF configuration removed here. This makes fallback retirement a substantive maintainer decision, not an inevitable cleanup. My proposal is to retain the fallback and add an explicit OFF configure/build lane in a suitable existing periodic workflow unless Jeremy deliberately chooses retirement. This is not a claim that the default TXA path is defective.

Scope

File/group	Change	Claimed?	Verdict
CMakeLists.txt	Removes option and exported macro	Yes	Central retirement decision
Hl2TxDsp.{h,cpp}	Deletes phasing implementation and selects TXA unconditionally	Yes	In scope
Hl2Backend.cpp	Unconditional TX setup step; simpler configured readback; rationale updates	Yes, including follow-up	In scope
AutomationServer.cpp, IRadioBackend.h, WdspChannel.cpp	Comment corrections and WBFM limitation documentation	Body/commit/follow-up	In scope; comment nit below
Four HL2 test files and wdsp_channel_test.cpp	Removes OFF-only branches; retains TXA assertions; updates declaration wording	Yes	In scope; no new regression test
HERMES.md, capabilities map, bridge documentation, TXA configuration document	Documents sole remaining path; preserves historical measurements	Yes	In scope

No unrelated feature, UI preference, new dependency, new keying verb, capability expansion, enforcement-baseline growth, or CHANGELOG edit found. The default-path assertions retain their existing thresholds. The deleted receive-only-mode identity block was already disabled in the default build; deleting it removes fallback-specific evidence rather than coverage running in today's default.

Blocker

1. Current-main integration fails. src/core/AutomationServer.cpp:5183, src/core/backends/IRadioBackend.h:1008, src/core/backends/hl2/Hl2Backend.cpp:5773, src/core/backends/hl2/Hl2TxDsp.cpp:21, and src/core/backends/hl2/Hl2TxDsp.h:29: git merge-tree --write-tree 3d895446 68cdf661 exits 1 with content conflicts in all five files. GitHub also reports CONFLICTING. Preserve the intervening main changes when updating the branch, then rerun the appropriate checks. All five displayed check contexts succeeded, but their pull-request runs were created 2026-09-26 16:20:27 UTC; current main 68cdf661 was committed 2026-10-01 23:59:33 UTC. Those runs do not validate the current integration.

Non-blocking nits and decision

• Retirement needs a maintainer decision (CMakeLists.txt:146, Hl2TxDsp.cpp:23). GOVERNANCE reserves architecture and feature scope to the project maintainer. The prior explicit compile-time fallback decision is still the relevant authority. Either obtain Jeremy's ruling to retire it, or keep it and exercise OFF builds. I am not manufacturing a new RFC violation for deletion of an optional build branch.
• Closing-issue linkage contradicts intent (PR body, “What this does not cover”; deletion at CMakeLists.txt:146). closingIssuesReferences currently lists #5796, despite the body saying it should remain open. GitHub recognizes the closing phrase even in a negated sentence. Rewrite it as “#5796 remains open; this addresses only its HL2 example” and verify that the closing linkage disappears before merge.
• Keep rationale concise and current (Hl2TxDsp.cpp:21-82, Hl2Backend.cpp:5776-5793, WdspChannel.cpp:1091-1122). The new prose repeatedly retells earlier failures/reviews and the readback paragraph cites a Constitution principle in code. AGENTS' Comments guidance says “History does not go in code” and “don't cite Constitution principles in code.” Retain short invariants and link the existing document; move the narrative to the PR. Also qualify Hl2TxDsp.cpp:80's “at every asserted point”: the body itself acknowledges a resolvable TXA skirt in the asserted widest-passband rows. “At the two comparison points above” is the precise scope of that table.

Verification and attacks

• Empirically preprocessed merge base 33c0032c and head with Clang, removing include directives only, with AETHER_HL2_TX_TXA=1, then compared C++ tokens. Hl2TxDsp.cpp, Hl2TxDsp.h, WdspChannel.cpp, hl2_fm_controls_declaration_test.cpp, and wdsp_channel_test.cpp are token-identical. This supports unchanged default implementation; it is not a compile or runtime test. The family-transition test differs in assertion text, as disclosed.
• Ran engine-boundary, touchpoint-manifest, capability-record, and command-plane gates on base and head. Both pass; engine findings are byte-identical (102 tracked findings, zero strict blockers), 71 capability booleans and 413 raw commands are unchanged, and the manifest is current. No new #5554 seam violations found in the diff.
• Inspected configured/unconfigured readback, refused channel creation, signed passband routing, retained no-conjugation rule, TX progress counting, removed symbols, and test thresholds. The configured-channel invariant supports removing the phasing readback alternatives. WBFM validation behavior is unchanged and was not represented as a new fix.
• Test-boundary notification: modified tests/hl2_family_transition_test.cpp:63,79 reaches real TCP/UDP connection paths via RadioModel against TEST-NET addresses. It is registered in CTest, outside the ordinary per-PR filters. Notified the operator before continuing; did not build or execute this target. Other changed tests were inspected for socket ownership; no new fake firmware peer was introduced.
• Local build/tests not run; no test mutation run. The author's 524/524 and later 546/546 reports were read, not independently reproduced. No app or bridge instance launched: the demo backend cannot exercise the removed HL2 compile-time path or HL2-specific readback, and default-path equivalence does not establish on-air TXA quality. No live hardware contacted or keyed. A separate automated code-review skill was unavailable; existing bot findings were checked against the updated source.

Recommendation

Request changes for current-main conflicts. Independently, needs maintainer decision on retiring the fallback. The diff appears mechanically coherent for the default TXA configuration, but that does not answer whether the working escape hatch should be removed. Resolve that decision first, correct the #5796 linkage, and validate a conflict-free updated head.

[jensenpat]

Closing this proposal: we are keeping the compile-time phasing-modulator fallback per Jeremy's guidance on #5678.

His ruling explicitly endorsed a build option as the way back, with no runtime switch: #5678 (comment)

The lack of an OFF build lane does not supersede that decision. #5796 remains open as the separate optional-configuration CI coverage question.

Closed at @jensenpat's direction.