Race Timing System: Recovery and scope

Recovery and scope

• SQLite archives raw reads and reconstructs results chronologically, so duplicate/reordered *delivered* data do not rely on process memory. Restart with the identical config and database.
• Enable/test reader retention if needed. Local storage cannot recover events never delivered by the reader; retention capacity and behavior depend on firmware/configuration.
• Back up SQLite using its backup API or stop all capture before copying the database; a live WAL database may have uncheckpointed data in its sidecar files.
• This prototype scans archived reads to reconstruct results and uses a single foreground HTTP receiver. It has not been load-tested for dense race starts or measured against a real FX9600. It is not an HA production server.
• Hardware acceptance work remains: capture a real payload, verify timestamp semantics/clock offset, calibrate antennas/read-zone placement and thresholds, test concurrent runners and missed/late reads, and reconcile against a reference timing method.
• Not yet included: LLRP/MQTT adapters, automatic direction detection, mandatory split-order validation, reader heartbeat monitoring, raw-read editing/voiding, graphical antenna configuration, integrated Hub tag/lap/split APIs, or automatic result approval. Lap elapsed readings remain local.