Two single lane CSI cameras for stereo: what to verify

You want stereo from two identical MIPI CSI-2 camera modules that each use a single data lane, at 720p30 or better, on an embedded board. The link itself is not the obstacle: one lane moves a 720p RAW8 stream with room to spare, and the worked example below puts a number on it. Builds stall on four other things - the board's driver stack, the lane count and connector, the frame budget, and exposure sync. This guide puts the checks in the order that finds the show-stopper first, works the bandwidth arithmetic for 1280 x 720 RAW8, and gives you a USB3 and GigE fallback that skips the CSI driver problem entirely.

The four checks, in order

Run them in this order, because the first failure is the expensive one:

1. Driver support. The board's camera stack must contain a driver for your exact sensor. Without it the module will not come up, whatever the connector does.
2. Lane count and connector. The module must be wired for one data lane, and the carrier connector must mate it correctly.
3. Frame budget. Width x height x frame rate x bits per pixel must fit under roughly 80% of the lane rate. At 720p RAW8 this passes with 3.6 times headroom.
4. Exposure sync. Both sensors must start each frame together, from hardware, not from two software start commands.

If check 1 fails and a driver is out of reach, change the transport, not the plan: the same stereo pair runs on USB3 or GigE board cameras without touching the CSI subsystem.

Check the driver stack before anything else

CSI-2 standardizes how pixels cross the wire: packet framing, lane distribution, error detection. It does not standardize the sensor. Each sensor family keeps its own I2C register map, power-up sequence and output format, so the board's kernel needs a driver written for that sensor, a device-tree entry naming it, and an ISP path if the module outputs Bayer RAW. The common wrong turn is treating the interface standard as a compatibility guarantee; the supported-camera list is the real catalog.

Ask the board vendor for that list before ordering modules. A sensor on it is buying into tested code; a sensor off it means a kernel driver and a device-tree overlay, which is weeks of work. When a probe fails at boot, three causes cover most cases: the wrong driver bound (read the boot log and see which sensor driver bound), a missing device-tree blob (diagnose missing DTBs), and a carrier the stack was never configured for (MIPI driver install fails on a third-party carrier board). If the sensor outputs Bayer RAW and the SoC has no ISP, the raw path needs its own handling (what raw sensor output means on a CSI camera with no ISP).

Check lane count and connector wiring

A module is wired for a fixed lane count - one, two or four data lanes - and the sensor is configured for the lanes the module actually wires. A two-lane module will not probe on a single-lane port, and dropping a lane by re-strapping is rarely exposed to the buyer. Match the module's lane count to the port first; the failure mode is a sensor that never appears (why a 2-lane module fails the sensor probe in 4-lane mode, and the reverse).

The connector is its own trap. FPC connectors differ in pin count, pin pitch and pin-1 orientation between carriers, so a cable made for one board will not mate another. Use the carrier's own adapter or cable design, and check your resolution and lane mode against its compatibility notes (what to check between a CSI camera and its carrier board, and how to check the host's resolution limits).

If the board exposes fewer CSI ports than you have cameras, a serializer/deserializer bridge aggregates two modules onto one CSI input. The bridge doubles the traffic on that lane and adds its own driver to the BSP; a walk-through of wiring a GMSL2 deserializer for two cameras shows what such a bridge adds to a build.

Worked example: 1280 x 720 RAW8 at 30 fps on one 1.0 Gbps lane

Inputs, with their sources:

• 1280 x 720 pixels - your 720p target resolution.
• 8 bits per pixel - RAW8, the leanest common mono output.
• 30 frames per second - your stated minimum.
• 1.0 Gbps per lane - a common single-lane ceiling in embedded application-processor documentation; faster SoCs run camera lanes at 1.5 to 2.5 Gbps.
• 80% usable fraction - packet headers, blanking and short packets consume the remaining 10 to 20%.

The rule in words: multiply width, height, frame rate and bits per pixel for the payload rate; multiply the lane rate by the usable fraction for the usable lane rate; divide the usable lane rate by the bits in one frame for the lane's maximum frame rate.

Arithmetic:

• Bits per frame: 1280 x 720 x 8 = 7,372,800 bits = 7.37 Mbit.
• Payload at 30 fps: 7.37 Mbit x 30 = 221 Mbps, or 27.6 MB/s.
• Usable lane: 1.0 Gbps x 0.8 = 800 Mbps, or 100 MB/s.
• Headroom at 30 fps: 800 / 221 = 3.6 times.
• Lane maximum: 800 / 7.37 = 108 fps.

Result: one healthy single-lane port at 1.0 Gbps carries 720p RAW8 at 30 fps with 3.6 times headroom and does not saturate until about 108 fps.

Decision: at 720p30, bandwidth is not your risk. Spend the effort on the driver, the connector and the sync. The budget tightens as frames grow or bit depth rises:

Cross into 1080p at 60 fps and the single lane is done: 995 Mbps of payload against 800 Mbps usable. You then need a faster lane, a second lane, or fewer bits per pixel. The lane is one link in the chain; the sensor's own readout also caps the rate (what limits MIPI camera frame rate, lane by lane).

Synchronize the two exposures

Stereo depth needs both frames to describe the same instant. Two streams started in software drift by milliseconds, and milliseconds are disparity: on a belt moving at 0.5 m/s, 5 ms of skew displaces the scene 2.5 mm between the left and right frames - straight into the depth error. Wire both sensors' trigger or frame-sync lines to one source. A hardware trigger aligns exposures to within microseconds; two software start commands rarely beat a few milliseconds. Before wiring the line, check the connector's GPIO electrical limits (camera GPIO wiring: prevent damage and triage power faults).

Global shutter or rolling shutter is the second half of the decision. A global-shutter sensor captures every line at once, so a moving scene stays undistorted. A rolling-shutter sensor scans line by line, which suits a static scene and distorts a moving one even when the pair is perfectly synchronized. For a fixed station at 720p30, rolling shutter works; for moving parts, buy global shutter.

Match the pair: two modules from the same batch, with the same sensor and the same lens, calibrate far more easily than a mixed pair. How to match sensors across a multi-camera set covers selection, raw stereo image calibration: verify streams and metadata covers the calibration step, and smoothing noisy stereo depth maps is the usual next fix when raw depth comes out rough.

If the driver check fails: USB3 and GigE board cameras

When the sensor is not on the board's list and a driver is out of reach, keep the plan and change the transport. USB3 and GigE board cameras plug into ports the host and the camera SDK already handle, so the CSI bring-up disappears. The bandwidth dwarfs the requirement: 720p30 RAW8 needs 27.6 MB/s, a GigE link moves about 118 MB/s of payload on a 1 GbE port - roughly four such streams per port - and USB3 gives about 350 to 400 MB/s.

For an Ethernet stereo pair, the MV-CB016-10GM-M-W offers a 1.6 MP mono IMX296 sensor with a global shutter behind an M12 mount:

On USB3, LS-BCM-0003 is a 3.1 MP board camera on a 1/1.8-inch IMX252 global-shutter sensor, rated to 120 fps:

And if you would rather not keep two streams in step at all, the catalog also lists LS-BCM-0059, a GigE split-sensor board camera (1.0 MP, mono, 1/4-inch sensor, M12 mount): one camera, one stream, and no second camera to synchronize.

Board cameras take small lenses: M12 screw-in lenses on compact modules, CS- and C-mount barrels on larger boards. Match the image circle to the sensor - an up-to-8 mm circle covers 1/2.7-inch and smaller formats, while 1/1.8-inch and 2/3-inch formats need the 8-11 mm class - and order two identical lenses for a stereo pair. The CCTV lens range, including M12 mounts sorts by mount and image circle, and the board-level camera range holds the camera side.

Hardware triggering still matters on the fallback path, because the sync requirement does not leave with the CSI port. Verify the trigger line is wired and exercised before committing the module, the same way you would for any synchronized pair. For the wider selection method, board level camera selection for embedded vision machines and the board camera evaluation checklist for inspection systems cover mount, sensor and interface choices, and camera module interface compatibility: what to verify lists what to confirm before ordering.

Checks before you order

• Sensor on the board's supported-camera list, checked against the current BSP release.
• Module lane count equals the port's lane count.
• FPC pin count, pitch and pin-1 orientation match, or the carrier documents an adapter.
• Frame budget passes: width x height x fps x bits per pixel at or below 80% of the lane rate - 720p RAW8 at 30 fps needs 221 Mbps against 800 Mbps usable.
• A trigger or frame-sync signal exists on both module connectors, with one source to drive both.
• Global shutter chosen if the scene moves; rolling shutter only for static scenes.
• Two identical modules and two identical lenses on the order.
• An ISP on the SoC, or a mono RAW pipeline, if the modules output Bayer RAW.
• The fallback priced: a USB3 or GigE pair, in case the driver check fails.

The decision, compressed: confirm the sensor's driver first; confirm one lane on both halves of the connector second; budget the frames third (720p RAW8 at 30 fps is 221 Mbps against 800 Mbps usable, a pass); trigger both cameras from one line fourth. If step one fails and no driver is coming, the identical stereo pair lands on GigE or USB3 board cameras without touching the CSI subsystem. To shortlist that fallback, filter the camera finder by interface and shutter, or build the pair with lenses in the camera configurator; the contact page takes specific pairing questions, and more board-camera guides cover the rest of the bring-up.