trikkeSensors/tests/fixtures/README.md

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:

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