3. Data acquisition for crash pulse emulation

Crash pulse emulation is only as trustworthy as the acceleration history fed into the sled controller. A pulse that looks plausible on a plot but was captured with the wrong sensor, an aliased sample rate, or an undocumented filter will drive the sled to a deceleration profile that no longer represents the vehicle it is supposed to reproduce. This section covers the acquisition chain from transducer selection through the preprocessed pulse that enters the emulation target file.

Sensor Selection and Placement

The primary measurement for pulse emulation is longitudinal acceleration at a rigid, non-crushing location. In full-scale barrier tests, this is typically the vehicle's rocker panel or a dedicated accelerometer block welded to the floorpan near the B-pillar, oriented along the vehicle X-axis. The convention used throughout this course is positive X forward, positive acceleration forward; a frontal impact therefore produces a large negative longitudinal acceleration. State this convention explicitly in every test report, because sign errors are the most common cause of an inverted sled pulse.

Sensor type matters. Piezoresistive accelerometers with a range of ±500 g to ±2000 g are standard for crash pulses; capacitive MEMS devices are acceptable for lower-severity sled work but have poorer high-frequency behavior. Mount the accelerometer with its sensitive axis parallel to the direction of travel and torque it to the manufacturer's specification — a loose sensor produces spurious high-frequency content that survives filtering as a distorted pulse.

For sled tests, the same accelerometer is mounted on the sled carriage or on the buck structure at the equivalent vehicle location. If the goal is to reproduce occupant-zone deceleration, measure on the buck floor; if the goal is to reproduce the vehicle's center-of-gravity pulse, measure on the carriage. These two locations give different pulses, and mixing them is a frequent source of mismatch.

Sampling Rate and Anti-Alias Filtering

SAE J211 specifies a channel filter class for crash data. Class 60 (cutoff at 60 Hz, −3 dB) is the standard for vehicle structure and occupant compartment acceleration; Class 180 and Class 1000 are used for higher-frequency measurements such as seat belt loads or component-level response. The sampling rate must be at least ten times the channel filter cutoff to avoid aliasing and to preserve the filter's phase behavior. For Class 60, a minimum of 1000 Hz is common; 10 kHz is used when the raw signal must be retained for later re-filtering.

The anti-alias filter must be applied before the analog-to-digital converter, not after. If the data logger only offers a fixed hardware anti-alias filter, verify its cutoff and roll-off; a 2-pole filter at 1 kHz does not adequately protect a 10 kHz sample rate from content near 5 kHz. The practical rule is: hardware anti-alias cutoff ≤ sample rate / 5, and the J211 channel filter is applied digitally during post-processing.

Never apply the J211 filter in the data logger and then re-filter in post-processing. Double filtering attenuates the pulse peak and shifts the timing of the deceleration onset, which directly biases the sled target.

Preprocessing Pipeline

Raw acceleration data from a crash test contains offset, drift, and integration artifacts. The preprocessing sequence below is the one used in this course; it is applied identically to full-scale and sled data so that the two are comparable.

  1. Offset removal. Compute the mean of a 50 ms window before the trigger event (T0) and subtract it from the entire record. This removes the DC bias of the accelerometer and the logger.
  2. Zeroing at T0. Define T0 as the last sample before the first sample exceeding 0.5 g. Set the pre-trigger baseline to exactly zero so that integration starts from a known state.
  3. J211 Class 60 digital filtering. Apply a 4-pole phaseless (zero-phase) Butterworth filter with a 60 Hz cutoff, or the SAE-specified equivalent. Phaseless filtering is essential: a causal filter delays the pulse and corrupts the timing of the deceleration peak.
  4. Integration to velocity. Integrate the filtered acceleration with the trapezoidal rule to obtain Δv(t). The final Δv must match the barrier impact velocity within ±2%; if it does not, the offset removal or the filter cutoff is wrong.
  5. Integration to displacement. Integrate velocity to obtain the crush displacement. Compare the peak displacement against the measured vehicle crush; a mismatch greater than 10% indicates residual drift.
  6. Resampling to the emulation time base. The sled controller typically expects a fixed time step (commonly 1 ms or 0.5 ms). Resample with linear interpolation and re-check Δv after resampling.

The velocity check is the single most useful validation gate. A pulse that integrates to the correct Δv but has the wrong peak timing will still produce a poor sled result, so also verify that the time of peak deceleration and the pulse duration match the reference test within one sample.

Worked Example: From Raw Record to Sled Target

Assume a 50 km/h frontal full-scale test. The barrier impact velocity is 13.89 m/s. The rocker-panel accelerometer is sampled at 10 kHz with a 1 kHz hardware anti-alias filter. After offset removal and J211 Class 60 filtering, the record integrates to −13.72 m/s, a 1.2% error — acceptable. Peak deceleration is −42.3 g at 68 ms, and the pulse returns to zero at 118 ms.

For the sled target, the pulse is resampled to 1 ms and the sign is inverted so that the sled controller commands a deceleration (positive command = deceleration in most controllers; confirm your controller's convention). The resulting target file has 119 points. Before running the sled, verify the target by integrating it in the controller's preview mode: the displayed Δv should read 13.72 m/s.

# Example preprocessing check (Python-style pseudocode)
a_raw = load_channel("rocker_x", fs=10000)      # g, positive forward
a_raw -= mean(a_raw[t < t0 - 0.05])              # offset removal
a_filt = j211_class60(a_raw, fs=10000)           # zero-phase, 60 Hz
v = cumtrapz(a_filt * 9.81, dx=1/fs)             # m/s
dv = v[-1] - v[0]                                # should be ~ -13.89 m/s
print(f"delta-v = {dv:.2f} m/s, error = {abs(dv+13.89)/13.89*100:.1f}%")

Common Failure Modes and Troubleshooting

SymptomLikely causeAction
Δv error > 5%Offset not removed, or filter cutoff too lowRe-check pre-trigger window; verify J211 class
Pulse peak too lowDouble filtering, or sensor range saturationInspect raw record for clipping; remove post-filter
High-frequency ringingLoose sensor or cable resonanceRe-torque sensor; strain-relieve cable
Timing shifted lateCausal (non-zero-phase) filterRe-filter with zero-phase implementation
Sled result overshootsSign convention invertedConfirm controller polarity; re-check target file
Crash Pulse Acquisition and Preprocessing Chain Transducer Piezoresistive ±500–2000 g Rocker / buck floor Anti-Alias Hardware LPF fc ≤ fs / 5 Before ADC Digitize fs = 10 kHz 16-bit min T0 trigger Preprocessing Offset removal → Zero at T0 J211 Class 60 zero-phase filter Integrate → Δv, displacement Validation Gate: Δv and Displacement Check |Δv − V_impact| ≤ 2% • Peak displacement within 10% of measured crush PASS → Resample 1 ms time base, invert sign FAIL → Diagnose Offset / filter / clipping Sled Target File 119 points @ 1 ms • Δv = 13.72 m/s Convention +X forward Frontal impact = −a

The chain above is deliberately linear because the physics is linear: each stage transforms the signal in a way that must be validated before the next. The two gates that catch the most errors are the Δv check after integration and the sign check before the target file is written. In practice, a well-instrumented full-scale test with a clean rocker-panel channel will pass both on the first attempt; a sled test with a poorly mounted accelerometer will usually fail the Δv check because the spurious high-frequency content integrates into a nonzero velocity offset. When that happens, inspect the raw record before touching the filter settings — the problem is almost always mechanical, not numerical.