Multi host camera synchronization with a shared LED strobe

Independent camera streams do not need to pass through one host to share an exposure event. Each host can acquire its own stream while a separate timing source distributes hardware triggers to the cameras and an LED strobe controller. The difficult part is proving that every camera actually integrates the same flash.

For distributed vision systems, choose the timing architecture before choosing the camera interface. You need documented camera inputs, compatible trigger distribution, and measured exposure windows. This guide explains how to establish those requirements, identify rolling-shutter limitations, and reject hardware that cannot support the required timing without undocumented modifications.

Choose the timing architecture before the interface

Use a shared hardware timing source with separate, electrically compatible branches to each camera and the lighting controller. Image data travels independently to each host. The timing network does not need to carry images, and the image network does not automatically synchronize exposure.

Separate three different requirements:

A shared trigger can address exposure timing only when the cameras support the selected trigger mode. A strobe can provide a common optical event only when all required pixels are integrating during that event.

The shared-trigger exposure synchronization guide explains the camera-side timing relationship. Here, the additional challenge is distributing that relationship across independent acquisition hosts.

Choose one documented timing authority. This can be an external timing controller or a camera with a documented timing output suitable for the job. Do not connect multiple output drivers together. If one camera becomes the timing authority, define what happens when it stops acquiring or restarts.

Qualify the complete camera I/O path

A synchronization signal named in a sensor document is not proof that a finished module exposes it. The board layout, intermediate electronics, firmware, driver, and acquisition mode must all support the intended function.

Before ordering, request documentation covering these points:

• Physical connection: connector pinout, supported synchronization terminals, and an approved cable or breakout arrangement.
• Electrical interface: input voltage limits, thresholds, polarity, isolation, input current, and required reference connections.
• Timing behavior: minimum pulse width, trigger latency, jitter, accepted trigger rate, and behavior when a trigger arrives while busy.
• Operating mode: supported trigger function at the required resolution, pixel format, exposure, and frame rate.
• Exposure feedback: whether an output represents frame start, sensor readout, exposure active, or another event.
• Software support: required firmware, driver, configuration sequence, and a way to read back the active settings.

A frame-start output and an exposure-active output are not interchangeable. An output that remains asserted during acquisition might represent acquisition state rather than individual exposures. Its meaning comes from documentation, not its label alone.

For embedded modules, require confirmation for the complete camera-and-host combination. Instructions for another carrier or software stack do not establish support on yours. The USB camera trigger support checklist provides a related qualification method for packaged interfaces.

Use a distribution stage appropriate to the documented electrical interfaces and cable lengths. Longer connections may require differential signaling or isolation, with suitable receivers at the cameras. Never extend an unspecified logic-level signal and assume it remains valid. Review camera GPIO wiring precautions before connecting equipment.

Calculate the common exposure window

For global-shutter cameras, the useful flash window is the intersection of their exposure intervals. Trigger distribution delay, camera latency, and jitter all affect that intersection.

Define each camera's exposure start relative to the shared timing event. Include the measured branch delay and camera response, rather than assuming the trigger edge is the exposure start.

Here, s_i is exposure start and E_i is exposure duration. A positive window is necessary, but it must also contain the flash and your timing margins.

Worked global-shutter example

Suppose three cameras have measured exposure starts of 0, 15, and 40 microseconds relative to a timing reference. Each exposure lasts 500 microseconds.

The latest start is 40 microseconds. The earliest finish is 500 microseconds, so the shared window is:

A flash scheduled from 100 to 200 microseconds fits comfortably in that example. These are hypothetical application timings, not specifications for any listed product. Actual margins must include measured worst-case variation and measurement uncertainty.

Rolling shutters add a second overlap problem

A rolling shutter starts different rows at different times. Synchronizing the first row does not make all rows integrate simultaneously.

For a simplified rolling-shutter mode with equal exposure duration across rows, let R_i be the time between the first and last relevant row starting exposure:

If the row-start span is 12 milliseconds and exposure is 2 milliseconds, the all-row overlap is 2 - 12 = -10 milliseconds. There is no instant when every row integrates together. A short flash produces a band rather than a uniformly illuminated frame.

At an exposure of 15 milliseconds, the same simplified mode offers 15 - 12 = 3 milliseconds of all-row overlap within one camera. Inter-camera offsets reduce the shared overlap further. Confirm the actual sensor mode; output frame rate alone does not reveal its row timing.

A longer exposure may permit common-flash capture, but ambient light still integrates throughout that longer interval. Motion blur and background contamination can therefore remain even when the flash itself is short.

Size each independent stream separately

Multi host camera synchronization does not reduce the image throughput required at each host. Specify field of view, sampling, frame rate, and delivered pixel format independently of the trigger design.

For example, a horizontal field of view of 1,920 millimeters at 0.5 millimeters per pixel requires:

This is a sampling requirement, not proof that a feature can be inspected reliably. Contrast, lens performance, motion, and the number of pixels across the smallest feature still matter.

For a hypothetical stream of 3840 × 2160 pixels at 30 frames per second:

These are decimal payload rates before transport overhead and additional memory copies. Each host must sustain its own acquisition, processing, and recording load. A camera's advertised resolution does not prove that it delivers the required cropped mode, trigger rate, or pixel format.

If reducing the image area is acceptable, source-side camera ROI cropping explains how to reduce transmitted data. Cropping after arrival does not relieve the camera link.

Keep transport timing separate from exposure timing. The frame-arrival jitter guide explains why host receipt times are poor evidence of synchronized integration.

Select documented hardware, not assumed capabilities

Start with board-level cameras when mechanical integration requires a module. Consider area scan cameras when a packaged camera may simplify the connection and integration work. Neither category guarantees external triggering.

The following parts illustrate catalog options, not a prequalified synchronized system. Their listings do not establish trigger input support, trigger latency, or compatibility with your host software.

Board-level architecture reference

The LS-BCM-0043 is listed as a binocular camera/module with USB3, a global shutter, and an M12 lens mount. Its lower resolution makes it an architecture reference rather than a candidate for the high-resolution stream example above. Also confirm whether its output arrangement meets an independent-stream requirement; the word binocular does not answer that question.

Global-shutter area-scan reference

The MV-CH120-11UC lists a global shutter, USB3, and 12 MP. Obtain documented frame-rate and trigger-mode details before treating it as a candidate for a particular acquisition requirement.

Rolling-shutter area-scan reference

The LS-CMR-0166 lists USB3, a rolling shutter, 30 fps, and 4000 × 3000 resolution. Those specifications are a starting point for pixel-count screening, not evidence of a usable common-flash window or a supported cropped mode.

Use the camera finder to narrow resolution, interface, and shutter choices. Then request the missing synchronization evidence before final selection.

Strobe controller reference

The LS-CTL-0070 is listed as a digital control box with a strobe feature. The listing alone does not establish minimum pulse duration, trigger-to-light delay, or compatibility with a particular LED bar.

Compare light controllers through the controller finder. Match the light's documented drive requirements, controller output type, permitted pulse conditions, and trigger interface. A camera timing output should command a compatible input; it should not directly supply LED operating current.

For a 100-microsecond pulse repeated 30 times per second, duty cycle is 100 × 10^-6 × 30 = 0.003, or 0.3%. That arithmetic does not establish a safe overdrive current. Follow the documented limits discussed in the strobe duty-cycle and timing guide.

Verify timing electrically and optically

Commission the timing path before adding the full processing workload. A practical sequence is:

1. Configure one camera. Disable automatic exposure changes where the application permits. Set the documented trigger mode and read back the active settings. Resolve trigger-line configuration problems before adding other cameras.
2. Measure the delivered trigger. Check the waveform at each receiver using appropriate instruments and probing methods. Record pulse width, polarity, branch delay, and edge variation under the intended cable arrangement.
3. Measure exposure response. Observe a documented exposure signal where available. Record what it represents, especially for rolling shutters. Do not substitute a frame-valid signal without evidence.
4. Measure actual light output. Use a photodiode and suitable measurement electronics. Electrical controller pulses do not reveal the complete optical rise time, duration, or turn-off behavior.
5. Inspect the captured images. Test the full image area for bands, dark rows, clipping, and ambient-light contamination. For rolling shutters, move a short test flash through the frame timing while observing which rows receive it.
6. Repeat under operating load. Run processing and recording on every host. Check startup, sustained acquisition, dropped-frame recovery, and stop/start sequences.

Specify an acceptance limit before testing. For example, an application may require exposure-start spread below 50 microseconds and no unmatched captures during a defined test run. These are example acceptance criteria, not universal tolerances. Choose limits from motion and measurement requirements.

The multi-camera RGB timing verification guide provides additional checks for distinguishing optical alignment from software pairing.

Handle restarts, missing frames, and unsuitable architectures

A shared trigger does not guarantee that every host receives every image. A camera can reject a trigger while busy, and a host can lose a frame after exposure. Pairing images by their position in separate queues can silently associate different events.

Use documented event identifiers, trigger counters, or timestamps tied to a known clock relationship where available. Otherwise, establish a verified acquisition epoch and detect count mismatches. After a restart or missing frame, re-establish correspondence rather than assuming independent local frame counters remain aligned.

Check early captures separately. A dark startup image can indicate a configuration or lighting sequence problem; the first-frame exposure and lighting guide gives a focused diagnostic path.

The usual shared-trigger answer is wrong when:

• The module has no supported timing connection. Choose documented synchronization hardware rather than building around unidentified test points.
• Rolling-shutter exposure windows cannot overlap. Select a suitable global-shutter camera or change the acquisition requirement; a brighter flash does not create overlap.
• Only frame correspondence is required. Timestamp-based association may suffice, provided its measured uncertainty fits the task. It is not equivalent to simultaneous exposure.
• Ambient light dominates a long rolling-shutter exposure. A short strobe cannot remove image content accumulated outside the pulse.
• The imaging pipeline cannot sustain the required mode. Use a documented alternative mode or camera. Removing intermediate electronics is not evidence that a supported raw-data path exists.

Keep this acquisition timing network separate from safety-rated machine controls. Image synchronization does not provide a safety function.

Check these points before ordering

Complete the timing specification before committing to the camera and lighting arrangement:

• Image requirement: field of view, minimum feature sampling, delivered dimensions, pixel format, and sustained frame rate.
• Independent streams: one usable stream per required host, without an unwanted combined-frame arrangement.
• Camera evidence: documented connector, electrical limits, supported trigger mode, exposure behavior, and host software support.
• Distribution evidence: compatible drivers and receivers, permitted cable arrangement, and measured delay variation.
• Optical evidence: a common exposure window large enough for the measured flash and timing margins.
• Controller evidence: compatible light drive, pulse duration, repetition rate, and documented operating limits.
• Recovery behavior: detection of rejected triggers, missing images, restarts, and loss of frame correspondence.
• Acceptance test: recorded electrical traces and representative images from the final operating mode.

Start a hardware shortlist with the camera configurator. If the required timing behavior is absent from the available documentation, send the stream requirements and proposed timing diagram through applications support before selecting parts.