Uncoded BPSK decodes through the UNCANCELLED soft arm, and #821's guard tests the other one

[dc0sk]

Found during design review of #1428, then verified here by reading the three call sites. This is
about the shipped product, not about #1363's proposed fix, and it stands whatever #1363 decides.

The split

ModemEngine::receive_from_samples (engine.rs:4497) prefers the soft demodulator whenever the
plugin advertises one:

let snr = self.rx_snr_db(mode, &samples.samples);
if plugin.supports_soft_demod(mode) {
    let llrs = openpulse_modem_descramble_soft(plugin.demodulate_soft(&samples.samples, &mod_cfg)?);

BpskPlugin::supports_soft_demod (plugins/bpsk/src/lib.rs:151) returns true unconditionally,
ignoring the mode. And BPSK's soft path deliberately does not apply cancel_crossfade_isi — the
reason is in its own NOTE at demodulate.rs:374 and is a real one (#832: the recursion breaks the
LLR calibration HARQ combining relies on).

So, by construction:

decode	path	cancellation
uncoded (FecMode::None)	decode_attempt → receive_from_samples (engine.rs:4557)	OFF (soft arm, hard-decided)
coded (Rs and friends)	receive_from_samples_with_fec	ON

Three call sites reach the uncancelled arm: receive() (engine.rs:3714), decode_attempt's
FecMode::None arm (4557), and decode_burst_phase1 (2399).

Why this is not academic

Uncoded BPSK is a live production path. Per #1123 the OTA arm's non-ladder traffic — periodic §97.119
station ID, filexfer, handshake, QSY, relay envelopes — is uncoded, and hpx_hf's entry rungs are
BPSK. So the frames that carry a station's identity and its control traffic decode through the arm
that #821's fix never reached.

The test that validates it exercises the other arm

crossfade_cancellation_lowers_awgn_ber (plugins/bpsk/src/lib.rs:286) is an uncoded BER test —
and it calls plugin.demodulate(...), the hard, cancelled arm. So the guard standing over
#821's cancellation, on uncoded data, tests a demodulator that no uncoded production decode uses.
That is the self-consistent-checker shape: the test and the product disagree about which code is
under test, and nothing says so.

The justification comment is false for BPSK

The soft preference is justified on the grounds that a hard retry "can't succeed where the soft pass
failed — both share the same acquisition front end". For BPSK the two arms differ by exactly the
cancellation, which is the thing #1363 has spent a week measuring: worth several dB of flip-bit
margin on AWGN, and worth 8 frames of 96 against you on a delayed-dominant fade. They are not
interchangeable in either direction.

What is NOT being claimed

Not that the uncoded path is wrong. #1363's measurements make the uncancelled arm the better
choice on moderate_f1 and the worse one on AWGN and pure Doppler, so the current split happens to
give uncoded traffic the fade-favourable arm and coded traffic the AWGN-favourable one. That may even
be the right answer — but it is an accident of a capability flag, it is undocumented, and the one
test standing over it measures the other branch.

Suggested shape

1. Decide deliberately which arm uncoded BPSK should use, and record the reason.
2. Make the validating test exercise the path the product takes — or add a second one that does.
3. Fix the justification comment, which is false for the one plugin whose arms differ.

Sizing: #1363 is measuring precisely this trade, so its numbers should inform (1) rather than being
duplicated here. Related: #821 (the cancellation), #832 (why soft skips it), #1361 (the soft/hard
split), #1363, #1428, #1123 (uncoded OTA traffic).

🤖 Generated with Claude Code

https://claude.ai/code/session_0188ATCj6DZ9aRVQ2vSirua6

[dc0sk]

Measured: the uncoded production path misses #821's own bar by 1.7×, on every seed of #821's own fixture.

Same payload, same σ = 0.9, same deterministic LCG noise as
crossfade_cancellation_lowers_awgn_ber, 8 seeds, BER over the 180-byte payload:

arm	what runs it	mean BER	vs the < 0.02 bar
demodulate (cancelled)	the test, and every CODED decode	0.0127	passes
demodulate_soft hard-decided (uncancelled)	every UNCODED decode	0.0336	fails on all 8 seeds (0.0243–0.0444)

So the guard standing over #821's cancellation, on uncoded data, is measuring an arm that no uncoded
production decode executes — and the arm that ships would not pass it.

Pinned, not just reported

the_uncoded_production_path_takes_the_uncancelled_arm (in bpsk-plugin) now asserts the
divergence on the same fixture, with three assertions that each name what their failure would mean:

• the cancelled arm still meets fix(bpsk): audit #1 — cancel crossfade ISI on the differential demod #821's bar (so a genuine regression in that arm is distinguishable
  from this divergence);
• the production arm is still materially worse (≥ 1.5×);
• the production arm still exceeds 0.02 — and if it stops doing so, the message says so and tells
  the reader to delete the test rather than loosen it, because that would mean Uncoded BPSK decodes through the UNCANCELLED soft arm, and #821's guard tests the other one #1429 was resolved.

It is a characterisation test, deliberately. It does not endorse either arm.

The false comment is corrected

engine.rs's justification for preferring soft said a hard retry "can't succeed where the soft pass
failed — both share the same acquisition front end". That is false for the one plugin whose arms
differ, and it differs by exactly the transform under discussion. The comment now records the
measurement, names the test that pins it, and states that the choice is open rather than settled.

What I have NOT done: decided which arm uncoded traffic should use

That is the maintainer's call, and it is a real trade rather than an oversight to reverse on sight:

• BPSK hard path: cancel_crossfade_isi loses ~24% of frames on moderate_f1 at 12-16 dB — validated on AWGN only (#821) #1363 measures the cancellation as a win on AWGN and pure Doppler, and a loss of 8 frames in
  96 on a delayed-dominant fade.
• The uncoded traffic on this path is §97.119 station ID, handshake, QSY and relay envelopes
  (An OTA-enabled daemon cannot receive any uncoded frame — filexfer, handshake, QSY and relay traffic are undecodable whenever ota_enabled = true #1123) — frames that live on fading channels.

So the current split hands uncoded traffic the fade-favourable arm and coded traffic the
AWGN-favourable one, which may well be right for the traffic each actually carries. What was not
defensible is that it happened by way of an unconditional capability flag, was justified by a false
comment, and that nothing tested the path that ships.

Three ways to close it, in rough order of my confidence that they are sensible:

1. Keep the split, record the reason, and let this characterisation test stand as the record.
   Cheapest, and consistent with what BPSK hard path: cancel_crossfade_isi loses ~24% of frames on moderate_f1 at 12-16 dB — validated on AWGN only (#821) #1363 knows today.
2. Make supports_soft_demod mode-aware so the choice is expressed rather than inherited from a
   flag that exists for a different purpose.
3. Revisit once #1363 follow-up: the engine-level coded A/B, and a decision-directed predicate that does not misfire on noise #1428 reports — if a gated canceller lands, both arms could take it and the
   question dissolves, which is BPSK's soft path skips the crossfade-ISI cancellation: a sequence-dependent margin loss that HARQ combining cannot average out (hpx_hf SL2-SL5) #1361's scope.

Apparatus: plugins/bpsk/src/lib.rs, public trait API only, no engine required. Deliberately the
same fixture as #821 — a different one would not be comparable to the bar being cited.

🤖 Generated with Claude Code

https://claude.ai/code/session_0188ATCj6DZ9aRVQ2vSirua6

[dc0sk]

Reopening — my mistake. PR #1431's body said "Closes #1429 as far as measurement and evidence
go", but Closes is a closing keyword and GitHub does not read the qualifier. The measurement half
is indeed done and merged; the half this issue actually exists for is not.

Done and on main (6cfd2876):

• the divergence is measured — cancelled arm 0.0127, shipped uncoded arm 0.0336 on fix(bpsk): audit #1 — cancel crossfade ISI on the differential demod #821's own
  fixture, above the bar on all 8 seeds;
• it is pinned by the_uncoded_production_path_takes_the_uncancelled_arm, whose assertions say what
  their own failure would mean;
• engine.rs's false justification comment is corrected.

Still open, and the reason this issue stays open: which arm uncoded BPSK should use. No arm was
switched. The three candidate closures are in the comment above, and the honest position is
unchanged — today's split hands uncoded traffic the fade-favourable arm and coded traffic the
AWGN-favourable one, which may be right for what each carries, but arrived by accident rather than by
a decision.

This is the second time in this session a closing keyword has done something I did not intend
(the first was caught by CI before merge, on #1418). The lesson is the same both times: a qualifier
in prose does not narrow a keyword GitHub parses mechanically.

🤖 Generated with Claude Code

https://claude.ai/code/session_0188ATCj6DZ9aRVQ2vSirua6