fix: update event handling in MiniMateClient and protocol to address 5A timeout issue

This commit is contained in:
2026-04-06 12:41:27 -04:00
parent 57e7225a62
commit d87e02fab2
3 changed files with 55 additions and 18 deletions
+24 -3
View File
@@ -178,16 +178,37 @@ echo) — in both cases, all zeros means "no more events."
there is only one event.
**Correct iteration pattern (confirmed empirically with live device, 2+ events):**
`count_events` (browse mode only, no 5A):
```
1E(all zeros) → key0, trailing0 ← trailing0 non-zero if event 1 exists
0A(key0) ← REQUIRED: establishes device context
0C(key0) [+ 5A(key0) for get_events] ← read record data
1F(all zeros / browse=True) → key1 ← use all-zero params, NOT token=0xFE
1F(all zeros / browse=True) → key1 ← use all-zero params
0A(key1) ← REQUIRED before each advance
0C(key1) [+ 5A(key1) for get_events]
1F(all zeros) → null ← done
```
`get_events` (download mode, with 5A):
```
1E(all zeros) → key0, trailing0 ← trailing0 non-zero if event 1 exists
0A(key0) ← REQUIRED: establishes device context
1E(token=0xFE) ← REQUIRED: arms device for 5A; CONFIRMED 4-2-26 + 4-3-26
0C(key0) ← read waveform record
5A(key0) ← bulk stream (metadata or full waveform)
1F(all zeros / browse=True) → key1
0A(key1)
1E(token=0xFE) ← re-arm for next event's 5A
0C(key1)
5A(key1)
1F(all zeros) → null ← done
```
**The 1E(token=0xFE) arm step is the root cause of the 5A timeout (FIXED 2026-04-06):**
The device silently ignores all 5A probe frames unless a second SUB 1E with token=0xFE
has been issued between 0A and 0C. This step is present in EVERY download cycle in both
the 4-2-26 and 4-3-26 BW TX captures. Without it, `read_bulk_waveform_stream()` blocks
for the full 120 s timeout.
`advance_event(browse=True)` sends all-zero params; `advance_event()` default (browse=False)
sends token=0xFE and is NOT used by any caller.
`advance_event()` returns `(key4, event_data8)`.