Every year, over 1.35 million people die in road crashes worldwide, and in the seconds after a collision, response time changes outcomes. A well-built crash detection algorithm turns a smartphone into a real-time collision sensor — identifying impact events within milliseconds from the accelerometer, gyroscope, and GPS already in every modern phone.
New to crash detection? Start with Crash Detection with Mobile Telematics for the concepts and use cases — this article is the technical deep-dive.
Below, we break down the detection pipeline end to end: the sensor physics, the classification stages, the false-positive filtering that separates a real collision from a pothole or phone drop, and the automated workflow that fires in the seconds after a crash is confirmed.
1. Sensor Fusion: How Phones Detect Crashes
Smartphone-based crash detection relies on sensor fusion — combining data from multiple independent sensors to build a more accurate picture than any single sensor could provide alone. New to sensor fusion? See How Your Smartphone Detects Driving for a primer on how each sensor works.
1.1 Accelerometer
The accelerometer measures linear acceleration along three axes (X, Y, Z). In normal driving, readings stay within ±2 m/s². During a collision, forces spike dramatically — a moderate crash at 30 mph generates 20-40 g (196-392 m/s²), while severe impacts exceed 60 g. The accelerometer captures these sudden deceleration spikes that characterize impact events.
The accelerometer data is decomposed into three components relative to vehicle movement:
- Direct (longitudinal): Acceleration/deceleration in the direction of travel — the primary collision signature
- Lateral: Side-to-side forces indicating T-bone impacts, sideswipes, or spin
- Vertical: Up/down forces from rollovers, undercarriage impacts, or launch events
1.2 Gyroscope
The gyroscope measures rotational velocity. During a crash, vehicles don’t just decelerate — they rotate. A T-bone impact causes yaw rotation, a rollover causes roll, and even frontal impacts produce pitch as the vehicle’s nose dips. The gyroscope detects these rotational signatures that distinguish a real crash from a simple hard brake.
1.3 GPS
GPS provides velocity context. A crash detection system needs to know the vehicle was moving at crash-capable speeds before the impact event. GPS also provides:
- Pre-impact speed: Validates that the deceleration magnitude matches a real collision at that velocity
- Post-impact movement: A vehicle that continues moving normally after a “crash event” likely experienced a false trigger
- Location: Exact coordinates for emergency dispatch and claims documentation
1.4 Why Single-Sensor Detection Fails
An accelerometer alone cannot distinguish a crash from a phone dropped on concrete (which can exceed 100 g). A gyroscope alone cannot tell a collision from a phone being tossed. GPS alone lacks the millisecond resolution needed for impact detection. Only by fusing all three — acceleration magnitude + rotational signature + velocity context — can the system achieve reliable detection.
2. The Detection Pipeline
The crash detection pipeline processes sensor data through multiple stages, each narrowing the classification from “something happened” to “this was a collision.”
2.1 Threshold Monitoring
The SDK continuously monitors accelerometer readings. When acceleration exceeds a configurable threshold (the trigger point), the system moves from passive monitoring to active analysis. Damoov’s SDK supports multiple sensitivity levels:
- Normal: Standard threshold for everyday driving conditions
- Sensitive: Lower threshold for detecting lower-speed impacts (parking lot collisions, minor fender-benders)
- Tough: Higher threshold for environments with rough roads or off-road vehicles where baseline vibration is higher
2.2 Impact Pattern Recognition
Once a threshold event triggers, the algorithm analyzes the full acceleration waveform. Real crashes have a characteristic signature:
- Rapid onset: Acceleration rises from baseline to peak in 50-150 milliseconds
- Sustained duration: The high-G event persists for hundreds of milliseconds (unlike a phone drop which is near-instantaneous)
- Multi-axis involvement: Real crashes produce force on multiple axes simultaneously
- Post-impact decay: Deceleration followed by oscillation as the vehicle settles
2.3 Context Validation
The pipeline cross-references the impact signature against GPS context:
- Was the device moving at vehicle speed before the event?
- Did the device stop or dramatically change velocity after the event?
- Does the rotational data match a vehicle collision pattern?
2.4 Reliability Scoring
Each detected event receives a reliability score — a confidence metric that weighs all contributing factors. Higher reliability scores trigger immediate notifications; lower scores may require additional confirmation (like detecting that the vehicle is now stationary and the driver hasn’t interacted with the phone).
3. High-Frequency Data Capture
When a crash event is detected, the system doesn’t just flag a boolean “crash happened.” It captures a high-frequency sensor buffer that records the complete physics of the impact.
3.1 Buffer Specifications
- iOS: 60 Hz sampling (60 data points per second)
- Android: 100 Hz sampling (100 data points per second)
- Window: 5 seconds before the crash + 5 seconds after the crash
This means a single crash event captures 600-1,000 individual sensor readings, creating a detailed forensic record of exactly what happened during the 10-second impact window.
3.2 What Gets Captured
The crash data buffer includes:
- Three-axis acceleration: Direct (longitudinal), lateral, and vertical — with min, max, median, and 5th/95th percentile values
- Speed: GPS-derived velocity at event start, end, and throughout the window
- Location: Start and end coordinates of the event
- Duration: Total event time and “pure duration” (time acceleration exceeded threshold)
- Trigger type: What specific condition initiated detection (e.g., low-speed threshold, high-speed threshold)
- Reliability score: System confidence in the detection
This data serves two purposes: it provides real-time intelligence for emergency response (confirming severity and location), and it becomes forensic evidence for insurance claims reconstruction. For detailed documentation of crash data fields, see Damoov’s crash data documentation.
4. False Positive Filtering
The biggest challenge in crash detection isn’t detecting crashes — it’s not detecting things that aren’t crashes. The Damoov SDK filters false positives through multi-signal validation (velocity, duration, and multi-axis gates) and configurable sensitivity profiles tuned to each deployment.
For the full false-positive analysis — source taxonomy, validation gates, and threshold tuning — see [T-212 Article 3: Crash Detection Algorithms — link pending publish].
5. What Happens After Detection
Once the system confirms a crash event with sufficient reliability, the response workflow activates within seconds.
5.1 Immediate Actions (0-5 Seconds)
- Data transmission: The high-frequency crash buffer is uploaded immediately, even over cellular data
- Backend notification: The platform fires a real-time webhook/notification to all subscribed systems (SNS, Azure, custom endpoints)
- Location fix: Final GPS coordinates are locked and transmitted with the crash event
5.2 Notification Payload
The crash notification sent to backend systems includes everything needed for immediate response:
- Event type and trigger reason
- Impact severity (derived from peak acceleration and reliability score)
- Exact GPS coordinates (start and end of event)
- Speed at impact
- Timestamp (UTC)
- User/device identifier
5.3 Response Chain
What happens next depends on the integrating application:
- Emergency services: Apps can auto-dial emergency numbers or alert monitoring centers
- Insurance claims: FNOL (First Notification of Loss) workflows trigger automatically
- Fleet management: Operations centers receive instant alerts with driver ID and location
- Family safety: Emergency contacts receive automated notifications with crash location
6. FNOL and Insurance Claims Automation
For insurance applications, crash detection’s highest-value outcome is FNOL automation — First Notification of Loss triggered instantly, without waiting for the policyholder to file a claim.
6.1 Traditional FNOL vs. Automated FNOL
| Metric | Traditional | Automated (Telematics) |
|---|---|---|
| Time to notification | Hours to days | Seconds |
| Data quality | Self-reported, inconsistent | Sensor-verified, forensic-grade |
| Fraud detection | Manual investigation | Impact data validates or contradicts claim |
| Location accuracy | “Near the intersection of…” | GPS coordinates ± 3-5 meters |
| Severity assessment | Estimated from damage photos | Measured from impact forces |
6.2 How Automated FNOL Works
- Crash detected: SDK identifies collision event with high reliability score
- Instant notification: Platform sends crash data to insurer’s claims system
- Severity triage: Peak acceleration and duration data enable immediate severity classification
- Claims file created: Automated file with timestamped sensor data, GPS location, speed, and impact vector
- Adjuster dispatched: For high-severity events, field response can begin immediately
6.3 Forensic Value
The 10-second high-frequency buffer becomes an objective record of what happened. It answers questions that traditionally require expensive accident reconstruction:
- What speed was the vehicle traveling at impact?
- What direction did the force come from? (front, side, rear)
- How severe was the deceleration?
- Did the vehicle roll or spin after impact?
- Was the vehicle moving or stationary when hit?
7. Damoov’s Crash Detection Implementation
Damoov’s Telematics SDK implements crash detection as a core capability on iOS and Android, with cross-platform support for Flutter, React Native, and Xamarin. Detection is active by default — you subscribe to crash events through the SDK’s event listener and consume the crash payload on your backend.
For use cases, integration examples, and an overview of the crash detection data payload, see Crash Detection with Mobile Telematics.
7.1 Technical Specifications
- Sensor sampling: 60 Hz (iOS) / 100 Hz (Android) during crash buffer capture
- Buffer window: ±5 seconds around the detected impact
- Sensitivity modes: Normal, Sensitive, Tough — configurable per deployment
- Background operation: detection runs even when the app is backgrounded or the screen is off
- Offline support: crash events are buffered locally and transmitted when connectivity is restored
- Platform notifications: real-time webhooks via SNS or Azure for backend alerting
7.2 Subscribing to crash events (Android)
Crash events are delivered through the SDK’s event listener alongside other trip events. Filter the array for type == "Accident":
override fun onNewEvents(context: Context, events: Array<Event>) {
val accidents = events.filter { it.type == "Accident" }
accidents.forEach { event ->
// event.theId, event.timeStart, event.speedStart,
// event.reliability, event.accidentTrigger
handleCrash(event)
}
}
7.3 Crash event payload (response schema)
When a crash is detected, the platform sends a notification containing the incident header. Key fields:
{
"Id": "b369587a-15ca-4322-95a4-971e88dc48aa",
"Type": "Accident",
"AccidentTrigger": "ACCELERATION_LOW_SPEED_THRESHOLD",
"Reliability": 2.4976,
"TimeStart": 1632473113173,
"Duration": 40996,
"SpeedStart": 0.1039,
"SpeedStop": 21.8057,
"AccelerationLateral": 1.0587,
"AccelerationDirect": 0.0857,
"AccelerationVertical": 9.0198,
"PointStart": { "Latitude": 60.0247, "Longitude": 30.2158 },
"PointEnd": { "Latitude": 60.0242, "Longitude": 30.2198 }
}
AccidentTrigger— which threshold fired (e.g.,ACCELERATION_LOW_SPEED_THRESHOLD)Reliability— confidence score for the detected eventPointStart/PointEnd— GPS coordinates at the start and end of the eventSpeedStart/SpeedStop— GPS speed (m/s) at the event boundaries
7.4 Configuration
- Sensitivity level (per user group or application-wide)
- Notification endpoints for crash events
- FNOL workflow integration (claims-system API connection)
- Custom thresholds for specialized vehicle types
7.5 Documentation and Resources
- Crash Data API Reference — full field descriptions for the crash event payload
- Callbacks & Listeners — subscribing to crash and trip events in the SDK
- Backend Notifications — webhook configuration for real-time crash alerts
FAQ
1. How does automatic crash detection work?
Automatic crash detection uses a smartphone’s built-in accelerometer, gyroscope, and GPS to identify collision events. The system continuously monitors sensor data for sudden, high-magnitude deceleration events. When a potential crash is detected, it validates the event against multiple signals — vehicle speed, force duration, rotational dynamics, and post-impact behavior — to confirm it’s a real collision before triggering alerts.
2. Can a smartphone really detect a car crash?
Yes. Modern smartphones contain the same types of sensors (MEMS accelerometers and gyroscopes) used in dedicated crash detection hardware, just in a smaller form factor. At 60-100 Hz sampling rates, a phone captures sufficient data resolution to detect and characterize vehicle collisions. The key challenge isn’t sensor capability — it’s algorithmic filtering to avoid false positives from everyday phone handling.
3. What’s the difference between crash detection and accident detection?
They refer to the same capability. “Crash detection” typically describes the technical sensor-level function, while “accident detection” is the user-facing feature name. Both mean: automatically identifying when a vehicle collision has occurred using sensor data, without any manual input from the driver.
4. How fast does crash detection respond?
From the moment of impact to backend notification: typically under 5 seconds. The SDK detects the event within the 10-second capture buffer, transmits the data immediately, and the platform fires webhooks to all subscribed systems. Total time from crash to emergency contact notification is limited primarily by network latency.
5. How are false positives prevented?
Multi-signal validation eliminates most false positives. The system requires: (1) vehicle-speed GPS velocity before the event, (2) sufficient force duration (not a point impulse like a phone drop), (3) multi-axis force signatures consistent with vehicle collision, (4) post-event behavior changes (vehicle stopping or moving erratically), and (5) rotational data matching crash dynamics. Each additional signal layer dramatically reduces false positive rates.
6. Does crash detection work without internet?
Yes. The SDK detects and records crash events locally, storing the full sensor buffer on-device. When connectivity is restored, the crash data and notifications are transmitted to the backend. Detection itself requires no network connection — only the post-crash notification delivery depends on connectivity.