From ea229ed19d5cfc58ca008c97434b1af2650ce7ee Mon Sep 17 00:00:00 2001 From: serversdown Date: Wed, 30 Sep 2026 14:02:32 -0400 Subject: [PATCH] docs(series4): monitoring reads confirmed, and setup-name case is inconsistent Two findings from a UM20147 run that was only meant to capture fixture bytes. 1. A MONITORING UNIT ANSWERS READS NORMALLY. UM20147 was read while actively monitoring -- monitoring=True on both indicators, which agree -- and served POLL, serial, state, monitor status and a 5-entry setup walk with no special handling. This confirms the SESSION_RESET finding with our own client. Series III REQUIRES a bare 41 03 before POLL or a monitoring unit will not answer over TCP. That was inferred from its absence in THOR's captures; it is now demonstrated directly, on the other firmware line, by a client that never sends one. (THOR's refusal to send a SETUP while monitoring is a write restriction -- reads are unaffected.) Monitoring moves two values, so neither is stable to compare against: battery drifted 3.55 -> 3.50 V and memory free 15,000,000 -> 14,848,448. 2. SETUP-NAME CASE IS NOT CONSISTENT BETWEEN COMMANDS. Same unit, same session, same file: 0x41 reported "test2.MMB" and 0x40 reported "test2.mmb". A run 45 minutes earlier reported "test2.mmb" from both, so it is not fixed per command either; what changed between is that the unit started monitoring. Cause is a guess from two samples. The consequence does not depend on it: compare setup file names CASE-INSENSITIVELY. An exact-string test of "is the active setup one I know about?" answers no on this unit. Worth fixing before it is a field bug, since name matching is on the path for anything that replaces THOR's setup/scheduler coupling. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL --- docs/micromate_protocol_reference.md | 40 ++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md index 819aa09..a6371ab 100644 --- a/docs/micromate_protocol_reference.md +++ b/docs/micromate_protocol_reference.md @@ -879,6 +879,46 @@ active setup `test2.mmb`, 15,000,000 bytes total and free. 21 reads, 2,165 B in. headline finding of 2026-09-23 — is now demonstrated by a working client, not just by matching response SUBs. +### ✅ A MONITORING unit answers reads normally (2026-09-30) + +UM20147 was read while actively monitoring — `monitoring=True` on **both** +indicators (`0x49` content[0] and `0x1C` content[1], which agree) — and +answered POLL, serial, state, monitor status and a 5-entry setup walk with no +special handling. + +**This confirms the `SESSION_RESET` finding with our own client.** Series III +*requires* a bare `41 03` before POLL or a monitoring unit will not answer over +TCP. That was previously inferred from its absence in THOR's captures; it is now +demonstrated directly, on the other firmware line, by a client that never sends +one. + +Note THOR *refuses to send a setup* to a monitoring unit — that restriction is +about writes. Reads are unaffected. + +Monitoring also moves two values, so neither is a stable thing to compare +against: battery drifted 3.55 → 3.50 V, and memory free dropped 15,000,000 → +14,848,448 (monitoring allocates as it runs). + +### ⚠ Setup-name case is NOT consistent between `0x41` and `0x40` + +Same unit, same session, same file: + +``` +0x41 active setup name -> test2.MMB +0x40 setup-list entry -> test2.mmb +``` + +An earlier run 45 minutes before reported `test2.mmb` from *both*, so the case +is not fixed per command either. What changed in between is that the unit +started monitoring — plausibly it rewrites the active-setup name in a canonical +form when loading a setup, but that is a guess from two samples. + +**Practical consequence, which does not depend on the cause: compare setup file +names case-insensitively.** An exact-string test of "is the active setup one I +know about?" answers *no* on this unit. Worth fixing before it is a field bug — +Thor's own UI couples the scheduler to a setup name, so name matching is on the +path for anything that replaces it. + ### Still not covered - **A download from a BD unit.** UM20147 had no events stored, so the chunk