Compare commits
66 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| a18712442f | |||
| 8aea46b8a0 | |||
| 9123269b1f | |||
| 9400f59167 | |||
| bbed85f7e2 | |||
| c641d5fc10 | |||
| 9afa3484f4 | |||
| 0484680c89 | |||
| 3711b11bda | |||
| 52c6e7b618 | |||
| 29ebc75656 | |||
| ebfe9877fa | |||
| c914a15e12 | |||
| a27693242d | |||
| eefec0bd64 | |||
| 7444738883 | |||
| 6b76934a04 | |||
| 7b62c790a9 | |||
| b66cc9d075 | |||
| 4ab604eff1 | |||
| e15f1567ef | |||
| bb33ad3837 | |||
| 45e61fbcaf | |||
| d758825c67 | |||
| 0fbb39c21a | |||
| 1ef55521b1 | |||
| 738b39f3cb | |||
| 625b0a4dfc | |||
| b14f31f3b0 | |||
| b9ab368934 | |||
| 9004241846 | |||
| 6861d9ed97 | |||
| 5cd5652560 | |||
| 897ac8a3f3 | |||
| 310fc5986c | |||
| e1150b30aa | |||
| a7585cb5e0 | |||
| 9bbecea70f | |||
| ae30a02898 | |||
| 2f084ed105 | |||
| 7976b544ed | |||
| 0415af19b4 | |||
| 35c3f4f945 | |||
| 43c8158493 | |||
| 242666f358 | |||
| 03540fdc00 | |||
| f83fd880c0 | |||
| ab2c11e9a9 | |||
| fa887b85d9 | |||
| ecd980d345 | |||
| bc9f16e503 | |||
| aa2b02535b | |||
| 2a2031c3a9 | |||
| 9e7e0bce2a | |||
| 5e2f3bf2a1 | |||
| 39ebd4bdaa | |||
| 84c87d0b57 | |||
| ec6362cb8e | |||
| 3eeafd24aa | |||
| 8cb8b86192 | |||
| 6dcca4da79 | |||
| c47e3a3af0 | |||
| dfbc9f29c5 | |||
| 4331215e23 | |||
| b3dcfe7239 | |||
| 9b5cdfd857 |
+388
@@ -4,6 +4,394 @@ All notable changes to seismo-relay are documented here.
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## v0.15.0 — 2026-05-07
|
||||||
|
|
||||||
|
### Added
|
||||||
|
|
||||||
|
- **Layered event storage architecture.** Each event now lands as four
|
||||||
|
files in the per-serial waveform store, each with a clear role:
|
||||||
|
|
||||||
|
- `<filename>` — the Blastware-readable binary (BW file). Untouched.
|
||||||
|
- `<filename>.a5.pkl` — the raw 5A frames (regenerative source).
|
||||||
|
- `<filename>.h5` — clean per-channel waveform arrays in physical
|
||||||
|
units (in/s for geo, psi for mic) plus event metadata (HDF5 with
|
||||||
|
gzip compression). This is the canonical format for downstream
|
||||||
|
analysis tools.
|
||||||
|
- `<filename>.sfm.json` — the modern review/metadata sidecar (peaks,
|
||||||
|
project, source provenance, review state, extensions).
|
||||||
|
|
||||||
|
SQLite (`seismo_relay.db`) is the searchable index over all four.
|
||||||
|
|
||||||
|
- **Plot-ready waveform JSON (`sfm.plot.v1`).** The `/device/event/{idx}/waveform`
|
||||||
|
and `/db/events/{id}/waveform.json` endpoints now return samples in
|
||||||
|
physical units with explicit time-axis metadata, peak markers, and
|
||||||
|
per-channel unit hints — no more guessing the ADC-to-velocity scale
|
||||||
|
client-side. The webapp waveform viewer was rewritten to consume
|
||||||
|
this shape.
|
||||||
|
|
||||||
|
- **In-app waveform viewer accuracy fix.** The standalone SFM webapp
|
||||||
|
viewer was scaling geophone amplitudes by `geoAdcScale / 32767`
|
||||||
|
(≈ 6.206 / 32767), where `geoAdcScale = 6.206053` is the device's
|
||||||
|
*in/s per V* hardware constant — not the ADC-counts-to-velocity
|
||||||
|
factor. This silently scaled every plot ~38% too low for Normal-range
|
||||||
|
geophones (the correct full-scale is 10.0 in/s, or 1.25 in/s for
|
||||||
|
Sensitive). Conversion is now done server-side using the geo_range
|
||||||
|
from compliance config; the client just plots.
|
||||||
|
|
||||||
|
- New `sfm/event_hdf5.py` module: `write_event_hdf5()`,
|
||||||
|
`read_event_hdf5()`, plus a plot-JSON helper.
|
||||||
|
- Backfill script extended to also emit `.h5` for existing events.
|
||||||
|
|
||||||
|
### Dependencies
|
||||||
|
|
||||||
|
- Added `h5py>=3.10` and `numpy>=1.24` for the HDF5 storage layer.
|
||||||
|
- Added `python-multipart>=0.0.7` (required by FastAPI for the
|
||||||
|
`/db/import/blastware_file` endpoint introduced in this release).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v0.14.3 — 2026-05-05
|
||||||
|
|
||||||
|
### Fixed
|
||||||
|
|
||||||
|
- **`build_5a_frame` — DLE-stuffing rule for 0x10 bytes in params (the
|
||||||
|
long-standing >1-sec event 0 "won't open in BW" bug).**
|
||||||
|
|
||||||
|
Previously `build_5a_frame` wrote params bytes RAW with no DLE stuffing,
|
||||||
|
based on the incorrect assumption that the device handled all `0x10`
|
||||||
|
bytes in params literally. It does not. The device's actual de-stuffing
|
||||||
|
rule for the params region is:
|
||||||
|
|
||||||
|
- `10 10` → de-stuffs to `10`
|
||||||
|
- `10 02/03/04` → kept literal (inner-frame markers)
|
||||||
|
- `10 X` for other X → de-stuffs to just `X` (drops the `0x10`)
|
||||||
|
|
||||||
|
When the counter passed in params has `0x10` in the high byte (e.g.
|
||||||
|
counter=`0x1000` produces params bytes `... 10 00 ...`), the device
|
||||||
|
silently corrupts the request to counter=`0x__00` and responds with
|
||||||
|
whatever lives at that wrong address. For counter=0x1000 the wrong
|
||||||
|
address was 0x0000, so the response was a copy of the file header +
|
||||||
|
STRT record. That STRT block then got embedded in the assembled body
|
||||||
|
at file offset `0x1016`, and Blastware refused to open the file
|
||||||
|
(interprets the second STRT as a malformed multi-event file).
|
||||||
|
|
||||||
|
This explains the entire >1-sec event-0 failure pattern:
|
||||||
|
|
||||||
|
- 1-sec events have `end_offset < 0x1000`, so the chunk walk never
|
||||||
|
requests counter `0x10__` and the bug never triggers.
|
||||||
|
- 2-sec / 3-sec / longer events all need a chunk at counter `0x1000`
|
||||||
|
(and longer events also need `0x1200`, `0x1400`, etc., none of which
|
||||||
|
have `0x10` in the high byte except `0x1000`). Just one corrupted
|
||||||
|
response is enough to embed STRT in the body and break the file.
|
||||||
|
|
||||||
|
Verified against BW 5-1-26 "copy 3sec" capture: all 17 5A request
|
||||||
|
frames (probe + 2 metadata pages + 13 sample chunks + TERM) now match
|
||||||
|
BW's wire output **byte-for-byte**, including the doubled `10 10 00`
|
||||||
|
for counter=0x1000.
|
||||||
|
|
||||||
|
### Notes
|
||||||
|
|
||||||
|
- `0x10` bytes in `offset_hi` (the standalone offset field at body[5])
|
||||||
|
are still written RAW — confirmed correct per the 1-2-26 capture.
|
||||||
|
- BW's actual encoding of `10 02` / `10 04` for meta pages 0x1002 /
|
||||||
|
0x1004 is *not* doubled — it relies on the device keeping `10 02`
|
||||||
|
and `10 04` as literal pairs. This is preserved by the fix.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v0.14.2 — 2026-05-04
|
||||||
|
|
||||||
|
### Fixed
|
||||||
|
|
||||||
|
- **`blastware_file.py` — removed harmful "duplicate header+STRT" strip.**
|
||||||
|
The v0.13.x strip logic was matching the byte sequence `00 12 03 00 STRT`
|
||||||
|
in legitimate waveform data — sample chunks at counter `0x1000` and
|
||||||
|
beyond often contain those bytes coincidentally — and zeroing 25 bytes
|
||||||
|
of valid samples per match. This is why event 0 (event-1 case in the
|
||||||
|
protocol) downloads of >1-sec recordings always failed in BW: the strip
|
||||||
|
destroyed real data at body offset `0x1012..0x102B` and propagated
|
||||||
|
alignment differences through the rest of the body. Sub-1-sec events
|
||||||
|
worked because their `end_offset` was below `0x1002`, so no sample
|
||||||
|
chunks landed in the metadata-page region and the strip's needle never
|
||||||
|
matched. Verified fix by re-feeding the BW 5-1-26 "copy 3sec" capture's
|
||||||
|
A5 frames into the file builder: output is now byte-identical to BW's
|
||||||
|
saved `M529LKIQ.G10` reference (8708 bytes, 0 differences).
|
||||||
|
- BW already concatenates frame contributions in stream order without
|
||||||
|
any de-duplication; SFM now does the same.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v0.14.0 — 2026-05-02
|
||||||
|
|
||||||
|
### Changed (major rewrite)
|
||||||
|
|
||||||
|
- **`read_bulk_waveform_stream` — STRT-bounded chunk walk.** Replaces the
|
||||||
|
earlier `0x0400`-step / `max(key4[2:4], 0x0400)` chunk-counter formula,
|
||||||
|
which over-read ~5× past the actual event end into post-event circular-
|
||||||
|
buffer garbage. The new walk:
|
||||||
|
|
||||||
|
1. Probe at `counter = start_offset` (event 1: `0x0000`; event N:
|
||||||
|
`cur_key[2:4]`).
|
||||||
|
2. Parse `end_offset` from the STRT record at `data[17]` of the probe
|
||||||
|
response (`end_key[2:4]` field).
|
||||||
|
3. For event 1 only, read the two fixed metadata pages at counter
|
||||||
|
`0x1002` and `0x1004` — these contain the global session-start
|
||||||
|
compliance setup (Project / Client / User Name / Seis Loc /
|
||||||
|
Extended Notes ASCII strings). Continuation events skip these
|
||||||
|
(BW caches them across the session).
|
||||||
|
4. Walk sample chunks at **`0x0200` increments (NOT `0x0400`)**, bounded
|
||||||
|
by `end_offset` — the loop exits when
|
||||||
|
`next_chunk_counter + 0x0200 > end_offset`.
|
||||||
|
5. Send the proper TERM frame (see new `bulk_waveform_term_v2()`) with
|
||||||
|
`offset_word = end_offset - next_boundary` and
|
||||||
|
`params[2:4] = next_boundary BE`. The TERM response carries the
|
||||||
|
partial last chunk + 26-byte file footer.
|
||||||
|
|
||||||
|
- **New helpers:** `bulk_waveform_term_v2(key4, end_offset, last_chunk_counter)`
|
||||||
|
and `parse_strt_end_offset(a5_data)` in `minimateplus.framing`.
|
||||||
|
|
||||||
|
- **`stop_after_metadata` / `extra_chunks_after_metadata` kwargs are now
|
||||||
|
no-ops** under the v0.14.x walk. They are retained on the
|
||||||
|
`read_bulk_waveform_stream` signature for backward compatibility but log a
|
||||||
|
DEBUG line when set. The old "scan for `b'Project:'` and stop one chunk
|
||||||
|
later" workaround is obsolete — the loop is deterministically bounded by
|
||||||
|
the STRT-derived `end_offset`.
|
||||||
|
|
||||||
|
- **Project / Client / User Name / Seis Loc string source corrected.**
|
||||||
|
These come from the dedicated metadata pages at counter `0x1002` /
|
||||||
|
`0x1004`, not from "A5 frame 7" of the sample-chunk stream. The
|
||||||
|
earlier "A5 frame 7" claim was an artifact of the broken `0x0400`-step
|
||||||
|
walk where the bad counter formula coincidentally landed sample-chunk
|
||||||
|
fi=7 on top of the 0x1002 metadata page.
|
||||||
|
|
||||||
|
### Verified
|
||||||
|
|
||||||
|
- Three independent BW MITM captures (4-27-26 + 5-1-26 + 5-4-26) confirm
|
||||||
|
the new walk matches BW's behaviour event-for-event.
|
||||||
|
- `end_offset` values verified across 3 events: `0x1ABE` (4-27-26 2-sec),
|
||||||
|
`0x21F2` (5-1-26 3-sec), `0x417E` (5-1-26 event-2).
|
||||||
|
|
||||||
|
### Notes
|
||||||
|
|
||||||
|
- Earlier v0.13.0 / v0.13.1 / v0.13.2 entries describe partial steps along
|
||||||
|
the way (some of the file builder fixes, filename bugs, etc.) that were
|
||||||
|
superseded by the full rewrite. Treat this v0.14.0 entry as the
|
||||||
|
definitive landing point for the corrected SUB 5A protocol.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v0.14.1 — 2026-05-04
|
||||||
|
|
||||||
|
### Fixed
|
||||||
|
|
||||||
|
- **`read_bulk_waveform_stream` — event-N probe counter off-by-`0x46`.**
|
||||||
|
Continuation events (start_key[2:4] != 0) were being probed at counter
|
||||||
|
`start_offset + 0x0046` instead of just `start_offset`. In the iteration
|
||||||
|
walk, `cur_key` from 1F is already the off=0x46 WAVEHDR record key, so the
|
||||||
|
earlier formula effectively double-counted the WAVEHDR offset. The probe
|
||||||
|
landed one WAVEHDR past the actual event start, the response no longer
|
||||||
|
contained the STRT record at byte 17, `parse_strt_end_offset` returned
|
||||||
|
`None`, and the chunk loop fell back to the `max_chunks=128` cap — walking
|
||||||
|
~110 chunks of post-event circular-buffer garbage. Verified against the
|
||||||
|
5-1-26 "copy 2nd address" and 5-4-26 BW 2-sec event captures: BW probes
|
||||||
|
counter=`0x2238` with key=`01112238` and STRT is present at byte 17 of
|
||||||
|
the response (end_offset=`0x417E`).
|
||||||
|
- **CLAUDE.md / docs/instantel_protocol_reference.md** — corrected the
|
||||||
|
event-N section to clarify that `start_key` in those formulas is the
|
||||||
|
off=0x46 key, not the off=0x2C boundary key, and removed the spurious
|
||||||
|
`+0x46` from the chunk-walk pseudocode.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v0.13.2 — 2026-05-01
|
||||||
|
|
||||||
|
### Fixed
|
||||||
|
|
||||||
|
- **`_extract_record_type` — third 0C-record header format ("short", 8 bytes).**
|
||||||
|
A live SFM download against BE11529 produced files named `M5290000.000`
|
||||||
|
(zero-stamped) because the 0C waveform record's first bytes were
|
||||||
|
`01 05 07 ea ...` — neither the 9-byte single-shot layout (`0x10` at byte 1)
|
||||||
|
nor the 10-byte continuous layout (`0x10` at bytes 0 and 2). Investigation
|
||||||
|
showed this is a third format observed in the wild: an 8-byte header with no
|
||||||
|
marker bytes at all (`[day][month][year_BE:2][unknown][hour][min][sec]`).
|
||||||
|
The detection logic now scans the year (uint16 BE) at byte 2 / byte 3 / byte
|
||||||
|
4 and picks whichever offset returns a sensible year (2015–2050) — each
|
||||||
|
format has the year at a unique position so this disambiguates cleanly.
|
||||||
|
- New format → `event.record_type = "Waveform (Short)"`,
|
||||||
|
`Timestamp.from_short_record()`.
|
||||||
|
- Existing single-shot and continuous parsers unchanged.
|
||||||
|
- The user's event from May 1, 2026 13:21:37 now correctly resolves to a
|
||||||
|
filename like `M529LKIQ.G10` instead of `M5290000.000`.
|
||||||
|
|
||||||
|
### Added
|
||||||
|
|
||||||
|
- `Timestamp.from_short_record(data)` — decodes the 8-byte header.
|
||||||
|
- `_detect_record_format(data)` — internal helper returning
|
||||||
|
`"single_shot" / "continuous" / "short" / None` via year-position scan.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v0.13.1 — 2026-05-01
|
||||||
|
|
||||||
|
### Fixed
|
||||||
|
|
||||||
|
- **`_extract_record_type` — Continuous-mode record headers misclassified as Unknown.**
|
||||||
|
In single-shot mode the 0C waveform record's 9-byte header puts the sub_code
|
||||||
|
marker `0x10` at byte 1, with the day at byte 0. In Continuous mode the
|
||||||
|
header is 10 bytes with the marker at byte 0 *and* byte 2, and the day at
|
||||||
|
byte 1. Previous logic only inspected byte 1 and treated any value other
|
||||||
|
than `0x10` / `0x03` as `"Unknown"`, which prevented `event.timestamp` from
|
||||||
|
being populated for any continuous-mode event whose day-of-month wasn't
|
||||||
|
exactly 3 or 16. As a downstream effect, `blastware_filename()` saw
|
||||||
|
`event.timestamp == None`, fell back to `stem="0000"` / `ab="00"`, and
|
||||||
|
produced filenames like `M5290000.000`. Discovered from a live SFM run on
|
||||||
|
BE11529 in continuous mode (day-of-month = 5).
|
||||||
|
Now disambiguates by checking BOTH byte 0 and byte 2: if both are `0x10`,
|
||||||
|
it's the 10-byte continuous header; else if byte 1 is `0x10`, it's the
|
||||||
|
9-byte single-shot header. Day-of-month no longer matters.
|
||||||
|
|
||||||
|
*Superseded by v0.13.2 — the user's actual record uses a third 8-byte format
|
||||||
|
with no `0x10` markers, which v0.13.1 still misclassified.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v0.13.0 — 2026-05-01
|
||||||
|
|
||||||
|
### Fixed
|
||||||
|
|
||||||
|
- **SUB 5A bulk waveform stream — over-read bug for events ≥ 2 sec.**
|
||||||
|
`read_bulk_waveform_stream` was walking the chunk counter past the actual
|
||||||
|
end of the event, picking up post-event circular-buffer garbage that
|
||||||
|
corrupted reconstructed Blastware files for any waveform > ~1 sec. The
|
||||||
|
loop now extracts the event's `end_offset` from the STRT record at
|
||||||
|
`data[23:27]` of the probe response and stops the chunk walk when the next
|
||||||
|
counter would step past it. Verified against three BW MITM captures
|
||||||
|
(4-27-26 + 5-1-26): 2-sec event drops from 37 over-read chunks to 7
|
||||||
|
bounded chunks; 3-sec drops to 9; non-zero-start "event 2" drops to 9.
|
||||||
|
|
||||||
|
### Added
|
||||||
|
|
||||||
|
- `framing.bulk_waveform_term_v2(key4, end_offset, last_chunk_counter)` —
|
||||||
|
computes the corrected SUB 5A TERM frame's `(offset_word, params)` per the
|
||||||
|
formula confirmed across all 3 BW captures. Not yet wired into
|
||||||
|
`read_bulk_waveform_stream` (the legacy TERM is still used to preserve the
|
||||||
|
existing `blastware_file.write_blastware_file` frame-structure expectations);
|
||||||
|
available for the next iteration that switches to BW's 0x0200 chunk step.
|
||||||
|
- `framing.parse_strt_end_offset(a5_data)` — extracts the event-end pointer
|
||||||
|
from the STRT record in an A5 response payload.
|
||||||
|
|
||||||
|
### Documentation
|
||||||
|
|
||||||
|
- **CLAUDE.md and `docs/instantel_protocol_reference.md` extensively
|
||||||
|
rewritten** to reflect the corrected SUB 5A protocol. See:
|
||||||
|
- CLAUDE.md "SUB 5A — chunk counter formula (REWRITTEN 2026-05-01)"
|
||||||
|
- CLAUDE.md "SUB 5A — STRT record encodes end_offset"
|
||||||
|
- CLAUDE.md "SUB 5A — TERM frame formula"
|
||||||
|
- CLAUDE.md "SUB 5A — fixed metadata pages 0x1002 and 0x1004"
|
||||||
|
- CLAUDE.md "SUB 0A — WAVEHDR response length distinguishes events from
|
||||||
|
boundaries" (0x46 = real event, 0x2C = boundary marker)
|
||||||
|
- protocol reference §7.8.5 / §7.8.6 / §7.8.7 / §7.8.8
|
||||||
|
- The previous chunk-counter formula (`max(key4[2:4], 0x0400) + (chunk-1) *
|
||||||
|
0x0400`) is now marked DEPRECATED and explicitly tagged WRONG with
|
||||||
|
pointers to the new sections, so future work doesn't re-derive it.
|
||||||
|
|
||||||
|
### Known minor diffs vs Blastware (deferred to a follow-up)
|
||||||
|
|
||||||
|
- We still use the OLD 0x0400 chunk step rather than BW's 0x0200; switching
|
||||||
|
also requires updating `blastware_file.write_blastware_file`'s skip values
|
||||||
|
and "extra chunk after metadata" logic, which depends on a fresh capture
|
||||||
|
to verify.
|
||||||
|
- We still use the legacy fixed `offset_word=0x005A` TERM frame rather than
|
||||||
|
BW's `end_offset - next_boundary` formula, for the same reason.
|
||||||
|
- Two fixed metadata pages at counter `0x1002` and `0x1004` are not yet
|
||||||
|
read explicitly; under the current 0x0400 walk their content is reachable
|
||||||
|
via the sample chunk that covers buffer addresses `[0x1000, 0x1400)`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v0.12.6 — 2026-05-01
|
||||||
|
|
||||||
|
### Fixed
|
||||||
|
|
||||||
|
- **`blastware_file.py` — waveform frame classification** — A5 frame classification for
|
||||||
|
waveform-only vs header-only frames now uses `frame.record_type` instead of frame index.
|
||||||
|
Only waveform frames (0x46) are written to the file body; metadata frames are skipped.
|
||||||
|
Fixes spurious data corruption from incorrectly classified frames.
|
||||||
|
|
||||||
|
- **`s3_analyzer.py` — A5/5A frame naming** — Bulk waveform stream frames (SUB 5A response)
|
||||||
|
are now correctly labeled "A5" in analyzer output instead of being conflated with other
|
||||||
|
multi-frame responses (SUB A4, E5, etc.).
|
||||||
|
|
||||||
|
- **`S3FrameParser` — frame terminator detection** — Corrected the bare ETX terminator
|
||||||
|
detection. Frame termination is now correctly identified by a standalone `ETX=0x03` byte,
|
||||||
|
not by the `DLE+ETX` sequence (which is part of the payload when it appears within a frame).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v0.12.5 — 2026-04-21
|
||||||
|
|
||||||
|
### Added
|
||||||
|
|
||||||
|
- **`seismo_lab.py` — Download tab** — New fourth tab for live wire-byte capture during event
|
||||||
|
downloads. Captures both BW→device and device→S3 frames in real time, allowing inspection
|
||||||
|
of the 5A bulk stream chunk sequence and frame-by-frame analysis without needing a bridge
|
||||||
|
or MITM proxy. Files are saved with user-specified labels for easy tracking.
|
||||||
|
|
||||||
|
### Changed
|
||||||
|
|
||||||
|
- **`s3_bridge.py` — raw captures always-on by default** — `--raw-bw` and `--raw-s3` now
|
||||||
|
default to `"auto"` instead of `None`. Every bridge session automatically generates
|
||||||
|
timestamped `raw_bw_<ts>.bin` and `raw_s3_<ts>.bin` files alongside the `.bin`/`.log`
|
||||||
|
session files. Pass `--raw-bw ""` (explicit empty string) to disable if needed.
|
||||||
|
|
||||||
|
- **`gui_bridge.py` — raw capture checkboxes pre-checked** — Both "BW→S3 raw" and
|
||||||
|
"S3→BW raw" checkboxes start checked. Path fields are empty by default (bridge auto-names
|
||||||
|
the files). Unchecking a box passes `--raw-bw ""` to explicitly disable capture.
|
||||||
|
|
||||||
|
- **`Bridge tab` — TCP mode added** — Serial/TCP radio toggle allows connection via cellular
|
||||||
|
modem (RV50/RV55) instead of direct RS-232. Supports multi-capture design (simultaneous
|
||||||
|
Bridge + Analyzer + Download sessions).
|
||||||
|
|
||||||
|
- **`ach_server.py` — TX capture added (`raw_tx_<ts>.bin`)** — Every ACH inbound session
|
||||||
|
now saves both directions: `raw_rx_<ts>.bin` (device → us, S3 side, as before) and
|
||||||
|
`raw_tx_<ts>.bin` (us → device, BW side). Both files are usable in the Analyzer.
|
||||||
|
TX bytes are buffered in memory until startup handshake succeeds (same as RX), preventing
|
||||||
|
scanner probes from creating empty files.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v0.12.4 — 2026-04-21 (protocol analysis / docs only — no code changes)
|
||||||
|
|
||||||
|
### Discovered
|
||||||
|
|
||||||
|
- **compliance_raw is wire-encoded, not logical bytes** — `read_compliance_config()` returns
|
||||||
|
bytes that include DLE prefix bytes (`0x10`) before any `0x03` values (because S3FrameParser
|
||||||
|
preserves DLE+ETX inner-frame pairs as two literal bytes). The previous CLAUDE.md claim that
|
||||||
|
"S3FrameParser handles this transparently so compliance_raw contains logical bytes" was wrong.
|
||||||
|
|
||||||
|
- **anchor-9 behavior per recording mode** (confirmed from 4-20-26 BW write captures):
|
||||||
|
- Single Shot (0x00) / Continuous (0x01): anchor-9 = `0x00`
|
||||||
|
- Histogram (0x03): anchor-9 = `0x10` — the E5 DLE prefix for the `0x03` recording_mode byte
|
||||||
|
- Histogram+Continuous (0x04): anchor-9 = `0x10` — an actual stored config byte for this mode
|
||||||
|
Anchor position shifts by ±1 when recording_mode = `0x03` due to the extra DLE byte; the
|
||||||
|
dynamic anchor search (`buf.find(ANCHOR, 0, 150)`) handles this correctly without code changes.
|
||||||
|
|
||||||
|
- **Write frame ETX escaping** — BW escapes `0x03` bytes in write frame data as `0x10 0x03`
|
||||||
|
on the wire. Our `build_bw_write_frame` sends data bytes raw without ETX escaping. Device
|
||||||
|
accepts our raw writes for all tested modes. Hypothesis: device write parser uses the
|
||||||
|
offset/length field for frame boundaries, not ETX scanning, making ETX escaping optional.
|
||||||
|
Histogram mode (recording_mode = 0x03) write via SFM from a non-Histogram starting state
|
||||||
|
not yet tested.
|
||||||
|
|
||||||
|
- **BW write payload vs E5 read payload are byte-identical** around the anchor region (confirmed
|
||||||
|
by comparing 3-11-26 BW TX and S3 captures). BW does NOT strip DLE prefix bytes before writing;
|
||||||
|
it round-trips the wire-encoded bytes verbatim with only the modified fields changed.
|
||||||
|
|
||||||
|
- **Capture folder content catalogued** — see CLAUDE.md "BW capture reference" table for a
|
||||||
|
summary of all available protocol captures and their contents.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## v0.12.3 — 2026-04-20
|
## v0.12.3 — 2026-04-20
|
||||||
|
|
||||||
### Added
|
### Added
|
||||||
|
|||||||
@@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
Ground-up Python replacement for **Blastware**, Instantel's Windows-only software for
|
Ground-up Python replacement for **Blastware**, Instantel's Windows-only software for
|
||||||
managing MiniMate Plus seismographs. Connects over direct RS-232 or cellular modem
|
managing MiniMate Plus seismographs. Connects over direct RS-232 or cellular modem
|
||||||
(Sierra Wireless RV50 / RV55). Current version: **v0.12.3**.
|
(Sierra Wireless RV50 / RV55). Current version: **v0.14.3**.
|
||||||
|
|
||||||
When new information about the protocol is discovered, please update the instantel_protocol_reference.md with the findings in addition to this document
|
When new information about the protocol is discovered, please update the instantel_protocol_reference.md with the findings in addition to this document
|
||||||
|
|
||||||
@@ -27,7 +27,7 @@ CHANGELOG.md ← version history
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Current implementation state (v0.12.3)
|
## Current implementation state (v0.14.3)
|
||||||
|
|
||||||
Full read pipeline + write pipeline + erase pipeline + monitor log + call home config working end-to-end over TCP/cellular:
|
Full read pipeline + write pipeline + erase pipeline + monitor log + call home config working end-to-end over TCP/cellular:
|
||||||
|
|
||||||
@@ -41,14 +41,15 @@ Full read pipeline + write pipeline + erase pipeline + monitor log + call home c
|
|||||||
| Event header / first key | 1E | ✅ |
|
| Event header / first key | 1E | ✅ |
|
||||||
| Waveform header | 0A | ✅ |
|
| Waveform header | 0A | ✅ |
|
||||||
| Waveform record (peaks, timestamp, project) | 0C | ✅ |
|
| Waveform record (peaks, timestamp, project) | 0C | ✅ |
|
||||||
| **Bulk waveform stream (event-time metadata)** | **5A** | ✅ new v0.6.0 |
|
| **Bulk waveform stream (event-time metadata + full waveform)** | **5A** | ✅ **byte-perfect against BW captures (v0.14.3, 2026-05-05)** — STRT-bounded chunk walk + correct event-N probe counter + DLE-stuffed `0x10` bytes in params + concatenate-only file body assembly. All 17 5A request frames in the 5-1-26 3-sec capture reproduce byte-for-byte. |
|
||||||
| Event advance / next key | 1F | ✅ |
|
| Event advance / next key | 1F | ✅ |
|
||||||
| **Write commands (push config to device)** | **68–83** | ✅ new v0.8.0 |
|
| **Write commands (push config to device)** | **68–83** | ✅ new v0.8.0 |
|
||||||
| **Erase all events** | **0xA3 → 0x1C → 0x06 → 0xA2** | ✅ new v0.9.0 |
|
| **Erase all events** | **0xA3 → 0x1C → 0x06 → 0xA2** | ✅ new v0.9.0 |
|
||||||
| **Monitor log entries (partial 0x2C records)** | **0A browse** | ✅ new v0.10.0 |
|
| **Monitor log entries (partial 0x2C records)** | **0A browse** | ✅ new v0.10.0 |
|
||||||
| **Auto Call Home config (read + write)** | **2C → 7E → 7F** | ✅ **new v0.12.3** |
|
| **Auto Call Home config (read + write)** | **2C → 7E → 7F** | ✅ **new v0.12.3** |
|
||||||
|
|
||||||
`get_events()` sequence per event: `1E → 0A → 0C → 5A → 1F`
|
`get_events()` sequence per event: `1E → 0A → 1E(arm token=0xFE) → 0C → 1F(arm) → POLL×3 → 5A → 1F(browse)`
|
||||||
|
(see "Correct iteration pattern" section below for full detail)
|
||||||
|
|
||||||
`push_config_raw()` write sequence: `68→73 | 71×3→72 | 82→83 | 69→74→72`
|
`push_config_raw()` write sequence: `68→73 | 71×3→72 | 82→83 | 69→74→72`
|
||||||
|
|
||||||
@@ -115,24 +116,203 @@ S3→BW (response):
|
|||||||
section contribute only `XX` to the running sum; lone bytes contribute normally. This
|
section contribute only `XX` to the running sum; lone bytes contribute normally. This
|
||||||
differs from the standard SUM8-of-destuffed-payload that all other commands use.
|
differs from the standard SUM8-of-destuffed-payload that all other commands use.
|
||||||
|
|
||||||
Both differences confirmed by reproducing Blastware's exact wire bytes from the 1-2-26
|
3. **Params region uses partial DLE stuffing (CONFIRMED 2026-05-05).** The device's
|
||||||
BW TX capture. All 10 frames verified.
|
de-stuffing rule for bytes inside the params region is:
|
||||||
|
|
||||||
### SUB 5A — chunk counter is monotonic (CORRECTED 2026-04-06)
|
- `10 10` → de-stuffs to `10`
|
||||||
|
- `10 02 / 03 / 04` → kept literal (these are inner-frame markers)
|
||||||
|
- `10 X` for other X → de-stuffs to just `X` (drops the leading `0x10`)
|
||||||
|
|
||||||
**Chunk counters are `chunk_num * 0x0400` for ALL chunks including chunk 1.**
|
Therefore any `0x10` byte in the *logical* params that is followed by a byte NOT in
|
||||||
|
`{0x02, 0x03, 0x04, 0x10}` MUST be doubled on the wire (`10 X` → `10 10 X`) so the
|
||||||
|
device's de-stuffer reproduces the original `10 X` pair. This applies most commonly
|
||||||
|
to counters with `0x10` in the high byte (e.g. counter=`0x1000` produces logical
|
||||||
|
params bytes `... 10 00 ...`, which BW encodes on the wire as `... 10 10 00 ...`).
|
||||||
|
Without this stuffing the device interprets counter=`0x1000` as `0x0000` and returns
|
||||||
|
the probe response (which contains a copy of the file header + STRT record). That
|
||||||
|
STRT block then gets embedded in the assembled file body at offset `0x1016`, and
|
||||||
|
Blastware refuses to open the file — see the v0.14.3 entry in `CHANGELOG.md`.
|
||||||
|
|
||||||
The 4-2-26 BW TX capture showed `counter=0x1004` for chunk 1 of event key `01110000`, which
|
`0x10` bytes in `offset_hi` (body[5]) are still written RAW — only the params region
|
||||||
led to `_CHUNK1_COUNTER = 0x1004` being hardcoded as a special case. This was a Blastware
|
has this stuffing requirement. The metadata-page params for counter `0x1002` /
|
||||||
artifact, not a protocol requirement. Empirical test 2026-04-06: with `counter=0x1004` for
|
`0x1004` survive without stuffing because `10 02` and `10 04` fall in the "kept
|
||||||
chunk 1 the device times out (120 s); with `counter=0x0400` (= `1 * 0x0400`) it responds
|
literal" carve-out.
|
||||||
immediately and streams all frames correctly.
|
|
||||||
|
|
||||||
The 4-3-26 capture confirms the pattern for a second event (key `0111245a`):
|
Both differences (1) and (2) confirmed by reproducing Blastware's exact wire bytes from
|
||||||
chunk 1 = `0x245A`, chunk 2 = `0x285A`, chunk 3 = `0x2C5A` (each +0x0400). Blastware's
|
the 1-2-26 BW TX capture (10 frames). Difference (3) confirmed against the 5-1-26
|
||||||
true formula is `key4[2:4] + n * 0x0400` — but since `key4[2:4]` of the first event is
|
"bwcap3sec" capture (17 frames, all match byte-for-byte after fix).
|
||||||
`0x0000`, `n * 0x0400` produces the right result. The device does not strictly validate the
|
|
||||||
counter and streams data for any valid 5A request; using `chunk_num * 0x0400` is correct.
|
### SUB 5A — chunk counter formula (REWRITTEN 2026-05-01 — see 5-1-26 captures)
|
||||||
|
|
||||||
|
> ⚠️ **Everything that came before this rewrite was WRONG in important ways.** The previous
|
||||||
|
> formula `max(key4[2:4], 0x0400) + (chunk_num - 1) * 0x0400` happened to *work* for events
|
||||||
|
> at start_key=0 because the device responds to whatever counter you ask for — but it caused
|
||||||
|
> a 5× over-read past the actual event, picking up post-event circular-buffer garbage that
|
||||||
|
> corrupts the reconstructed file for any event > ~1 sec of waveform. The captures in
|
||||||
|
> `bridges/captures/4-27-26/` and `5-1-26/comcheck/` show BW reads only ~12-16 chunks for
|
||||||
|
> the same events SFM was reading 37+ chunks for. See "TERM frame" and "STRT end_offset"
|
||||||
|
> sections below for the actual mechanism.
|
||||||
|
|
||||||
|
**Chunk addressing is just absolute device-buffer addresses.**
|
||||||
|
|
||||||
|
`params[0]=0x00`, `params[1:5]` is a 4-byte absolute device flash-buffer address (= the
|
||||||
|
"key" of that location), `params[5:11]` are zeros. The device returns 0x0200 (= 512) bytes
|
||||||
|
starting at that address. Increments between consecutive chunks are **0x0200 (NOT 0x0400)**
|
||||||
|
— this matches the chunk payload size. The previous "0x0400 step" worked by accident: BW
|
||||||
|
asks for half-size chunks; SFM was asking for double-size chunks, both with the same-named
|
||||||
|
"counter" field, but the value is just an address pointer the device honors as-is.
|
||||||
|
|
||||||
|
**The chunk pattern depends on whether the event sits at start_key=0 or not.**
|
||||||
|
|
||||||
|
#### Event 1 case — start_key[2:4] == 0x0000 (first event after erase / wrap)
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Probe at counter=0x0000 (params[1:5] = full key, returns STRT record)
|
||||||
|
2. Read 2 fixed metadata pages: counter=0x1002, counter=0x1004
|
||||||
|
(these are GLOBAL session metadata — read ONCE per
|
||||||
|
Blastware session, not per event; contain the
|
||||||
|
Project/Client/User Name/Seis Loc strings)
|
||||||
|
3. Sample chunks: counter=0x0600, 0x0800, …, by 0x0200 increment,
|
||||||
|
up to but not including end_offset (rounded down to
|
||||||
|
0x0200 boundary)
|
||||||
|
4. TERM frame (see TERM formula below)
|
||||||
|
```
|
||||||
|
|
||||||
|
The reason `0x0046..0x0600` is skipped for event 1 is unknown — likely some pre-event
|
||||||
|
firmware reserved area for the first slot in a freshly-erased buffer. Harmless to skip.
|
||||||
|
|
||||||
|
#### Event 2+ case — start_key[2:4] != 0x0000 (continuation events)
|
||||||
|
|
||||||
|
```
|
||||||
|
1. First chunk at counter = start_key[2:4] (this IS the probe — response
|
||||||
|
contains STRT at byte 17)
|
||||||
|
2. Sample chunks: counter += 0x0200 each, up to but
|
||||||
|
not including end_offset
|
||||||
|
3. TERM frame
|
||||||
|
```
|
||||||
|
|
||||||
|
**`start_key` here is the off=0x46 WAVEHDR record key returned by 1F** (e.g. `01112238`),
|
||||||
|
NOT the off=0x2C boundary key that immediately precedes it. An earlier draft of this
|
||||||
|
doc described event-N as "probe at start + 0x46" — that formula came from naming the
|
||||||
|
boundary key as `start_key`. In the iteration walk, `cur_key` passed to
|
||||||
|
`read_bulk_waveform_stream` is always the off=0x46 key (the partial-record skip path in
|
||||||
|
`get_events` re-runs 1F to advance past boundary records before invoking 5A), so the
|
||||||
|
probe counter is just `cur_key[2:4]` with no extra offset. **Adding +0x46 caused the
|
||||||
|
probe to overshoot, miss the STRT record at byte 17 of the response, fall back to the
|
||||||
|
`max_chunks=128` cap, and walk ~110 chunks of post-event garbage** — observed in
|
||||||
|
SFM 5-4-26 capture before the fix.
|
||||||
|
|
||||||
|
Confirmed across:
|
||||||
|
- 5-1-26 "copy 2nd address" BW capture: probe counter=0x2238, key=01112238, STRT@17 end=0x417E.
|
||||||
|
- 5-4-26 BW 2-sec event capture: probe counter=0x2238, key=01112238, TERM offset_word=0x0146 → end=0x417E.
|
||||||
|
|
||||||
|
No metadata pages — those have already been read during event 1 in the same Blastware
|
||||||
|
session, and BW caches them. Note that the metadata-page reads happen ONCE per
|
||||||
|
Blastware-session-on-the-device, not once per event, so an SFM session that downloads
|
||||||
|
several events should read 0x1002/0x1004 only once at the start.
|
||||||
|
|
||||||
|
#### History (do not re-derive)
|
||||||
|
|
||||||
|
- Original: `_CHUNK1_COUNTER = 0x1004` hardcoded (Blastware capture artifact — WRONG).
|
||||||
|
- 2026-04-06: `chunk_num * 0x0400` (worked for key 01110000 only).
|
||||||
|
- 2026-04-24: `key4[2:4] + (chunk_num-1) * 0x0400` (fixed non-zero offsets, broke key 01110000).
|
||||||
|
- 2026-04-26: `max(key4[2:4], 0x0400) + (chunk_num-1) * 0x0400` (broken — over-read past event end).
|
||||||
|
- 2026-05-01: Increments are 0x0200 not 0x0400; absolute addresses inside event range; bounded
|
||||||
|
by STRT end_key, not by `max_chunks` cap or device-side timeout.
|
||||||
|
- 2026-05-04: Removed spurious `+0x0046` from event-N probe counter. `cur_key` from 1F
|
||||||
|
is already the off=0x46 WAVEHDR key, so adding +0x46 would have placed the probe one
|
||||||
|
WAVEHDR past the actual event start. This caused probe responses to lack a STRT
|
||||||
|
record (no `end_offset` parsed → `0xFFFF` fallback → `max_chunks=128` cap), walking
|
||||||
|
~110 chunks of post-event circular-buffer garbage. Fixed in protocol.py
|
||||||
|
`read_bulk_waveform_stream`.
|
||||||
|
|
||||||
|
### SUB 5A — STRT record encodes end_offset (NEW 2026-05-01)
|
||||||
|
|
||||||
|
The first A5 response (probe response, or the first chunk for event 2+) contains a STRT
|
||||||
|
record at byte offset 17 of the `data` field. Layout:
|
||||||
|
|
||||||
|
```
|
||||||
|
data[17:21] "STRT" magic
|
||||||
|
data[21:23] ff fe sentinel
|
||||||
|
data[23:27] end_key ← 4-byte key of where this event ENDS
|
||||||
|
data[27:31] start_key ← 4-byte key of where this event STARTS
|
||||||
|
data[31:33] uint16 BE ?? sample-count or total bytes (varies; not yet decoded)
|
||||||
|
data[33:35] uint16 BE ??
|
||||||
|
data[35] 0x46 record type (waveform full record)
|
||||||
|
…
|
||||||
|
```
|
||||||
|
|
||||||
|
`end_offset = (end_key[2] << 8) | end_key[3]` is **the authoritative event-end pointer**.
|
||||||
|
SFM must extract this from the first A5 response and use it to bound the chunk loop and
|
||||||
|
encode the TERM frame. The device will happily respond to chunk requests past `end_offset`
|
||||||
|
(returning post-event circular-buffer contents) — that's the over-read bug.
|
||||||
|
|
||||||
|
Verified across 3 events:
|
||||||
|
|
||||||
|
| Capture | start_key | end_key | end_offset | event size |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 4-27-26 "open 2sec" / "copy event to disk" | `01110000` | `01111ABE` | `0x1ABE` | 6,846 B |
|
||||||
|
| 5-1-26 "copy 3sec" / Download All event 1 | `01110000` | `011121F2` | `0x21F2` | 8,690 B |
|
||||||
|
| 5-1-26 "copy 2nd address" / DA event 2 | `011121F2` | `0111417E` | `0x417E` (event 2 span 0x1F8C = 8,076 B) |
|
||||||
|
|
||||||
|
### SUB 5A — TERM frame formula (FINALIZED 2026-05-01)
|
||||||
|
|
||||||
|
The TERM frame fetches the partial last chunk *and* the file footer. It is **not** a simple
|
||||||
|
"goodbye" frame — its response payload contains the bytes between the last full 0x0200-aligned
|
||||||
|
chunk and `end_offset`, and is required for reconstructing the Blastware file format.
|
||||||
|
|
||||||
|
```
|
||||||
|
last_chunk_counter = address of last full 0x0200-byte chunk read
|
||||||
|
next_boundary = last_chunk_counter + 0x0200
|
||||||
|
TERM offset_word = end_offset - next_boundary
|
||||||
|
TERM params[0] = key[0] (= 0x01 on every observed device)
|
||||||
|
TERM params[1] = key[1] (= 0x11)
|
||||||
|
TERM params[2] = (next_boundary >> 8) & 0xFF
|
||||||
|
TERM params[3] = next_boundary & 0xFF
|
||||||
|
TERM params[4:10] = zeros
|
||||||
|
build_5a_frame(offset_word, params) (10-byte params, NOT 11)
|
||||||
|
```
|
||||||
|
|
||||||
|
The device reconstructs `requested_address = (params[2] << 8) | offset_word = end_offset`
|
||||||
|
and replies with `(end_offset - next_boundary)` bytes from `next_boundary` — the residual
|
||||||
|
between the last 0x0200 boundary and the actual event end. Append the TERM response data
|
||||||
|
to the chunk stream like any other A5 frame; it carries the final waveform tail + footer.
|
||||||
|
|
||||||
|
Verified across 3 events:
|
||||||
|
|
||||||
|
| end_offset | last chunk | next_boundary | TERM offset_word | TERM params[2:4] |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| `0x1ABE` | `0x1800` | `0x1A00` | `0x00BE` ✓ | `1A 00` ✓ |
|
||||||
|
| `0x21F2` | `0x1E00` | `0x2000` | `0x01F2` ✓ | `20 00` ✓ |
|
||||||
|
| `0x417E` | `0x3E38` | `0x4038` | `0x0146` ✓ | `40 38` ✓ |
|
||||||
|
|
||||||
|
The previous code's hard-coded `offset_word = 0x005A` and `term_counter = last + 0x0400`
|
||||||
|
are wrong; the device's response under that path is a tiny 101-byte device-side terminator
|
||||||
|
(arrived only after we walked the entire post-event buffer), not the proper file footer.
|
||||||
|
|
||||||
|
### SUB 5A — fixed metadata pages 0x1002 and 0x1004 (NEW 2026-05-01)
|
||||||
|
|
||||||
|
Two chunk addresses are GLOBAL device/session metadata, not event-specific:
|
||||||
|
|
||||||
|
- `counter=0x1002` — first metadata page
|
||||||
|
- `counter=0x1004` — second metadata page
|
||||||
|
|
||||||
|
These are at fixed absolute addresses in the device's flash buffer. They contain the
|
||||||
|
session-start compliance setup (Project/Client/User Name/Seis Loc/Extended Notes ASCII
|
||||||
|
strings). Under the v0.14.0+ walk these strings are read directly from the metadata
|
||||||
|
pages, not from the sample-chunk stream.
|
||||||
|
|
||||||
|
BW reads them ONCE per Blastware session (during event 1's download) and caches them.
|
||||||
|
For SFM, that means:
|
||||||
|
- Once per call-home / once per `MiniMateClient.connect()` is enough.
|
||||||
|
- Subsequent events in the same session don't need to re-fetch them.
|
||||||
|
- Their content does not change when iterating events; only when the user opens
|
||||||
|
Compliance Setup → Apply on the device or sends a SUB 71 compliance write.
|
||||||
|
|
||||||
|
The full byte-for-byte layout of the metadata pages has not been mapped — `_decode_a5_metadata_into`
|
||||||
|
locates the ASCII strings via label scans (`Project:`, `Client:`, `User Name:`, `Seis Loc:`,
|
||||||
|
`Extended Notes`) which works correctly across observed captures. Future work could
|
||||||
|
dump the structural layout if more session-global fields need to be extracted.
|
||||||
|
|
||||||
### SUB 5A — params are 11 bytes for chunk frames, 10 for termination
|
### SUB 5A — params are 11 bytes for chunk frames, 10 for termination
|
||||||
|
|
||||||
@@ -140,10 +320,11 @@ counter and streams data for any valid 5A request; using `chunk_num * 0x0400` is
|
|||||||
confirmed from the BW wire capture. `bulk_waveform_term_params()` returns 10 bytes.
|
confirmed from the BW wire capture. `bulk_waveform_term_params()` returns 10 bytes.
|
||||||
Do not swap them.
|
Do not swap them.
|
||||||
|
|
||||||
### SUB 5A — event-time metadata lives in A5 frame 7
|
### SUB 5A — event-time metadata source (FINALIZED 2026-05-05)
|
||||||
|
|
||||||
The bulk stream sends 9+ A5 response frames. Frame 7 (0-indexed) contains the compliance
|
The metadata strings come from the two fixed metadata pages at counter `0x1002` and
|
||||||
setup as it existed when the event was recorded:
|
`0x1004` (see "SUB 5A — fixed metadata pages 0x1002 and 0x1004" above). These pages
|
||||||
|
are GLOBAL session metadata — read once per Blastware/SFM session, not per event.
|
||||||
|
|
||||||
```
|
```
|
||||||
"Project:" → project description
|
"Project:" → project description
|
||||||
@@ -153,44 +334,71 @@ setup as it existed when the event was recorded:
|
|||||||
"Extended Notes"→ notes
|
"Extended Notes"→ notes
|
||||||
```
|
```
|
||||||
|
|
||||||
**IMPORTANT — 5A "Project:" is session-start config, NOT per-event (confirmed 2026-04-05):**
|
**IMPORTANT — these strings are session-start config, NOT per-event:**
|
||||||
The "Project:" string in the A5 frame 7 payload reflects the compliance setup from when
|
Project / Client / User Name / Seis Loc reflect the compliance setup from when the
|
||||||
the *monitoring session first started*, not the individual event's project name. The per-
|
*monitoring session first started*, not the individual event's per-event metadata. The
|
||||||
event project name is correctly stored in the 210-byte 0C waveform record and must be
|
authoritative per-event project name is stored in the 210-byte 0C waveform record.
|
||||||
used as the authoritative source. `_decode_a5_metadata_into` therefore only sets
|
`_decode_a5_metadata_into` therefore only sets `project` from the 5A metadata pages
|
||||||
`project` from 5A when 0C didn't already supply one.
|
when 0C didn't already supply one.
|
||||||
|
|
||||||
"Client:", "User Name:", "Seis Loc:", and "Extended Notes" are **NOT** present in the 0C
|
"Client:", "User Name:", "Seis Loc:", and "Extended Notes" are **NOT** present in the 0C
|
||||||
record — 5A remains the sole source for those fields and they are set unconditionally.
|
record — the metadata pages are the sole source for those fields and they are set
|
||||||
|
unconditionally.
|
||||||
|
|
||||||
`stop_after_metadata=True` (default) stops the 5A loop as soon as `b"Project:"` appears,
|
#### Deprecated knobs (do not re-introduce)
|
||||||
then sends the termination frame.
|
|
||||||
|
|
||||||
### SUB 5A — end-of-stream signal (confirmed 2026-04-06)
|
The `read_bulk_waveform_stream()` function still accepts these legacy kwargs for
|
||||||
|
backward compatibility, but they are **no-ops** under the v0.14.0+ walk:
|
||||||
|
|
||||||
After streaming all waveform chunks, the device sends exactly **1 raw byte** in response to
|
- `stop_after_metadata=True` — used to scan the chunk stream for `b"Project:"` and stop
|
||||||
the next chunk request, then goes silent. This is the natural end-of-stream indicator — NOT
|
one chunk later as a workaround for the missing end_offset bound. Obsolete: the loop
|
||||||
a complete A5 frame. `S3FrameParser.bytes_fed` will be 1; no frame is assembled.
|
is now deterministically bounded by `end_offset` parsed from the STRT record at
|
||||||
|
data[17] of the probe response, with the partial tail fetched by the TERM frame.
|
||||||
|
- `extra_chunks_after_metadata` — same era, same reason. No-op.
|
||||||
|
|
||||||
Handling: on `TimeoutError`, if `bytes_fed > 0` AND frames were already collected, treat as
|
If you find code or docs referencing "A5 frame 7" as the source of metadata strings,
|
||||||
graceful end-of-stream, break the loop, and proceed to the termination frame. If `bytes_fed
|
that's an old-walk artifact (the broken `0x0400`-step formula occasionally caught the
|
||||||
== 0` with no prior frames, it is a genuine transport failure — re-raise.
|
0x1002 metadata page at sample-chunk fi=7). Update to reference the dedicated metadata
|
||||||
|
pages instead.
|
||||||
|
|
||||||
**Chunk recv timeout must be 10 s, not the default 120 s.** Chunks arrive within ~1 s each.
|
### SUB 5A — end-of-stream (FINALIZED 2026-05-01)
|
||||||
Using 120 s causes a ~2-minute stall at every end-of-stream detection. The `_recv_one` call
|
|
||||||
in the chunk loop passes `timeout=10.0` explicitly.
|
|
||||||
|
|
||||||
**Typical chunk count (BE11529, 1024 sps):** A 9,306-sample event produces 35 chunks before
|
Under the v0.14.0+ STRT-bounded walk the stream ends cleanly:
|
||||||
end-of-stream. Chunks with uniform 1,036-byte data are all-zero ADC samples (post-event
|
|
||||||
silence). Only the initial variable-size chunks contain actual signal.
|
```
|
||||||
|
… last full chunk at counter < end_offset
|
||||||
|
TERM request (offset_word = end_offset - next_boundary,
|
||||||
|
params address (next_boundary))
|
||||||
|
TERM response (page_key = 0x0000 or 0x0001, data = the residual
|
||||||
|
end_offset - next_boundary bytes including the file footer)
|
||||||
|
```
|
||||||
|
|
||||||
|
No timeout-based detection, no "1-byte teaser," no `max_chunks` cap. The chunk loop
|
||||||
|
exits when `counter + 0x0200 > end_offset`; the TERM frame fetches the tail.
|
||||||
|
|
||||||
|
**Chunk recv timeout is 10 s, not the default 120 s.** Chunks arrive within ~1 s each.
|
||||||
|
Using 120 s would cause a ~2-minute stall on any unexpected timeout. The `_recv_one`
|
||||||
|
call in the chunk loop passes `timeout=10.0` explicitly.
|
||||||
|
|
||||||
|
**Typical chunk count under the v0.14.0+ walk (BE11529, 1024 sps over TCP/cellular):**
|
||||||
|
|
||||||
|
| Event duration | Sample chunks | Metadata pages | TERM | Total A5 frames |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 2-sec (event 1) | ~12 | 2 | 1 | ~15 |
|
||||||
|
| 3-sec (event 1) | 13 | 2 | 1 | 16 |
|
||||||
|
| 2-sec (continuation) | 15 | 0 | 1 | 16 |
|
||||||
|
| 3-sec (continuation) | ~14 | 0 | 1 | ~15 |
|
||||||
|
|
||||||
|
For comparison, the deprecated `0x0400`-step walk produced ~37 chunks for a 2-sec
|
||||||
|
event with chunks 17-37 containing post-event circular-buffer garbage. Do not
|
||||||
|
re-introduce that walk under any circumstances.
|
||||||
|
|
||||||
### SUB 5A — fi==9 hardcoded skip (FIXED 2026-04-06)
|
### SUB 5A — fi==9 hardcoded skip (FIXED 2026-04-06)
|
||||||
|
|
||||||
`_decode_a5_waveform()` previously had `elif fi == 9: continue` — a leftover from the
|
`_decode_a5_waveform()` previously had `elif fi == 9: continue` — a leftover from the
|
||||||
9-frame original blast capture where frame 9 was assumed to be a terminator. For current
|
9-frame original blast capture where frame 9 was assumed to be a terminator. Removed.
|
||||||
35-frame streams, fi==9 is live waveform data (~133 sample-sets were being dropped).
|
TERM detection in the file builder uses `frame.page_key != 0x0010` (sample marker),
|
||||||
Removed. Terminator detection is via `page_key == 0x0000` in `read_bulk_waveform_stream`,
|
not frame index — see `blastware_file.py`.
|
||||||
not frame index.
|
|
||||||
|
|
||||||
### SUB 1E / 1F — event iteration null sentinel and token position (FIXED, do not re-introduce)
|
### SUB 1E / 1F — event iteration null sentinel and token position (FIXED, do not re-introduce)
|
||||||
|
|
||||||
@@ -295,6 +503,55 @@ sends token=0xFE and is NOT used by any caller.
|
|||||||
`advance_event()` returns `(key4, event_data8)`.
|
`advance_event()` returns `(key4, event_data8)`.
|
||||||
Callers (`count_events`, `get_events`) loop while `data8[4:8] != b"\x00\x00\x00\x00"`.
|
Callers (`count_events`, `get_events`) loop while `data8[4:8] != b"\x00\x00\x00\x00"`.
|
||||||
|
|
||||||
|
### SUB 0A — WAVEHDR response length distinguishes events from boundaries (NEW 2026-05-01)
|
||||||
|
|
||||||
|
When iterating events with the "Download All" pattern (1E → 0A → 1F → 0A → 1F → …), the
|
||||||
|
DATA_LENGTH at `data_rsp.data[5]` (= the byte BW echoes back as the offset for the data
|
||||||
|
fetch step) takes one of two values:
|
||||||
|
|
||||||
|
| WAVEHDR offset | Meaning |
|
||||||
|
|---|---|
|
||||||
|
| `0x46` (= 70) | Real event start key — there is event data at this address |
|
||||||
|
| `0x2C` (= 44) | Boundary marker between events — this key is the END of the previous event AND the START key for the empty space after it (or is the next event's pre-header) |
|
||||||
|
|
||||||
|
Confirmed from the 5-1-26 "Download All" capture:
|
||||||
|
|
||||||
|
```
|
||||||
|
0A(key=01110000) → off=0x46 ← event 1 real start
|
||||||
|
1F → key=011121F2
|
||||||
|
0A(key=011121F2) → off=0x2C ← event 1 END / event 2 boundary
|
||||||
|
1F → key=01112238
|
||||||
|
0A(key=01112238) → off=0x46 ← event 2 real start (= boundary + 0x46)
|
||||||
|
1F → key=0111417E
|
||||||
|
0A(key=0111417E) → off=0x2C ← event 2 END / next-empty marker
|
||||||
|
1F → null sentinel
|
||||||
|
```
|
||||||
|
|
||||||
|
This is why event 2's first 5A chunk is at `start_key + 0x46` — that's the address of the
|
||||||
|
"real start" 0x46-record, distinct from the `0x2C`-record at the raw boundary. Use the
|
||||||
|
`0x46` keys as the input to `read_bulk_waveform_stream`, not the `0x2C` keys.
|
||||||
|
|
||||||
|
For event 1 only (start_key[2:4] = 0x0000) BW probes at counter=0x0000 directly, which is
|
||||||
|
the `0x46`-keyed start record. Subsequent events use `start_key + 0x46`.
|
||||||
|
|
||||||
|
**Practical iteration pattern (replaces the old 1E/1F walk for downloads):**
|
||||||
|
|
||||||
|
```
|
||||||
|
Setup: SERIAL × 2 → CHCFG → 1E (token=0x00) → key0
|
||||||
|
For each event:
|
||||||
|
0A(cur_key) → DATA_LENGTH = 0x46 (real) or 0x2C (boundary)
|
||||||
|
1F (token=0x00) → next_key
|
||||||
|
if length was 0x46: → cur_key is a real event; queue it for download
|
||||||
|
cur_key = next_key
|
||||||
|
if next_key all-zero null sentinel: stop
|
||||||
|
|
||||||
|
Then for each queued real-event key:
|
||||||
|
download_event(key) → 5A bulk stream with STRT-bounded chunk walk
|
||||||
|
```
|
||||||
|
|
||||||
|
This is what BW does in the 5-1-26 "Download All" capture — it walks the full event chain
|
||||||
|
collecting `(key, length)` tuples first, *then* downloads each event using the `0x46` keys.
|
||||||
|
|
||||||
### SUB 1A — compliance config — orphaned send bug (FIXED, do not re-introduce)
|
### 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:
|
`read_compliance_config()` sends a 4-frame sequence (A, B, C, D) where:
|
||||||
@@ -386,7 +643,9 @@ bytes `\x01\x2c` = 300 (5-minute default histogram interval); changes when inter
|
|||||||
|
|
||||||
| Offset | Field | Format | Notes |
|
| Offset | Field | Format | Notes |
|
||||||
|---|---|---|---|
|
|---|---|---|---|
|
||||||
| anchor − 7 (write) / anchor − 8 (read) | recording_mode | uint8 | E5 read has extra `0x10` at anchor−7 |
|
| anchor − 9 | mode_prefix | uint8 | `0x00` for Single Shot / Continuous; `0x10` for Histogram (DLE prefix in E5 encoding) and Histogram+Continuous (actual config byte). See "compliance_raw DLE encoding" note below. |
|
||||||
|
| anchor − 8 | recording_mode | uint8 | **Same offset for both read and write** — confirmed 2026-04-21. `_encode_compliance_config` writes `buf[anc-8]`. NOTE: for Histogram (0x03), E5 encodes the value as `0x10 0x03` so compliance_raw[anc-9]=0x10, compliance_raw[anc-8]=0x03. |
|
||||||
|
| anchor − 7 | constant | `0x10` | Always `0x10` in both E5 read and BW write payloads (not a DLE marker — it is part of the sample_rate field area). Do NOT overwrite. |
|
||||||
| anchor − 6 | sample_rate | uint16 BE | same in read & write |
|
| anchor − 6 | sample_rate | uint16 BE | same in read & write |
|
||||||
| anchor − 4 | histogram_interval_sec | uint16 BE | seconds; same in read & write ✅ 2026-04-20 |
|
| anchor − 4 | histogram_interval_sec | uint16 BE | seconds; same in read & write ✅ 2026-04-20 |
|
||||||
| anchor − 2 | `0x00 0x00` | padding | |
|
| anchor − 2 | `0x00 0x00` | padding | |
|
||||||
@@ -395,15 +654,42 @@ bytes `\x01\x2c` = 300 (5-minute default histogram interval); changes when inter
|
|||||||
|
|
||||||
**recording_mode enum** (confirmed 2026-04-20 from 4-20-26 captures):
|
**recording_mode enum** (confirmed 2026-04-20 from 4-20-26 captures):
|
||||||
|
|
||||||
| Value | Mode |
|
| Value | Mode | anchor-9 in compliance_raw |
|
||||||
|---|---|
|
|---|---|---|
|
||||||
| `0x00` | Single Shot |
|
| `0x00` | Single Shot | `0x00` |
|
||||||
| `0x01` | Continuous |
|
| `0x01` | Continuous | `0x00` |
|
||||||
| `0x02` | ❓ not observed |
|
| `0x02` | ❓ not observed | ❓ |
|
||||||
| `0x03` | Histogram |
|
| `0x03` | Histogram | `0x10` (DLE prefix from E5 wire encoding of 0x03) |
|
||||||
| `0x04` | Histogram + Continuous |
|
| `0x04` | Histogram + Continuous | `0x10` (actual config byte for this mode) |
|
||||||
|
|
||||||
**DLE escaping in write frames — CONFIRMED 2026-04-20:** Write frame data payloads DO escape `0x03` (ETX) bytes with a `0x10` DLE prefix. For histogram_interval = 900 (0x0384), the wire carries `10 03 84` — the `0x03` high byte is preceded by a DLE escape. After DLE destuffing (`10 XX → XX`), the logical field value is correctly `03 84` = 900. The CLAUDE.md claim that write frame data is "written RAW" was incorrect; at minimum ETX (0x03) bytes are escaped. S3FrameParser handles this transparently so the decoded `compliance_raw` always contains logical (destuffed) bytes.
|
**compliance_raw DLE encoding — IMPORTANT (confirmed 2026-04-21 from 4-20-26 captures):**
|
||||||
|
`compliance_raw` (returned by `read_compliance_config()`) is NOT purely logical bytes — it is
|
||||||
|
the wire-encoded representation where `0x03` bytes in the config are preceded by a `0x10` DLE
|
||||||
|
prefix (because S3FrameParser preserves DLE+ETX inner-frame pairs as two literal bytes).
|
||||||
|
|
||||||
|
Consequences:
|
||||||
|
- When recording_mode = `0x03` (Histogram), `compliance_raw[anc-9] = 0x10` (DLE prefix) and
|
||||||
|
`compliance_raw[anc-8] = 0x03` (the value). The anchor position is +1 compared to modes
|
||||||
|
without `0x03` bytes before the anchor.
|
||||||
|
- For Histogram+Continuous (`0x04`), `compliance_raw[anc-9] = 0x10` for a different reason:
|
||||||
|
it is an actual stored config byte, not a DLE prefix.
|
||||||
|
- The anchor search (`buf.find(b'\xbe\x80\x00\x00\x00\x00', 0, 150)`) correctly locates
|
||||||
|
the anchor regardless of these mode-dependent shifts.
|
||||||
|
- When SFM writes recording_mode and round-trips the rest verbatim, the byte at `anc-9` is
|
||||||
|
preserved from the previous read. This means transitioning Histogram→other modes via SFM
|
||||||
|
leaves a `0x10` at `anc-9`. The device stores it as a literal byte; it does not affect
|
||||||
|
recording mode operation (which is at `anc-8`), but differs from what BW writes. This is a
|
||||||
|
known minor discrepancy that does not impact device behavior.
|
||||||
|
- **Histogram recording mode (0x03) write via SFM**: untested. When starting from a mode with
|
||||||
|
`anc-9 = 0x00`, SFM writes bare `0x03` at anc-8. BW would write `0x10 0x03`. Device likely
|
||||||
|
accepts both (write frames probably use offset/length for framing, not ETX scanning).
|
||||||
|
|
||||||
|
**DLE escaping in write frames — confirmed 2026-04-20:** Blastware escapes `0x03` bytes in
|
||||||
|
write frame data as `0x10 0x03` on the wire (defensive ETX escaping). Our `build_bw_write_frame`
|
||||||
|
does NOT do this escaping — it sends data bytes raw. Device acceptance of bare `0x03` bytes
|
||||||
|
in write frame data is confirmed for the tested modes (Single Shot, Continuous, Histogram+Continuous
|
||||||
|
where `0x10 0x03` already appears from round-tripping). Histogram mode (bare `0x03` write from
|
||||||
|
non-Histogram starting state) has not been directly tested.
|
||||||
|
|
||||||
### SUB 0C — Waveform Record (210 bytes = data[11:11+0xD2])
|
### SUB 0C — Waveform Record (210 bytes = data[11:11+0xD2])
|
||||||
|
|
||||||
@@ -490,6 +776,8 @@ All DB endpoints are read-only except `PATCH /db/events/{id}/false_trigger`.
|
|||||||
| 3-11-26 | `bridges/captures/3-11-26/` | Full compliance setup write, Aux Trigger capture |
|
| 3-11-26 | `bridges/captures/3-11-26/` | Full compliance setup write, Aux Trigger capture |
|
||||||
| 3-31-26 | `bridges/captures/3-31-26/` | Complete event download cycle (148 BW / 147 S3 frames) — confirmed 1E/0A/0C/1F sequence; only 1 event stored so token=0xFE appeared to work |
|
| 3-31-26 | `bridges/captures/3-31-26/` | Complete event download cycle (148 BW / 147 S3 frames) — confirmed 1E/0A/0C/1F sequence; only 1 event stored so token=0xFE appeared to work |
|
||||||
| 4-3-26 | `bridges/captures/4-3-26/` | Browse-mode S3 capture with 2+ events — confirmed all-zero params for 1F, 1F response layout, null sentinel, 0A context requirement |
|
| 4-3-26 | `bridges/captures/4-3-26/` | Browse-mode S3 capture with 2+ events — confirmed all-zero params for 1F, 1F response layout, null sentinel, 0A context requirement |
|
||||||
|
| 4-27-26 | `bridges/captures/4-27-26/` | BW "open 2sec waveform" + "copy event to disk" + paired SFM "seismo_dl" — first proof that SFM was over-reading 5× past event end. BW reads 14 chunks at 0x0200 increments + TERM at end_offset; SFM was reading 37 chunks at 0x0400 increments. STRT end_key field located. |
|
||||||
|
| 5-1-26 | `bridges/captures/5-1-26/comcheck/` | Three sub-captures: SFM 3-sec download (`seismo_dl_…`), BW comms-check + 3-sec download (`bwcap3sec/`), BW second-event download + "Download All" (`raw_*_170945`/`_171216`). Confirmed: TERM frame formula across 3 events; metadata pages 0x1002/0x1004 are global (read once per session); event-1 vs event-N chunk-pattern split; WAVEHDR length 0x46 vs 0x2C disambiguates real events from boundaries. |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -753,7 +1041,7 @@ offsets in the raw 1A/E5 payload. Only fields with `✅` have confirmed offsets
|
|||||||
|
|
||||||
**Notes tab:**
|
**Notes tab:**
|
||||||
- Enable User Notes (bool)
|
- Enable User Notes (bool)
|
||||||
- Project, Client, User Name, Seis Loc (ASCII strings) ✅ (sourced from A5 frame 7 via 5A)
|
- Project, Client, User Name, Seis Loc (ASCII strings) ✅ (sourced from 5A metadata pages at counter 0x1002 / 0x1004 — see "SUB 5A — fixed metadata pages" section)
|
||||||
- Enable Extended Notes (bool); Extended Notes text; Extended Notes Title
|
- Enable Extended Notes (bool); Extended Notes text; Extended Notes Title
|
||||||
- Enable Job Number (bool); Job Number (int)
|
- Enable Job Number (bool); Job Number (int)
|
||||||
- Enable Scaled Distance (bool); Distance from Blast (float); Charge Weight (float) — Scaled Distance is derived
|
- Enable Scaled Distance (bool); Distance from Blast (float); Charge Weight (float) — Scaled Distance is derived
|
||||||
@@ -1067,9 +1355,58 @@ body) because writing a dial string may require DLE escaping for embedded contro
|
|||||||
|
|
||||||
- **Database** — SQLite store for events + monitor log entries; dedup by key; queryable
|
- **Database** — SQLite store for events + monitor log entries; dedup by key; queryable
|
||||||
- **Histograms** — decode histogram-mode A5 data (noise floor tracking)
|
- **Histograms** — decode histogram-mode A5 data (noise floor tracking)
|
||||||
|
- **Blastware-compatible file output** — `write_blastware_file()` and `write_mlg()` implemented. `blastware_filename()` generates correct Blastware filenames (AB0 for direct, AB0W/AB0H for ACH). **Confirmed BYTE-PERFECT against BW reference (v0.14.3, 2026-05-05):** when fed the BW 5-1-26 3-sec capture's A5 frames, the SFM-built file matches BW's saved `M529LKIQ.G10` byte-for-byte (8708 bytes, 0 differences). Live SFM downloads of event 0 (3-sec) and event 1 (3-sec continuation) both open cleanly in Blastware with full Event Reports, frequency analysis, and waveform plots. Body assembly is just contiguous concatenation of frame contributions in stream order (probe → meta@0x1002 → meta@0x1004 → samples → TERM); no stripping, no overlay, no special handling. Histogram+Continuous mode deferred (5A stream for those events embeds histogram interval records that may need different handling — untested under v0.14.x). Extension mapping: extensions encode timestamp (AB0T for ACH, AB0 for direct), NOT recording mode. Filename format: `<prefix_letter><serial3><4-char-base36-stem><ext>`
|
||||||
|
|
||||||
|
**Serial encoding (CONFIRMED 2026-04-22):** `prefix_letter = chr(ord('B') + floor(serial_numeric / 1000))`, `serial3 = f"{serial_numeric % 1000:03d}"`. Examples: BE6907→H907, BE11529→M529, BE14036→P036, BE17353→S353, BE18003→T003. The prefix letter encodes the production generation (batch of 1000 units).
|
||||||
|
|
||||||
|
**Stem encoding (FULLY CONFIRMED 2026-04-22):** stem = 4-char base-36 of `floor(total_seconds / 1296)` where `total_seconds = (event_local_time − 1985-01-01T00:00:00_local)` in seconds. Epoch = `1985-01-01 00:00:00` device local time — confirmed against 3,248 files from 10-year production archive with zero errors. Decode: `event_time = datetime(1985,1,1) + timedelta(seconds=stem_int*1296 + ab_int)`. Example: P036L318.C80H → BE14036, 2025-05-26 15:00:08, Full Histogram.
|
||||||
|
- **Blastware filename extension — NEW FIRMWARE FULLY DECODED (confirmed 2026-04-21, further confirmed 2026-04-22 from 10-year production archive frequency analysis):**
|
||||||
|
|
||||||
|
Extension format = `AB0T` (4 chars):
|
||||||
|
- `AB` = 2-char base-36 encoding of `total_seconds % 1296` (seconds within the 21.6-min window, 0–1295); `A = value // 36`, `B = value % 36`
|
||||||
|
- `0` = always literal digit zero (third character, invariant)
|
||||||
|
- `T` = event type: `W` = Full Waveform, `H` = Full Histogram
|
||||||
|
|
||||||
|
Combined with the 4-char stem, the full filename encodes a complete second-resolution timestamp. Verified against three S353L4H0.{3M0W,8S0H,9X0W} events (all match to the second) plus large-scale frequency analysis of a 10-year archive.
|
||||||
|
|
||||||
|
**3-day cycle property (confirmed 2026-04-22):** A unit recording at a fixed daily time cycles through exactly **3 extensions** with a 3-day period. Each calendar day shifts `total_seconds % 1296` by 864 (since `86400 % 1296 = 864`). The cycle repeats every 3 days because `gcd(1296, 864) = 432` and `1296 / 432 = 3`. The three extension values are spaced 432 seconds apart. Confirmed from 10-year archive: the top 3 extensions overall were `CE0H` (95 files), `0E0H` (93), `OE0H` (91) — all three are the 3-day cycle of a 06:00:14 daily call-in time (seconds-in-window = 14, 446, 878; all three have `E` as second character because `14 = E` in base-36 and adding 864 never changes `value % 36` since `864 = 24 × 36`).
|
||||||
|
|
||||||
|
**B character invariance:** For a unit recording at a fixed time of day, the second character `B` of the extension (`value % 36`) **never changes** — only the first character `A` cycles through 3 values. This means same-time-of-day files from different dates all share the same `B` character.
|
||||||
|
|
||||||
|
**Old firmware (S338, 3-char extensions ending in `0`):** encoding unknown. Extension is NOT recording mode. `blastware_filename()` returns `.N00` as a placeholder for old-firmware units.
|
||||||
|
|
||||||
|
**Micromate Series 4** uses a different extension format entirely (observed: `IDFH`, `IDFW`). The `AB0T` formula applies only to MiniMate Plus / V10.72 firmware.
|
||||||
- Compliance config encoder — build raw write payloads from a `ComplianceConfig` object
|
- Compliance config encoder — build raw write payloads from a `ComplianceConfig` object
|
||||||
|
- **Test Histogram recording mode (0x03) write via SFM** — confirmed working for Single Shot / Continuous / Histogram+Continuous; Histogram (0x03) needs a live test from a non-Histogram starting state (bare 0x03 in write vs BW's DLE-escaped `10 03`)
|
||||||
|
- **Compliance write anchor-9 cleanup** — when changing recording_mode via SFM, the byte at anchor-9 is not explicitly managed. A spurious `0x10` may persist after Histogram→other mode transitions. Does not affect device operation but differs from BW's byte-perfect output.
|
||||||
- Locate "Sensor Check" byte in compliance config (need capture with Disabled vs Before-monitoring)
|
- Locate "Sensor Check" byte in compliance config (need capture with Disabled vs Before-monitoring)
|
||||||
- Call Home — map time slots 3/4 offsets; add dial_string write support; confirm `modem_power_relay_enabled`
|
- Call Home — map time slots 3/4 offsets; add dial_string write support; confirm `modem_power_relay_enabled`
|
||||||
- Modem manager — push RV50/RV55 configs via Sierra Wireless API
|
- Modem manager — push RV50/RV55 configs via Sierra Wireless API
|
||||||
- RV55 DCD/DTR issue — newer RV55 firmware doesn't assert DCD by default; units don't
|
- RV55 DCD/DTR issue — newer RV55 firmware doesn't assert DCD by default; units don't
|
||||||
resume monitoring after call-home disconnect (`--restart-monitoring` flag deferred) | |||||||