PTP timestamp sync for GigE cameras, lidar and IMU

A camera, a lidar and an IMU each stamp their own output on their own oscillator, and those clocks drift apart by milliseconds within minutes — enough to smear every fused point cloud and to break camera-IMU calibration. On a GigE network the fix is IEEE 1588 Precision Time Protocol (PTP). A GigE Vision 2.0 camera slaves its internal clock to one grand master on the network, so the chunk timestamp latched at exposure end becomes directly comparable with the lidar's and the IMU's stamps. This guide walks through enabling PTP on every camera, publishing the timestamp your fusion stack can actually use, the trigger-line fallback for USB3 cameras, and the jumbo-frame change that keeps every frame complete once all the streams run together.

Choose the clock path for each device

Decide per device before you touch software. The rule: a device on the GigE network that implements GigE Vision 2.0 joins PTP; a device on USB or a serial bus takes a shared trigger pulse plus an estimated residual delay.

PTP capability shows in the feature tree, not on a shelf card: open the transport-layer features of one of our GigE area scan cameras and look for the PTP group. If the group is there, the camera joins the clock network; if not, that camera belongs on the trigger line.

What PTP changes, and what it does not

PTP is the IEEE 1588 standard folded into GigE Vision 2.0. Devices exchange timed messages, elect one grand master, and each camera corrects its clock offset against the master using hardware timestamps rather than host software time. Vendors document microsecond-level multi-camera accuracy once the cameras have converged; convergence takes seconds to a couple of minutes depending on the announce rate, and until then the stamps are simply unsynced.

Two things PTP does not do. It does not align shutters: frames still start on each camera's own schedule unless you trigger them, so two PTP-synced cameras can still expose milliseconds apart. And it does not add bandwidth: the periodic PTP messages total kilobits per second while the pixel stream takes hundreds of megabits. Both facts drive the decisions below.

Step 1: put every GigE camera on the PTP clock

1. Open the camera in your SDK's browser and find the PTP group in the transport-layer features — an enable switch, a status readout and the network role. Naming varies between camera families, but the group itself is part of the GigE Vision 2.0 feature set.
2. Set the role to slave on every camera, or leave the election free and force master only on your most stable clock — usually the lidar or a dedicated time source. One master, many slaves; the protocol settles the ordering on its own.
3. Wait for convergence before you trust anything. Read the PTP status: it should report a synced or slave state with a small, stable offset. Several announce cycles must pass, so give it a minute rather than a second.
4. Repeat on every camera. One un-synced camera stamps in its own time base and quietly corrupts the fusion.

Cross-check with hardware: enable chunk timestamps (next section), point two cameras at one blinking LED and compare the stamps. For role choice, the epoch question and that cross-check in more depth, see PTP GigE camera synchronization: master, slave and timestamp check.

Step 2: publish the timestamp your fusion stack can use

The camera owns the stamp, which is why the driver's timestamp parameters are read-only. Do not write the value — change the clock underneath it, which PTP just did. What you control is which stamp you carry forward:

• Enable chunk mode on the camera, then the timestamp chunk inside it — GenICam feature lists name them chunk_mode_active and chunk_enable_timestamp. The value latches at exposure end on the camera's now-disciplined clock, so network and driver latency never enter it.
• Copy that chunk value into each published image message. Host arrival time carries tens of milliseconds of jitter under load and tells the fusion nothing about when the sensor actually integrated.
• Align epochs before fusing. Check what each stamp counts from — seconds since power-up, a configured base time, or wall clock. If the lidar stamps wall clock and the camera stamps device time, convert once with the logged PTP offset, or set the camera's base time if its feature set exposes one.
• Publish the PTP offset alongside the images so downstream code can move between clocks without re-deriving it.

Chunk data timestamp: camera time at exposure end and how to latch it shows how the value is latched and how to prove it on your own camera.

Worked example: a 5 MP mono stream at 24 fps on a 1 Gbit/s link

The case: one 5 MP camera streaming 2448 × 2048 mono 8-bit (1 byte per pixel) at 24 frames per second onto one dedicated 1000BASE-T port with a 1000 Mbit/s wire rate — a typical mid-resolution GigE stream, so substitute your own width, height, bit depth and frame rate. The question is which packet size fits. Overhead is 66 bytes per packet: 8 preamble + 14 MAC header + 4 FCS + 12 interframe gap + 20 IPv4 + 8 UDP (IPv6 adds 20 more).

Payload: 2448 × 2048 × 1 B = 5,013,504 B per frame; × 24 fps = 120,324,096 B/s ≈ 120.3 MB/s; × 8 = 962.6 Mbit/s.

Standard 1500-byte frames: 962.6 × 1566/1500 = 962.6 × 1.044 ≈ 1005 Mbit/s. That exceeds the 1000 Mbit/s wire rate, so the link tail-drops packets and the driver discards incomplete frames — the no-images-published symptom.

Jumbo 9000-byte frames: 962.6 × 9066/9000 = 962.6 × 1.0073 ≈ 970 Mbit/s. It fits, with about 30 Mbit/s — 3% — of headroom for control and PTP traffic.

The same stream capped at 22 fps on standard frames: 962.6 × 22/24 = 882.4 Mbit/s payload; × 1.044 ≈ 921 Mbit/s — fits with 8% headroom.

Decision: at 24 frames per second this stream must have 9000-byte packets end to end, and even then the headroom is thin, so keep the camera on a port of its own. If any hop in the path caps packets at 1500 bytes, cap the camera at 22 fps instead. Two cameras of this class sharing one port demand about 1,940 Mbit/s and never fit a GigE link — one port per camera, or faster hardware. And read the symptom correctly: the timestamps were never wrong, the link was full. A marginal cable that negotiates the port below gigabit shrinks the ceiling tenfold and shows up as the same incomplete frames, as in GigE camera packet size error when your link drops below gigabit.

Step 3: jumbo frames end to end, then prove zero drops

1. Set 9000 bytes in three places: the camera's packet-size feature, the NIC's MTU, and every switch port in the path. One 1500-byte device in the chain re-fragments or drops, and every lost packet shows up as an incomplete frame.
2. Give each streaming camera its own NIC port. Two cameras on one port double the demand; a multi-port card beats a switch for a two- or three-camera rig.
3. Route around 1500-only hops — management VLANs, VPN tunnels and Wi-Fi bridges commonly cap a path and silently undo the settings above.
4. Run the full rate for 10 minutes and require a zero: the camera's dropped-packet or packet-resend statistic and the driver's incomplete-frame counter should both stay at zero. Loss after that points at hardware, and the cable is the first suspect.

When drops persist after the settings are right, split link-side from host-side causes. Diagnosing GigE Vision stream packet loss walks the link path; when the host receive queue, not the wire, is the bottleneck, the pattern matches GigE camera buffer overflow errors; and for rigs where several cameras stream together, troubleshooting multi-camera frame drops on GigE cameras covers the shared-link cases. On the host side itself, the high-performance NIC driver for GigE Vision is worth switching on.

On the card side: a dual-port PoE NIC such as the MV-GE2002P gives a stereo pair one streaming port per camera. Where four of these streams share one host they total roughly 3.9 Gbit/s. A quad-port copper 10GbE NIC such as the MV-GT2104 carries that class of load with room to spare. Both live in the frame grabbers and network cards category.

On the machine, ordinary patch leads are the first thing to fail: use screw-lock RJ45 on fixed runs and a drag-chain-rated cable on a moving axis. The camera data cables category splits them by use.

USB3 cameras: hardware trigger plus residual delay

USB3 Vision has no PTP, so a USB3 camera cannot join the clock network no matter what the SDK exposes; its stamps count a power-up clock the lidar will never share. The working arrangement:

1. Drive the camera's trigger input from a source the whole rig trusts — a pulse generator, the controller's digital output, or the lidar's sync-out if it has one. Exposures now start on pulse edges instead of the camera's own schedule.
2. Put the camera in continuous acquisition with external triggering so every pulse yields a frame. A camera that returns exactly one frame is sitting in single-shot mode, not broken.
3. Estimate the residual delay — which IMU sample belongs to which trigger edge — from the data: camera-IMU calibration tooling recovers it by comparing camera and IMU motion, or you pulse slowly and match events by eye. Re-run the estimate after any wiring or firmware change, because the number is only as constant as the timing chain behind it.

For two USB cameras sharing one trigger source, hardware sync two USB cameras: trigger both cameras together covers the wiring and the mode settings. Keep the trigger line short and referenced the same way at both cameras; a long shared line picks up noise that appears as double exposures.

Checks before you trust the sync

• LED flash: blink one LED into two cameras and compare chunk stamps. Converged PTP puts them within a few microseconds of each other; a gap measured in milliseconds means one camera has not synced.
• Offset log: record the PTP offset for 10 minutes at full stream rate. Small and flat is synced; oscillating or growing is not.
• Zero-drop run: the incomplete-frame counter stays at zero for a 10-minute run at full rate. Discarded frames also bias any delay estimate computed from them, so this check gates the others.
• Epoch check: subtract camera stamp from lidar stamp on a shared event. The difference should be a small constant; a growing difference means one device has left the PTP clock — a camera that rebooted un-synced is the usual culprit.
• Trigger estimate: run the residual-delay estimation twice without touching the wiring. The two estimates should agree; if they drift, the trigger chain is moving, not the math.

When the trigger line beats PTP

Trigger instead of stamping when exposures must be simultaneous: a stereo pair on a moving conveyor needs both shutters open within microseconds, and PTP aligns clocks, not shutters. One pulse source drives both cameras — and cameras firing together on a shared network bring their own failure mode, as multiple GigE cameras, same trigger: why frames arrive incomplete shows.

Stay on host time when a single camera feeds a single process at a modest rate: a measured end-to-end latency bound is often enough, and a clock protocol adds moving parts without buying fusion accuracy. The awkward middle case — a lidar with neither PTP nor a sync output — leaves data-driven offset estimation as the only path; it works, but plan to re-estimate after power cycles and when the temperature swings.

To pick the hardware: start with the camera finder, match NICs and cables in the accessories finder, or step through the system configurator. The rest of the stream-integrity stack lives on the systems topic page, and if you want a second pair of eyes on a multi-sensor clock tree, the contact page reaches the applications team.