Event camera IMU sync quality evaluation with a shared trigger

An event camera and an IMU can share a hardware trigger and still look unsynchronized if you test them the wrong way. The usual check — did the acceleration step or the event burst rise first during the shake — returns a different winner on every run, even on a rig whose clocks are perfectly coupled. The randomness belongs to the test, not to the rig. This page gives you the test that works: split one trigger pulse into both devices, use the recorded trigger timestamps as a shared ruler, and score synchronization by the spread of the offset that ruler reports. You get the wiring, the bound you can claim in milliseconds, a worked example for a 1 kHz IMU, and the pass/fail numbers to hold the result against.

Why the lead-or-lag test flips sign on a good rig

The two streams do not measure the same thing and do not report it at the same moment. An IMU samples acceleration at its own instants and ships each value over its bus one or more samples later. An event camera stamps brightness-change events on the sensor itself, at microsecond resolution. Between a physical jolt and the value you read, each device adds latency: bus transfer and filtering on the IMU side, detection and packetization on the camera side.

Each side also carries an onset rule that you control. You mark the start of the disturbance when acceleration crosses a threshold and when the event rate surges. Those rules react at different speeds, and the acceleration threshold reacts at a speed that depends on shake amplitude.

So the measured lead or lag equals (IMU latency + threshold delay) − (camera detection delay) + clock offset. The threshold term alone swings by about a millisecond between runs, more than the sync you are trying to prove. The sign comes out as a coin toss even on a perfectly coupled rig. A stable timestamp relationship inside each stream proves each clock is steady; it says nothing about whether the two clocks agree. To test agreement, both devices must see the same third event.

One pulse, two timestamp records: the ruler

Drive one pulse generator at rate f_p and split its output so both devices receive every edge. The event camera writes each pulse into its trigger-timestamp record, in the same clock as its events. The IMU side records the same edge, either into the IMU's mark input or onto the timer that stamps the IMU samples. You now hold two mark trains, one per device, built from the same pulses.

Every IMU sample at time t_s falls between two consecutive marks m(k) and m(k+1) in the IMU clock, and those same two marks exist in the camera clock. The bracket moves the sample into the camera time base:

Snapping each onset to its nearest mark on both sides gives the worst case: the pairing error between an event and its IMU sample is at most one trigger period. Linear interpolation between the bracketing marks collapses that bound to timestamp jitter plus relative drift across a single pulse interval. For ±25 to ±50 ppm oscillators, drift across a 0.5 ms interval is 50 × 10⁻⁶ × 0.5 ms = 25 ns, so the interpolated pairing error sits well under a microsecond. The interpolation weight is the same arithmetic used to align two timestamp streams by interpolation.

The ruler works because the pulse is a third, dominant event present in both records and paired by index, not by physics. The devices never need to share a clock epoch; the marks couple them.

Wiring the shared pulse

Use one source and one split. A function generator, a PLC fast output or an MCU timer pin all work. Split with a buffered fan-out rather than a Y-cable — the same wiring that fans one TTL pulse out to several cameras, one buffer per branch, keeps the edges sharp into both inputs. A single pulse feeding two devices is also how two cameras fire together on one shared pulse; you are building that hardware and scoring it differently.

Match the levels before the first pulse.

Route the camera leg through a power and I/O cable, and keep a breakout on the bench for a scope or logger tap. The two cables below cover both jobs.

On a rig that moves during the test, run the streaming link in a high-flex GigE cable rated for drag-chain service, so the cabling survives the motion test after test.

Set the pulse width near 10 µs. That clears the few-microsecond minimums common on trigger inputs and costs 2% of the 0.5 ms period at a 2 kHz pulse rate.

Running the test

1. Set the pulse rate to twice the IMU rate or faster. For a 1 kHz IMU, 2 kHz pulses put every sample strictly inside a 0.5 ms bracket.
2. Fire at least 30 isolated disturbances. A finger tap on the mount is enough; each one produces one event burst and one acceleration step.
3. Detect the burst onset as the first event after a quiet gap and the step as the first sample past a fixed acceleration threshold. Fix both rules before the run.
4. Snap each onset to its nearest mark, or interpolate between the two marks that bracket it.
5. Compute Δt = t_burst − t_step for every repeat and report the mean and the spread, max minus min, across all repeats.
6. Confirm the mark counts: each stream must show exactly the number of pulses the generator sent.

Run one recording with the mount untouched. A quiet recording should contain no bursts; if it does, the detector is firing on noise, and the spread you measure later is a property of the detector, not of the sync. The residual Δt is not zero even on perfect hardware, because it carries the IMU's filter and transfer latency plus the camera's response time. That is expected: the mean becomes a calibration constant and the spread is the quality figure.

Worked example: 1 kHz IMU, 2 kHz pulses

The periods first: T_imu = 1 / 1000 Hz = 1 ms and T_p = 1 / 2000 Hz = 0.5 ms. The nearest-mark bound is 0.25 ms + 0.25 ms = 0.5 ms, half a sample period, so the rig can order any event against any sample, and interpolate to better still.

Thirty tap repeats give residuals in milliseconds with a mean of +0.22, a minimum of +0.19 and a maximum of +0.24.

• Spread = 0.24 − 0.19 = 0.05 ms, a twentieth of the sample period.
• Mean, checked on the first five repeats: (0.21 + 0.24 + 0.19 + 0.22 + 0.23) / 5 = 1.09 / 5 = 0.218 ms, which rounds to 0.22 ms.
• Camera-side mark spacing measured at 0.49997 ms against the generator's 0.5 ms, a relative clock offset of 60 × 10⁻⁶ = 60 ppm.

Verdict: pass. The spread of 0.05 ms shows the two devices respond to the same edge with constant latency; the +0.22 ms mean is the combined device delay and goes into your time-offset calibration as a fixed number. The 60 ppm offset would slip 3.6 ms over one minute if you paired the mark trains once and walked away — but pairing at every mark re-anchors the ruler every 0.5 ms, so the slip never enters a measurement.

Reading the result: spread decides, mean gets absorbed

A constant offset inside one sample period is harmless to fusion; a jittering one is not. If the spread passes and results still degrade, suspect a variable latency — burst-mode bus delays produce exactly that — rather than the clock coupling. Scrambled ordering inside one of the streams is the same fault seen from the timestamp side, and the out-of-order timestamps check isolates it. Once the offset is one constant, a fusion filter absorbs it; the Kalman filter walkthrough for IMU and camera data shows where that constant enters the state.

Drift and long recordings

The bracket method contains drift by construction, provided you re-pair at every mark. Pair the trains once at the start and assume the offset holds, and crystal error accumulates instead: two ±25 ppm clocks can drift 50 ppm apart, which over a 60 s recording is 50 × 10⁻⁶ × 60 s = 3 ms, three full sample periods of a 1 kHz IMU. Re-pairing per mark means the ambiguity never exceeds one pulse period.

For hour-long unattended captures, give both devices a disciplined time base and keep the pulse test as the audit. PTP on a dedicated network typically holds device clocks to sub-microsecond agreement, and the marks then verify that agreement against real sampling instants — the part clock discipline alone cannot see. Where the recorder's own clock enters the picture, the camera-to-PC timestamp mapping covers the recording side.

The same test on any triggered camera

Nothing in the method is specific to event cameras. Any device that latches a trigger timestamp into its own time base can be audited against an IMU with the same ruler: area scan cameras on motion stages, depth cameras, force and torque loggers. GigE cameras in this class expose hardware trigger inputs on their I/O connector.

The MV-CU020-90GC, a 2.5 MP GigE camera with a 1/1.7" sensor and a global shutter, is the kind of triggered camera this ruler audits on a stage rig. The scoring is identical: bracket the IMU sample, bracket the trigger-latched frame, compare. One change is that a frame-triggered camera samples once per exposure, so the pass line is the frame period — 10 ms at 100 fps, from 1 / 100 Hz — which almost any wiring achieves. What the test still catches is the surprise case: a trigger routed through software instead of the input, or an exposure that lags the strobe by a variable delay. A fixed delay is ordinary and modelled; the trigger-to-detection delay timing page shows how, and why a variable one is the fault.

Checks before you trust the spread

• Mark counts equal pulse counts in both records.
• Measured mark spacing matches 1 / f_p on both sides within tens of ppm.
• One recording with the pulse line disconnected produces no marks in either stream.
• The mean of the first ten repeats matches the mean of the last ten within a fraction of a sample period.
• The quiet recording contains no detected bursts.
• Thresholds were fixed before repeat one, not adjusted afterwards.

Where to go next

Build the ruler once and reuse it on every multi-sensor rig. Pick a trigger-capable camera in the camera finder, pull the trigger and I/O cabling from the cables category, and let the system configurator match camera, cabling and trigger accessories into one order. If you want a wiring sketch checked against your IMU's mark input before first power-on, send it through the contact page. More timing and synchronization guides sit on the systems topic page.