The Event Data Recorder download has become the centerpiece of modern reconstruction. A clean download, a glossy report, several seconds of vehicle speed sampled at 2 Hz — for many cases it is the closest thing to a videotape of the moments before impact. Treated correctly, it is invaluable. Treated as gospel, it is dangerous.
The pre-crash buffer is not recorded continuously to non-volatile memory. It is a rolling window held in RAM and committed only when a deployment-level event is detected. If the trigger threshold is met during a complex multi-impact sequence, the buffer that is preserved may correspond to the wrong impact in the chain. We have seen cases where the recorded pre-crash speeds belonged to the second impact, not the first — and where the first impact was the one that mattered.
Firmware matters as well. Manufacturers periodically issue technical bulletins documenting known issues with specific modules — and the bulletins are not widely distributed outside the reconstruction community. An expert relying on raw EDR values without cross-checking against physical evidence will be impeached, fairly, on cross-examination.
Three practical recommendations for counsel.
First, always have the EDR imaged by your own expert, even when the opposing expert has already done so. Modern imaging tools produce a hash; the hashes should match. If they do not, something has been altered.
Second, never accept EDR data as a substitute for physical evidence. The two should reinforce each other. When they diverge, the divergence is itself the evidence.
Third, ask your reconstructionist specifically whether they have considered firmware-level anomalies in the module at issue. The answer should be more than 'I assume the data is correct.'