docs(series4): A/B the two firmware lines -- the protocol is the same

UM12947 (11.0CB, Blastware line) and UM20147 (11.0BD, Thor line) each given
the identical read-only sweep on the bench. Both answer Series III command
frames: all ten read SUBs, correct response-SUB rule, valid DLE-aware
checksums, working two-step probe/data reads.

The firmware line does not change the wire protocol. One protocol stack can
drive the whole fleet regardless of build, which downgrades "standardise the
fleet on one firmware" from a prerequisite to an optional convenience.

Two differences do exist:

1. Response payload[1] (flags) is 0xC5 on the Blastware line and 0x03 on the
   Thor line, constant across all ten SUBs on both units -- so the build is
   detectable from any response without reading device info. Two units, one
   each, so this is a strong hypothesis rather than a proven encoding.

   Note 0x03 is ETX, so it arrives DLE-escaped as 10 03 on Thor-line units. A
   parser that does not destuff will mis-locate every field by one byte on
   half the fleet.

2. SUB 0x1C (monitor status) is 4 bytes longer on the Thor line, 0x30 vs
   0x2C, with four extra trailing bytes (0f a0 00 00, purpose unknown).

That second one breaks relative-to-end parsing: Series III reads battery and
memory from the end of the 0x1C block, and those offsets yield a battery
reading of 577.92 V on UM20147. Parse forward from the declared length, not
backward from the end. With the shift applied, UM20147 reads 3.81 V and
15,000,000 bytes total/free.

Also noted: ID string is MM/ISEE/S/IO on the Blastware unit and MM/ISEE/S on
the Thor one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL

docs/micromate_protocol_reference.md

@@ -362,6 +362,53 @@ are DLE-stuffed**, so a parser must destuff before applying field offsets.
 
 ---
 
+## A/B: Blastware build vs Thor build (2026-09-23)
+
+UM12947 (`11.0CB`) and UM20147 (`11.0BD`) were each put on the bench and given
+the identical read-only sweep.  **Both answer Series III command frames.**
+
+| | UM12947 `11.0CB` | UM20147 `11.0BD` |
+|---|---|---|
+| POLL answers | ✓ | ✓ |
+| All 10 read SUBs answer | ✓ | ✓ |
+| `response_SUB = 0xFF − req` | ✓ | ✓ |
+| DLE-aware checksum valid | ✓ | ✓ |
+| Two-step probe/data read | ✓ | ✓ |
+| ID string | `MM/ISEE/S/IO` | `MM/ISEE/S` |
+| **flags byte** | **`0xC5`** | **`0x03`** |
+| **`0x1C` length** | **`0x2C`** | **`0x30`** |
+
+**The firmware line does not change the wire protocol.**  One protocol stack
+can drive the whole fleet regardless of which build a unit is on.  This is the
+single most consequential finding so far: "standardise the fleet on one
+firmware" becomes an *optional* convenience rather than a prerequisite for
+building a call-home receiver.
+
+### The two differences that do exist
+
+**1. The flags byte identifies the build.**  Response `payload[1]` is `0xC5`
+on the Blastware line and `0x03` on the Thor line, constant across all ten
+SUBs on both units.  That makes firmware line detectable from *any* response,
+without reading device info.  ⚠ Two units, one each — treat as a strong
+hypothesis, not a proven encoding.
+
+Note `0x03` is ETX, so on Thor-line units it arrives DLE-escaped as `10 03`.
+A parser that fails to destuff will mis-locate every field by one byte on
+exactly half your fleet.
+
+**2. `SUB 0x1C` (monitor status) is 4 bytes longer on the Thor line** —
+`0x30` vs `0x2C` — with four extra trailing bytes (`0f a0 00 00`, purpose
+unknown).
+
+⚠ **This breaks relative-to-end parsing.**  Series III reads battery and
+memory from the *end* of the `0x1C` block (`[-10:-8]`, `[-8:-4]`, `[-4:]`).
+Those offsets are correct on `11.0CB` and wrong on `11.0BD` — applying them
+blindly to UM20147 yields a battery reading of **577.92 V**.  Parse forward
+from the declared length instead of backward from the end.
+
+With the offsets shifted by 4, UM20147 reads correctly: battery **3.81 V**,
+memory 15,000,000 total and free (no events stored).
+
 ## Divergences from Series III (running list)
 
 1. **No `DLE` prefix on responses** — bare `STX`.
@@ -372,6 +419,8 @@ are DLE-stuffed**, so a parser must destuff before applying field offsets.
 4c. **`1E`/`1F` return the event size**, where Series III returns an offset.
 4d. **`0x0A` vs `0x0C` split by record type**, not by the `0x46`/`0x2C`
     length discriminator Series III uses.
+4e. **Response `payload[1]` (flags) encodes the firmware line** — `0xC5`
+    Blastware, `0x03` Thor — where Series III has a constant `0x10`.
 5. **Modem serial rate is 115200**, not 38400 (per TMI provisioning practice;
    not independently verified here).