IEEE 1588 PTP camera synchronization for GigE cameras

A four-camera rig with each camera free-running gives you four unrelated clocks: timestamps that differ by milliseconds and frames you cannot line up after the fact. IEEE 1588 Precision Time Protocol (PTP) fixes that over the Ethernet cable you already run: every PTP-capable GigE Vision camera on the network locks its 64-bit timestamp to one shared clock. Here you get the accuracy to plan for through real switches, the mechanism that fires exposures without a trigger wire, the timing arithmetic that decides which method a station needs, and the hardware that carries it.

What does IEEE 1588 PTP give a GigE Vision camera?

Every PTP-capable camera on the network adopts one common clock instead of its own: a 64-bit timestamp that GigE Vision devices tick at 1 µs or faster, disciplined by PTP to better than 100 ns on a network designed for it.

PTP works by trading timestamped messages between one master clock and every slave. Each slave measures the round trip, computes how far its clock has drifted, and corrects continuously. The camera keeps its own 64-bit counter, but PTP discipline runs that counter on the common time, so a reading from camera A sits on the same scale as a reading from camera B.

Comparability is the payoff. You can measure frame phase between cameras, derive part speed from two views of the same part, and rebuild the order of events across a line. The master is normally the host interface or one nominated camera; the master, slave and timestamp check shows how to confirm which device holds the clock and whether the slaves have settled. What the camera latches into that timestamp, and when, is its own subject — see the chunk data guide to exposure-end time, and for host-side conversion timestamp rollover and monotonic time mapping.

How accurate is PTP through real switches and cables?

Plan on better than 100 ns when every hop timestamps PTP packets — a direct link or PTP-aware switches running as transparent clocks — and a few microseconds per hop through ordinary switches, because each one adds its own store-and-forward and queueing delay to the exchange.

A transparent clock is a switch that timestamps PTP messages in hardware and corrects each packet for its own residence time, so the timing exchange passes through without accumulating the switch's delay. An ordinary switch does the opposite: it stores and forwards every timing packet, and whatever the queue did that day becomes part of the clock error.

Translate that into planning numbers. Better than 100 ns needs a network designed for PTP: direct links, or PTP-aware hops end to end. Ordinary managed switches under a light image load land in the single-digit microseconds per hop, and bursts of frame traffic push that up. If the station only needs cameras to agree to about a millisecond, plain switches are fine and PTP-aware hardware is optional. Choose from the application's budget, which the worked example below computes.

Can PTP replace the trigger cable?

Yes, when your timing budget is tens of microseconds or wider: GigE Vision action commands schedule an exposure time in the future, and every camera sharing the clock fires at that instant — no trigger wire, because data and, on PoE cameras, power ride the same Ethernet cable.

An action command is a small broadcast the host sends with an execution time attached. Every camera in the target group arms itself and fires its exposure at that moment, on the shared clock. GigE Vision's own wording for the result is that multiple devices trigger at roughly the same time, and roughly is the operative word: delivery across Ethernet still varies, so the skew you get is PTP offset error plus that jitter. On a quiet network, plan for single-digit microseconds.

Two habits make it behave. Schedule the execution time far enough ahead that the command reaches the slowest camera before it falls due — a few tens of milliseconds is comfortable on a LAN. And spend the first commissioning hour measuring: capture the same event on every camera, subtract timestamps, and let the spread tell you what you have.

The last row is the trap. At a 16.7 ms frame period, free-running cameras are up to 16.7 ms apart — a number that returns in the worked example below with real consequences.

What timing budget does your application need?

One pixel of travel sets the budget: a part on a 250 mm/s belt crosses an 81.7 µm pixel in 327 µs, so a few microseconds of PTP skew is harmless, while free-running cameras can be a frame apart — 16.7 ms, about 51 pixels.

Worked example. A belt inspection at 250 mm/s needs two views stitched over a 200 mm field of view. The camera is a 5 MP unit with 2448 × 2048 pixels of 3.45 µm, so the sensor is 2448 × 3.45 µm = 8.45 mm wide, and it sits 300 mm from the belt. The inputs are illustrative; the arithmetic is what you repeat with your own numbers.

Timing next. Half a pixel of blur allows 40.9 µm of travel, which at 250,000 µm/s gives a 163 µs exposure; choose 200 µs and the smear is 250,000 µm/s × 200 µs = 50 µm, or 0.61 px — still sharp. Sync budget: an action command landing within 5 µs across cameras smears 5 µs × 250,000 µm/s = 1.25 µm, or 0.015 px. Free-running cameras at 60 fps can be a full period apart: 16.7 ms × 250,000 µm/s = 4.2 mm, about 51 pixels of mismatch.

The decision follows from those lines: PTP with scheduled action commands runs this station with a 65× margin on the one-pixel budget (327 µs / 5 µs), and free-running does not run it at all. Check your own focal length with the calculator below.

How do you set PTP up on a GigE Vision camera network?

Enable the camera's PTP feature in its GenICam feature list, let one device serve as the grandmaster — the host NIC or a single nominated camera — and give every camera time to lock before you trust the timestamps: the feature list carries lock state and current offset next to the enable switch.

1. Confirm support: open each camera's feature list in a GenICam browser and look for the PTP entries. A camera without them keeps its free-running counter and cannot join the shared clock.
2. Nominate one grandmaster, the host NIC or a single camera. Two masters produce wandering offsets; the protocol's master election decides it, so set the priorities deliberately rather than leaving them to chance.
3. Keep the timing domain flat: every PTP device must receive every sync and delay message, so put cameras and host on the same switch fabric with no router between. The port and bandwidth plan still comes first, because timing traffic shares those links.
4. Enable PTP on every camera and let the offset settle — seconds, not milliseconds — before you schedule an action command against it.
5. Measure, then trust: capture one shared event on two cameras, subtract the timestamps, and repeat for a few minutes. The spread is your real skew. Offsets that never settle or timestamps that misbehave downstream have a short list of causes, covered in the Unix-time checklist.

A bench can be timed in an afternoon with that list; a production line deserves the measurement log kept as part of commissioning.

When should you still run a trigger wire?

Run the wire anyway when you need sub-microsecond agreement: strobe firing for a frozen image, line scan with an encoder, stereo pairs at speed — a hardware line acts at the edge itself, while action commands inherit PTP error plus Ethernet delivery jitter.

Strobe lighting is the first case: the action command fires the camera, but the flash still follows a wired trigger from the camera's strobe output, so the cable exists whether or not the network sync does. Line scan with an encoder is the second — each line is commanded at the edge. The third is any pair where the budget is itself a microsecond or less: hardware wins because the signal arrives at the input pin instead of through a switch queue.

For the wired side, shared-trigger exposure synchronization covers pulse distribution, and missing trigger pulses is the first stop when a wired input ignores you. What happens between the edge and the pixels is trigger call versus exposure time, and stereo pairs on a shared pulse are treated in stereo trigger synchronization.

Decision: wire the strobe and any sub-microsecond pair; let PTP handle everything from a few microseconds upward.

What hardware does a PTP camera network need?

Four things: PTP-capable cameras, a switch that understands PTP or sits lightly loaded, a host interface with enough ports and bandwidth for the streams, and cables rated for the run — one dual-port PoE NIC covers a two-camera bench with power over the same cable.

The host side decides how gracefully the station scales. A dual-port PoE NIC carries two cameras on one card and supplies power over the same Ethernet cable, so a two-camera bench needs one card and two cable runs. More cameras want a switch, or a four-port card, with the bandwidth divided per port as in the planning guide above. 10GigE hosts follow the same logic at ten times the per-port rate.

The same logic holds on 10GigE hosts:

When the trigger wire stays in the machine, a frame grabber gives it a proper home on the host:

Cables are the last piece, and moving runs want different construction from fixed ones:

Specify in that sequence: cameras with PTP in their feature list from the area scan cameras page, the host interface from frame grabbers, then cables to match the runs. To size the whole chain in one pass, start at the camera finder or step through the configurator; the timing guides around this one are collected on the systems topic page.