You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
arq: drop an unreachable pattern correlation; refuse to truncate callsigns
Three connect-path cleanups, no wire change.
1. expect_pattern_ack no longer includes ACCEPTING. No pattern can arrive in
that state: the caller answers an ACCEPT with either a coded DATAC16 confirm
or a first MFSK DATA burst, never a pattern — send_ack() emits one only once
the session is CONNECTED. So the correlator ran for the whole ~18 s ACCEPT
window, and per the measurement already recorded at that site it costs about
half the RX sample budget (3.5k samp/s consumed against 8k arriving, capture
ring growing to ~400 kB). It was burning that precisely while the answerer
had to decode the frames that complete the connect.
Note this is NOT visible in connect_bench: the sim has no DSP, so it cannot
show RX budget. The justification is that the branch is unreachable plus the
existing DIAG measurement of what the correlator costs; confirming the gain
needs the live path (make DEBUG_IO=1).
2. Callsign encoders refuse over-long input instead of truncating. Truncating
an arithmetic code does not shorten the string — it decodes to a DIFFERENT
one, so the peer answers a call from a station that does not exist, or drops
one that does. Both encode_callsign_payload (CALL/ACCEPT) and
encode_callsign_only_payload (CQ) had this. They now return -1, which
build_call_accept already propagates, and send_call_accept says why rather
than leaving a session retrying against silence.
Tests: a round-trip over realistic callsigns including SSIDs (PU2UIT-2,
DL9ABC-15) and a refusal test verified to fail against the old truncating
code.
3. Dead code: startup_deadline_ms was written at three sites and read nowhere;
ARQ_CONNECT_GRACE_SLOTS and ARQ_CONNECT_BUSY_EXT_S were never referenced.
Left alone deliberately, because it is user-facing and the call is not
mine: `startup_max_s` is a documented mercury.ini knob, clamped 2..60 and
written back by cfg_write, whose ONLY effect was to set the unread field
above. It is now inert — an operator can tune it and nothing happens. It
should either be implemented or removed.
Full C suite green, go test -count=1 green (203 s). The arq.c:754
format-truncation warning is pre-existing (present on the unmodified tree).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0 commit comments