An event data recorder is not a flight recorder, and the gap between the two matters more than the nickname suggests. It is a small block of memory inside a module whose primary job is deciding whether to fire a restraint; recording is a secondary function performed across a few seconds around that decision. What sits inside that window — what the module measured, what it computed, and what it never saw at all — separates a download that survives cross-examination from one doing more work in a report than the data supports.
A crash sensor with a short memory
The module at the centre of a download exists to deploy restraints. It watches accelerometers, and on many vehicles wheel-speed and yaw-rate signals, deciding within milliseconds whether the deceleration it sees is a crash. The record is a by-product: a rolling buffer of pre-crash data overwritten continuously in normal driving, plus a capture of the crash interval, locked when a qualifying event occurs.
In the United States, 49 CFR Part 563 governs that record for light vehicles equipped with an EDR. The rule does not require one to be installed. It standardises the data elements, recording intervals, survivability and format for vehicles that have one, and requires retrieval to be commercially available. Older and many heavy vehicles sit outside it.
The trigger is a threshold, not a judgement
Recording begins when a change in velocity crosses a wake-up threshold, and what survives depends on what happened next. A deployment event, where restraints fired, is generally locked permanently. A non-deployment event, where the threshold was crossed but nothing fired, may be retained only until later events overwrite it or ignition cycles clear it.
The consequence is easy to miss. A minor first contact, a secondary impact, or a sideswipe before the main event may be in the record, may have been overwritten, or may never have crossed the threshold. Absence of a recorded event is not evidence that nothing happened.
Recorded, derived, and merely reported
Not every value in a download is a measurement. Some are sensed. Others are computed — speed derived from wheel-speed sensors, velocity change integrated from accelerometer output — each carrying the assumptions of its derivation. A third group is status rather than physics: belt-switch state, brake-switch state, gear position.
SAE J1698 addresses exactly this, covering how event data are defined, retrieved and verified so a reader knows what each element means. Working without the manufacturer's own definitions is how a brake-switch state becomes reported braking effort, or a belt-switch state becomes proof of belt use.
Pre-crash speed is not impact speed
Pre-crash channels are sampled on a coarse timebase, at intervals measured in fractions of a second across the seconds before the trigger. The final sample is a snapshot at a moment defined by the algorithm's own clock, not at contact. Between that sample and first contact the vehicle may have braked hard, and the difference can be substantial.
Treating the last recorded speed as impact speed is the most common error here. It is a bound, in the direction the deceleration trend indicates, and properly an input to reconstruction rather than a substitute for it.
Wheel speed carries its own error
Because speed is usually derived from wheel rotation, anything decoupling rotation from ground speed corrupts it. Lockup under braking, wheel spin, a yawing or sliding vehicle, off-nominal tyre diameter from a replacement size, and airborne wheels after a trip all produce reported speeds that are real signals but not velocity over ground.
This does not make the channel useless. It makes it something to qualify: state the source, the conditions during the recorded window, and what scene evidence independently indicates.
Imaging is a procedure, not a button
Retrieval should be documented as a forensic imaging exercise: photograph the vehicle and module in place before anything is connected, record the module part and serial numbers, note whether imaging was done through the diagnostic connector or at the module, and capture the tool and software versions with the raw output file, not only the formatted report.
Where the electrical system is compromised, direct-to-module imaging is often safer, and that choice belongs in the record.
The ways a record is lost
Data disappears through ordinary, well-intentioned handling. Driving the vehicle afterwards consumes ignition cycles that can clear a non-deployment record. Jump-starting, disconnecting the battery, or a salvage yard powering the vehicle to move it all carry risk. Replacing the restraint module during repair removes the evidence outright.
A preservation letter naming the module specifically, not just the vehicle, is a materially different instrument.
Other electronic records are not EDR data
Heavy trucks commonly hold engine-control data with a different structure, different triggers and different retention. Telematics platforms, infotainment modules, dash cameras and mobile devices each hold their own timeline. These can be richer than an EDR capture, but they are separate sources with separate provenance questions and often much shorter retention windows.
Reconciling their clocks against each other and against the EDR is part of the work, because none are guaranteed to agree.
Where these opinions are challenged
Predictably: that the last pre-crash sample was treated as impact speed, that a derived channel was described as a measurement, that the imaging chain of custody is incomplete, or that the record was read without the element definitions for that make, model year and module.
Analysis stating each channel's origin, its timebase, and how the conclusion changes if the channel is wrong tends to hold. A download reproduced as though every number were equally solid does not.
This article is general technical orientation, not a failure analysis, an engineering opinion, or advice on any specific matter. Determining the cause of a particular incident requires hands-on examination by a credentialed expert.