PPS GPS camera time sync: timestamp at exposure start or end

A GPS-disciplined camera promises timestamps you can line up with a wheel encoder, an IMU trace or a second camera — until someone asks whether the stored value marks the start of the exposure, the end of it, or somewhere in between. For a rig running on PPS sync the answer is fixed and printed, and turning a timestamp into a capture time takes one line of arithmetic. This guide gives you the latch convention per acquisition mode, the published offset and its spread, the midpoint formula with the microseconds worked through, the drift a PPS pulse actually removes, and the status flags that prove the lock is real. The worked numbers come from one published GPS camera family; your camera manual prints its own values on the same pattern, and the decision at the end covers the case where it prints none.

Which instant does the stored timestamp actually mark?

The timestamp marks one fixed, stated instant of the exposure, never a random point between the timestamp and the timestamp plus the shutter, so a trigger-mode frame's completion time is simply the stored time minus the latch offset — about 45 µs in the published example below.

The latch point does not move with gain, shutter width or illumination. The value comes from a counter inside the camera that starts at power-up and increments on its own oscillator; exposure settings only change the shutter term you add or subtract afterwards. A trigger-mode frame therefore completes at the stamp minus the offset, not somewhere inside the shutter window, and the only open question is which edge your camera family chose to latch. Reading the value belongs to the acquisition code itself: the guide on chunk data timestamps latched at exposure end shows how to pull the stamped instant per frame instead of falling back to host receive time.

Does the camera latch the timestamp at exposure start or exposure end?

The convention depends on the acquisition mode: the published GPS camera example stores the stamp at the end of integration in trigger mode and at the start of integration in free run, while many non-GPS families latch at the start in both.

The reason for two conventions is mechanical. A triggered camera stamps the integration it has just completed; a free-running camera stamps when acquisition starts, before the shutter opens. Many non-GPS families latch at start of integration in both modes, which is why copying another camera's formula silently costs one shutter width. At a 2 ms exposure on a part moving 1 m/s, that copying error alone puts every logged event 2 mm away from the truth.

How do you calculate the true capture midpoint from the timestamp?

In trigger mode subtract the latch offset and half the shutter from the stored time — with a +45 µs offset and a 2 ms exposure that is 45 + 1,000 = 1,045 µs before the timestamp — while in free run you add half the shutter instead.

Both terms come off the frame itself. The shutter value arrives with the image — each frame can carry its timestamp and exposure as chunk data — and the offset is a single printed number; add it in free run too if the manual quotes one there. Shutter accuracy adds its own term: a shutter specified to ±5% at 2 ms shifts the midpoint by up to ±50 µs, which dwarfs the ±8 µs offset spread and is worth knowing before you chase nanoseconds.

The completion instant answers the original question directly: 10:00:05.500000 - 45 µs = 10:00:05.499955, and it is exactly as deterministic as the midpoint.

What does the PPS pulse correct, and by how much?

Each PPS edge steers the camera's free-running counter back to GPS time; a typical camera oscillator drifts 25-50 ppm, which is 3 ms after one minute and 180 ms after one hour without correction, so the pulse is what keeps a multi-hour capture honest.

Left alone, the counter starts from the host or boot clock at power-up and drifts at the oscillator rate. The arithmetic compounds quickly: 50 ppm is 50 µs per second, 3,000 µs after one minute and 180,000 µs — 180 ms — after one hour. Each PPS edge erases the accumulation by steering the counter onto the UTC second. Between edges the counter still wanders by its ppm figure, so roughly 50 µs of intra-second wobble is the realistic residual for a typical camera oscillator, and the ±8 µs latch spread in the example is what remains once steering is active. How a camera counter differs from wall-clock time in the first place is its own subject; camera frame timestamp versus system time covers the clock sources.

How do you confirm the PPS sync has locked?

Judge sync by the receiver status flags, not by how plausible the timestamps look: in the published example, sync counts as achieved only when GPS status, PPS status and fix quality all read locked — fix quality 1 or 2 and the PPS flag set.

Fix quality 1 means an autonomous satellite fix and 2 a differential one; before both flags read locked, many receivers emit no pulse at all, and the camera keeps stamping free-running local time that still looks plausible. Log the three flags with every capture and re-check them at each power-up, because yesterday's lock says nothing about today. A pulse that never arrives is wiring or compatibility: confirm the pulse on a scope, confirm its level against the camera's input window, and confirm the receiver is one the camera SDK explicitly supports. The wider menu of timing sources, from free run to PTP-scheduled capture, is compared in the industrial camera trigger modes guide.

What hardware carries the PPS pulse into the cameras?

The receiver's pulse-per-second output drives each camera's trigger or opto-isolated GPIO input — one rising edge per UTC second — with a one-to-many buffer splitting the same edge to every camera in a multi-camera rig, so all counters steer on the same event.

A PPS signal is one electrical pulse per second whose rising edge lands on the UTC second. The receiver drives it into each camera's trigger or opto-isolated input; the camera manual states the voltage window and which input selects timestamping from that pin. Keep camera runs shielded and similar in length — propagation costs about 5 ns per metre, so a 10 m imbalance shifts one counter roughly 50 ns against the other, real but far below the ±8 µs spread you inherit anyway. Indoor rigs need a receiver that keeps disciplining without a sky view, or a pulse generator standing in for GPS during bench tests.

How far apart do PPS-synchronized cameras still land?

Cameras sharing one PPS edge keep their counters within the pulse distribution skew — about 5 ns per metre of cable difference, so roughly 50 ns across a 10 m imbalance — and the dominant residual is each camera's latch offset, ±8 µs in the example.

Counters agreeing is not images matching. Two cameras stamped 10:00:05.500000 in the same trigger convention, one with a 1 ms shutter and one with 2 ms, hold midpoints 500 µs apart — 10:00:05.499455 against 10:00:05.498955 — so correlate midpoints, never raw stamps. Choose each shutter from the motion budget rather than convenience; exposure time versus shutter speed for moving parts walks that calculation. And when the frames themselves must align, PPS will not do it: clock and cadence are separate problems, and the spacing between frames is exposure plus readout, as maximum frame rate on a hardware trigger derives.

When does the latch convention trip up a working system?

The expensive mistakes are assuming a start-latch on an end-latch camera — a 2 ms shutter then shifts every event time by the full 2 ms — mixing free-run and trigger cameras under one PPS source, and trusting stamps before the fix flags ever read locked.

• A configuration reset quietly returns a camera to free run, so it stamps at start of integration while your arithmetic still assumes end of integration; the hardware trigger configuration guide covers pinning the mode.
• Mixed modes under one PPS source: the free-run camera stamps at start and the triggered one at end, so the apparent skew between them equals the shutter difference rather than zero.
• A wrapped counter: finite timestamp registers roll over, and mapping the wrap onto monotonic host time is its own exercise — see the timestamp rollover guide.
• Stamps read before the fix flags lock carry the 3 ms-per-minute drift, not the ±8 µs you designed around.

Which capture hardware do you need for a PPS rig?

Budget the ports before the pulses: two GigE cameras share one dual-port PoE NIC, four 10GigE cameras fit a quad-port copper card, and the camera you buy must state GPS or PPS discipline plus per-frame shutter in its SDK — the latch numbers above exist only where the manual prints them.

On the camera side the requirement is documentation: GPS or PPS discipline, the latch point, the offset and per-frame exposure must all appear in the manual or SDK, because every number above is only as good as that printed line. On the host side, size the ports to the camera count and the interface bandwidth. The area scan cameras category covers the sensor side and the frame grabbers category the host side; the camera step of the configurator filters mounts and interfaces either way.

Two cameras on GigE, with power over the same cable, are the classic single-card rig.

The MV-GE2002P is a dual-port PoE NIC built for exactly that layout. Each camera lands on its own port, and power rides the network cable toward the host.

Larger 10GigE rigs scale the same logic onto copper runs rated for the higher bandwidth.

The MV-GT2104 is a quad-port copper 10GbE NIC. Four cameras terminate on that single card before anything reaches the host.

CoaXPress rigs swap NICs for frame grabbers; the extras step of the configurator narrows those by interface and port count.

The decision, per case. A trigger-mode camera with an end-of-integration latch: completion is the timestamp minus the offset, and the midpoint is the timestamp minus the offset minus half the shutter — 10:00:05.498955 for the worked frame. A free-run camera with a start-of-integration latch: the midpoint is the timestamp plus half the shutter. A multi-camera rig: distribute one PPS edge through a buffer, log the fix flags with every capture, and correlate midpoints rather than stamps. And if the manual never prints the latch point or the offset, that camera cannot deliver deterministic GPS time, however fine its counter resolution — choose one whose documentation does.

The surrounding timing pieces — frame-time arithmetic, chunk data, rollover handling — sit together on the systems topic page.