Synchronize two cameras at high frame rate

Capturing fast RGB video from two cameras creates two separate engineering problems: starting exposures together and moving every image into memory. Solving only one leaves you with synchronized cameras that drop frames, or complete recordings whose images represent different moments. For a desktop acquisition system, choose the resolution and timing tolerance first, then validate the camera, interface, and capture application as one system.

Define what synchronized means before choosing cameras

To synchronize two cameras at high frame rate, specify an exposure-time relationship rather than asking only for matching frame rates. Two cameras can each deliver 100 fps while their exposures remain offset or drift apart.

Write down these requirements before comparing area scan cameras:

• Image dimensions and minimum usable field of view.
• Required delivered frame rate, not just the sensor's maximum rate.
• Maximum difference between corresponding exposure start times.
• Exposure duration and permitted motion blur.
• Required color representation: raw Bayer data or converted RGB.
• Recording duration and whether missing frames are acceptable.

At 100 fps, the frame period is 10 ms. Saying that cameras must agree within one frame therefore permits almost 10 ms of skew. That may be adequate for loosely associated video clips, but unsuitable for measuring a moving object from two views.

For example, an object moving at 250 mm/s travels 2.5 mm during 10 ms. Reducing the timing difference to 100 microseconds reduces that displacement to 0.025 mm. These are timing-induced position differences, not complete measurement-error estimates.

For the distinction between exposure alignment and matching video streams, use the multi-camera RGB exposure-timing guide.

Calculate payload before selecting an interface

The payload depends on the transmitted pixel format, not simply on whether the finished image looks colorful. A Bayer image with one transmitted byte per pixel carries much less data than an RGB image with three bytes per pixel.

Use this estimate for uncompressed image payload:

For an illustrative 1920 × 1080 image at 100 fps:

• Bayer8: 1920 × 1080 × 1 × 100 = 207,360,000 bytes/s per camera.
• RGB8: 1920 × 1080 × 3 × 100 = 622,080,000 bytes/s per camera.
• Two Bayer8 streams require approximately 415 MB/s of image payload combined.
• Two RGB8 streams require approximately 1,244 MB/s combined.

Here, MB means one million bytes. These figures exclude packet overhead, metadata, retransmissions, padding, and application copies. Packed formats and higher bit depths require their own calculation using the actual transport layout.

Recording ten minutes of the two Bayer8 streams would require approximately 249 GB before metadata or file overhead:

Converting Bayer data on the host can reduce transport and recording load, but it moves color processing into the computer. If recording converted RGB, storage bandwidth rises even when camera-link traffic remains unchanged.

The RGB pixel-format and exposure guide explains why color format and exposure settings can change the attainable operating point.

Compare interfaces using the whole transport path

The following capacities are nominal signaling-rate conversions, not achievable image-payload guarantees.

A faster interface does not make a sensor read out faster. Verify the required dimensions, pixel format, exposure, and trigger mode together. Cropping may increase frame rate when it reduces the limiting sensor readout, but an arbitrary region of interest does not guarantee an increase.

For USB, inspect the controller topology. Separate physical sockets can share an upstream controller or hub. A hub adds ports, not upstream bandwidth. An expansion adaptor also needs sufficient host-bus capacity and documented controller architecture.

For Ethernet, inspect each camera link and every shared uplink. Independent camera ports can still converge on a limited host connection. When cameras expose together, their subsequent transfers may also overlap, producing short bursts above the long-term average.

Compare interface options in the camera finder. For the receiving hardware, use the frame grabbers category and accessories finder to check the complete connection chain.

Choose the trigger strategy separately from transport

A shared hardware trigger is usually the practical starting point when exposure alignment matters. The same event reaches both cameras without relying on the operating system to schedule two separate commands. Actual alignment still depends on input delays, configured trigger delays, sensor behavior, and camera readiness.

Hardware triggering does not consume less image bandwidth. It can actually concentrate transfers into the same interval, so synchronized operation must be included in the bandwidth test.

Software triggering is not universally too slow, but sequential commands are not inherently simultaneous. If your tolerance is 10 ms, software commands might pass a measured acceptance test. That result should not be assumed to hold under every host workload.

Scheduled acquisition is an alternative only when both cameras explicitly support the necessary clock and acquisition features. Clock synchronization alone does not automatically synchronize exposures.

For electrical implementation, follow the shared-trigger approach for two USB cameras. Check input voltage, polarity, reference, and isolation against the exact camera documentation before connecting anything.

Shortlist parts without assuming an unlisted frame rate

The following parts illustrate interface choices, not a qualified high-rate system. Their catalog entries do not establish the frame rate, trigger behavior, or timestamp facilities required for this application. Obtain the exact operating-mode documentation before ordering.

The MV-CH120-11UC is a color USB3 camera with a global shutter. The MV-CH250-25TC-F-NF is a color 10GigE camera with a global shutter. Compare their supported acquisition modes rather than treating interface speed as a frame-rate specification.

For USB acquisition, the MV-GU2204 is a USB3 adaptor. Confirm its controller topology, host-slot requirements, operating-system support, and suitability for the combined payload.

For Ethernet acquisition, the MV-GT1102P is a 10GigE frame grabber. Verify the camera connection, driver support, host-bus capacity, and supported simultaneous traffic before selecting it.

The LS-CBL-0219 is a USB3.0 camera cable specified for drag-chain use. Check connector compatibility and the complete cable route; that designation alone does not qualify a particular camera installation.

Use the cables category to match data connections and any separate trigger connection. A matching connector shape does not establish an electrical pinout.

Before committing to either architecture, request written confirmation of the required resolution, delivered frame rate, pixel format, exposure duration, and external-trigger behavior. Also confirm lens requirements and the intended field of view separately.

Build acquisition around frame identity and ownership

Configure both cameras explicitly rather than relying on saved settings. Record the effective image dimensions, pixel format, exposure, gain, trigger configuration, and transport settings after configuration has completed.

Start reception and queue buffers before enabling the timing source. If supported, check camera readiness before starting the trigger train. A camera that is armed late can miss an event even though its wiring is correct.

Keep the capture path short. Receive the image, attach its identity and timing metadata, and transfer ownership to a bounded processing queue. Do not perform display rendering, color conversion, or disk compression inside a time-critical capture callback.

Copy image data when the acquisition library requires it. Holding a pointer after its buffer has been returned can corrupt an apparently successful recording.

Pair images using a shared event identity when available. Frame counters can identify gaps within a stream, but matching counter values are not proof of a shared physical event unless startup and reset behavior are controlled. Timestamp pairing requires clocks with a known relationship.

Choose a queue-overflow policy before testing. A larger buffer absorbs temporary stalls; it cannot fix a sustained processing deficit. If backlog grows continuously, latency will grow until frames are dropped or memory is exhausted.

Validate frame rate and exposure timing independently

Use a staged acceptance test that exposes the limiting subsystem. The following is a starting procedure, not a universal qualification duration.

1. Run each camera separately at the final dimensions, format, exposure, and trigger settings. Confirm delivered rate and missing-frame counters.
2. Run both cameras with image reception only. Disable previews and expensive processing to isolate acquisition capacity.
3. Add Bayer conversion or other processing. Watch queue depth and CPU load rather than only the preview rate.
4. Add recording, then display, using the intended production workload.
5. Run a steady-state test for at least ten minutes, then extend it to the required recording duration and expected load conditions.
6. Measure exposure alignment with a common observable event or documented exposure-active outputs, where available.

At 100 accepted triggers per second over 600 seconds, expect 60,000 images from each camera. Exclude deliberate startup settling consistently, and distinguish generated triggers from triggers actually accepted by the cameras.

Measure exposure timing independently of host arrival time. A frame can arrive later because of buffering or transport while its exposure occurred correctly. Likewise, equal callback times do not prove equal exposures.

For electrical timing checks, use only outputs whose documented meaning corresponds to the exposure event. For an optical check, place a controlled changing light source in both views and account for pulse width, exposure duration, and shutter behavior.

Record delivered rate, missing frame identities, exposure-skew distribution, maximum observed skew, queue depth, and recording throughput. Report the tested duration and load alongside the measurements. A percentile alone can conceal an occasional unacceptable timing error.

Recognize when the usual answer is wrong

A common trigger cannot make cameras capture faster than their supported triggered operating point. If pulses arrive while a camera is busy, behavior depends on its documented trigger handling. Check the external-pulse frame-rate guide before increasing the trigger frequency.

Similarly, equal exposure starts do not make rolling-shutter images simultaneous across every row. For rapidly moving scenes or geometric correspondence, global-shutter acquisition is generally easier to reason about. If rolling shutter is necessary, characterize line timing and the relationship between corresponding image rows.

Reducing exposure may not improve frame rate when transport, readout, or host processing is limiting. Conversely, a faster receiving interface does not fix an exposure that exceeds the available frame interval.

A larger buffer is also the wrong fix for steadily increasing latency. Separate temporary scheduling interruptions from sustained throughput shortfalls using the camera frame-rate bottleneck diagnostic.

Finally, synchronized capture does not imply low display latency. Sensor readout, transport, conversion, rendering, and display refresh all add delay after the exposure event. Measure capture-to-display latency separately if an operator or feedback loop depends on it.

Check the operating point before ordering

Use this short acceptance checklist for the proposed pair:

• Confirm frame rate at the exact image dimensions and transmitted format.
• Confirm whether exposure overlaps readout and how that affects triggered operation.
• Specify maximum exposure skew separately from delivered-frame latency.
• Calculate per-camera payload and every shared upstream bottleneck.
• Verify trigger electrical requirements and documented timing behavior.
• Confirm timestamp meaning, frame identity, and dropped-frame reporting.
• Check host drivers, acquisition-library support, connectors, and required cables.
• Test reception, processing, display, and recording together before acceptance.

Start with the camera configurator once the operating point is defined. If the required triggered frame rate or timing facilities are not documented, send the resolution, format, exposure, skew limit, and recording duration through technical support before selecting the pair.