fix(protocol): update chunk counter formula to use max(key4[2:4], 0x0400) for accurate data streaming

This commit is contained in:
2026-04-26 01:28:47 -04:00
parent 7976b544ed
commit 2f084ed105
3 changed files with 56 additions and 39 deletions
+24 -16
View File
@@ -585,13 +585,12 @@ class MiniMateProtocol:
frames_data: list[S3Frame] = []
counter = 0
# BW counter formula (confirmed from 4-3-26 capture for key 0111245a):
# counter for chunk n = key4[2:4] + (n - 1) * 0x0400
# key4[2:4] is the event's circular-buffer base offset — without it, chunk
# requests address the wrong region of the device buffer and the device
# streams data from the wrong event (no "Project:" in any response).
# PREVIOUSLY WRONG NOTE: "device does not validate counter; chunk_num*0x0400
# is correct" — that was only true for key 01110000 where key4[2:4]==0x0000.
# BW counter formula (confirmed from 4-3-26 capture for key 0111245a,
# and empirical live-device test 2026-04-06 for key 01110000):
# counter for chunk n = max(key4[2:4], 0x0400) + (n - 1) * 0x0400
# key4[2:4] is the event's circular-buffer base offset. The max() guard
# ensures chunk 1 never uses counter=0x0000 (which equals the probe address
# and causes the device to re-return STRT record data for the first chunk).
_key4_offset = (key4[2] << 8) | key4[3]
# ── Step 1: probe ────────────────────────────────────────────────────
@@ -612,15 +611,24 @@ class MiniMateProtocol:
log.debug("5A A5[0] page_key=0x%04X %d bytes", rsp.page_key, len(rsp.data))
# ── Step 2: chunk loop ───────────────────────────────────────────────
# Correct counter formula: key4[2:4] + (chunk_num - 1) * 0x0400
# This matches Blastware exactly (confirmed from 4-3-26 capture).
# For events where key4[2:4]==0 (e.g. 01110000), this gives the same
# result as the old chunk_num*0x0400 formula shifted by one step, which
# the device also accepted — but for events with a non-zero base offset
# (e.g. key 01111884 with key4[2:4]=0x1884) the old formula sends
# completely wrong counters and the device streams the wrong buffer region.
# Counter formula: _chunk_base + (chunk_num - 1) * 0x0400
# where _chunk_base = max(key4[2:4], 0x0400).
#
# For events with key4[2:4] != 0 (e.g. key 0111245a, offset 0x245a):
# _chunk_base = 0x245a → chunk 1=0x245a, chunk 2=0x285a, ...
# Confirmed from 4-3-26 capture.
#
# For events with key4[2:4] == 0 (e.g. key 01110000):
# _chunk_base = max(0, 0x0400) = 0x0400
# → chunk 1=0x0400, chunk 2=0x0800, ... (= old chunk_num*0x0400)
# CRITICAL: counter=0x0000 (same as the probe) causes the device to
# re-return the STRT record data for chunk 1, making frame 1 look like
# a second probe response (confirmed from server log: frame 1 len=1097,
# contains STRT\xff\xfe, contributes zero body bytes after DLE-strip).
# counter=0x0400 for chunk 1 confirmed working (empirical test 2026-04-06).
_chunk_base = max(_key4_offset, _BULK_COUNTER_STEP)
for chunk_num in range(1, max_chunks + 1):
counter = _key4_offset + (chunk_num - 1) * _BULK_COUNTER_STEP
counter = _chunk_base + (chunk_num - 1) * _BULK_COUNTER_STEP
params = bulk_waveform_params(key4, counter)
log.debug("5A chunk %d counter=0x%04X", chunk_num, counter)
self._send(build_5a_frame(_BULK_CHUNK_OFFSET, params))
@@ -675,7 +683,7 @@ class MiniMateProtocol:
chunk_num, extra_chunks_after_metadata)
for _extra_n in range(extra_chunks_after_metadata):
chunk_num += 1
counter = _key4_offset + (chunk_num - 1) * _BULK_COUNTER_STEP
counter = _chunk_base + (chunk_num - 1) * _BULK_COUNTER_STEP
params = bulk_waveform_params(key4, counter)
self._send(build_5a_frame(_BULK_CHUNK_OFFSET, params))
try: