Damoov

Posted on Aug 3 • Originally published at damoov.com

Crash Detection Algorithms on Smartphones: How to Minimize False Positives in Telematics Apps

#mobile #android #ios #telematics

Detecting a high-G impact on a smartphone accelerometer is straightforward. Knowing whether that impact was a vehicle collision — and acting on it without flooding your claims desk with pothole alerts — is where crash detection algorithms earn or lose integrator trust.

This article is the canonical false-positive reference for Damoov's developer content series. It covers validation pipeline architecture, severity-banded classification, threshold tuning for different deployments, and how to handle accident events in production code. For the full crash-detection pipeline (sensor fusion, high-frequency capture, FNOL), see How Automatic Crash Detection Works. For the business and use-case angle, start with Crash Detection with Mobile Telematics.

Why false positives dominate the engineering problem

A phone in a moving vehicle experiences dozens of high-G events per day that have nothing to do with collisions: drops onto a seat, door slams, speed bumps, hard braking, railway crossings. A naive threshold — "trigger if acceleration exceeds X g" — produces alert volumes that make the feature unusable.

The cost of getting this wrong is asymmetric:

Insurance FNOL. Every false alert creates a claims touchpoint, adjuster time, and policyholder anxiety. Alert fatigue erodes trust in the entire telematics program.
Fleet safety. Managers stop responding when 80% of "crashes" are curb bumps on urban routes.
Emergency services. False positives in SOS workflows have regulatory and liability implications.

The crash detection algorithm that ships in production is therefore a filtering problem layered on top of a detection problem. Detection finds candidate impacts; validation decides which candidates become confirmed accidents.

False positive taxonomy: what triggers look like

False positives fall into predictable categories. Understanding the taxonomy helps you tune thresholds and explain alert volumes to stakeholders — without treating every pothole as a unique mystery.

Device-handling events (no vehicle context)

Phone drop — extreme peak G (50–200 g), near-instant duration, single-axis dominant, no preceding vehicle speed.
Phone toss onto seat — sharp deceleration spike, rotation pattern inconsistent with vehicle impact, no GPS velocity context.

Road-surface events (vehicle moving, sub-collision forces)

Potholes and speed bumps — vertical-axis dominant spike (3–8 g), vehicle continues at speed, no sustained multi-axis deceleration signature.
Railway crossings and expansion joints — rhythmic vertical impulses; duration and frequency distinguish from deformation events.

Driving dynamics (real vehicle, below crash threshold)

Hard braking without collision — sustained longitudinal deceleration (3–6 g) but vehicle continues moving; below crash confirmation gates.
Aggressive cornering — lateral G elevated but no impact discontinuity; gyroscope shows controlled rotation not impact spin.

Post 15100 summarizes these categories in its detection pipeline overview. This article goes deeper on how the algorithm rejects them — the gates, bands, and tuning levers — not the source list itself.

Multi-signal validation pipeline

Reliable crash detection algorithms require convergence across independent signals before confirming an accident. No single gate is sufficient; the pipeline stacks them in sequence:

Velocity gate — device was traveling at vehicle speed (typically >15 km/h) in the seconds before the event. Filters stationary phone drops and parking-lot handling.
Duration gate — high-G persists long enough to reflect vehicle deformation, not a point impulse. A dropped phone peaks and returns in milliseconds; collision energy dissipates over hundreds of milliseconds.
Multi-axis gate — real crashes produce significant force on at least two axes (longitudinal + lateral or vertical). Single-axis dominance flags handling events.
Post-event behavior gate — after a confirmed crash, the vehicle typically stops or moves erratically. Continuing at highway speed after a 40 g spike is a rejection signal.
Rotation correlation gate — gyroscope dynamics must be consistent with vehicle impact, not device rotation in a cup holder.

Each gate is a configurable threshold, not a hardcoded constant. That is what makes the same architecture work for teen-driver monitoring (more sensitive) and long-haul fleet on rough roads (more tolerant).

Severity-banded classification

After validation, confirmed events are classified into severity bands that drive downstream behavior. Treating every confirmed impact as a maximum-severity FNOL is how integrators burn out their operations team.

A practical three-band model:

Band	Typical signature	Recommended action
Low	Passes minimum gates; peak G and duration below high-severity thresholds; reliability score moderate	Log event, include in trip timeline, no automated FNOL
Medium	Strong multi-axis signature; reliability above review threshold; speed context consistent with minor collision	In-app driver prompt ("Were you in an accident?"); queue for manual review
High	High peak G, sustained duration, post-event stop, high reliability score	Trigger FNOL workflow, emergency contact, high-frequency buffer upload

The Damoov platform exposes a Reliability score on accident events (see Crash Data) — a numeric confidence measure integrators can map directly to these bands. An event with low reliability should not trigger the same workflow as one scoring high confidence, regardless of peak G alone.

Threshold tuning by deployment

There is no universal threshold set. The same algorithm architecture supports different sensitivity profiles:

Sensitive (UBI, teen monitoring) — lower velocity gate, shorter duration minimum, more medium-band events. Accepts higher false-positive rate in exchange for catching low-speed parking-lot impacts.
Standard (general insurance) — balanced defaults. Suitable for mixed urban/suburban driving.
Tough (fleet, rough-road routes) — higher G thresholds, stricter multi-axis requirements, longer duration gate. Reduces pothole and speed-bump triggers on degraded surfaces.

Tuning is not a one-time launch task. Monitor false-positive rate per 1,000 trips by road-type segment and adjust quarterly. A fleet operating exclusively in urban cores needs different parameters than long-haul highway logistics.

Handling accident events in code

When the SDK detects a candidate accident, it surfaces through the event callback. Your app should filter by event type and apply reliability-based routing — not treat every callback as a confirmed crash.

Android / Kotlin — filter and route by reliability:

override fun onNewEvents(context: Context, events: Array<Event>) {
    events.filter { it.type == "Accident" }.forEach { accident ->
        when {
            accident.reliability >= HIGH_RELIABILITY_THRESHOLD -> {
                // High band: trigger FNOL / emergency workflow
                triggerFnolWorkflow(accident)
            }
            accident.reliability >= REVIEW_THRESHOLD -> {
                // Medium band: prompt driver or queue for review
                showAccidentConfirmationDialog(accident)
            }
            else -> {
                // Low band: log only, no automated claims action
                logSubThresholdAccident(accident)
            }
        }
    }
}

The accident payload includes peak accelerations, speed at impact, duration, GPS coordinates, and the reliability score. Full field reference: Crash Data documentation. High-frequency sensor buffers (60 Hz iOS / 100 Hz Android, 5 seconds before and after) upload separately for forensic review on high-band events.

Measuring alert fatigue in production

Integrators should track these metrics from launch, not after the claims desk complains:

Confirmed accidents per 1,000 trips — baseline varies by market; sudden spikes often indicate threshold misconfiguration, not more crashes.
FNOL auto-triggers overturned by driver denial — high denial rate = sensitivity too aggressive.
Medium-band events with no user response — may indicate prompt fatigue; consider raising review threshold.
Reliability score distribution — if 90% of events cluster below review threshold, your high-band gate may be too strict (missing real crashes).
Geographic clustering — false positives concentrated on specific routes often indicate road-surface triggers; tune Tough profile for those user segments.

Pair SDK event data with claims outcomes after 90 days to calibrate bands. The goal is a stable precision/recall trade-off documented for actuarial and operations stakeholders.

Common pitfalls

Peak G alone. A 40 g spike without velocity context, duration, and multi-axis confirmation is not a crash. This is the most common DIY implementation mistake.
One global threshold. Urban gig drivers and rural fleet haulers need different profiles. Use segment-level tuning or user-group settings.
Skipping reliability. The platform computes confidence for a reason. Routing all Accident-type events to FNOL ignores it.
No driver confirmation layer. Medium-band prompts reduce false FNOL without sacrificing high-band automation.
Duplicating 15100 §4 in a second article. Keep pipeline context on post 15100; keep false-positive depth here.

Ship crash detection that operations teams trust

False-positive control is what separates a demo from a production crash detection deployment. The Damoov Telematics SDK implements multi-signal validation, severity-banded classification, and reliability scoring — so your team routes high-confidence events to FNOL and filters the rest before they reach a human.

Explore the Telematics SDK or read Crash Data to integrate accident event handling into your claims workflow.

DEV Community