thejayman77/trikkeSensors
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add reliable Android BLE ride recorder

Browse Source
This commit is contained in:
Jay
2026-08-20 12:40:39 -04:00
parent 3bad2275cc
commit 6e408a3048
40 changed files with 2781 additions and 120 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/binary-record-v1.md
+11 -8
View File
@@ -106,15 +106,17 @@ does not by itself prove corruption or a hostile receiver.
## Buffering
Acquisition runs in a dedicated higher-priority task and writes complete samples
to a 1024-entry RAM queue. The lower-priority output task batches up to eight
records per frame. At 100 Hz this queue represents about 10.24 seconds of
Under BLE, acquisition does not start until the version-2 session handshake has
established a clean capture boundary. Once started, the dedicated
higher-priority acquisition task writes complete samples to a statically
reserved 3072-entry RAM queue. The lower-priority output task batches up to eight
records per frame. At 100 Hz this queue represents about 30.72 seconds of
decoupling when the transport reports backpressure or failure accurately. A
failed write retains and retries the same encoded packet rather than dequeuing
more samples, so the queue accumulates the outage backlog. After reconnection,
the oldest retained data is sent first. If the queue fills, acquisition drops
new samples rather than overwriting older ones; sequence gaps and the cumulative
lost-sample counter expose that permanent loss.
more samples, so the queue accumulates the outage backlog. After a same-token
reconnection, the oldest retained data is sent first. If the queue fills,
acquisition drops new samples rather than overwriting older ones; sequence gaps
and the cumulative lost-sample counter expose that permanent loss.
The shared transport state machine distinguishes three nonfatal states. `RETRY`
is valid only from initial submission: it means zero bytes were accepted and the
@@ -136,7 +138,8 @@ the endpoint accepts them. CRC and sequence checks make resulting loss visible,
but an application acknowledgement and replay window are still required to
guarantee receipt. Accordingly, USB `COMPLETE` means endpoint drain, while
reliable BLE reserves `COMPLETE` for an application ACK of the exact frame. See
`ble-transport-v1.md` for fragmentation, replay, and UUIDs.
`ble-transport-v2.md` for session establishment, fragmentation, replay, and
UUIDs.
Receivers report bytes left in an incomplete trailing frame when capture ends.
Those bytes cannot pass CRC validation and are not silently admitted as samples.