Five events on the bench unit (4 waveform + 1 histogram). The Series III
browse walk -- 1E, then 0A/0C per key, then 1F to advance -- works unmodified,
and the null sentinel terminated correctly after exactly 5.
Findings:
- Event keys are a sequential counter (055d4a81..85), NOT flash-buffer
addresses. Series III key arithmetic does not carry over; its 5A chunk walk
assumes addresses and must not be ported blindly.
- The 4 bytes after the key in 1E/1F are the event's SIZE in bytes, where
Series III puts an offset to the next key. 4,076 for the histogram and
8.7-13.4 KB for the waveforms, matching real .IDFH/.IDFW file sizes.
- SUB 0x0C returns a 210-byte (0xD2) waveform record -- the same length as
Series III -- carrying the event key, date/time, the title note "Location",
the PROJECT STRING, the serial, channel labels Tran/Vert/Long/Mic and
float32 peaks.
That last point closes the biggest open question for the call-home receiver:
the job identity strings that today arrive only via Thor's .txt sidecar, and
which no amount of sample decoding can reconstruct, are readable over the
wire. Direct-to-SFM events need not arrive with blank metadata.
- SUB 0x0A returns len 0x1E for the histogram and 0x00 for every waveform. The
histogram payload holds two timestamps plus a "Vert: 0.300 in/s" trigger
string -- structurally the Series III monitor-log partial record. So 0A
describes interval records and 0C describes triggered events; Series III's
0x46-vs-0x2C length discriminator does not apply.
- DLE stuffing in responses is now confirmed (previously marked untested): the
0C timestamp contains 10 10, which destuffs to one 0x10 and yields a clock
reading of 16:33 on 23 Sep 2026 -- matching when the events were recorded.
Read-only throughout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5
73eaa0a6ac