serversdown/seismo-relay
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

docs(series4): RETRACTED -- there is no 0x5A streaming mode; offset is a byte count

Browse Source 
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
This commit is contained in:
serversdown
2026-10-02 01:28:43 -04:00
co-authored by Claude Opus 5
parent 18ed1a27be
commit 248ddc9cda
2 changed files with 116 additions and 134 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/micromate_protocol_reference.md
+47 -11
View File
@@ -694,19 +694,55 @@ key size(1E) chunks sum(offsets) last offset
055d4a86 6092 6 6092 0x03cc
```
**These are probably two different modes, not a contradiction.** THOR's
`offset_hi` is the chunk length (`0x04`, `0x03`, `0x00` …). Our single-request
probes set `offset_hi = 0x10` — which in Series III is precisely the
bulk-stream marker `build_5a_frame()` writes raw. So `0x10XX` plausibly means
"stream until done" and returns **several** frames, which the parser of the day
concatenated into the 11,049 bytes recorded below. That reconciles both
observations, but it is a hypothesis: those 2026-09-23 captures never landed in
the repo, so it cannot be re-derived from bytes on disk.
> #### ⚠ RETRACTED 2026-10-02 — there is no streaming mode
>
> This section previously hypothesised that `offset_hi = 0x10` meant "stream
> until done" and returned several frames, reconciling THOR's chunk loop with
> our 2026-09-23 single-request observation. **Measured directly on UM20147,
> it does not:**
>
> | request | one frame returns | file bytes |
> |---|---|---|
> | `offset = 0x1014` (4,116) | 4,127 B data | **4,116** |
> | `offset = 0x111c` (4,380) | 4,391 B data | **4,380** |
>
> **`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
> marker — it is part of the number. One model covers every `0x5A` request ever
> observed, THOR's and ours.
>
> So the 2026-09-23 note that `offset_word = 0x1000 + 2 × pages` returned an
> entire 11 KB event is **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 — but it does not need to be, because the
> live measurement is unambiguous.
>
> 🔑 **And the negative result turned up something better. See below.**
### 🔑 1024 bytes per request is THOR's choice, not the device's limit
The retraction above has a payoff. In establishing that `offset` is a plain byte
count, UM20147 served **4,380 bytes in a single frame** without being asked
twice. THOR uses 1024; nothing about the device requires it.
That matters because of the round-trip cost: ~0.65 s each over cellular,
regardless of payload. A 72,560-byte event is **71 requests ≈ 46 seconds** at
THOR's chunk size. The offset field is a **uint16**, so the structural ceiling is
**65,535 bytes per request** — which would make that same event **2 requests,
~1.3 seconds**.
⚠ The *device's* ceiling is not yet known, only that it is at least 4,380. It may
be bounded by an internal buffer well below 65,535. `scratch/mm_stream_probe.py`
walks ascending sizes and checks 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.
**Implement THOR's chunked form.** It is verified byte-exact across six events
and five distinct sizes, and it is what the firmware runs every day. The
single-request form is worth one bench test as an optimisation — `offset_hi =
0x10` and count the frames — but not worth depending on first.
and five distinct sizes, and it is what the firmware runs every day.
### The offset word is a LENGTH, not a position