Camera frame timing jitter: acquisition vs arrival time

You time frames in software, the interval wanders by milliseconds, and the camera datasheet promises a fixed rate. Both observations are true: the camera exposes on a stable oscillator, while your program sees packets that the operating system and network stack deliver whenever they get to them. This page separates the two clocks, works the arithmetic that predicts each one's error, and gives you three ways to prove acquisition spacing — device timestamps, a hardware trigger and a counter on the strobe output. The numbers matter most when you fuse frames with external events or publish a frame rate in an uncertainty budget; if you only inspect parts, the milliseconds never touch the image.

Why does the frame interval I measure in software vary?

You are measuring delivery, not exposure: the camera starts every frame on its own clock at an exact period, while the operating system, driver buffers and network scheduling delay each frame independently and add milliseconds of spread to host arrival times.

Each frame carries three instants: when it was exposed, when the camera finished sending it, and when your process got hold of it. Only the first is fixed by the camera's timing logic. The rest pass through the link, the driver and the scheduler, and each contributes its own variable delay:

Host-side terms dominate. Desktop operating systems reschedule threads on millisecond scales — commonly 1-10 ms, longer when the same machine runs browsers, editors and builds alongside your acquisition. Add driver buffering and queueing on a shared link, and a few milliseconds of arrival spread is normal; tens of milliseconds appear under load or with small buffers. The isolation procedure is in GigE Vision frame arrival jitter: isolate camera and host timing.

Which clock sets the exposure instants?

The camera's own oscillator sets them: in free run the camera divides its reference clock down to the frame period, and a standard crystal holds that frequency to tens of ppm — at 70 fps, a 14.286 ms period with about ±0.7 µs of error.

Crystal tolerance is a standard electronics specification, commonly ±20 to ±50 ppm, and the ppm error scales with the period itself:

Worked example at 70 fps: T = 1/70 = 0.0142857 s = 14.286 ms. With a ±50 ppm crystal, ΔT = 14.286 ms × 50 / 1,000,000 = 0.000714 ms = ±0.71 µs. Over one second of wall time the same drift is 50 µs. Temperature swings add tens of ppm across a bench's range — still three to four orders of magnitude below the millisecond delivery spread. ±50 ppm is the working figure for a standard crystal; a specific model's ppm term sits in its timing specification.

How do I separate acquisition timing from arrival jitter in software?

Compare the camera's device timestamp against your host arrival time: GenICam cameras can latch a timestamp at exposure end and carry it in the frame's chunk data, so the gap between that value and your program's receive time is pure delivery, and its spread is your jitter budget.

Latch the camera-side value and read both times for every frame: the chunk data timestamp guide shows how the latch works, and camera frame timestamp vs system time covers converting between the camera's clock and the host's.

GigE Vision cameras with IEEE 1588 (PTP) support can discipline their clock to a network time master; once locked, camera and host share a microsecond-class time base on a dedicated link. That gives you comparable numbers without extra wiring, at the cost of a short convergence period after power-up.

How do I prove the acquisition rate with hardware?

Route the camera's strobe output into a counter/timer or oscilloscope and read the pulse spacing directly: a 10 MHz timebase resolves each period to 0.1 µs, so 100 pulses at 70 fps read 14.2857 ms with sub-microsecond scatter, and that reading is your acquisition proof.

The strobe pulse marks the exposure itself, which is exactly the event you want to time; camera strobe output timing shows how the pulse and the image timestamp relate. The procedure:

1. Enable the strobe or exposure-active output so it pulses once per exposure.
2. Feed it to a counter/timer or scope input matched to the output's electrical specification; if wiring is impractical, point an LED at the lens and time the light pulses with a photodiode instead.
3. Record 100 or more consecutive periods and compute the mean and standard deviation.

Arithmetic for the run: 100 pulses contain 99 periods, so at 70 fps the capture spans 99 × 14.2857 ms = 1,414 ms. The counter should report a 14.2857 ms mean with sub-microsecond scatter. Millisecond-scale scatter here means you are timing delivery again — check what the counter is actually connected to.

Does external triggering make timing better or worse?

Triggering moves the decision, not the accuracy: it lets you choose the exposure instants, and the spacing then takes its accuracy from your trigger source — a logic-level pulse train from a counter or timer card holds microsecond-class edge timing, comparable to the camera's free-run clock.

Trigger latency through the input stage is a few microseconds and near-constant, so it shifts every frame equally and does not spread the spacing. What spreads spacing is the source: a software-generated pulse that has crossed an operating system inherits the same scheduling jitter you were trying to escape. Trigger when the exposure instants must line up with something outside the camera — a stimulus, a fixture, another camera — and take timing for all of them from one pulse source.

Triggering also sets a rate ceiling: the period must cover exposure plus readout. At a 70 fps target, the 14.29 ms period leaves 13.29 ms for readout when exposure is 1 ms; if the sensor needs longer, the achievable rate drops below 70 fps. Maximum frame rate on a hardware trigger works that limit, and trigger call versus exposure time explains why the trigger instant and the exposure window are not the same event.

When does one timestamp per frame stop telling the truth?

On a rolling-shutter sensor the rows start at different times, so a frame is a time sweep rather than an instant: row n begins row n × t_row after row 0, and for an event that moves during the scan, that skew — not delivery jitter — dominates the error.

Take 10 µs per row across 2,048 rows — illustrative figures: the sweep is 20.5 ms, longer than the 14.29 ms period of the 70 fps example. An event landing mid-scan cannot be assigned to a single time, however good the clock is. A global-shutter sensor exposes every pixel in the same instant, so the latched timestamp describes one moment; where an event's time within the frame matters, global shutter is the requirement.

Every frame is then one instant on one clock:

What goes into the timing budget, and what stays out?

Put the clock term — and, if triggered, the trigger source's jitter — into the acquisition budget, leave host delivery in the latency budget, and at 70 fps free run that first line is ±0.71 µs per interval.

The split, for the 70 fps example:

Only the first three rows describe acquisition. The last row is latency: it delays when you see the frame and never changes what the frame contains. If the measurement compares image events with external signals, subtract delivery first — the device timestamp exists for exactly that — and Compute camera frame time from exposure and readout gives the exposure-plus-readout arithmetic behind the period budget.

Which approach should you use for your case?

Match the method to the job: inspection needs none of this, correlating frames with external events needs device timestamps or a hardware trigger, and publishing a rate needs a counter on the strobe output.

• Viewing and defect inspection. Free run and host arrival times are fine. Millisecond delivery jitter never changes what is inside the frame, so the timing budget needs no line for it.
• Stimulus-response and multi-camera work. Take time from the camera side: chunk timestamps, PTP where the camera offers it, or one hardware trigger feeding camera and stimulus from the same source. Budget ±0.71 µs of clock error per interval at 70 fps, plus your trigger source's jitter.
• Published rates and calibration. Counter/timer on the strobe output, mean period with its scatter — 14.2857 ms with sub-microsecond scatter is consistent with the ±0.71 µs crystal term.

Two bench choices keep those numbers honest. Rolling shutter is out for timing work, so pick a global-shutter model from the area scan cameras range — the camera finder filters by shutter type. Then put the camera on a dedicated NIC port rather than sharing an onboard controller with office traffic:

The MV-GE2002P is a dual-port PoE GigE NIC, so a second port stays free for another camera on its own link. The accessories finder lists NICs and frame grabbers; for CoaXPress and Camera Link set-ups the card's FPGA handles trigger and timing capture, as frame grabber FPGA types explains. To spec the whole chain, start the camera configurator, and the systems topic page collects the rest of the timing guides.