Multi depth camera sync configuration and validation

Two depth cameras joined by a cable still disagree about time until you configure and prove them. One pulse can start an exposure, gate an illumination sequence, or mark a timestamp, and the capture application can rewrite all of it when it opens the devices. This guide gives you the timing contract to write first, the arithmetic that turns motion tolerance into a skew budget, a fixed commissioning order, and the validation runs — 1,000 cycles, an application restart, a camera power cycle — that a multi-camera depth rig must pass before it runs unattended. Keep each camera's data sheet open while you work.

Write the timing contract before you wire anything

"Synchronized" means one of three contracts, and your software must know which:

• Common start. Every camera begins one depth acquisition on the same trigger edge. GenICam names the controls TriggerMode, TriggerSource and TriggerActivation; set the same edge on every camera and read the settings back.
• Common clock. Every frame carries a timestamp from one clock, so software pairs frames by time. GigE Vision cameras that implement IEEE 1588 PTP share such a clock, typically within about 1 µs on a network with hardware timestamping.
• Scheduled illumination. Cameras emit one at a time, so their patterns never overlap and cannot corrupt each other's depth maps.

Name the streams the contract covers — depth, intensity, color, inertial. Sync hardware is selective: on one widely used stereo depth camera family, the hardware sync path aligns depth between cameras and has never carried the inertial stream during sync. If your algorithm fuses inertial data, that stream rides its own clock and you align it in software.

Write the tolerance as a number and an event. "Frames within 1.25 ms, measured from the start of the depth measurement" is a contract you can test; "tight sync" is not. For the electrical side of a shared pulse, start with the shared-trigger exposure synchronization guide. Geometric alignment comes later, with the shared-coordinate-frame calibration workflow — calibration cannot undo motion that happens between acquisitions.

Turn motion tolerance into a skew budget

The tolerance comes from the part, not the camera. Convert it:

maximum timing error in seconds, allowable displacement in millimetres, target speed in millimetres per second.

Worked example, a conveyor at 0.8 m/s and a specification that two views of the same feature may differ by 1 mm:

Now allocate the 1.25 ms so one term never carries the whole risk:

These are starting allocations for a four-camera rig on TTL wiring; replace each term with its measured value as you commission. Treat fixed delay and random jitter differently: a repeatable offset of 0.35 ms can be subtracted in software, but jitter must be budgeted at its worst measured value. The pass limit for the rig is the 0.80 ms allocation, not the 1.25 ms ceiling.

Assign master and slave roles the cameras support

One camera acts as master when two conditions hold: its trigger output level matches the slaves' inputs, and its rated fan-out covers the group. Use a controller output with a distribution module when either condition fails, or when the plant clock should own the schedule. Typical industrial I/O levels are 5 V TTL and 24 V opto-isolated, and they never mix.

Build the role table from each data sheet's I/O page:

Two rules stop most integration failures. An input that accepts a pulse does not make a camera a master — master duty needs a rated output. And a camera that gates illumination is not thereby exposure-triggered; the gate opens a sequence, it does not mark the observation instant.

Respect the minimum trigger interval with arithmetic: a data sheet value of 40 ms caps the rig at 1,000 ÷ 40 = 25 acquisitions per second, so clock the master at or below that rate. For role configuration in software, follow the depth-camera slave-mode and trigger setup guide. When a pulse is present but ignored, work the camera trigger common-reference checks; before any trial connection, apply the camera GPIO wiring checks. Order camera data, power and I/O cables by pin assignment and interface class, then confirm each run through the accessory finder.

Commission in a fixed order

1. Record the baseline. Log serial numbers, firmware versions and application version. Confirm each camera alone returns valid depth in the intended mode.
2. Wire with power off, then power the receivers before enabling the timing source.
3. Set the roles. Enable the master's output; on every slave set TriggerMode on, TriggerSource to the external line, TriggerActivation to the same edge.
4. Lock exposure. Auto exposure slides the observation window across its whole permitted range: with 10 ms of auto range, two cameras can be 10 ms apart in when they looked while their triggers align within 0.1 ms. Fix the exposure, or validate across the full auto range.
5. Read back effective settings. Record what each device accepted, not what the application attempted to write.
6. Start the source. Note the first valid frame index and every missed frame in the first second.
7. Settle persistence. Establish which settings survive a camera power cycle and which the application must re-apply at every open.
8. Run the validation of the next section at full operating load, processing and disk transfer included.

If a slave reports no trigger, run the GenICam trigger-line checks before touching the wiring again.

Validate in the application that will run the line

A rig configured in the vendor's tool is not yet validated in the application that will run the line, because that application can load a profile, change exposure or restart streams when it opens the devices. Test three states, in this order:

Screening run: 1,000 scheduled cycles at line conditions. Record missing frames, mispairings, median skew and worst skew; pass when the worst skew stays inside the 0.80 ms allocation. Then repeat with a moving target — a flat plate swept through the field at 0.8 m/s must produce its depth step in the same cycle index at both cameras.

Pair frames on acquisition time or trigger count, never on host arrival order: two frames acquired 3 ms apart can reach the host in the same millisecond after buffering. The asynchronous frame-matching guide covers the clock basis frame pairing needs. If frames go missing only under full processing load, switch to the image-acquisition stall diagnostic workflow — transport overload and sync faults need different fixes.

Choose the cameras and the host for the rig

Pick 3D sensors through the camera finder by measurement principle first, then qualify each candidate's I/O page against the role table. For full-field depth on static or fixtured parts, the MV-DPS200P-02 projects a structured-light pattern and returns a depth map per accepted trigger. For volume, presence and pallet-overlap checks at conveyor speed, the MV-DT01WMU senses depth by time of flight.

Host the rig on vision controllers rather than a desktop PC: the MV-SVC2506-16G60-128G carries camera ports for the sensors alongside separate network ports for the plant.

Size the host for the stream count, not the camera count: four depth cameras at 30 fps deliver 120 depth maps per second to register, filter and inspect, and the timing software rides on the same processor. When the cameras share a switch with the plant network, put PTP traffic on its own VLAN so best-effort traffic cannot delay the sync messages.

When the cameras must illuminate one at a time

Overlapping projected patterns corrupt every depth map in the group. When interference appears — valid-pixel counts fall the moment a second camera joins — switch to scheduled illumination:

schedule length in milliseconds per cycle; the two intervals come from each camera's data sheet.

Worked example, four cameras with a 9 ms measurement interval and a 2 ms guard:

Run the group at 20 Hz, or cut to three cameras: 3 × 11 = 33 ms fits the 40 ms period at 25 Hz. Then price the stagger in displacement: four cameras spread the views across 33 ms, which at 0.8 m/s is 800 mm/s × 0.033 s ≈ 26 mm of travel between the first and last view. Against a 1 mm motion tolerance, staggering is the wrong tool — slow the part, change the sensor arrangement, or pick cameras whose illumination can overlap.

Acceptance evidence, grouped by stage

Before ordering. The timing contract with streams, event and tolerance; the role table with levels, fan-out and minimum trigger interval from each data sheet; the skew budget with every allocation replaced by a measured or data-sheet value.

At commissioning. Readback of effective settings after the application opens the cameras; the 1,000-cycle screening run with median and worst skew; valid-pixel rate above 99% on a static target; exposure locked, or validated across its full auto range.

At acceptance. The same readback and skew measurement after an application restart and a camera power cycle; a missing-frame log that shows pairing recovered rather than shifted; the recovery behaviour when the timing signal drops for one second and returns.

File the readbacks, traces, logs and pass limits together. A rig that only works in the minutes after manual configuration is not ready for unattended shifts.

Put three artifacts in the project file before you order: the timing contract, the role and I/O table, and the acceptance limits. Then plan the physical connections in the configurator's accessory step, or send the timing contract to applications support and we will match cameras, controller and cabling to it with you.