feat: update event iteration logic to use null sentinel for end-of-events detection
This commit is contained in:
22
CLAUDE.md
22
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.6.0**.
|
||||
(Sierra Wireless RV50 / RV55). Current version: **v0.7.0**.
|
||||
|
||||
---
|
||||
|
||||
@@ -135,6 +135,26 @@ the setup at record time, not the current device config — this is why we fetch
|
||||
`stop_after_metadata=True` (default) stops the 5A loop as soon as `b"Project:"` appears,
|
||||
then sends the termination frame.
|
||||
|
||||
### SUB 1E / 1F — event iteration null sentinel (FIXED, do not re-introduce)
|
||||
|
||||
**The null sentinel for end-of-events is `event_data8[4:8] == b"\x00\x00\x00\x00"`, NOT
|
||||
`key4 == b"\x00\x00\x00\x00"`.**
|
||||
|
||||
Event 0's waveform key is `00000000` — all-zero key4 is a valid event address.
|
||||
Checking `key4 == b"\x00\x00\x00\x00"` exits the loop immediately after the 1E call,
|
||||
seeing event 0's key and incorrectly treating it as "no events."
|
||||
|
||||
Confirmed from the 4-3-26 two-event capture (`bridges/captures/4-3-26-multi_event/`):
|
||||
|
||||
```
|
||||
1E response (event 0): key4=00000000 data8=0000000000011100 ← valid, trailing bytes non-zero
|
||||
1F response (event 1): key4=0000fe00 data8=0000fe0000011100 ← valid
|
||||
1F null sentinel: key4=0000fe00 data8=0000fe0000000000 ← done, trailing 4 bytes = 00
|
||||
```
|
||||
|
||||
`advance_event()` returns `(key4, event_data8)`.
|
||||
Callers (`count_events`, `get_events`) loop while `data8[4:8] != b"\x00\x00\x00\x00"`.
|
||||
|
||||
### SUB 1A — compliance config — orphaned send bug (FIXED, do not re-introduce)
|
||||
|
||||
`read_compliance_config()` sends a 4-frame sequence (A, B, C, D) where:
|
||||
|
||||
Reference in New Issue
Block a user