CSI camera carrier board compatibility: what to verify

Two cameras can work separately yet fail together because their installation packages replace the same kernel or device-tree files. A carrier board with enough connectors does not resolve that conflict. For an embedded multi-camera project, the buying decision must cover the complete hardware and software combination, not just the sensor and connector.

Before ordering, establish who supplies and supports the combined software image, which camera modes operate simultaneously, and how the finished application will be verified. The checks below separate physical compatibility, software support, acquisition timing and recording throughput so you can request useful evidence before committing to hardware.

Make a supported combined image the first purchasing gate

CSI camera carrier board compatibility means that the compute module, carrier revision, camera modules and software release operate together in the required configuration. Separate demonstrations of each component are not equivalent to a demonstration of the complete system.

Ask for a supported board-support package, or BSP, covering the exact combination. Its kernel, kernel modules, device-tree configuration, camera drivers and required userspace components must belong to a compatible release set. A documented integration process can also be acceptable, provided someone owns the resulting configuration and its support.

Two installation packages that both replace shared boot components should not be assumed to combine safely. Installing one after the other may remove configuration needed by the first. Successful installation messages do not establish that both cameras remain supported.

The missing device-tree troubleshooting guide explains the failure mode after installation. Before purchase, the better question is whether the supplier can provide the complete, supported release set in the first place.

Build a compatibility matrix before comparing hardware

Create a short matrix that can be attached to a quotation request. Replace broad statements such as “supports multiple cameras” with specific hardware revisions, software releases and operating modes.

Request software and documentation only from the manufacturer or its authorized distributors. Save release notes and configuration identifiers alongside the purchasing record.

For wider mechanical and interface decisions, use the embedded camera selection guide. The compatibility matrix adds the software ownership questions that a dimensional drawing cannot answer.

Verify the electrical path, not just the connector

Matching connector width or contact count does not prove electrical compatibility. Check the documented pin assignment, cable orientation, signaling interface, supply requirements, reset behavior and reference-clock arrangement.

For each camera port, establish:

• Which receiver it reaches, and whether that receiver is shared.
• How many data lanes are wired and supported for the selected camera mode.
• Whether cameras operate concurrently or through a switching arrangement.
• How control-bus addressing is handled when identical modules are connected.
• Whether a bridge or aggregator requires additional driver support.
• Which cable construction and length the vendor has validated.

A board with several camera sockets may support simultaneous streams, switched access or only particular combinations. Ask for the topology rather than inferring operation from the number of sockets.

Our board-level cameras include interface options for embedded systems, but that category does not establish CSI compatibility. Use the camera finder to identify candidates, then check the complete integration documentation.

Treat the BSP as a versioned system

The device tree describes hardware connections and configuration to the operating system. Camera drivers and the surrounding capture stack must agree with that description. Kernel modules also need compatibility with the running kernel and its build configuration.

Ask the supplier to identify the actual supported release, not merely an operating-system family. Record the image identifier, kernel build, camera package release, device-tree configuration and required acquisition libraries.

A practical handover should include these items:

1. The official image or package source and its release identifier.
2. The supported flashing or installation procedure.
3. The configuration for all required cameras operating together.
4. A minimal acquisition example for each camera and the combined arrangement.
5. A recovery procedure that restores a known configuration.
6. A documented upgrade path, including any required reinstallation.

Do not assume that merging device-tree files resolves a conflict. Different packages may also depend on incompatible kernel changes, capture components or userspace libraries. Integration work should be quoted explicitly when no supported combined image exists.

The CSI acquisition troubleshooting guide helps distinguish later startup failures. The acquisition software compatibility guide addresses the separate question of whether your application can use the supported capture interface.

Calculate three different bandwidth budgets

A system can have enough camera-link capacity and still fail during conversion or recording. Estimate sensor transport, host-memory traffic and storage traffic separately.

For an illustrative pair of cameras, assume each delivers 1920 × 1080 pixels at 30 frames/s with a packed 10-bit payload. These are application assumptions, not specifications for any catalog product.

This is image payload only. It excludes packet overhead and additional transmitted data. Validate the actual lane rates, receiver limits and port allocation against the supported camera modes; an aggregate total alone cannot prove that each port can carry its assigned stream.

Next, suppose the application converts both streams into an uncompressed format using 3 bytes per pixel:

That figure describes one pass of image data, not total memory traffic. Copies, conversions and processing can require additional reads and writes.

Finally, assume an encoder produces 12 Mbit/s per stream:

Container overhead, variable bitrate behavior and filesystem activity add to the storage requirement. Encoding quality and processing capacity must be tested; the assumed bitrate is not a recommendation for every scene.

If fewer source pixels satisfy the task, camera-side ROI cropping can reduce traffic before it reaches the host. Resizing after acquisition does not reduce the original camera-link load.

Define simultaneous acquisition separately from synchronization

“Both cameras run” and “both exposures occur together” are different requirements. Establish whether your application needs independent recordings, approximately aligned frames or a specified exposure-time relationship.

For independent recordings, ask for concurrent acquisition at the required modes without starvation or unexplained frame loss. For aligned views, define an allowable exposure-time difference and how it will be measured.

At 30 frames/s, the nominal frame period is approximately 33.3 ms. An application requiring less than 5 ms exposure skew cannot accept host read order as proof of timing. Buffering and scheduling can separate delivery time from exposure time.

Confirm whether the documented system supports a shared trigger, shared clock, timestamp relationship or another suitable timing method. Do not infer synchronization support from the CSI interface itself.

The shared-trigger synchronization guide explains exposure alignment where the hardware supports it. Also verify that identical cameras can be assigned stable identities after reboot, so application channels do not silently exchange views.

Compare CSI with supported USB and GigE alternatives

CSI is attractive when a supported embedded platform already covers the required cameras and application. It becomes a less certain choice when a project must fund integration across unrelated software packages.

Neither USB nor GigE removes the need to validate drivers, processing capacity or synchronization. They change the integration boundary rather than guaranteeing success.

The LS-BCM-0003 is a USB3, global-shutter alternative to investigate. Its listing does not establish support for your compute platform or application.

The LS-BCM-0020 provides a GigE, rolling-shutter alternative. Confirm that its shutter behavior and acquisition support suit the intended task.

For USB or GigE alternatives, review camera cables through the accessory finder. A cable listing is not evidence of compatibility with a CSI camera connector.

Request an acceptance test that matches the workload

A live preview proves less than a representative recording test. Ask for results from the exact combined image, camera modes and application path you intend to deploy.

A useful staged test separates the likely bottlenecks:

1. Capture from each camera individually without recording.
2. Capture from all cameras concurrently without recording.
3. Add the required pixel-format conversion and processing.
4. Add encoding, then storage writing.
5. Stop acquisition, finalize files and release camera resources.
6. Restart acquisition and repeat after a full system reboot.

For an example acceptance target, request a 60-minute run at 30 frames/s per camera. The nominal count is 30 × 3600 = 108,000 frames per camera. Compare acquired counts, recorded counts and timestamps, while documenting startup exclusions and the agreed allowance for dropped frames.

Also consider 10 stop/start cycles and several cold starts. These are proposed project checks, not universal certification thresholds. Choose values that reflect the cost of an interrupted recording.

If simultaneous capture passes but the application stalls, investigate buffer queues and callbacks. If release fails, the acquisition shutdown troubleshooting guide addresses that separate acceptance failure.

Check the purchase package and the exceptions

Before approving the order, confirm that the proposal includes more than working hardware:

• Exact configuration: hardware revisions and all camera variants are identified.
• Combined software: the supported release and installation source are recorded.
• Concurrent modes: resolution, format and rate are specified for every stream.
• Application access: the required capture API and processing path are demonstrated.
• Recording evidence: counts, timestamps and file completion are checked under load.
• Recovery: the system can return to a documented working configuration.
• Support ownership: responsibility for cross-component faults is agreed.
• Change control: upgrades require revalidation of the complete arrangement.

A vendor image is not always the right answer. A team maintaining its own kernel may prefer a documented source-based integration. That remains an engineering project with version control, reproducible builds and regression testing—not an assumption that independent installers will combine correctly.

Likewise, avoid buying additional camera ports when the actual limit is conversion or storage throughput. Conversely, faster storage cannot repair an unsupported receiver configuration.

Use the camera configuration workflow to organize candidate components. For a review of the complete combination, send your compatibility matrix and acceptance targets through technical support before ordering.