Waveform decode bug: some events decode to monotonic ramps/garbage (corrupts shape-based FT detection) #32

New Issue

2026-08-24T19:11:51-04:00

serversdown commented

2026-08-24 19:11:51 -04:00

Symptom

SFM's waveform decode is wrong for SOME events — they render as a monotonic ramp / garbage in the app instead of a real geophone oscillation. The renderer is fine (it draws good events correctly); this is a parser/decode bug in the codec.

Evidence (both serial BE9558, MiniMate Plus series3, project "I-80-North Fork Bridges - 87 Jenks St.")

BE9558 @ 2026-05-04 15:02:30 (waveform key 0111b242): TRAN peak 0.5350 in/s but the TRAN trace is a smooth ramp -0.6 -> +0.6 over the record; LONG/VERT look like decode noise. Not a real event.
BE9558 @ 2026-02-20 16:00:14 (key 0111bbd8): decodes perfectly — clean decaying oscillation (peaks 0.415 / 0.690 / 0.260).

Same unit + same series -> renderer is fine; the codec diverges on certain events.

Impact (not cosmetic)

A ramp has crest factor ~= 1 and ~100% of samples near the peak — exactly the signature seen on a cluster of events during the Phase A shape-metrics work. So the Phase A shape_crest_factor / shape_near_peak_count columns, and the Phase B1 false-trigger suspicion built on them, are garbage-in for affected events.

How to investigate

Pull an affected event's raw BW binary + its preserved <serial>/<filename>_ASCII.TXT (Blastware's own report = ground truth; downloadable via the event-detail modal's "original .TXT download"). Decode the binary by hand and find where minimateplus/waveform_codec.py diverges from the TXT's reported peaks/samples. The .h5 is decoded from the BW binary (int16 ADC counts -> in/s via geo range in sfm/event_hdf5.py::_samples_to_float), NOT from the TXT — so TXT vs h5 is the diff.

Separate suspected issue

Mic (MicL) rendering also looks off in the modal — likely a third, unrelated thing.

Logged from the FT-feature session 2026-08-24; deferred to a dedicated debugging session.

## Symptom SFM's waveform decode is wrong for SOME events — they render as a monotonic ramp / garbage in the app instead of a real geophone oscillation. The renderer is fine (it draws good events correctly); this is a parser/decode bug in the codec. ## Evidence (both serial BE9558, MiniMate Plus series3, project "I-80-North Fork Bridges - 87 Jenks St.") - **BE9558 @ 2026-05-04 15:02:30** (waveform key `0111b242`): TRAN peak 0.5350 in/s but the TRAN trace is a smooth ramp -0.6 -> +0.6 over the record; LONG/VERT look like decode noise. Not a real event. - **BE9558 @ 2026-02-20 16:00:14** (key `0111bbd8`): decodes perfectly — clean decaying oscillation (peaks 0.415 / 0.690 / 0.260). Same unit + same series -> renderer is fine; the codec diverges on certain events. ## Impact (not cosmetic) A ramp has crest factor ~= 1 and ~100% of samples near the peak — exactly the signature seen on a cluster of events during the Phase A shape-metrics work. So the Phase A `shape_crest_factor` / `shape_near_peak_count` columns, and the Phase B1 false-trigger suspicion built on them, are garbage-in for affected events. ## How to investigate Pull an affected event's raw BW binary + its preserved `<serial>/<filename>_ASCII.TXT` (Blastware's own report = ground truth; downloadable via the event-detail modal's "original .TXT download"). Decode the binary by hand and find where `minimateplus/waveform_codec.py` diverges from the TXT's reported peaks/samples. The `.h5` is decoded from the BW binary (int16 ADC counts -> in/s via geo range in `sfm/event_hdf5.py::_samples_to_float`), NOT from the TXT — so TXT vs h5 is the diff. ## Separate suspected issue Mic (MicL) rendering also looks off in the modal — likely a third, unrelated thing. _Logged from the FT-feature session 2026-08-24; deferred to a dedicated debugging session._

serversdown commented

2026-08-24 23:23:53 -04:00

Scope + detector (from the FT-feature session, 2026-08-25)

Characterized the bug: it's in the decode-to-.h5 stage (sample data), not rendering — the .h5 peak matches the device-reported peak, but the samples carry a large DC offset / baseline instead of oscillating around zero.

Detector: dominant-axis |mean| / peak — a healthy AC geophone trace ≈ 0; affected traces ≫ 0 (the known-bad BE9558 @ 2026-05-04 15:02:30 reads 0.84 on TRAN).

Scope (across 1,687 waveform events with full samples in the dev snapshot, |mean|/peak > 0.3):

364 affected (22%)
series-3: 361 / 1301 (28%) ← the bug lives here (MiniMate Plus BW-binary codec)
series-4: 3 / 386 (1%) — negligible

Impact on the shape-based FT detection (Phase A/B1): peaks + magnitude/cross-axis signals are unaffected (device-report-derived), but crest-factor + points-near-peak come from these samples, so a DC-offset trace reads as crest≈1.2 / many-points-near-peak → misclassified as a real ringing event (false negative), never over-flagged.

Sequencing decision: fix this before the prod shape backfill/deploy (it also mis-decodes new series-3 events, and the fix requires re-decoding affected .h5 + re-backfilling). Fine to backfill dev now for UX testing (idempotent; re-run after the fix).

Where to dig: the series-3 BW-binary → samples path — minimateplus/waveform_codec.py + sfm/event_hdf5.py::_samples_to_float (geo-range scaling / baseline subtraction). Compare the decoded samples against the preserved <serial>/<filename>_ASCII.TXT (Blastware's own values = ground truth).

### Scope + detector (from the FT-feature session, 2026-08-25) Characterized the bug: it's in the **decode-to-`.h5` stage** (sample data), not rendering — the `.h5` peak matches the device-reported peak, but the samples carry a large **DC offset / baseline** instead of oscillating around zero. **Detector:** dominant-axis `|mean| / peak` — a healthy AC geophone trace ≈ 0; affected traces ≫ 0 (the known-bad BE9558 @ 2026-05-04 15:02:30 reads **0.84** on TRAN). **Scope** (across 1,687 waveform events with full samples in the dev snapshot, `|mean|/peak > 0.3`): - **364 affected (22%)** - **series-3: 361 / 1301 (28%)** ← the bug lives here (MiniMate Plus BW-binary codec) - series-4: 3 / 386 (1%) — negligible **Impact on the shape-based FT detection (Phase A/B1):** peaks + magnitude/cross-axis signals are unaffected (device-report-derived), but crest-factor + points-near-peak come from these samples, so a DC-offset trace reads as crest≈1.2 / many-points-near-peak → misclassified as a *real ringing event* (false negative), never over-flagged. **Sequencing decision:** fix this before the prod shape backfill/deploy (it also mis-decodes new series-3 events, and the fix requires re-decoding affected `.h5` + re-backfilling). Fine to backfill dev now for UX testing (idempotent; re-run after the fix). **Where to dig:** the series-3 BW-binary → samples path — `minimateplus/waveform_codec.py` + `sfm/event_hdf5.py::_samples_to_float` (geo-range scaling / baseline subtraction). Compare the decoded samples against the preserved `<serial>/<filename>_ASCII.TXT` (Blastware's own values = ground truth).

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: serversdown/seismo-relay#32