THE PROBLEM
Vehicle crashes produce a surge of time-critical information that emergency services and insurance providers need immediately but rarely receive accurately. Manual crash reporting is slow, incomplete, and depends on the driver being able to report at all. The initial implementation conditioned SOS dispatch on the full evidence chain finishing first, video encoding, upload, confirmation, which measured out at roughly 14 minutes. Re-architecting around a dual-path pipeline cut that to about 30 seconds in bench testing, with no driver action required.
ENGINEERING DECISIONS
Raspberry Pi 5, not Pi 4 or a microcontroller
The Pi 5's quad-core Cortex-A76 gives headroom to run four real-time jobs at once without any of them starving: 100 Hz IMU polling, hardware H.264 encoding at 30 fps into the ring buffer, LTE/NMEA I/O, and ffmpeg frame extraction after a trigger. A microcontroller can't do concurrent workloads like that, and the Pi 4 didn't have the margin to keep all four running smoothly under load, which mattered specifically because a crash detection system that stutters right after impact fails at the one moment it can't afford to.
Decouple SOS dispatch from video upload entirely
The obvious design queues telemetry, waits for the post-event clip to finish recording and uploading, then dispatches. That's what the first implementation did, and it measured out to roughly 14 minutes crash-to-SOS, dominated by encoding and upload, exactly the two things a cellular connection is worst at right after a collision. The fix wasn't optimizing that path, it was deleting it from the critical one: the device POSTs the crash record and confirms with clip_uploaded=false immediately on trigger, which starts server-side auto-SOS on telemetry alone. The clip and key frames upload afterward on a separate, deferred path that triggers AI forensics once it lands. That single architectural change, not a faster encoder or a bigger pipe, is what took dispatch latency to about 30 seconds, independent of clip size or network conditions.
An N-of-M debounce instead of a raw threshold
A bare acceleration threshold fires on anything sharp, and Lebanese roads produce plenty of sharp, single-sample spikes that have nothing to do with a crash: potholes, speed bumps, aggressive braking. A genuine crash pulse sustains force over tens of milliseconds; a pothole doesn't. Requiring 3 consecutive 100 Hz samples above 4.0g before triggering, roughly a 30 ms sustained-force minimum, rejects the single-spike case without needing a learned model to tell the difference. It's a cheap, deterministic filter tuned to a specific, real failure mode of the road network the device actually has to run on.
Gemini and a dedicated OCR service in parallel, not one vision model
Reading a license plate and assessing whether a crash narrative is internally consistent are different problems, and asking one model to do both well is a worse bet than routing each to something built for it. The forensic stage runs Gemini's multimodal video analysis, which cross-checks the footage against the sensor telemetry for consistency (in one recorded case it correctly flagged a 4.1g event whose video showed no camera movement as a likely staged claim), in parallel with a dedicated plate-recognition API tuned for the region, then resolves any detected plate against the Lebanese vehicle registry. Splitting the two meant each could fail independently without taking the whole forensic report down with it.