Two cameras watching the same part from different angles need to agree on when 'when' is. Precision Time Protocol (PTP, IEEE 1588) gives every GigE camera on one network a shared clock, with no trigger generator and no extra wiring beyond the switch you already own. This guide sets one camera as master and the rest as slaves, switches on chunk timestamps, and proves the result with a pulse-per-second freerun test that takes about ten minutes. It also budgets the bandwidth, because a synchronized pair that drops frames is still a broken pair. Every step runs through GenICam feature names your SDK already exposes, so the same five settings work whichever camera family you deploy.
What does PTP align on a GigE camera and what does it not?
PTP aligns each camera's internal timestamp clock to one master clock across the existing Ethernet link, with 1 ns timestamp resolution and a real-world offset of a few microseconds, but it aligns clocks only — shutter timing still needs a trigger signal.
The cameras exchange PTP synchronization messages in defined cycles. Each camera records the send and receive times of those messages and steers its internal counter onto the master's timebase. The counter is an epoch timer that starts at 1 January 1970, 00:00:00 and ticks at 1 ns. Resolution is not accuracy: queueing and latency jitter on real switches keep camera-to-camera offsets in the microsecond range, while the standard's sub-microsecond target assumes suitable network and local clock resources (IEEE 1588-2008).
PTP also says nothing about whether the counter reads true wall-clock time — that takes an external PTP master with hardware timestamping on the NIC. If your recorded frames need real Unix time as well as a shared clock, settle that after the group is formed; restoring Unix time on camera PTP timestamps walks the checks. What this guide builds is relative synchronization: one clock, one origin, and every camera stamping its frames on it.
Which cameras and network parts do you need for PTP?
You need every camera on one dedicated GigE switch, each camera exposing the PtpControl features (PtpEnable, PtpSlaveOnly, PtpStatus) in its GenICam tree, and a host PC that only configures — the PC takes no part in the synchronization itself.
Open one camera in your SDK's feature browser and look for the PtpControl category. Those three features settle in two minutes whether the camera can join a clock group, and firmware that predates PTP updates through the manufacturer's own tooling. Keep the topology flat: cameras and a single host NIC port on a small dedicated switch, nothing else on it.
A master-and-slave cell needs a pair of C-mount GigE area scan cameras:
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Sensor format
- 1"
- Lens mount
- C-mount
The MV-CU020-90GC is a 2.5 MP GigE camera with a global shutter and a 1/1.7" sensor; the MV-CS200-10GC adds 20 MP color on the same link. The host joins the same switch through a clean port, and a dual-port PoE NIC keeps the camera network off the plant network while powering the cameras over the same cable:
- Interface
- GigE
- Ports
- 2 ports
How do you set up the PTP master camera?
Configuration is two feature writes on the master candidate: PtpEnable = True and PtpSlaveOnly = False, and the role is confirmed when PtpStatus changes from Listening to Master.
- Open the camera in the feature tree and select the PtpControl category.
- Set PtpEnable = True.
- Set PtpSlaveOnly = False, which grants the camera permission to lead the group.
- Re-read PtpStatus until it leaves Listening and reports Master.
If several cameras are allowed to lead, the IEEE 1588 master election picks one on its own; making the intended leader the only camera with PtpSlaveOnly = False keeps the hierarchy predictable. One master per switch is the configuration to aim for.
How do you set up the PTP slave cameras?
On each follower camera set PtpEnable = True and leave PtpSlaveOnly = True; PtpStatus then walks from Listening through Uncalibrated to Slave, and Slave means the clock is locked to the master.
- Set PtpEnable = True on the follower camera.
- Leave PtpSlaveOnly = True so it can only ever follow.
- Watch PtpStatus: it starts in Listening, shows Uncalibrated while it measures the path to the master, then settles on Slave.
- Repeat for every camera that must share the clock.
No trigger cable and no PC involvement: the group forms over the switch by itself. When the last camera reads Slave, relative synchronization is complete, and every camera stamps its frames on the same 1 ns timebase.
How do you put a timestamp on every image?
Every image carries its acquisition time as chunk metadata once you set ChunkModeActive = True, select Timestamp with ChunkSelector and enable it with ChunkEnable; you then read the ChunkTimestamp value from the nodemap for each finished buffer.
- Set ChunkModeActive = True to attach chunk data to each image buffer.
- Set ChunkSelector = Timestamp.
- Set ChunkEnable = True.
- After each buffer arrives, read ChunkTimestamp from the nodemap; it is the acquisition time on the shared clock.
The timestamp travels inside the image buffer, so any GenICam-compliant SDK reads it the same way.
How do you prove the cameras are synchronized?
Trigger both cameras from their own PPS outputs — a pulse every second while PTP is active — and compare timestamps frame by frame: if the master-to-slave difference sits in single-digit microseconds, the clocks are locked.
While PTP is active, every camera in the group, master and slave alike, outputs a pulse-per-second signal aligned to the shared clock. Trigger ExposureStart from that pulse and both cameras acquire at effectively the same instant, so whatever difference remains in the timestamps is the true clock offset.
- Route the pulse out: LineSelector = Line2, LineMode = Output, LineSource = PPS. Line2 is the reference wiring; most cameras put PPS on one of their GPIO lines.
- Trigger on it: TriggerSelector = ExposureStart, TriggerMode = On, TriggerSource = Line2.
- Set ExposureTime to 10 ms, comfortably inside the 1 s pulse period.
- Cap each stream so neither starves the other: DeviceLinkThroughputLimit = 60000000, which is 60,000,000 bytes/s = 60 MB/s per camera.
- Execute AcquisitionStart on both cameras and record about 60 frames — one pulse per second for one minute.
- Subtract per frame: Δt = t_slave − t_master.
On a quiet dedicated switch the test settles at that single-digit level, and that flat, microsecond-scale line is the number to demand from the rig.
How much bandwidth does a synchronized two-camera cell need?
A 12 MP Mono8 frame is about 12 MB, so one 12 MP camera at 9 fps already pulls 108 MB/s of a 1 GbE port's roughly 118 MB/s usable payload — two such cameras need two ports, not one.
A 1 GbE port moves 1,000,000,000 bit/s ÷ 8 = 125 MB/s on the wire; after Ethernet, IP, UDP and GigE Vision overhead, plan on roughly 118 MB/s of payload (125 MB/s × 0.94 ≈ 118 MB/s). The sum must stay under that per port. A 12 MP sensor at 12,000,000 pixels produces 12 MB per Mono8 frame, and at 9 fps one camera pulls 12 × 9 = 108 MB/s, while two ask for 216 MB/s.
Cut pixels with ROI or binning, cut frame rate, or split the streams across two ports — in that order. Keep the caps in place, because DeviceLinkThroughputLimit = 60000000 stops either camera from squeezing its partner off the link. Halve the height with ROI and the same camera moves 6 MB frames: 6 × 9 = 54 MB/s per camera, and two fit a single port at 108 MB/s total.
When streams split across two host ports, keep both ports on the same camera switch so the PTP messages still see one network segment; putting two GigE cameras on one host with per-port bandwidth budgets works through that cabling. Bigger cells divide the budget before anything is ordered — the multi-camera GigE bandwidth budget is the method — and then move to a four-port GigE frame grabber with an independent port per camera (frame grabbers).
If frames drop even inside the budget, the pipeline is outrunning the host buffers rather than the link, and troubleshooting GigE camera buffer overflow errors sorts the host-side symptoms.
When should you trigger in hardware instead of trusting PTP?
Use hardware triggering whenever the cameras must expose at the same instant — stereo, photogrammetry, fast moving lines — because PTP aligns the timestamps, not the shutter openings, and microseconds of clock accuracy do not close a millisecond of trigger skew.
Three situations push you to a trigger line. Measurement rigs that need simultaneous exposure fire every camera from one generator; sharing one trigger across several cameras covers the wiring and the settings. A multi-camera calibration has the same demand, and the calibration and synchronization workflow shows how the captures must line up before the extrinsics can be trusted. When several host PCs are involved, a shared strobe beats PTP because each host still stamps on its own clock hierarchy; multi-host synchronization with a shared LED strobe is the pattern to copy.
What should you check before you trust the sync in production?
The pass state is concrete: one master, every other camera reading Slave, timestamps attached, a flat microsecond-scale PPS test, and a link budget with margin — rerun the checks below after every power cycle, firmware update or cabling change.
- Exactly one camera with PtpSlaveOnly = False: PtpStatus = Master there, Slave everywhere else.
- ChunkModeActive, ChunkSelector = Timestamp and ChunkEnable set on every camera, with your code reading ChunkTimestamp from each buffer.
- A full minute of PPS freerun: 60 frame pairs, every offset in single-digit microseconds, trend flat.
- Per-port load with margin: the sum of fps × frame size at or below about 110 MB/s, with the 60 MB/s caps set.
- A dedicated camera switch with no office traffic and no path into the plant network.
Ready to specify the cell? The GigE camera finder filters by interface, resolution and shutter, the camera configurator builds the chain step by step, and we will check the link and timing budget with you — send the frame sizes and camera count through the contact page. The systems topic page collects the rest of the timing and synchronization guides.
Questions
Do USB3 cameras support PTP?
No. IEEE 1588 is defined for Ethernet networks, and a USB3 link has no PTP role, so a USB3 camera cannot join the camera-side clock group. In a mixed cell, keep the GigE cameras on PTP for a shared timebase and fire the USB3 cameras from the same hardware trigger the PPS test uses.
Can PTP run through an ordinary office switch?
Yes, the sync messages are ordinary multicast Ethernet frames, but office switches buffer them unpredictably, which inflates the offset. Put the cameras on a small dedicated switch for single-digit-microsecond results. Switches with boundary-clock or transparent-clock support correct for forwarding delay and hold tighter offsets, but a two-camera cell does not need one.
Does the host PC need a special NIC for relative PTP synchronization?
No. For camera-to-camera relative synchronization the PC only writes the configuration, so any standard Ethernet port does the job and the PC is not part of the clock group. Hardware timestamping on the NIC matters only when you introduce an external grandmaster clock to hand out absolute time.
Can I mix camera models in one PTP group?
Yes. Master and slave are feature roles, not model properties: any camera whose tree exposes PtpControl can take either role, and the election decides who leads when several are allowed. Keep every camera on PTP-capable firmware, enable the Timestamp chunk on each one, and run the PPS test on the whole group before you trust it.
What if the feature tree has no PtpControl category?
Update the camera firmware and the SDK through the manufacturer's own channels first, because older firmware often ships without the features. If the category is still missing afterwards, that camera does not implement PTP: keep it out of the clock group and fire it from the same hardware trigger the rest of the cell uses.
How often should the PPS check be repeated?
After every power cycle, firmware update, or change to the cabling or the switch, because the clock group re-forms from scratch each time the cameras start. Keep a minutes-long recording of per-frame offsets as the acceptance evidence: a flat line in the microseconds means the group is healthy, a rising line means a slave never locked.