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
18ed1a27be