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
serversdownandClaude Opus 5
38ad58d4a4