2 Commits

Include renames

Author	SHA1	Message	Date
serversdownandClaude Opus 5	5fe99568a2	feat(micromate): framing layer -- and three spec rules the bytes refuted ... Step 1 of docs/micromate_client_spec.md: micromate/framing.py plus 31 offline tests. Every rule was checked against the captures BEFORE being written, which is the only reason this commit is not a bug. Three things the spec asserted are wrong, all of which fail silently: 1. Requests are NOT plain Series III frames. A Micromate escapes four byte values -- 0x02 0x03 0x04 0x10 -- where Series III escapes one. minimateplus.build_bw_frame reproduces 161 of Thor's 218 captured read frames; build_request() reproduces 218/218. The 57 it missed include EVERY 0x5A download (offset 0x0400 puts a literal 0x04 in offset_hi) and the scheduler enable. An unescaped 0x03/0x04 terminates the frame, so the unit never answers -- indistinguishable from a dead unit, and event download would have hit it on the first request ever sent. 2. The checksum is plain SUM8 of the destuffed payload, not the DLE-aware variant. 251/251 both directions. The DLE-aware form is correct paired with Series III destuffing, which leaves an escaped byte as two bytes; after uniform destuffing it subtracts the correction twice and disagrees with the wire on 55 of 251 responses. scratch/mm_frame_parse.py shipped with exactly that pairing and looked clean only because it accepts either rule -- so it labelled those 55 "SUM8" and never flagged one bad. "Zero bad checksums" was true and carried no information. A tool that tries N candidate rules cannot falsify any of them. Fixed to validate against SUM8 alone. 3. SUB 0x5A is a 1024-byte chunk loop, not one request per event. Thor's form, verified on all six bench events (4,076 -> 13,424 B): chunks = ceil(size/1024), offset = min(1024, size - 1024*i) as a byte count, params[2:4] = the byte offset, response data = offset + 11. sum(offsets) == size exactly, every time. This does not retract the earlier single-request observation -- that used offset_hi = 0x10, which in Series III is the bulk-stream marker, so it is plausibly a distinct streaming mode returning several frames. Those captures never landed in the repo, so it cannot be re-derived. Implement Thor's form; the other is worth one bench test. Also: a 0x10 inside request params needs no special handling (settled -- Thor sends it, the wire doubles it), so the planned NotImplementedError guard is gone. declared_length -> probe_length, because it is only meaningful in a probe reply and Thor never probes. Synthesised test frames are marked and each says what it stands in for. The flags=0x03 case is the only coverage of the Thor firmware line -- it wants a real 11.0BD capture next time UM20147 is on a bench. No writes. Read-path framing only; nothing here can originate a command. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL	2026-09-27 05:24:24 -04:00
serversdownandClaude Opus 5	c8d972f685	docs(series4): the setup-write path, observed end to end ... Thor pushed a setup named TEST1.mmb to UM12947 while seismo_lab's TCP bridge recorded both directions. We still have not originated a write frame -- the wire format is now known, our encoder is not written. Topology worth reusing: socat shares /dev/ttyACM0 on TCP from mint-mac, seismo_lab relays Thor to it. Thor is pointed at 127.0.0.1 as if the unit were a field modem. No modem, no SIM, production Thor box untouched. The sequence is Series III's, plus one command: Thor: 5B | 41 | 08 | 2E | 1A | DA | 68->73 | 82->83 | 71->72 unit: A4 | BE | F7 | D1 | E5 | 25 | 97 8C | 7D 7C | 8E 8D All 12 device responses checksum-validate and every write is acked. Every write response SUB matches the Series III table exactly. New: * SUB 0xDA names the target .MMB file -- 256 bytes, filename null-padded, nothing else. This is why no generic file-transfer command exists: Thor names the file, then writes the ordinary config block into it. * SUB 0x41 reads the active setup's filename; SUB 0x2E reads trigger config. * Reads are single-step -- Thor asks offset=0xFFFF and skips the probe. * 0x71 writes the whole 2090-byte block in ONE frame, not Series III's three chunks. 0x69/0x74 are absent. Write-frame destuffing is `10 XX` -> `XX` uniformly, including `10 03`. Chosen by checksum, not assumption: of four candidate rules, only this one makes all four data-carrying write frames validate. 0x71's data holds 4 literal 0x03 bytes escaped as `10 03`, so escaping is mandatory for any writer. The write body IS the read body -- 0x71 and the 0xE5 response align at a fixed 11-byte shift with 1902/2090 bytes equal (91.0%). Setups are read-modify-write. The 12 differing regions are fully mapped: setup name, four 64-byte [label:22][value:42] note entries, sensor location, and the three geo trigger levels (0.3 -> 0.5 in/s) on a 48-byte channel stride. Independent confirmation of the geo LSB: each channel block carries float32BE 3.10308 at label+24. 3.10308/10000 = 0.000310308 = _GEO_LSB_IPS to 8 figures, and 10.0/3.10308*10000 = 32226.046 = the 32226.05 full scale. That value was derived statistically from 991,415 rounding constraints in v0.30.0; the unit reports it directly. It is exactly half Series III's 6.206053, so the ADC runs 10,000 counts per volt. Do NOT retune _GEO_LSB_IPS -- this corroborates it. The `offset` field is NOT a single length formula: two frames are len, two are len+2, and Series III's data[1]+2 reproduces neither. Recorded as observed constants the device accepted; pinning the rule needs a capture with differently-sized payloads. This doc has been wrong once by inferring a length field -- not inferring this one. Also adds scratch/mm_frame_parse.py, because S3FrameParser cannot see Micromate responses at all (it scans for DLE+STX; Micromate responses start at a bare STX). That is why the first pass at this capture looked like 12 unanswered requests. 24/24 frames parse with 0 bad checksums. Stale claims corrected: the "write half is not yet attempted" note, the "empty unit" limitation (5 events since 2026-09-23), and the unsafe-until-agreed list, which now distinguishes observed from exercised. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL	2026-09-24 18:35:58 -04:00