Event camera tracking: split events between two mirror positions

Two targets, one event camera, one fast steering mirror: the trigger input stamps every move, and you sort the event stream on that stamp plus a delay. Yet both targets still appear in every reconstruction. The cause is structural, not a configuration slip: four separate offsets sit between the trigger edge and the first trustworthy event of a dwell, and the sensor's share of them moves with your event rate. Event cameras earn their keep on fast motion, but their timestamps carry latency that a fixed delay cannot absorb.

If the sensor choice is still open, compare event based vision against frame cameras for fast motion before building the optics. This guide takes the 200 Hz two-target case, shows where each offset lives, and walks through measuring the real boundary from your own stream, gating it per travel direction, and deciding when the mirror has to go.

Why a trigger plus a fixed delay cannot separate the dwells

A sorting rule of the form keep every event with t_event greater than t_trigger plus d must satisfy two conditions at once. The delay d has to exceed every offset between the trigger edge and the first event of the new dwell, and that total has to stay constant. Here neither holds: the mirror side is repeatable but never zero, and the sensor side is neither repeatable nor zero.

The stream carries no target tag. During a move, the whole scene sweeps across the sensor and every pixel on the path emits, which produces a dense burst of events belonging to neither target. Each event is timestamped when the sensor emits it, not when the photons arrived. So an event from target A generated just before the move can carry a stamp after the trigger, and a travel event can land late enough to pose as dwell B.

The gate opens after the driver response (t_response), the travel and settle burst (t_burst), and a guard band (t_guard) sized to the drift of the sensor latency. That guard is the term a fixed delay never has.

The four offsets between a trigger edge and clean events

1. Trigger-to-timestamp offset. The trigger input latches the edge into the sensor's own time base and places a trigger stamp in the stream. Events and stamps then share one clock, so the fixed part of this offset cancels in the gate arithmetic and only cycle-to-cycle jitter survives. The same bookkeeping appears on conveyor lines, where trigger delay timing offsets the camera fire against part travel. Frame pipelines do the identical latching with chunk-data timestamps that record the camera's time at exposure end; latch on the camera, never on the host.

2. Mirror driver response. The edge reaches the driver, the servo builds current, and only then does the mirror leave position A. No datasheet settles this for your load and drive electronics; the histogram in the next section measures it as the quiet gap before the burst.

3. Travel and settle. The sweep and the ringing after arrival make the burst, usually the largest offset. It can differ between the two directions: backlash and asymmetric loads make the B-to-A move slower than the A-to-B move, so measure both.

4. Sensor latency. Per-pixel detection and arbitration delay each event by microseconds at low rates and toward a millisecond or so when many pixels fire together. The mean is tolerable; the spread blurs the boundary. Your readout path adds its own share on top, so read buffer latency between the camera and your code separately when you debug.

Find the real boundary with a trigger-time histogram

1. Record at least 1,000 trigger cycles of raw events with their stamps, on the scene and biases you actually run. Sort nothing yet.
2. Assign each event to the most recent stamp before it and compute dt = t_event - t_trigger. Events before the first stamp belong to the opening dwell and can be dropped.
3. Histogram dt in 50 µs bins, one histogram per travel direction. The shape repeats every cycle: a quiet gap, a dense burst, then the dwell floor.
4. Read the burst end where the count settles to the dwell floor, and read how that bin moves across cycles; with 1,000 cycles you can quote a 3-sigma spread.
5. Open each gate at t_burst_end + t_guard, with t_guard equal to the 3-sigma spread rounded up to the next bin.
6. Validate spatially: project the gated events of one dwell and confirm they cluster inside the target footprint. Scatter between footprints means the gate still opens too early.

Worked example: two targets at 200 Hz with a 1.45 ms settle burst

Inputs, with their sources: trigger rate 200 Hz, one trigger per mirror move, from the tracking set-up this guide is built on, giving a dwell of 5 ms per position. Burst measurements come from the histogram procedure above, run over 1,000 cycles per direction on such a rig: the burst starts about 40 µs after the stamp and ends at 1.45 ms for the A-to-B move and 1.52 ms for B-to-A. The 3-sigma spread of the burst end is 180 µs, so the guard rounds up to 200 µs at 50 µs bins.

Rule in words: the gate opens at the burst end plus the guard, everything from there to the next trigger's gate belongs to the new position, and the clean window is what remains of the dwell.

Arithmetic:

• dwell = 1 / 200 Hz = 0.005 s = 5.0 ms per position
• gate open, A to B: 1.45 + 0.20 = 1.65 ms, run at 1.70 ms
• gate open, B to A: 1.52 + 0.20 = 1.72 ms, run at 1.75 ms
• clean window, A to B: 5.0 - 1.70 = 3.30 ms, which is 66% of the dwell
• clean window, B to A: 5.0 - 1.75 = 3.25 ms
• margin floor: 5 × spread = 5 × 0.20 = 1.00 ms; both windows clear it by more than 3×

Decision: keep the 200 Hz trigger and run per-direction gates of 1.70 ms and 1.75 ms. The decision rule is that the clean window must stay above five times the measured spread, because the spread is the 3-sigma jitter of the boundary and scene changes push latency within it. If a heavier load pushed the burst to 4.5 ms, the window at 200 Hz would fall to 5.0 - 4.70 = 0.30 ms, below the 1.00 ms floor; the fix is not a tighter gate but a slower clock, since at 100 Hz the dwell doubles to 10.0 ms and the same burst leaves 10.0 - 4.70 = 5.30 ms clean.

Events still mixed? Causes in order of probability

1. The gate opens inside the burst. The delay came from a settle figure rather than the stream. Test: if the histogram has not fallen to the dwell floor at your gate time, this is it. Fix: move the gate to the measured burst end plus the guard.
2. Latency drift between scenes. The gate was measured on one scene and runs on another with a different event rate. Test: repeat the histogram on the high-contrast scene and watch the burst end move late. Fix: widen the guard to the worst spread, or cut the rate as below.
3. One gate for both directions. Backlash makes one move slower; the worked example showed a 70 µs difference between directions. Test: separate histograms per direction. Fix: per-direction gates; on geared or belt-driven mirrors the difference reaches hundreds of microseconds.
4. Trigger stamps jitter or drop. The stamp was taken on the host after transport instead of on the camera's trigger input. Test: histogram the intervals between stamps; at 200 Hz each must read 5.0 ms within a small fraction of the guard, and a missing stamp shifts every later dt by a full dwell. Fix: latch on the hardware trigger input and read the stamp from the stream.
5. Late ringing inside the dwell. The histogram looks settled but the mirror still oscillates at low amplitude. Test: an event map of the last millisecond of each dwell shows residual bands along the scan direction. Fix: extend the gate, or take the mirror controller's in-position output as a second, later stamp.

Cut the latency at the source: event rate and bias settings

Sensor latency and its spread grow with the event rate, and rate reduction through the bias settings is the first lever the sensor vendor's own tuning guide gives. Moves in the order that costs least sensitivity:

• Raise the change threshold or lengthen the per-pixel refractory period so background edges stop firing on every flicker.
• Remove illumination and high-contrast edges you do not need; every one of them spends readout bandwidth.
• Crop to the two footprints; pixels outside them cannot contribute anything useful.

As the rate falls, the burst tightens, the spread shrinks, and the same measured procedure returns an earlier gate. The trade is sensitivity to small or slow contrast changes, so re-run your tracking accuracy check after each change.

Watch the link as well: once the event stream saturates it, events drop wholesale and the boundary you measured stops existing, which is what happens when an event camera's data throughput is exceeded. Frame cameras meet the same wall differently, where exposure settings cap the frame rate.

When one sensor should replace the mirror

The gate earns its complexity only when the targets cannot share one field of view. When they can, remove the mirror: one lens, one continuous stream, no travel bursts and no per-direction gates. For two viewpoints, run two cameras on one hardware trigger and pair their recordings; the failure modes move from timestamps to trigger wiring across two cameras. And when the job is really two targets in 3D, a depth camera watching both at once, such as the MV-DT01WMU, replaces the moving assembly with a static one.

Compare depth, stereo and profiler options against your field of view in the 3D sensors category or the camera finder.

Prevention checklist before the next recording run

• Record 1,000+ cycles per direction before trusting any gate.
• Keep one gate per travel direction, never one for both.
• Size the guard from the measured 3-sigma spread, not from a round figure.
• Log the bias set with every recording; a gate is only valid for the biases it was measured with.
• Check the clean window stays above five times the spread; below that, slow the trigger before tightening anything.
• Histogram the intervals between trigger stamps; 5.0 ms at 200 Hz with a tight spread confirms the stamp path.
• Re-run the spatial cluster check whenever the scene, the optics or the illumination change.

If the timing chain still fights you, the vision system configurator's trigger step walks camera, trigger and cabling as one chain, and the systems topic collects the timing guides. For a set-up question that needs a person, bring your trigger rate and measured burst to the contact page.