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

minimateplus/client.py

@@ -301,6 +301,19 @@ class MiniMateClient:
                 proceed = False
 
             if proceed:
+                # SUB 1E (download-arm) — MUST be sent between 0A and 0C.
+                # The device ignores 5A probe frames unless this second 1E with
+                # token=0xFE has been issued first.  Confirmed from both 4-2-26
+                # and 4-3-26 BW TX captures (2026-04-06).
+                # The returned key is the same event key we already hold — ignore it.
+                try:
+                    proto.read_event_first(token=0xFE)
+                except ProtocolError as exc:
+                    log.warning(
+                        "get_events: 1E download-arm failed for key=%s: %s",
+                        key4.hex(), exc,
+                    )
+
                 # SUB 0C — full waveform record (peak values, timestamp, "Project:" string)
                 try:
                     record = proto.read_waveform_record(key4)
@@ -317,8 +330,6 @@ class MiniMateClient:
                 # is found — fetches only ~8 frames for event-time metadata.
                 # When full_waveform=True: fetch the complete stream (stop_after_metadata=False,
                 # max_chunks=128) and decode raw ADC samples into ev.raw_samples.
-                # The full waveform MUST be fetched here, inside the 1E→0A→0C→5A→1F loop.
-                # Issuing 5A after 1F has advanced the event context will time out.
                 try:
                     if full_waveform:
                         log.info(
@@ -364,11 +375,10 @@ class MiniMateClient:
                 )
 
             # SUB 1F — advance to the next record key.
-            # Uses browse mode (all-zero params) — empirically confirmed to work on
-            # this device.  token=0xFE (download mode) returns null regardless of
-            # context, even after 0A+0C+5A.  The 3-31-26 capture only had one event
-            # so we never saw 1F actually return a second key in download mode;
-            # the token=0xFE assumption was never validated for multi-event iteration.
+            # Uses browse mode (all-zero params) — empirically confirmed to work
+            # with 2+ events stored (4-3-26 browse-mode capture).  BW itself uses
+            # token=0xFE here in download mode, but browse mode is simpler and
+            # avoids complications with the download-arm state machine.
             try:
                 key4, data8 = proto.advance_event(browse=True)
                 log.info(