debug(protocol): event-N probe is now at counter = start_offset instead of start_offset + 0x46

CLAUDE.md

@@ -2,7 +2,7 @@
 
 Ground-up Python replacement for **Blastware**, Instantel's Windows-only software for
 managing MiniMate Plus seismographs. Connects over direct RS-232 or cellular modem
-(Sierra Wireless RV50 / RV55). Current version: **v0.13.2**.
+(Sierra Wireless RV50 / RV55). Current version: **v0.14.1**.
 
 When new information about the protocol is discovered, please update the instantel_protocol_reference.md with the findings in addition to this document
 
@@ -160,13 +160,28 @@ firmware reserved area for the first slot in a freshly-erased buffer.  Harmless
 #### Event 2+ case — start_key[2:4] != 0x0000 (continuation events)
 
 ```
-1.  First chunk at counter = start_key[2:4] + 0x0046    (this IS the probe — response
-                                                          contains STRT)
+1.  First chunk at counter = start_key[2:4]              (this IS the probe — response
+                                                          contains STRT at byte 17)
 2.  Sample chunks:                                       counter += 0x0200 each, up to but
                                                           not including end_offset
 3.  TERM frame
 ```
 
+**`start_key` here is the off=0x46 WAVEHDR record key returned by 1F** (e.g. `01112238`),
+NOT the off=0x2C boundary key that immediately precedes it.  An earlier draft of this
+doc described event-N as "probe at start + 0x46" — that formula came from naming the
+boundary key as `start_key`.  In the iteration walk, `cur_key` passed to
+`read_bulk_waveform_stream` is always the off=0x46 key (the partial-record skip path in
+`get_events` re-runs 1F to advance past boundary records before invoking 5A), so the
+probe counter is just `cur_key[2:4]` with no extra offset.  **Adding +0x46 caused the
+probe to overshoot, miss the STRT record at byte 17 of the response, fall back to the
+`max_chunks=128` cap, and walk ~110 chunks of post-event garbage** — observed in
+SFM 5-4-26 capture before the fix.
+
+Confirmed across:
+- 5-1-26 "copy 2nd address" BW capture: probe counter=0x2238, key=01112238, STRT@17 end=0x417E.
+- 5-4-26 BW 2-sec event capture: probe counter=0x2238, key=01112238, TERM offset_word=0x0146 → end=0x417E.
+
 No metadata pages — those have already been read during event 1 in the same Blastware
 session, and BW caches them.  Note that the metadata-page reads happen ONCE per
 Blastware-session-on-the-device, not once per event, so an SFM session that downloads
@@ -180,6 +195,12 @@ several events should read 0x1002/0x1004 only once at the start.
 - 2026-04-26: `max(key4[2:4], 0x0400) + (chunk_num-1) * 0x0400` (broken — over-read past event end).
 - 2026-05-01: Increments are 0x0200 not 0x0400; absolute addresses inside event range; bounded
   by STRT end_key, not by `max_chunks` cap or device-side timeout.
+- 2026-05-04: Removed spurious `+0x0046` from event-N probe counter.  `cur_key` from 1F
+  is already the off=0x46 WAVEHDR key, so adding +0x46 would have placed the probe one
+  WAVEHDR past the actual event start.  This caused probe responses to lack a STRT
+  record (no `end_offset` parsed → `0xFFFF` fallback → `max_chunks=128` cap), walking
+  ~110 chunks of post-event circular-buffer garbage.  Fixed in protocol.py
+  `read_bulk_waveform_stream`.
 
 ### SUB 5A — STRT record encodes end_offset (NEW 2026-05-01)