Run against UM12947 by bridges/mm_client_check.py, read-only, over the USB-B
CDC-ACM port and over the RX55 to TCP :9034.
THE WIRE BYTES ARE IDENTICAL ON BOTH PATHS -- 11,580 B in and 761 B out, to
the byte, with matching identity, state and a 24-entry setup walk. The
protocol does not care which physical layer it runs over, which is the thing
the modem path needed to prove.
Three findings, one of them a correction to my own prediction:
1. THE MODEM NEEDS FEWER READS, NOT MORE. 36 against USB's 83. The tool's
banner claimed the opposite. The modem coalesces -- it buffers ~1 s then
forwards one large TCP segment, where CDC-ACM delivers many small chunks.
That is reassuring rather than alarming: the risk was a frame arriving
split across reads, and the modem splits LESS than USB does. Banner fixed
to state the measured numbers instead of a guess.
2. ~0.65 s PER ROUND TRIP over cellular, independent of payload size. A
1,024 B chunk and a 16 B state read cost the same. list_setups() takes
16.05 s over the modem against 0.46 s over USB, for 24 commands.
This is the number that matters for SFM's design: over cellular, minimise
round trips, not bytes. Enumerating setups costs 16 s -- cache it, never
refresh it on a timer. A 13 KB event is 14 chunks ~ 8.4 s of latency
against ~0.03 s of data, which makes the unconfirmed single-request 0x5A
streaming mode worth its two-minute bench test on its own.
3. THERE IS A RECORD-TYPE FIELD: 0x0C content[11], 0x07 waveform, 0x08
histogram. The reference says no type field is known and that the type
must be carried out of the chain walk. Found by diffing the six bench
events' 0x0C records against their known types -- exactly one byte
separates the groups and is constant within each -- then confirmed by
predicting the right suffix for 6 of 6 on a blind re-run.
Six events split 4/2 is thin evidence for a byte that could be a counter or
a channel count, so it is recorded as a strong candidate, not settled, and
mm_client_check keeps a fallback: it tries the other suffix on failure and
says when the guess was wrong.
Also flagged: the reference's claim that the type comes from SUB 0x0A's
length is not visible in the download capture, where 0x0A is a standalone
monitor-log walk after the last chain entry, not a per-event probe.
END TO END: all six bench events assembled by read_event_file() from captured
0x5A responses decode with the existing codec -- 4 waveforms at 12,288 /
12,288 / 12,288 / 8,192 samples and 2 histograms. No new codec work needed;
/db/import/idf_file ingests a directly downloaded event unchanged.
Not covered: 11.0BD (still pure inference), a monitoring unit, a nearly-full
buffer, and the inbound call-home session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5
0d6eb1621f