Trigger to frame ready latency: exposure, readout and transfer

You assert a trigger and start a timer. The camera is set to 60 fps with 1/1000 s exposure, so a frame in about 18 ms seems fair — instead the wait reads 34 to 36 ms, and any deadline below 34 ms succeeds only sometimes. The delay from trigger-in to a complete frame in your callback is exposure plus sensor readout plus transport plus host scheduling, and it lands on multiples of the frame period, not on the number in a frame-rate setting. Below: the budget, the arithmetic for a real 60 fps case, a measurement method that does not fool itself, why the first trigger after a mode switch can vanish, and the timeout to commit to.

The number to budget

Commit to this: a triggered frame needs its exposure plus one readout period, and your timeout must cover exposure plus two. The readout period is the reciprocal of the camera's maximum frame rate at the format and pixel clock you configured; it does not shrink because a faster number was typed anywhere else. Most frames arrive a few milliseconds after exposure plus one period; the rest miss a readout slot and finish one period later, which is normal sensor behaviour, not a fault.

For the derivation of the period itself, read compute camera frame time from exposure and readout. For how fast you may trigger before frames drop, see maximum frame rate on a hardware trigger. This page covers the wait between those two questions: how long until the frame is actually in your buffer.

Where the delay comes from

Five terms add up, and you strongly influence only two of them:

• t_delay — the trigger delay you configured; zero when unset.
• t_exposure — exactly the exposure time you set.
• t_readout — fixed by sensor format and pixel clock; the one term the camera fully owns.
• t_transport — the wire: roughly frame size divided by payload bandwidth.
• t_host — the driver copy into your buffer, callback dispatch, and OS scheduling.

Sensor manuals print an exposure-and-readout timing chart with readout values such as 1/30, 1/15 or 1/7.5 s, one per format and binning mode, and that row describes only the format it lists. When the camera reaches 60 fps in triggered mode at the working format, the readout there is one 1/60 s slot, and the bench measurement below confirms it. Trust the measured period over a chart row written for another format. Whether the exposure setting itself includes readout is a sensor-specific overlap question, covered in does minimum exposure time include sensor readout time?.

Why the wait lands on frame-period multiples

The readout engine runs on its own frame-sync at the maximum frame rate. An asynchronous trigger starts exposure immediately, but the finished frame can only enter the next readout slot. Trigger just before a slot boundary and you pay exposure plus one period: 1.0 + 16.67 = 17.7 ms at 60 fps and 1/1000 s. Trigger just after a slot opens and the frame queues for the following one: 1.0 + 2 × 16.67 = 34.3 ms.

That is the whole story behind a 36 ms reading on a 60 fps camera: not a slow sensor, a missed slot. The intermittent failures below 34 to 35 ms are your timer racing the slot boundary, a coin flip decided by microseconds of trigger phase. At slow trigger rates the sensor idles between frames, the second period disappears, and latency approaches exposure plus readout — which is why a bench test at one frame per second looks clean while bursts at full rate do not.

Worked example: a 60 fps camera at 1/1000 s exposure

Inputs, each from the field case: frame-rate setting 60 fps; exposure 1/1000 s; measured waits from trigger-in to complete data of 16 to 17 ms on most frames and 34 to 36 ms on the rest, with rare stretches near 32 ms attributed to host scheduling; a VGA-class frame, so transport contributes about 3 ms or less on GigE.

The rule in words: latency is exposure plus n readout periods, with n = 1 when the trigger aligns with a slot and n = 2 when it does not.

The arithmetic:

• Frame period: T = 1/60 s = 16.67 ms
• Exposure: 1/1000 s = 1.0 ms
• Aligned slot: 1.0 + 16.67 = 17.7 ms
• Missed slot: 1.0 + 2 × 16.67 = 34.3 ms
• Timeout: 34.3 ms + 16.7 ms host margin = 51 ms, so set 50 ms

The measured 16 to 17 ms sits a millisecond under the 17.7 ms prediction, within the resolution of host timestamping. The decision: below 17.7 ms the frame is physically not complete, so any shorter deadline manufactures random failures. Between 17.7 and 34.3 ms you are flipping a coin on trigger phase. At 50 ms a missing frame is a genuine fault — trigger wiring, the wrong acquisition mode, or an overtrigger condition — and that is where debugging starts. Commit the 50 ms.

Measuring it without fooling yourself

• Timestamp the trigger at the electrical edge, with a scope or input capture, not at the moment your code calls the trigger function; that call can be delayed by the very scheduling you are trying to measure.
• Timestamp completion where the callback holds the fully copied frame, not where the callback was merely dispatched.
• Log every frame and read the histogram, not the average: peaks at one and two frame periods are the signature of slot alignment, and a long tail is the host.
• Expect roughly 15 ms scheduler hiccups on Windows, and rare stretches near 32 ms when threads transition and shared resources are contended — exactly what the field case recorded.
• Compare like with like: a vendor capture tool re-opens the device from a stopped state, so its timings will not match a live pipeline you flip mid-stream.

Writing exposure every frame costs its own one-frame delay, so lock exposure and gain before measuring, as set exposure every frame: latency and the one-frame delay explains. The same host-side discipline applies to any device you poll: non-blocking CAN read loops that prevent latency and frame loss shows the pattern on another bus.

The first trigger after a free-run to triggered switch

Repeatedly switching a live stream between free-run and triggered mode is the second classic: the first trigger sometimes returns nothing while every later one works. Three causes, in order of likelihood:

1. The mode change lands on a frame boundary. The camera applies the new acquisition mode at its next internal sync, and a trigger issued during the transition is dropped.
2. Exposure and gain are still converging. Values tuned during free-run leave auto-exposure chasing the new condition, so the first frame is dark or clipped even when it arrives — the same settling discussed in first camera frame dark: exposure settling or light timing.
3. The host queue is not armed. Until the restarted pipeline has buffers queued, the camera can complete a frame that never reaches a callback.

The fix: stop the stream, apply the mode, wait one frame period, then arm triggers, and discard the first frame as policy. A vendor capture tool succeeds here because it configures from a stopped device and typically fires a priming acquisition it throws away; your code flips a running stream in place, which is the harder path. If clean code still drops the first trigger, read the camera's release notes — at least one model shipped a firmware update specifically for first-trigger drops in this scenario. A single missed frame after a mode switch is a different fault from hardware trigger stops after one frame, which is an acquisition-mode setting rather than a transition.

Transport: the term you choose

Readout is fixed; the wire is a purchase decision. Payload rates after protocol overhead, and what a frame pays on each:

A 20 MB frame is a 20 MP mono8 sensor, and the arithmetic is frame size over payload: 20 MB / 100 MB/s = 200 ms. Small triggered parts never notice the wire; large sensors live or die by it.

A 20 MP frame is where the wire starts to matter:

The MV-CS200-10GC puts a 1-inch sensor on GigE with a C-mount, so at that resolution most of the wait is the cable. Move the frame to 10GigE and the wire stops being the constraint:

The MV-CH250-25TC-F-NF is a 25 MP camera on 10GigE with an F-mount and a fan for the sensor, exactly the class this interface was built for. Compare interfaces across the area scan cameras range or let the camera finder filter by interface. Keep the link itself boring in drag chains:

The LS-CBL-0199 is a 3 m high-flex GigE cable with screw locks for drag-chain use — a connector that works loose shows up as phantom latency long before it shows up as an error. On the host end:

The MV-GT2104 is a quad-port copper 10GbE NIC, so several cameras each keep a full link; browse the frame grabbers for CoaXPress and Camera Link options and the cables range for the rest. If a 10GigE camera crawls at 1 Gbps, the NIC packet size is the first suspect — a 10GigE camera at only 1 Gbps throughput walks the fix.

When the usual answer is wrong

• Exposure longer than the frame period. At 50 ms exposure on the same 60 fps sensor, t_ready is about 50 + 16.7 = 67 ms and the maximum trigger rate is 1 / (0.050 + 0.0167) = 15 Hz. Exposure, not readout, now sets the pace.
• Cameras sharing a bus. Two USB3 cameras on one hub split the payload; a USB hub dropping camera frame rate shows how to budget first.
• A deep buffer queue in oldest-first mode. Your callback serves stale frames and latency reads as multiples of queue depth; set newest-only stream buffer handling for live decisions.
• Overtriggering. Triggers arriving faster than one per (exposure + readout) are rejected, not delayed; the symptom is dropped frames with overtrigger errors, per sequenced exposure trigger timing.
• Binning changed the period. Binned formats read out faster, so one camera has several valid readout periods; 4x4 binning versus 2x2 works the numbers.

Checklist before you raise the timeout

1. Frame period: 1 / maximum fps at the format you set — 16.67 ms at 60 fps.
2. Exposure: from your own setting — 1.0 ms at 1/1000 s.
3. Predict both waits: exposure + 1 period and exposure + 2 periods — 17.7 and 34.3 ms here.
4. Scope the trigger edge: a clean pulse inside the input ratings comes before any timing claim.
5. Histogram the callback: two peaks one period apart means slot alignment; a smear means the host.
6. Lock exposure and gain: values moving mid-test contaminate every number.
7. After a mode switch: wait one frame period and discard the first frame.
8. Set the timeout: exposure + 2 periods + one period of margin — 50 ms for this case.
9. Only then suspect the camera: a frame missing at that timeout is wiring, mode, or overtrigger.

If the budget still does not close, run the camera step of the configurator with your frame size and rate, or bring the histogram and your timing numbers to the contact page and we will work the arithmetic with you.