From 1765b3300da2083e96616d3bfcf5d351393eeeec Mon Sep 17 00:00:00 2001 From: serversdown Date: Sun, 20 Sep 2026 22:32:13 +0000 Subject: [PATCH] docs(changelog): waveform event-time fix (exact trigger from binary) Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_01YDXjZCr4RqT2U3QvMDhgzf --- CHANGELOG.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 1ce4446..0cb5125 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,6 +6,22 @@ All notable changes to seismo-relay are documented here. ## Unreleased +### Fixed + +- **Waveform event times were the monitoring-session start, not the trigger + (~hours off).** `read_blastware_file` stamped events with footer `ts1`, which + for a waveform is the session start a unit shares across every event that day + (a unit arming at 06:00 stamped 06:00 on all of them — the modal and PDF both + showed it, since it's the stored value). The event time is footer `ts2` (the + recording stop), and Blastware's trigger = `ts2 - record time`. The record + time is a big-endian float32 in the recording-setup config block (30 bytes + before the `Standard Recording Setup` marker), so the **exact trigger is now + recovered from the binary alone** — all 7 BE12844 oracle events decode to + their exact Blastware time (e.g. N844LQHB 10:33:29), no paired `.TXT` needed. + Histograms keep `ts1` (the ~24 h window start). A paired report's + `event_datetime` stays authoritative (unit-clock drift). + ⚠ **Needs a re-decode backfill** to correct existing stored events' timestamps. + ### Added - **Diagnostics tab in the SFM standalone webapp.** Surfaces the device