Multi depth camera synchronization: slave mode and trigger setup

When two or more depth cameras watch the same scene, frames that are even one exposure period apart disagree about anything that moves: a part on a conveyor, a robot gripper, a person walking through a cell. Fusing the point clouds then produces ghost surfaces instead of a clean model. The fix is hardware synchronization: one camera or pulse source sets the timing, and every other camera exposes on cue. This guide walks through planning the roles, wiring the sync lines, configuring master and slave modes, and proving the frames are aligned.

If your end goal is one merged point cloud rather than aligned frames, read multi-camera point cloud synchronization for mobile robots alongside this guide, and multi camera extrinsic calibration in one shared coordinate frame for the spatial half of the problem.

What you need before you start

• Depth cameras with a hardware sync input and output. Not every model exposes one; check the interface section of the data sheet. A compact option for embedded cells is the ToF sensing camera, while projected structured-light cameras cover different working distances, and multi-DOE volume cameras suit larger logistics fields.
• Firmware at the version that introduces the sync mode. Many sync commands silently do nothing on older firmware; the camera accepts the call and stays in free-run.
• The vendor's documented register or SDK call for master and slave roles. Use exactly the sequence the documentation presents; hand-crafted payloads often encode a mode value that later firmware revisions renamed.
• Sync cable, level shifter if logic families differ, and a pulse generator or the master camera's sync output.
• A moving test object and a way to capture from all cameras within one host process.

Confirm the firmware and SDK pairing first. Depth camera startup problems that look like sync failures are often connection problems instead; the checklist in multiple USB depth cameras on Linux: startup troubleshooting rules out enumeration and power issues before you touch the sync lines.

Assign master and slave roles

Pick the camera whose timing you care about most as the master. On a robot cell that is usually the camera watching the gripper; on a conveyor scan it is the camera at the upstream station. All other cameras become slaves that expose when the master's sync line pulses.

Decide also whether you want a single exposure pulse per frame or a continuous external clock. A pulse per frame is easier to debug and pairs well with a PLC trigger; a shared clock keeps long sessions aligned without accumulating pulse-count errors. If a PLC closes the loop, read camera hardware trigger frame rate with external pulses for the pulse-train arithmetic, and hardware trigger source not detected: check GenICam line settings when the camera reports no trigger source at all.

Wire the sync lines

Three wiring rules prevent most sync failures:

1. Fan out, do not daisy-chain. Feed the master's sync output to a small buffer or terminal block, then run one cable to each slave. Chaining through camera inputs multiplies rise-time degradation and makes one bad camera break all downstream cameras.
2. Match cable lengths within a few tens of centimeters. At the pulse widths sync lines use, skew between unequal runs is usually negligible, but matched lengths also match the load the master sees.
3. Check logic levels. A 3.3 V sync output driving a 5 V threshold input reads as no pulse at all. If the cameras differ, put a level shifter in the line.

Keep sync cables away from motor and drive cabling where practical. A corrupted sync pulse looks like a missing or duplicated frame, which is easy to misread as a bandwidth problem of the kind described in depth camera black image: fix USB bandwidth and power issues.

Configure the master

With roles assigned and cabling in place, configure the master first and confirm it still frames correctly:

1. Set the master's frame rate and exposure to the values your application needs.
2. Enable the sync output in its documented mode so a pulse goes out on every frame start (or on every clock period, if you chose shared-clock operation).
3. Capture a few hundred frames and confirm the frame rate is stable before connecting any slave. A master that drops frames will desynchronize every slave behind it.

Configure the slaves

For each slave, in order:

1. Update firmware to the release that documents external sync support, using the vendor's own update tool.
2. Apply the vendor-documented command or SDK call that selects external sync or slave mode. Verify the return value rather than assuming success; a rejected mode change is the failure the opening scenario most often hides.
3. Set the slave's exposure to a value at or below the pulse period so each pulse yields exactly one clean exposure.
4. Confirm the camera reports external sync as its active trigger source, not internal. Many SDKs expose this as a readable line or trigger-source property; read it back after every camera power cycle.

If a slave ignores the mode command on current firmware, check the command payload against the documentation byte by byte, then confirm the sync line actually toggles with an oscilloscope or the camera's trigger-counter property. Only after both check out should you contact the vendor's support channel for a firmware status update.

Verify the frames are aligned

Synchronization is only proven by a moving target:

1. Wave a hand or run a marked part through the shared field of view.
2. Capture one frame set from all cameras in the same host loop and record each frame's timestamp.
3. Compare the position of the moving edge between cameras. Aligned cameras freeze it in the same place; a one-frame skew shifts it by exactly the distance the object travels in one frame period.
4. Repeat at production frame rate and after a full power cycle of the cell.

That arithmetic is why visual verification matters: seventeen millimetres of ghosting is obvious on a 100 mm part, but the same skew on a slow object hides completely. If your downstream code compares depth against color or another modality, the timestamp checks in depth and color synchronization: check the right timestamps apply to inter-camera timing as well.

Common mistakes

• Software-triggering across cameras and calling it synchronization. Host-side triggers drift by milliseconds and jitters with system load. Reserve them for scenes that truly stand still.
• Mixing firmware versions across a sync group. Pulse polarity and mode values differ between releases; keep the whole group on one firmware version.
• Reading the mode command's success as proof of sync. Always read back the active trigger source and confirm with a moving target.
• Ignoring power. Several cameras plus active sync circuitry on one hub is a classic brown-out; give each camera its own powered port.

Pre-commissioning checklist

• All cameras on the same, documented firmware version.
• Master stable at target frame rate before slaves are connected.
• Sync output enabled and confirmed on the master.
• Each slave reads back external sync as its active source.
• Sync cables fanned out from one buffered source, lengths matched.
• Logic levels verified end to end.
• Moving-object test passes at production frame rate, after power cycling the whole cell.
• Roles, modes and cabling written into the cell documentation.

When the usual answer is wrong: if frames align on the bench but drift in the cell, suspect a noise source or an overloaded host rather than the sync scheme. Capture timestamps over several minutes and look for periodic corruption. For depth quality problems that persist once timing is proven, the ROI and layer-scan settings covered in this depth camera ROI layer-scan guide are the next lever.

Once synchronization is proven, build the full rig with our 3D sensors, narrow candidates with the camera finder, or lay out the complete stack in the system configurator. For help matching a sync scheme to your cell, use the contact page and include your camera models, frame rate and cabling plan.