From 492b6683a44c397328bdf20744b7be3739aae7a7 Mon Sep 17 00:00:00 2001 From: serversdown Date: Wed, 23 Sep 2026 17:08:47 -0400 Subject: [PATCH] docs(series4): fleet firmware audit, and retract the Thor-compatibility claim Physical audit of all nine Micromates: 4 on the Blastware line (11.0CB), 2 on the Thor line (11.0BD), 3 pre-split (11.0AK x2, 10.90GC). The Blastware line is already the plurality, which makes "standardise on Blastware" less disruptive than it first looked. Cross-checked against a store-derived audit (firmware is recorded in every .sfm.json as extensions.idf_report.version): 7 of 9 agree. The two that differ, UM6047 and UM14133, are the most recently deployed and were reflashed after their last stored event -- so the store reconstructs firmware history without touching a unit, but lags reality by one deployment. RETRACTION: an earlier draft suggested UM12947's trouble with Thor was explained by its Blastware firmware. Not supported. Ped Bridge runs UM11402 (11.0BD) and UM11719 (11.0CB) side by side from the same deploy date and both call Thor fine -- UM11719 has 331 Thor-collected events while on 11.0CB. A Blastware-line unit does feed Thor, so the CB/BD split is not "which host can collect from it", and UM12947's problem remains unexplained. What is actually established is narrower: a 11.0CB unit answers Series III command frames. Whether a 11.0BD unit does is untested -- and UM20147 (11.0BD) is on the bench, so that is one A/B away. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL --- docs/micromate_protocol_reference.md | 52 ++++++++++++++++++++++------ 1 file changed, 42 insertions(+), 10 deletions(-) diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md index 0fe5332..88e45f5 100644 --- a/docs/micromate_protocol_reference.md +++ b/docs/micromate_protocol_reference.md @@ -50,18 +50,50 @@ machines, and units that will not cross over. It is not a misconfiguration. **Instantel ships different firmware for different host software**, and the wire protocol differs with it. -Versions observed so far: +### Fleet audit (physical, 2026-09-22/23) -| where | version | notes | -|---|---|---| -| bench unit UM12947, today | **`11.0CB`** | Blastware line — answers Series III | -| corpus, 932 event files | `11.0AK` | produced Thor-collected `.IDFW`/`.IDFH` | -| corpus, 83 event files | `10.90GC` | older; UM12947's own files from Sept 2025 | +| unit | firmware | line | location | +|---|---|---|---| +| UM11719 | `11.0CB` | Blastware | Ped Bridge Loc 2 | +| UM6047 | `11.0CB` | Blastware | Brookville Loc 9 | +| UM12947 | `11.0CB` | Blastware | **bench** | +| UM14133 | `11.0CB` | Blastware | Pitt-Music Bldg Loc 1 | +| UM11402 | `11.0BD` | Thor | Ped Bridge Loc 1 | +| UM20147 | `11.0BD` | Thor | **bench** | +| UM13981 | `11.0AK` | pre-split | RKM Loc 1 | +| UM20146 | `11.0AK` | pre-split | Karns Loc 2 | +| UM12420 | `10.90GC` | pre-split | RKM Loc 2 | -Note UM12947 produced `10.90GC` files in production last year and reports -`11.0CB` on the bench now — so **it has been reflashed at some point**, and -firmware is not stable per-unit over time. Any fleet-wide claim needs a -per-unit firmware audit first. +**4 Blastware / 2 Thor / 3 pre-split.** The Blastware line is already the +plurality, which makes "standardise on Blastware" less disruptive than it +first appeared. + +A store-derived audit (firmware is recorded in every `.sfm.json` sidecar as +`extensions.idf_report.version`) agreed with the physical audit on **7 of 9**. +The two that differed — UM6047 and UM14133 — are the most recently deployed +units, reflashed after their last stored event. Useful technique: the fleet's +firmware history is reconstructable from the store without touching a unit, +but it lags reality by one deployment. + +Firmware is **not stable per-unit over time** — five of nine have been +reflashed at least once. Any fleet-wide claim needs a fresh audit. + +### ⚠ Retraction: firmware line does NOT determine Thor compatibility + +An earlier draft of this document suggested that UM12947's trouble with Thor +was explained by its being on the Blastware build. **That is not supported.** + +Ped Bridge runs UM11402 (`11.0BD`) and UM11719 (`11.0CB`) side by side, both +deployed 2026-04-20, and **both call Thor successfully** — UM11719 has 331 +Thor-collected events in the store while on `11.0CB`, through 2026-08-23. + +So a Blastware-line unit does feed Thor. Whatever the CB/BD split changes, it +is not "which host software can collect from it", and UM12947's specific +problem remains unexplained. + +**What is actually established:** a `11.0CB` unit answers Series III command +frames. Whether a `11.0BD` unit does is **untested** — and UM20147 (`11.0BD`) +is on the bench, which makes that a direct A/B away. The version is readable over the wire from `SUB 0x01` as two separate ASCII runs — `"0CB"` then `"11"` — with no single concatenated string.