Why sensor synchronisation matters

A trace from a steering sensor and a trace from a yaw-rate sensor can both be perfectly accurate and still tell the wrong story. If one lags the other by 30 milliseconds, an analyst will read a delay in the vehicle’s response that is really a delay in the data. Synchronisation is the part of instrumentation that decides whether channels can be compared at all.

Sampling is a choice

The sampling theorem says a signal must be sampled at more than twice its highest frequency of interest. Anything faster than half the sample rate folds back into the data as a false, slower signal, which is why an analogue anti-alias filter sits in front of the converter. In practice engineers sample several times faster than the minimum. Brake pressure has fast edges and deserves hundreds of samples per second. A thermocouple on a duct may need only ten.

Channels recorded at different rates are not a problem in themselves. They become one when the timestamps they carry are not comparable.

Clocks drift

Every logger counts time with an oscillator, and oscillators are never exact. A crystal with a tolerance of 20 parts per million gains or loses 72 milliseconds in an hour. Two loggers that were aligned at the start of a test session are therefore noticeably apart by the end of it, and the error grows steadily rather than appearing as noise.

There are two common remedies. One is to distribute a shared time reference, such as a protocol like IEEE 1588, which on suitable hardware can align clocks to well under a microsecond. The other is to log a common event or a periodic sync pulse on every device and correct the drift afterwards.

Where the timestamp is applied

A sensor samples at one moment, and the logger may record the value at another. On a CAN-style bus, frames wait for arbitration, travel and sit in a buffer. If the logger stamps each frame when it arrives, the stamp includes that variable wait. Stamping at the sensor, or sending a counter with each sample, removes it. The design question is simple to state: where in the chain is the time written, and how large is the uncertainty between there and the physical event?

Aligning video with data

Video is a useful witness but a coarse clock. At 30 frames per second a frame lasts 33 milliseconds; at 60 it lasts 17. At 100 km/h a vehicle covers 27.8 metres per second, so one frame is almost a metre of travel, and a single millisecond is about 2.8 centimetres. Aligning video with telemetry therefore needs a visible, recorded event — a light that flashes when logging starts, for example — rather than trust in the start of the file.

Filters move signals in time

Smoothing a channel delays it. A causal low-pass filter, the kind that runs in a controller, shifts the signal later by an amount that depends on its cut-off frequency. Offline, a forward-and-backward filter can cancel that shift, but it cannot be used in real time. If two channels pass through different filters, they are shifted by different amounts, and a synchronised pair can leave the pipeline misaligned again.

A practical checklist

• Record the sample rate, anti-alias filter and any digital filter for every channel.
• State where each timestamp is applied and how its uncertainty was estimated.
• Log a common sync event at the start and end of every session to measure drift.
• Compare filter delays across channels before comparing phase between them.
• Keep raw timestamps alongside the corrected ones.

None of this is difficult. It is just easy to leave until after the test, when the cost of getting it wrong is a month of analysis built on channels that never lined up.