Measured directly on UM20147. offset 0x1014 (4,116) returned one frame of 4,127
B data = 4,116 B of file; offset 0x111c (4,380) returned 4,391 B = 4,380 B. So
`offset` is simply a BYTE COUNT, the device returns exactly offset + 11 bytes in
one frame, and page_key is offset // 256. `0x1000` is not a bulk-stream marker;
it is part of the number. One model now covers every 0x5A request ever observed,
THOR's and ours.
The 2026-09-23 note that offset_word = 0x1000 + 2*pages returned an entire 11 KB
event is therefore wrong -- 0x102C is 4,140, and 4,140 bytes is what it would
have returned. Most likely the 11,049 figure was the whole capture rather than
one frame's payload. Those captures never landed in the repo so the error cannot
be traced further, and does not need to be: the live measurement is unambiguous.
The probe tried BOTH escapings of offset_hi, which is why this negative counts --
a malformed frame would have produced the same silence. The escaped form
answered, so the uniform escape set holds for 0x10 in offset_hi too, and the
Series III exception does not carry over.
AND THE NEGATIVE TURNED UP SOMETHING BETTER. In establishing that offset is a
byte count, the unit served 4,380 bytes in a SINGLE frame. 1024 is THOR's
choice, not the device's limit. Since a round trip costs ~0.65 s over cellular
regardless of payload, and a 72,560-byte event is 71 requests ~ 46 s at THOR's
chunk size, the ceiling is worth knowing precisely: the offset field is a uint16,
so 65,535 B per request would make that same event 2 requests, ~1.3 s.
mm_stream_probe.py repurposed to walk ascending request sizes, checking each
against a known-good chunk-loop download so a pass means byte-identical output
rather than a plausible length.
micromate/protocol.py still uses 1024 -- THOR's value, the one with captures
behind it. Raising it is a one-constant change once the ceiling is MEASURED, and
it should not be raised on inference.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
Downloads the SAME event twice -- once with the verified chunk loop, once with a
single offset_hi = 0x10 request -- and diffs the bytes. A differential test
rather than a suggestive one: byte-identical output means the streaming form is
safe to adopt, anything else tells us exactly what it is instead.
Why it is worth asking: a round trip over cellular costs ~0.65 s regardless of
payload, so UM20147's 72,560-byte event is 71 chunks ~ 46 seconds. If one
request fetches it, that becomes under a second. Our 2026-09-23 probes recorded
exactly that behaviour with offset = 0x1000 + 2*ceil(size/512), but those
captures never landed in the repo and cannot be re-derived.
IT TRIES BOTH ESCAPINGS OF offset_hi, and that is the point of the design. On
Series III, `offset_hi = 0x10` in a 5A frame must be written RAW -- doubled to
`10 10` the device SILENTLY IGNORES the frame, which is a documented rule for
this exact command. The Micromate escapes 0x04 in that position (218/218
captured THOR frames), which argues the uniform set applies to 0x10 as well, but
Series III is a direct counter-example in the same command. Testing one form
risks concluding "no streaming mode" when the real finding is "that frame was
malformed" -- so a null result here only counts because both were tried.
Defaults to the SMALLEST event, as the gentlest first attempt; --event largest is
the one that matters. Ends by re-POLLing, because the honest risk of this
experiment is leaving the session wedged and the script should say so rather than
leave it to be discovered later.
Read-only. 0x5A is a read we have sent thousands of times; the only new thing is
a value in its offset field.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5