fix(protocol): remove auto-detection of frame mode and ensure extra chunks are always used for valid waveform footer
This commit is contained in:
@@ -350,14 +350,20 @@ Do NOT use fixed absolute offsets for sample_rate or record_time.
|
|||||||
**SUB 5A (bulk waveform) TCP frame splitting — confirmed 2026-04-27:**
|
**SUB 5A (bulk waveform) TCP frame splitting — confirmed 2026-04-27:**
|
||||||
|
|
||||||
Over TCP via cellular modem, each 5A chunk request that produces a single ~1100-byte
|
Over TCP via cellular modem, each 5A chunk request that produces a single ~1100-byte
|
||||||
A5 response over direct RS-232 arrives as **two separate, complete S3 frames** of
|
A5 response over direct RS-232 may arrive as **two separate, complete S3 frames** of
|
||||||
~550 bytes each. This is because the device sends its RS-232 response as multiple
|
~550 bytes each ("2-frame mode"). The modem's Data Forwarding Timeout (~100-150 ms)
|
||||||
frames, and the modem's Data Forwarding Timeout (~100-150 ms) delivers them to us
|
can split the RS-232 response into two TCP segments, each parsed as a complete S3 frame.
|
||||||
as separate TCP segments, each parsed as a complete S3 frame.
|
Under different modem/timing conditions the full ~1100-byte response arrives as **one
|
||||||
|
S3 frame** ("1-frame mode").
|
||||||
|
|
||||||
|
**Both modes require `extra_chunks_after_metadata=1`** (the extra chunk at metadata_counter
|
||||||
|
+ 0x0400). The device's waveform footer data lives at circular-buffer address 0x1C00 for
|
||||||
|
this event; the terminator frame must be sent at 0x1C00 (not 0x1800) to receive it.
|
||||||
|
|
||||||
Example for a 2-second Continuous event (BE11529, key=01110000) via TCP:
|
Example for a 2-second Continuous event (BE11529, key=01110000) via TCP:
|
||||||
- 1 probe frame (554 B) + 5 chunks × 2 frames (556-573 B) + 1 extra chunk × 2 frames + 1 terminator (208 B) = **14 A5 frames**
|
- **2-frame mode:** 1 probe frame (554 B) + 5 chunks × 2 frames (556-573 B) + 1 extra chunk × 2 frames + 1 terminator (208 B) = **14 A5 frames** → 6864-byte file
|
||||||
- All 14 frames contribute body data; using all of them gives the correct 6864-byte file.
|
- **1-frame mode:** 1 probe frame (~1097 B) + 5 chunks × 1 frame (~1079-1113 B) + 1 extra chunk × 1 frame (smaller, tail of event) + 1 terminator → **8 A5 frames** → 6864-byte file
|
||||||
|
- All frames contribute body data; using all of them gives the correct file.
|
||||||
|
|
||||||
**Fix (confirmed 2026-04-27):** `_recv_5a_batch()` in `protocol.py` collects ALL
|
**Fix (confirmed 2026-04-27):** `_recv_5a_batch()` in `protocol.py` collects ALL
|
||||||
A5 frames per chunk request before the next request is sent, using a 0.5 s batch
|
A5 frames per chunk request before the next request is sent, using a 0.5 s batch
|
||||||
@@ -365,6 +371,12 @@ timeout after the first frame to catch the ~150 ms delayed second frame. `write
|
|||||||
includes ALL body frames without skipping — the extra chunk's frames are part of the
|
includes ALL body frames without skipping — the extra chunk's frames are part of the
|
||||||
body data, NOT padding to be discarded.
|
body data, NOT padding to be discarded.
|
||||||
|
|
||||||
|
**WRONG earlier hypothesis (do not re-introduce):** An attempt was made to auto-detect
|
||||||
|
1-frame vs 2-frame mode from the probe frame size and skip the extra chunk when
|
||||||
|
`probe_data_len >= 700`. This was wrong — the extra chunk is always needed to advance
|
||||||
|
the device's internal state to the footer address. The `_probe_is_large` branch was
|
||||||
|
removed 2026-04-27.
|
||||||
|
|
||||||
### Required ACEmanager settings (Sierra Wireless RV50/RV55)
|
### Required ACEmanager settings (Sierra Wireless RV50/RV55)
|
||||||
|
|
||||||
| Setting | Value | Why |
|
| Setting | Value | Why |
|
||||||
|
|||||||
@@ -614,31 +614,14 @@ class MiniMateProtocol:
|
|||||||
[f"0x{f.page_key:04X}" for f in probe_batch],
|
[f"0x{f.page_key:04X}" for f in probe_batch],
|
||||||
)
|
)
|
||||||
|
|
||||||
# Auto-detect frame mode from probe response size.
|
# Log probe frame size for diagnostics.
|
||||||
#
|
# The device always needs extra_chunks_after_metadata chunks after the
|
||||||
# Two observed TCP modes (confirmed from 4-26-26 and 4-27-26 captures):
|
# metadata frame before termination to prime the valid waveform footer.
|
||||||
#
|
# This holds regardless of TCP frame size (1-frame vs 2-frame mode).
|
||||||
# 1-frame mode (RS-232 / fast TCP): probe returns 1 large frame (~1100 B).
|
_effective_extra_chunks = extra_chunks_after_metadata
|
||||||
# Each subsequent chunk also returns 1 large frame. The probe contributes
|
|
||||||
# ~999 bytes of ADC body data. The correct term_counter = metadata_counter
|
|
||||||
# + 0x0400, which returns ~702 bytes of tail+footer — NO extra chunk needed.
|
|
||||||
#
|
|
||||||
# 2-frame mode (TCP frame-splitting): probe returns 1 smaller frame (~554 B).
|
|
||||||
# Each subsequent chunk returns 2 smaller frames (~550 B each). The probe
|
|
||||||
# contributes only ~487 bytes. The missing ~512 bytes of body data must come
|
|
||||||
# from an extra chunk after metadata, terminating at metadata_counter+0x0800.
|
|
||||||
# The caller's extra_chunks_after_metadata value (default 1) covers this.
|
|
||||||
#
|
|
||||||
# Threshold 700 B sits comfortably between the two observed probe sizes (554 vs
|
|
||||||
# 1097 bytes) and is robust to minor variation.
|
|
||||||
_probe_is_large = (
|
|
||||||
len(probe_batch) == 1 and len(probe_batch[0].data) >= 700
|
|
||||||
)
|
|
||||||
_effective_extra_chunks = 0 if _probe_is_large else extra_chunks_after_metadata
|
|
||||||
log.warning(
|
log.warning(
|
||||||
"5A probe data_len=%d _probe_is_large=%s effective_extra_chunks=%d",
|
"5A probe data_len=%d effective_extra_chunks=%d",
|
||||||
len(probe_batch[0].data),
|
len(probe_batch[0].data),
|
||||||
_probe_is_large,
|
|
||||||
_effective_extra_chunks,
|
_effective_extra_chunks,
|
||||||
)
|
)
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user