CSI-2 multi camera connection: compatibility checks

An intermittent image from one socket, a sensor that disappears when the second camera powers up, or a system that passes every single-camera test and fails the moment two streams run: these are the standard symptoms of a CSI-2 multi camera connection built on the wrong adapter. The camera is rarely the fault. The cause sits in the adapter topology, the control-bus addressing, the lane mapping, or the per-lane data rate. This sequence finds the failing element in order of probability, with the arithmetic to size every link, and ends with the acceptance test that proves the repair.

Start with the adapter's function, not its socket count

Adapters for CSI-2 come in three functional types, and the type alone decides how many cameras can stream at once:

Count the MIPI CSI-2 receiver inputs on your processor, with the lane count of each. A passive flex cannot manufacture a receiver: a processor with two 4-lane receivers routes two cameras passively, and a third camera needs a selector, which streams one at a time, or an active aggregator the host driver actually supports. When the camera interface does not match the processor's receiver at all, a bridge is the required part, and bridging is its entire job.

Order the adapter named in the carrier board's assembly drawing, and check the drawing's revision against your carrier, camera and software release. The carrier board compatibility checks cover the host-side requirements in detail.

Check the physical path with power off

1. Shut the system down and remove power. Check whether the adapter carries its own supply before touching any connector.
2. Label every camera, cable and socket at both ends, so each substitution later traces back to a part.
3. Compare connector pitch, contact count and contact orientation against the assembly drawing. Two flexes can share a 0.5 mm pitch and present contacts on opposite faces; mechanical fit says nothing about pin 1.
4. Inspect each flex for creases, scratched contacts and uneven insertion at the stiffener end.
5. Reinsert the cable squarely, close the latch fully, and replace a damaged connector instead of holding it in place by hand.
6. Support the camera and the cable so neither loads the connector during the test.

Before adding length or a second adapter, run the CSI camera extension cable checks. The camera cables in the shop cover the USB3, GigE and I/O assemblies for the interface change covered later; none of them replaces a CSI flex.

Prove control, then one stream, on the reference socket

Put one camera on the reference socket with the manufacturer's software and a fixed mode: one resolution, one pixel format, one frame rate. Control and image data are separate paths. The sensor answers register reads on the I2C control bus at 100-400 kbit/s, the standard and fast modes, while the pixels ride differential data lanes at hundreds of Mbit/s. A camera can pass every register read and still deliver nothing.

Capture the startup log and mark the last stage that succeeds:

• Power and reset sequencing completed.
• The expected sensor answered at its 7-bit address on the intended bus segment.
• The receiver accepted the mode: lane count, lane rate, pixel format.
• Acquisition started and complete frames arrived, with no short-frame reports.

If detection itself fails, follow sensor connection diagnostics. If the sensor answers but no frames arrive, use the CSI acquisition sequence. Never load a driver configuration written for a visually similar module: the lane count, lane order and clock settings must match the assembly on your bench. Take software and firmware only from the manufacturer or its distributors.

Fix the two multi-camera killers: address conflicts and lane order

Two identical sensors answer the same 7-bit I2C address. Wire both onto one control segment and every register access gets two replies: reads return garbage, writes land on both sensors at once. The fix belongs in the adapter, in one of three forms: a separate bus segment per camera, an address-select strap that moves one sensor to a second address, or reset-gated initialization that holds every sensor except the one being programmed. Solve it there, not by improvising pull-ups or reset wiring on the bench.

Lane order is the second killer. The receiver expects lane 0 on its lane-0 input, in sequence, and an adapter that swaps two lanes delivers a sensor that enumerates fine and produces a torn or black image. Check the lane mapping in the driver configuration against the adapter drawing, line by line, before blaming the sensor.

Size each physical output before adding streams

Bandwidth is a per-output question, not a system-wide one. Independent receiver inputs each carry their own lane budget; an aggregator puts every stream on one shared link.

• width, height: transmitted image size in pixels
• bits_per_pixel: bits sent per pixel on the link, 10 for RAW10
• fps: frame rate in frames per second
• active_data_lanes: MIPI data lanes carrying the link

Work it for a 2048 × 1536 sensor at RAW10 and 30 fps:

Two limits apply. MIPI D-PHY v1.2 sets the signaling ceiling at 2.5 Gbit/s per data lane, and embedded processors commonly run 0.8-1.5 Gbit/s per lane, so read the supported lane rate from your processor's receiver specification. Then budget 80% of the lane rate for payload, because packet headers, line blanking and LP-HS transitions consume the rest. Four lanes at 0.944 Gbit/s each sit at 38% of the D-PHY ceiling, with real margin.

Host memory is the second limit. Unpacking RAW10 into 16-bit buffers multiplies the DMA write by 1.6: 3.77 Gbit/s on the wire becomes about 0.75 GByte/s into memory, so size the host for the expanded figure.

Dropping the frame rate is the cleanest diagnostic in this class. If errors disappear at 20 fps, which is 0.63 Gbit/s per stream for this sensor, the fault is capacity or signal integrity, not software. The camera lane bandwidth explanation separates this payload arithmetic from the modes a receiver actually supports.

Read the failure pattern, then change one part

Order the tests by cost. Seating and configuration cost minutes; cameras and adapters cost money.

For faults that hit several streams at once, the shared-hardware isolation method narrows the common component. For faults that survive a clean physical check, the intermittent acquisition checks separate transport faults from application behavior.

Never wiggle a live cable as a stress test. Reposition with power off, secure the assembly, then watch the stream without touching anything.

Fix the mechanics before judging stability

A camera loose on a bench changes cable tension between tests, so a configuration change looks like a cure when the real change was mechanical. Hold the camera at a repeatable position with a fixture from the camera stands range. The LS-MNT-0006 portable optical test stand does this job on the bench: it carries the board at a set height and reach, so the flex holds the same bend in every test and a passing test means the connection passed.

Support the flex separately, with no pull or twist on the connector, and check mounting-hole positions and board clearance against the stand before final assembly. The accessories finder lists the mounting and cable options. A stand fixes positioning; it does not reroute lanes or replace the adapter named in the drawing.

When a different interface is the right answer

If the processor offers one 2-lane receiver and the application needs four synchronized views, aggregation on CSI-2 is the wrong fight. Move the cameras to interfaces built for multi-drop:

• USB3 gives each camera a private 5 Gbit/s link and its own share of host controller bandwidth.
• GigE gives each camera a 1 Gbit/s link with 100 m of reach on Cat5e, the IEEE 802.3 limit, and clean switching between cameras.

For synchronized multi-view capture, LS-BCM-0003 is the pick: a 3.1 MP USB3 board camera with a 1/1.8-inch global-shutter sensor at 120 fps, so one shared hardware trigger catches every view inside the same exposure window. At 8 bits per pixel, 3.1 megapixels at 120 fps is 3,100,000 × 8 × 120 ≈ 3.0 Gbit/s of payload, 60% of the USB3 link.

For distributed stations on one switch, LS-BCM-0020 is the pick: a 6.3 MP GigE board camera with a 1/1.8-inch sensor at 18 fps. At 8 bits per pixel that is 6,300,000 × 8 × 18 ≈ 0.91 Gbit/s, a full 1 Gbit/s link, so budget one cable per camera and switch backplane for the total.

Both routes, side by side:

For the cable runs, the interface cable assemblies are:

LS-CBL-0219 and LS-CBL-0199 pair with the USB3 and GigE routes; match the connector family and retention to the ports on the host before ordering. Narrow the field in the board-level cameras or the camera finder. The interface comparison explains why resolution alone never picks an interface.

Treat synchronization as its own requirement: simultaneous delivery is not simultaneous exposure. The multi-camera exposure timing checks align the exposures with one shared trigger.

Prove the repair, then order against a checklist

Set the acceptance bar before you call it fixed. Screen every enabled stream with 10,000 frames and require zero incomplete frames and zero transport errors; at 30 fps that is 10,000 / 30 ≈ 333 s, about 5.6 minutes per stream. Repeat from a cold power-up and after a stop-and-restart of acquisition, then run the intended duty cycle for the production workload.

Order against this list:

• Adapter function and revision match the assembly drawing, and the drawing matches the carrier and camera revisions.
• Every connector, cable orientation and lane route is identified on paper.
• The simultaneous camera count and every mode are supported by the receiver and driver.
• Control addressing is isolated per camera, and power sequencing is defined.
• Per-link payload sits under 80% of the lane rate, and host memory covers the expanded data.
• The fixture removes connector strain without blocking board clearance.
• Any interface change carries its own cable, software and synchronization plan.

Buy the adapter through the manufacturer or its distributor. If the design must change, start from the camera configurator. For a second opinion on a complete camera, cable and mounting arrangement, send the connection diagram and test log through application support.