extend telemetry queue to five seconds

This commit is contained in:
Jay
2026-08-17 11:53:22 -04:00
parent aceaa2b270
commit bc4a2856e1
4 changed files with 8 additions and 5 deletions
+4 -1
View File
@@ -28,6 +28,8 @@ Both breakouts share SDA, SCL, 3V3, and GND. The firmware checks both possible
- ADXL345: `0x53` or `0x1D`; expected `DEVID` is `0xE5`.
- L3G4200D: `0x69` or `0x68`; expected `WHO_AM_I` is `0xD3`.
The XIAO ESP32-C3 external antenna is installed for the upcoming BLE transport.
## Sensor configuration
- ADXL345: nominal 100 Hz output rate, full-resolution mode, +/-8 g. Nominal scale is
@@ -63,7 +65,8 @@ consumer can distinguish a fresh sample from a repeated poll and identify gyro
overruns. Hardware data-ready interrupts and FIFO acquisition are deferred to the
later sensor-side acquisition refinement.
Completed samples enter a 128-record RAM queue. A lower-priority output task
Completed samples enter a 512-record RAM queue, providing 5.12 seconds of
transport-stall tolerance at 100 Hz. A lower-priority output task
batches up to eight records into versioned `TRK1` frames, isolating acquisition
from brief USB or future BLE stalls. CRC, packet and sample sequences, timestamps,
and cumulative loss/overrun counters make loss detectable.
+2 -2
View File
@@ -75,7 +75,7 @@ before that first valid frame separately from CRC failures after synchronization
## Buffering
Acquisition runs in a dedicated higher-priority task and writes complete samples
to a 128-entry RAM queue. The lower-priority output task batches up to eight
records per frame. At 100 Hz this queue represents about 1.28 seconds of
to a 512-entry RAM queue. The lower-priority output task batches up to eight
records per frame. At 100 Hz this queue represents about 5.12 seconds of
decoupling from a blocked transport. Queue overflow never overwrites an older
sample silently: sequence gaps and the cumulative lost-sample counter expose it.
@@ -51,7 +51,7 @@ BLE link overhead, far below the previous CSV stream.
## Task separation and buffer
The 100 Hz I2C acquisition runs at FreeRTOS priority 10. USB encoding/output runs
at priority 5 and receives samples through a 128-entry queue (about 1.28 seconds
at priority 5 and receives samples through a 512-entry queue (about 5.12 seconds
at 100 Hz). The hardware capture's zero timing anomalies and zero loop overruns
confirm that packet encoding, CRC, float metadata, and USB output did not disturb
the acquisition cadence.
+1 -1
View File
@@ -22,7 +22,7 @@
#define TRIKKE_I2C_FREQ_HZ 400000
#define TRIKKE_SAMPLE_RATE_HZ 100
#define TRIKKE_SAMPLE_TICKS pdMS_TO_TICKS(1000 / TRIKKE_SAMPLE_RATE_HZ)
#define TRIKKE_SAMPLE_QUEUE_DEPTH 128
#define TRIKKE_SAMPLE_QUEUE_DEPTH 512
#define TRIKKE_METADATA_INTERVAL_PACKETS 64
// Software calibration from the 2026-08-17 enclosure six-face capture.