…gnostic

Rebased onto PR aethersdr#4471, which already carried the transmit work by content and
adds the receive-handedness fixes this needs. Generalises txcert into a phased
runner covering both directions.

ONE VERB, NOT TWO, and the reason is not tidiness. The checks worth the most are
CROSS-CONSUMER, and two separate tools structurally cannot make them:

  panadapter      vs demodulator      (15.5 — each had the other's convention)
  RX handedness   vs TX handedness    (one wire fact, two users)
  demodulated audio vs transmitted    (14.6)

A combined runner states the wire handedness ONCE and shows every consumer
agreeing or not. Split in two, you get two self-consistent reports that both
pass — which is precisely how this radio transmitted on the wrong sideband for a
fortnight.

RECEIVE RUNS FIRST when both phases are selected. The wire's handedness is one
fact both directions consume, so a transmit result read before the receive
convention is settled is a result about an unknown quantity (15.6).

New receive stages, each a transcription of a specific failure:

  mode-map                    every mode the app can emit survives a round trip.
                              Plain "CW" was absent while "CWU" was present, so CW
                              was demodulated as SSB with the indicator correct;
                              "RTTY" is advertised over TCI with no mapping to
                              this day. An unmapped mode does not fail, it becomes
                              USB. (15.7)
  zero-shift                  forces the NCO to re-centre so the slice shift is
                              exactly zero. Two compensating errors cancel at any
                              other geometry, so measurements taken at normal
                              off-centre tuning prove nothing. (15.4)
  rx-sidebands                all FOUR SSB-family modes against a known off-centre
                              carrier. A single-mode sideband test proves nothing:
                              hl2_shift_test validated in LSB, the one mode the
                              inversion made correct, and passed throughout. (15.3)
  consumer-agreement          panadapter versus demodulator. Not yet automated —
                              it needs a spectrum tap through the seam — so it is
                              reported as an operator check rather than quietly
                              omitted. It is the check that found the bug. (15.5)
  passband-after-mode-change  SetRXAMode discards a passband applied before it.
                              CW then DIGU is the ordering that exposed it: a
                              500 Hz window survived into a wide mode and the
                              decoder saw nothing. (15.7)

WWV is the default receive reference. It is free, always on, exactly known, and
comes from a source that is not us — the one external reference available
without a second radio, which is what 15.4 used to settle handedness.

The receive phase does NOT require transmit permission. Gating it would put the
first thing a new radio needs behind a permission nobody would have granted yet;
only the keying phases are gated, on the same rail as every other TX verb.

Still deliberately diagnostic — no pass/fail. Thresholds meaningful for one radio
are guesses for the next, and the report says so. It ends with what it cannot
determine, now including the two receive items: panadapter-versus-demodulator
off-centre, and third-party spots in the mode under test. The receive bring-up
ended with 63 spots on 14.074 DIGU, the first evidence that could not have come
from a self-consistent loop.

Suite: 184/184.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…r#4500, aethersdr#4493)

WSJT-X lost all rig control in v26.7.4: band changes failed, the dial read
the wrong frequency, and transmissions went out of band.

aethersdr#4407 replaced the model-driven tune with a raw `slice tune` written at the
connection, using the radio's command reply as a barrier to read the settled
frequency back out of SliceModel. Both halves of that are wrong on a Flex.
The raw command bypasses SliceModel, so nothing updates m_frequency; and the
radio answers `slice tune` with no RF_frequency status either (measured by
@milenjb in aethersdr#4493: 89 tunes, 0 frequency statuses in one session). The
read-back could therefore only ever observe the PRE-TUNE value, and every
confirmation echoed the frequency the slice had already left.

WSJT-X's do_frequency() waits on that echo. It concluded the radio had not
moved and reported rig-control failure on every band change — while the radio
was in fact on the new band, which is how transmissions ended up out of band
and why this is a licence-compliance bug rather than a cosmetic one.

aethersdr#4407 also added a short-circuit that confirmed from the model WITHOUT
commanding the radio whenever the request matched what the model held. On its
own that is harmless. Downstream of a model that no longer tracks the radio it
is not: once the two diverged, a client asking for the frequency it had just
been told got a false confirmation and the radio never moved at all. That is
the second, worse divergence, and it is gone with the model authoritative
again — a no-op now falls through to the setter, which ignores it internally
and is still acknowledged.

Tune through the model on every command plane. The setter IS the command path,
not an addition to it: setFrequency() emits the byte-identical
"slice tune <id> <mhz> autopan=0" this open-coded, and additionally updates the
model, honours a locked slice, emits frequencyChanged, and routes through the
TX-inhibit-guarded slice sink that the raw sendCmdPublic bypassed. There is no
second command and no double-tune.

This also collapses the Flex/seam split that aethersdr#4471 introduced: the non-Flex
path already did exactly this, so only Flex was carrying the broken mechanism.
One path now, and tuneSliceAndConfirm is synchronous, so a caller's route
transition closes after the tune has really been taken rather than before.

The confirmation is sent unconditionally even though a successful tune also
reaches clients via frequencyChanged → broadcastSliceFrequencies(). That
duplicates the channel-0 vfo: frame, which is idempotent; the alternative
failure — a client left with no confirmation — hangs WSJT-X for its full
rig-control timeout, and channel 1 is not covered by that automatic path
unless the routing state happens to be bound.

Tests: three cases in tci_server_review_test, asserted on the wire via
tciMessage rather than only on the model, since the echo is what clients
consume. The accumulating-tune case is @milenjb's Stream Deck encoder
scenario. Verified to fail without the fix — "model did not take the tune
(wanted 14224000, model holds 14225000)".

Not fixed here, and worth its own issue: the radio never confirming a tune at
all predates aethersdr#4407. The optimistic model update is what masks it, which is
exactly why removing that update broke this much.

…r#4500, aethersdr#4493)

WSJT-X lost all rig control in v26.7.4: band changes failed, the dial read
the wrong frequency, and transmissions went out of band.

aethersdr#4407 replaced the model-driven tune with a raw `slice tune` written at the
connection, using the radio's command reply as a barrier to read the settled
frequency back out of SliceModel. Both halves of that are wrong on a Flex.
The raw command bypasses SliceModel, so nothing updates m_frequency; and the
radio answers `slice tune` with no RF_frequency status either (measured by
@milenjb in aethersdr#4493: 89 tunes, 0 frequency statuses in one session). The
read-back could therefore only ever observe the PRE-TUNE value, and every
confirmation echoed the frequency the slice had already left.

WSJT-X's do_frequency() waits on that echo. It concluded the radio had not
moved and reported rig-control failure on every band change — while the radio
was in fact on the new band, which is how transmissions ended up out of band
and why this is a licence-compliance bug rather than a cosmetic one.

aethersdr#4407 also added a short-circuit that confirmed from the model WITHOUT
commanding the radio whenever the request matched what the model held. On its
own that is harmless. Downstream of a model that no longer tracks the radio it
is not: once the two diverged, a client asking for the frequency it had just
been told got a false confirmation and the radio never moved at all. That is
the second, worse divergence, and it is gone with the model authoritative
again — a no-op now falls through to the setter, which ignores it internally
and is still acknowledged.

Tune through the model on every command plane. The setter IS the command path,
not an addition to it: setFrequency() emits the byte-identical
"slice tune <id> <mhz> autopan=0" this open-coded, and additionally updates the
model, honours a locked slice, emits frequencyChanged, and routes through the
TX-inhibit-guarded slice sink that the raw sendCmdPublic bypassed. There is no
second command and no double-tune.

This also collapses the Flex/seam split that aethersdr#4471 introduced: the non-Flex
path already did exactly this, so only Flex was carrying the broken mechanism.
One path now, and tuneSliceAndConfirm is synchronous, so a caller's route
transition closes after the tune has really been taken rather than before.

The confirmation is sent unconditionally even though a successful tune also
reaches clients via frequencyChanged → broadcastSliceFrequencies(). That
duplicates the channel-0 vfo: frame, which is idempotent; the alternative
failure — a client left with no confirmation — hangs WSJT-X for its full
rig-control timeout, and channel 1 is not covered by that automatic path
unless the routing state happens to be bound.

Tests: three cases in tci_server_review_test, asserted on the wire via
tciMessage rather than only on the model, since the echo is what clients
consume. The accumulating-tune case is @milenjb's Stream Deck encoder
scenario. Verified to fail without the fix — "model did not take the tune
(wanted 14224000, model holds 14225000)".

Not fixed here, and worth its own issue: the radio never confirming a tune at
all predates aethersdr#4407. The optimistic model update is what masks it, which is
exactly why removing that update broke this much.

…4493) (#4501)

Fixes #4500. Fixes #4493.

**Release-blocking.** WSJT-X lost all rig control in v26.7.4 — band
changes fail, the dial reads the wrong frequency, and transmissions go
out of band. Two users hit it independently within hours of the release,
from opposite directions (WSJT-X and a Stream Deck encoder).

## Root cause

#4407 replaced the model-driven tune with a raw `slice tune` written at
the connection, using the radio's command reply as a barrier to read the
settled frequency back out of `SliceModel`. Both halves are wrong on a
Flex:

- the raw command **bypasses `SliceModel`**, so nothing updates
`m_frequency`;
- the radio answers `slice tune` with **no `RF_frequency` status**
either — measured by @milenjb in #4493: 89 tunes, 0 frequency statuses
in one session.

So the read-back could only ever observe the **pre-tune** value, and
every confirmation echoed the frequency the slice had already left.

WSJT-X's `do_frequency()` waits on that echo. It concluded the radio had
not moved and reported rig-control failure on every band change — while
the radio *was* on the new band. That mismatch is why this produces
out-of-band transmissions rather than just a wrong display, and why it
is labelled `safety`.

### The second divergence

#4407 also added a short-circuit that confirmed from the model **without
commanding the radio** when the request matched what the model held.
Alone, harmless. Downstream of a model that no longer tracks the radio,
not: once the two diverged, a client asking for the frequency it had
just been told got a false confirmation and the radio never moved at
all.

## The fix

Tune through the model on every command plane.

**The setter is the command path, not an addition to it.**
`SliceModel::setFrequency()` emits the byte-identical `slice tune <id>
<mhz> autopan=0` this open-coded — there is no second command and no
double-tune. It additionally updates the model, honours a locked slice,
emits `frequencyChanged`, and routes through the TX-inhibit-guarded
slice sink that the raw `sendCmdPublic` bypassed.

Net effect on `TciServer.cpp` is **47 added, 58 removed** — this is a
simplification. It also collapses the Flex/seam split #4471 introduced:
the non-Flex path was already doing exactly this, so only Flex carried
the broken mechanism. `tuneSliceAndConfirm` is now synchronous, so a
caller's route transition closes *after* the tune has been taken rather
than before.

The no-op short-circuit is removed rather than kept. Its stated purpose
— acknowledging a repeat so WSJT-X cannot time out during startup
convergence — survives, because a no-op falls through to the setter
(which ignores it internally via `qFuzzyCompare`) and is still
confirmed. There is a test pinning that specifically.

### On the duplicate broadcast

The confirmation is sent unconditionally even though a successful tune
also reaches clients via `frequencyChanged` →
`broadcastSliceFrequencies()`. That duplicates the channel-0 `vfo:`
frame.

Deliberate: a duplicate is idempotent, whereas the opposite failure — a
client left with **no** confirmation — hangs WSJT-X for its full
rig-control timeout. Channel 1 is not covered by that automatic path at
all unless the routing state happens to be bound, so suppressing this
would make split confirmations depend on unrelated state. Documented at
the call site.

## Testing

Three cases in `tci_server_review_test`, asserted **on the wire** via
`tciMessage` rather than only on the model, because the echo is what
clients actually consume:

- **accumulating tune** — @milenjb's nine-detent encoder scenario; each
confirmation must carry the frequency just reached, and the stale value
must not also go out.
- **refused tune** — a locked slice must be confirmed with what the
model *holds*, never with what the client asked for.
- **no-op** — must still be acknowledged rather than met with silence
(the behaviour the removed short-circuit was protecting).

Verified to fail without the fix:

```
step 0: model did not take the tune (wanted 14224000, model holds 14225000)
FAIL  vfo: SET confirms the frequency reached (#4500/#4493)
FAIL  vfo: SET confirms the truth when the tune is refused
```

Full suite **190/191**. The single failure is `cross_needle_meter_test`
("SWR label placement cache is keyed by the rendered font"), which
reproduces identically on pristine `origin/main` in a separate worktree
— a local font-environment issue, unrelated.

## Not fixed here

**The radio never confirming a tune at all predates #4407.** The
optimistic model update is what masks it — which is precisely why
removing that update broke this much. This PR restores the mask; the
underlying gap wants its own issue, and #4220's TCI conformance RFC is
the natural home for it.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

…-bus audit

The WSPR beacon was refused outright on any non-Flex family. The reasoning was
sound for a family that needs a `dax_tx` stream: ensureDaxTxStream() returns
true optimistically on a pending `stream create`, so a backend whose command
sink drops that text would "succeed" with a stream that never arrives and leave
`transmit dax` latched for minutes.

A host-modulating backend needs no stream. The transmit route already existed,
built for TCI in aethersdr#4471 — pumpWsprBeacon() → feedDaxTxAudioInternal()'s
m_hostModulation branch → txFinalMonitorPcmReady → submitTxAudio. So this adds
an early arm in prepareWsprTransmit() that latches and returns true, the
matching release, and teaches hasWsprTxStream() that "the route is ready" and
"a dax_tx stream exists" are different claims.

Three things that looked like blockers and were not:

- Mic collision. Two producers into one modulator would put shack ambience on
  the frame, and the HL2 has no radio-side mic mute to hide behind. But
  startWsprPump() already calls setDaxTxMode(true), and onTxAudioReady()
  early-returns on m_daxTxMode before emitting txFinalMonitorPcmReady. The
  suppression is local and family-independent — written for Windows and for
  Linux-without-PipeWire, and exactly what a host-modulating backend needs.
- Interlock timeout. m_interlockTimeout defaults to 0, HL2 never sets it, and
  isInterlockTimeoutSufficient(0) is true.
- Keying. requestPttOn(PttSource::Wspr) already reaches setKeying() via
  moxCommandIssued on every non-Flex family.

`transmit filter_low/high` stays Flex-only and is now documented as advisory
rather than dropped: the HL2 derives its TX passband from the mode (DIGU →
150…3000 Hz), which contains the 1400–1600 Hz WSPR offset, and the tone is a
single ~6 Hz-wide 4-FSK carrier.

HERMES.md gains §18: the audit of which voice/data features actually work on
this radio. Three RX audio buses carry identical payloads on different wires;
every consumer is hard-wired to one at connect() time. CW, RTTY, the QSO
recorder's RX tap, AetherClock, RADE, the DAX bridge and the DAX-IQ applet are
all dead on HL2 for that reason alone. ASR, the AX.25/APRS/PMS stack and TCI
work because they tap AudioEngine rather than a transport. Two of the dead
ones (RADE, DAX bridge) deref panStream() bare and are a SIGSEGV on mode
change, not a decline — flagged as the thing to fix ahead of this.

§13 gains Tier 5 for the bus work; §6 cross-references gaps 16–19.

Tests: the hl2_family_transition_test block that asserted the refusal now
asserts the host-modulated arm, that it does NOT latch `transmit dax`, that
release clears it, that it is re-armable, and that no claim survives a
round-trip back to Flex. 192/192 green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>