Step 3 of docs/micromate_client_spec.md: micromate/client.py, two models in
micromate/models.py, 26 offline tests. Every response constant in the tests
is a real captured data section from UM12947.
Field offsets were measured rather than taken from the spec, which turned up
one general rule and one trap:
THE RESPONSE SHAPE. Every response carries an 11-byte prefix and content
starts at data[11]. One rule, every command.
THE TRAP: data[0] is the content length & 0xFF, with no high byte anywhere in
the prefix. It is therefore correct for every response under 256 bytes --
most of them -- and then reports 44 for a 2,092-byte setup block, 30 for a
286-byte monitor-log record, and 0 for a 1,024-byte download chunk. 182 of
251 captured responses agree with a naive read; the 69 that disagree are
exactly the ones >= 256 bytes.
That is the third length in this protocol read too narrow, after
payload[9]-vs-payload[8:10] in the probe response. The client takes content
as data[11:] and lets the frame's own length bound it -- nothing needs the
declared length, since the frame already knows how long it is.
Also measured:
- POLL content[3] is 0x50, printable as "P", immediately before "Instantel".
A generic printable-run scan therefore returns "PInstantel" -- it caught a
test, not a unit. Vendor comes from a fixed offset; the model is found by
searching for "MM/", which is structural rather than positional and so
survives the Thor line's shorter "MM/ISEE/S".
- The setup walk terminates on an EMPTY NAME, not an error: 23 responses, 22
names, factory.MMB first through TEST1.mmb last.
- The 0x1C clock has an unidentified byte at content[6]; the hour is at
content[7]. The protocol reference's 0x1C section already had this right
and names the byte -- its one-line summary in the divergences list reads as
six contiguous fields and is the version not to trust. Re-verified against
three captures: 19:12:25, 19:13:34 and 01:14:05 against filenames stamped
19:12:14, 19:12:14 and 01:14:03.
- Battery and memory are read FORWARD from content start, never backward from
the end. This block is 4 bytes longer on the Thor line; the Series III
from-the-end offsets give a 11.0BD unit 577.92 V. A test appends the four
trailing bytes and asserts the forward offsets survive.
connect() is narrower than the spec asked. The spec said to mirror Thor's
POLL -> SERIAL -> 0x49 -> POLL "because it is known-good"; measurement showed
that is Thor's connection check (3 of 8 sessions) and its fourth frame repeats
its first. So connect() sends the three reads that gather something, and
0x01 is not read at all -- Thor never reads it, its layout is unmapped, and
firmware_line comes free from any response's flags byte. If a unit ever
refuses the next command after a cold connect, put the fourth POLL back and
record it.
A dead clock battery yields device_time=None rather than failing the whole
state read; an unreadable active setup yields active_setup=None rather than
failing connect. Both are real device states.
Still verified only against 11.0CB and only over USB. The BD offsets follow
from the extra bytes being trailing, which is documented but not something
this code has seen.
Full suite unchanged at 16 pre-existing failures; 445 passed, up 26.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5
f09b7dcaaf