Dual camera CSI-2 aggregation and synchronization

A compact stereo module needs more than a component that accepts two camera connectors. You must align the exposures, transport both image streams, and deliver distinguishable frames to software without exceeding the host's limits. Those are separate engineering requirements, even when one device implements several functions.

This guide is for teams evaluating dual camera CSI-2 aggregation before selecting a bridge, programmable device, or processing host. Start with a timing and bandwidth specification rather than a component name. You can then compare architectures without assuming that aggregation provides synchronization, or that a supported connector guarantees a working capture pipeline.

Separate synchronization, aggregation, and host delivery

Treat the design as three contracts:

• Exposure contract: both sensors observe the scene within the permitted timing error.
• Transport contract: both streams fit through every input, output, and shared buffer.
• Software contract: the host exposes identifiable images that your application can pair correctly.

A CSI-2 aggregator combines traffic onto an output link. Depending on its documented implementation, it may distinguish streams using virtual channels or another supported arrangement. That function alone does not establish simultaneous exposure.

A synchronizer controls or coordinates sensor timing. It still needs compatible sensor timing modes, suitable electrical connections, and documented configuration.

A bridge changes the delivery interface, such as from CSI-2 to USB. It may also aggregate streams or control sensors, but those capabilities must be confirmed independently.

The first decision is therefore architectural: can your host receive both sensors directly? If so, aggregation may add complexity without reducing the final assembly meaningfully. Use the embedded stereo sizing guide for the broader processor and memory decision; keep this evaluation focused on the acquisition interfaces between sensors and host.

Calculate bandwidth from exact image dimensions

Do not size the link from a label such as 2K. Specify width, height, frame rate, transmitted pixel format, and camera count.

For uncompressed active pixels, the payload estimate is:

Consider a hypothetical pair of cameras, each delivering 2048 × 1080 pixels at 90 frames/s with packed RAW10:

These figures describe active image payload, not the required physical link rate. Packet overhead, link transitions, scheduling gaps, and the bridge's forwarding behavior still matter. Obtain the actual sensor timing and transport documentation rather than applying one universal overhead percentage.

For preliminary screening, suppose you reserve 25% above active payload. The output budget becomes 3.98 × 1.25 ≈ 4.98 Gbit/s. Across four equally loaded data lanes, that is approximately 1.24 Gbit/s per lane.

That reserve is an engineering assumption, not proof of compatibility. A four-lane output operating at 1.5 Gbit/s per lane has 6 Gbit/s of nominal lane capacity. It still needs compatible packet handling and sufficient buffering for simultaneous input bursts.

If bandwidth is excessive, consider reducing the image at the sensor before buying a faster host. The source-side ROI cropping guide explains why cropping after capture does not reduce upstream traffic.

Set an exposure-skew budget before choosing hardware

Define synchronization by the time the pixels observe the scene, not by when image buffers reach your application.

A useful first estimate connects image motion to temporal mismatch:

Suppose the fastest relevant feature moves at 1500 pixels/s, and the temporal displacement allowance is 0.25 pixel:

This is a motion-error estimate, not a complete stereo depth-error model. Calibration, correspondence accuracy, optical geometry, and scene motion also affect depth.

Ask whether the requirement concerns exposure start, exposure midpoint, or another documented sensor event. Different exposure durations can shift the effective observation time even when the starts align.

For rolling shutters, corresponding rows also need compatible readout timing and direction. A shared frame-start signal does not make every row simultaneous. Global shutters simplify that timing relationship, but still require verified trigger behavior.

The stereo synchronization guide covers those exposure relationships in greater detail. If a shared trigger does not produce the expected captures, follow the dual-camera trigger troubleshooting guide before replacing the aggregation hardware.

Compare acquisition architectures, not connector counts

Use the following table to narrow the design before requesting evaluation hardware.

A selector that alternates between inputs is not equivalent to a simultaneous dual-input acquisition architecture. It may be suitable for sequential observations, but only if the sensors' output and buffering behavior support that use.

Likewise, composition is not synchronization. Placing two images next to each other does not prove they came from the same exposure interval.

A programmable device is worth considering when fixed-function bridges cannot meet the documented requirements. However, account for firmware maintenance, interface support, verification, and board-level integration rather than treating programmability as a shortcut.

For host receiver questions, consult the MIPI CSI host-limit checks. Lane count alone does not establish that the receiver driver supports the proposed multi-stream arrangement.

Verify the complete host and software contract

Request written confirmation of the capture path from sensor output to application buffer. Check these points separately:

• CSI-2 data types and pixel packing accepted at each stage.
• Lane configuration and documented lane-rate operating range.
• Virtual-channel routing supported by both hardware and driver.
• Ability to expose both streams concurrently to applications.
• Sensor control access when identical devices share a control bus.
• Frame identifiers, timestamps, and documented timestamp meaning.
• Behavior after a dropped frame, sensor restart, or capture restart.

Do not assume virtual-channel support in receiver hardware means the operating-system driver exposes separate capture streams. Ask for a demonstrated configuration using the intended software release.

Memory traffic can exceed wire traffic. If the example's packed images become 16-bit pixels in host memory, the image write rate becomes approximately 796.3 MB/s. Reading those images once for processing adds another similar transfer, before rectification outputs or display copies.

USB delivery needs its own budget. A link advertised at 5 Gbit/s cannot be assumed to carry 3.98 Gbit/s of image payload after encoding and protocol overhead. Expanded 16-bit delivery would exceed that nominal link rate before overhead.

Use bounded queues and explicit pair identifiers rather than assuming alternating buffer arrivals represent matching exposures. The multi-camera acquisition architecture guide explains session organization, while timestamp-based result matching addresses association after asynchronous processing.

Consider complete-camera alternatives when integration dominates

If the project does not require a custom sensor board, compare the integration cost against complete area scan cameras. The camera finder helps separate interface, shutter, and resolution choices.

The following parts illustrate alternative interface architectures. They are not CSI-2 aggregators, a matched stereo pair, or a validated solution for the worked example.

The MV-CU020-90GC is a GigE area scan camera with a global shutter.

The MV-CH120-11UC is a USB3 area scan camera with a global shutter.

For either route, separately verify frame rate at the selected format, external timing capabilities, and supported host software. The catalog information here does not establish those requirements.

Host interface hardware also needs careful interpretation. The MV-GE2002P is a GigE interface card.

The MV-GU2204 is a USB3 adaptor.

Neither a port count nor a matching interface name proves independent sustained bandwidth. Confirm the card's upstream connection, shared resources, driver support, and power arrangement.

Browse frame grabbers and interface cards through the accessories finder. A conventional host interface card does not automatically accept a bare CSI-2 sensor connection.

Vision controllers are another host architecture to evaluate when camera acquisition and processing belong in one dedicated unit. Require documented compatibility with the chosen camera interfaces; do not assume direct CSI-2 inputs.

Validate timing, throughput, and recovery separately

Use an evaluation setup before committing to a compact board layout. Test the three contracts independently, then exercise them together.

1. Confirm each sensor alone. Record exact dimensions, format, frame rate, exposure settings, and error counters.
2. Run both streams without heavy processing. Check delivered frame counts and transport errors over a defined interval.
3. Measure exposure alignment. Use documented exposure signals where available, supported timing instruments, and a suitable optical timing target.
4. Add the intended processing pipeline. Measure queue growth, dropped images, memory use, and pair integrity.
5. Exercise documented recovery paths. Test capture restart and supported reconnect procedures without relying on arrival order afterward.

At 90 frames/s, a 60-second run should contain 5400 frames from each continuously running stream. Compare camera counters, bridge counters, and application records where those signals are available.

That short run is a screening test, not production qualification. Extend testing to representative operating durations and workloads, including storage and display activity when they are part of the application.

Know when aggregation is the wrong answer

Aggregation is unnecessary when the host already supports both inputs and the additional component does not solve a measured constraint. It is also unsuitable when the combined payload exceeds the output link, regardless of how many input lanes the device provides.

A fixed-function bridge may be a poor choice when its supported sensor list excludes your devices or its maintained software cannot expose the required streams. Obtain firmware, software, and integration documentation through the manufacturer or an authorized distributor.

Reducing sensor count or alternating captures can be reasonable for static scenes. It is not a substitute for simultaneous stereo capture when scene motion exceeds the timing budget.

Compression may reduce bandwidth, but introduces another validation problem. Check latency, image fidelity, and correspondence accuracy using representative scenes before accepting it for measurement.

Finish the requirements checklist before ordering

Create one acquisition specification that every candidate architecture must satisfy:

• Images: exact dimensions, frame rate, pixel format, and permissible image reduction.
• Timing: shutter behavior, exposure duration, maximum skew, and synchronization method.
• Transport: input rates, output capacity, packet handling, and buffering behavior.
• Host: receiver support, memory traffic, driver release, and concurrent-stream operation.
• Pairing: frame identifiers, timestamp definitions, and missing-frame policy.
• Integration: board dimensions, connector access, power, software maintenance, and supported recovery.
• Acceptance: measurable limits for dropped frames, skew, latency, and sustained operation.

Do not order from a description that merely promises to combine cameras. Require evidence for the exact sensors, format, timing mode, and host software you intend to use.

For a complete-camera alternative, start with the camera configuration step. For acquisition architecture review, send the requirements sheet and bandwidth calculation through application support.