# Hardware outage fixtures

These captures came from the assembled XIAO ESP32-C3 prototype. The files
contain only complete, CRC-valid `TRK1` frames.

The two forced-outage captures used a temporary validation build that made the
packet writer report failure while acquisition kept running. That injection was
removed before production firmware was built and flashed.

- `forced_outage_3s.trk` — SHA-256
  `01482816cdaa668e4681c33c8baa1df331d733b9bbcbc4f448ece25e88185ad6`.
  It contains 2,144 contiguous samples, sequences 0 through 2,143, with no
  reported drops, overruns, or timestamp saturation.
- `forced_outage_7s.trk` — SHA-256
  `2ea8a5742944bdebc13bec2ccdbceba75f0bb71e48c856b0f86285878e190cd3`.
  It contains 1,840 delivered samples. The sole sequence gap is 511 to 650:
  138 samples were dropped after the 512-entry queue filled, the cumulative
  drop count reached 138, and the corresponding timestamp delta is exactly
  1,390,000 us.
- `direct_usb_stall.trk` — SHA-256
  `40f874b7eaa7f705524ecdd75f832e8a724252366633116ac015fc75dfd16558`.
  This came from the direct USB driver build after leaving the enumerated USB
  endpoint without a serial reader long enough to overflow the acquisition
  queue. It contains 864 samples. The retained block ends at sequence 511,
  delivery resumes at 1,706, and both the sole 1,194-sample gap and the device's
  cumulative drop counter equal 1,194. There are no packet gaps, CRC failures,
  loop overruns, trailing bytes, or timestamp-saturation flags.

  The first captured sample is sequence 8 because the flashing process still
  had the endpoint open long enough to drain sequences 0 through 7 before the
  capture application opened. That is deliberate evidence of the remaining
  distinction: USB endpoint drain is observable, but application receipt
  requires the planned acknowledgement/replay layer.
- `direct_usb_3c95f3d.trk` — SHA-256
  `f495486f094a758bb785e145026e3934d60b52dd5083aef7f5d896195d967869`.
  This is the validated-frame output from the final exact-commit smoke capture:
  1,680 contiguous samples, sequences 0 through 1,679, with zero packet/sample
  gaps, resets, CRC failures, reported drops, loop overruns, trailing bytes, or
  timestamp saturation.
- `direct_usb_3c95f3d.wire` — SHA-256
  `3bdaeadff7962c6eac48c4ebeda285c8eb359e439d5e1728104add2009122c03`.
  This is the byte-for-byte wire side of the same capture. It contains 563 bytes
  of startup text before the valid frames. That text includes the literal
  `TRK1`, producing one rejected candidate header as designed. Extracting all
  valid frames reproduces `direct_usb_3c95f3d.trk` byte-for-byte.
- `direct_usb_73e5680.trk` — SHA-256
  `fd34bb3bf8f92a64960024f1287e553c03076ff3714fe629ec629bec81ddf821`.
  This exact firmware-hardening capture contains 1,184 contiguous samples,
  sequences 0 through 1,183, with zero packet/sample gaps, resets, CRC failures,
  reported drops, loop overruns, trailing bytes, or timestamp saturation.
- `direct_usb_73e5680.wire` — SHA-256
  `82d6d17bbf0729e9bfc53f337ec9adf70bcb5e5898b039685eda5dfa19cf4eea`.
  This is the byte-for-byte `--reset --wire` capture corresponding to the
  validated file above. Its 3,589 skipped startup bytes and one candidate-header
  rejection are deterministic, and extracting its 151 valid frames reproduces
  `direct_usb_73e5680.trk` byte-for-byte.
- `ble_reconnect_483ace3.trk` — SHA-256
  `c4a0d795cdf9d490acaca0144c3ad33f85bbfb2214d3f7abdfe515c4e5f25398`.
  This is the resumed half of a real macOS receiver interruption against exact
  firmware commit `483ace3`. It contains 2,576 contiguous samples, sequences
  1,992 through 4,567, with zero packet/sample gaps, resets, CRC failures,
  reported drops, loop overruns, trailing bytes, or timestamp saturation. The
  final status records one disconnect and one deliberate frame replay, with
  zero notification failures or invalid ACKs. It validates that the 10.24-second
  queue covered the measured resubscription interval without permanent loss.
  Of its 2,575 contiguous sample intervals, 1,293 differ from exactly 10 ms.
  Absolute deviation has a 4 us median, 160 us p95, 170 us p99, and 780 us
  maximum; cumulative error is 152 us over 25.75 seconds. This records bounded
  BLE scheduling jitter without rate drift and requires timestamp-derived `dt`
  in future fusion work.
- `ble_mtu_race_4bf00eb.trk` — SHA-256
  `4a231b54a3c7320fd69cac869b830e94aca8f704f946881b9cdfd21991bfa41f`.
  This exact-commit stress capture followed six rapid subscribe, first-fragment,
  and disconnect cycles aimed at the MTU lookup race. Telemetry remained live
  afterward: the capture contains 1,848 CRC-valid samples with zero packet gaps,
  resets, send failures, or invalid ACKs, while status records exactly six
  disconnects and six replays. The test deliberately withheld application ACKs
  beyond the 10.24-second queue window, so sequences 1,024 through 4,021 were
  intentionally lost; the single 2,998-sample gap, matching queue-overflow total,
  demonstrates bounded buffer exhaustion rather than a suspended output task.
- `ride_20260820_090607.trk` — SHA-256
  `c938934c0905748d2f8d8be61cff1ff446d8415b34850628654967398fd7d91f`.
  This is the Android recorder acceptance capture after increasing the firmware
  queue to 3,072 samples (30.72 seconds). Bluetooth was deliberately disabled
  from the phone for five seconds and then restored. The completed capture
  contains 2,578 consecutive packets and 19,984 consecutive samples, both
  starting at sequence zero, with zero CRC/header errors, packet/sample gaps,
  sensor failures, queue overflows, transport send failures, invalid ACKs,
  loop overruns, or trailing bytes. Firmware status records one disconnect and
  one replay. The Android recorder durably deduplicated that exact replay, as
  recorded in `ride_20260820_090607.session.json` (SHA-256
  `b16a8f0c213a14fd2760b6efba1c6288f3631e57a331c553893e281dce047888`),
  and closed the session with `complete=true` and no error.

  All 19,983 sample intervals are contiguous. Of those, 8,745 differ from
  exactly 10 ms. Across all intervals, absolute deviation is 0 us median, 40 us
  p95, 240 us p99, and 1,630 us maximum; among only the off-grid intervals it is
  10 us median, 60 us p95, and 750 us p99. Cumulative error is -726 us over
  199.83 seconds. The capture also has six explicitly flagged ADXL345 overruns;
  timestamps are taken before both I2C reads and therefore understate delays
  caused by preemption between the timestamp and physical sensor access.

The post-rename phone smoke test for application ID
`com.jsjdesigns.trikkerecorder` was verified live but not retained as a fixture.
It closed cleanly with 366 consecutive frames and 2,832 consecutive samples,
zero CRC/header errors, packet/sample gaps, drops, queue overflows, loop
overruns, or trailing bytes. The package-only rename did not change the Android
protocol or storage implementation, and the retained outage fixture above
remains the authoritative end-to-end acceptance artifact.

`tests/test_trikke_protocol.py` verifies the hashes, parses the captures in
fragmented chunks, and asserts these signatures so the hardware evidence remains
executable regression data. To inspect a file manually:

```sh
python3 tools/decode_binary.py tests/fixtures/forced_outage_3s.trk /tmp/outage.csv
```