# 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.

`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
```