Board level camera sensor compatibility: match the host before you buy

You have chosen a board-level camera module for its sensor, paired it with a host board, seated the ribbon cable and flashed the newest firmware — and the connected-camera list still comes back empty. In most cases nothing is broken: the sensor is not on the host's supported list, so the host never starts it. This guide is for engineers building embedded vision machines with FFC or board-to-board camera modules. It gives you the five-point compatibility check to run before you buy, the bandwidth arithmetic with real numbers, a symptom table that separates a list problem from a wiring fault, and the bench sequence that settles a pairing in about an hour.

Why does a seated ribbon cable still give an empty camera list?

Because a raw sensor board has no voice on the link: a CSI-2 ribbon carries only the pixel stream, so when the sensor is missing from the host's supported-sensor table, the host never starts it and every port reports an empty list.

A raw sensor board is dumb by design. It pushes pixels over its MIPI CSI-2 lanes once its registers are set, and it offers the receiver no way to ask what is attached. USB and Ethernet devices answer a discovery handshake; a CSI-2 link does not. The host firmware carries the knowledge instead: a compiled-in table of sensor drivers, each holding that sensor's register map, lane mapping, data-type codes and link frequencies. No entry, no camera — and no error message that says so.

That is also why a firmware version proves so little. Current means current for the sensors it lists. If the release notes never name your sensor part number, updating again will not change the answer. An empty list on every port you try is the signature of an unsupported pairing; a wiring fault is almost always specific to one cable or one port. The CSI camera and carrier board compatibility checks cover the rest of that pairing.

What must match between a sensor module and its host board?

Five things have to match: the sensor part number must be on the host's supported list, the CSI-2 lane count must match the module, the pixel data format must be one the receiver decodes, the connector pinout and I/O voltages must agree, and the link must carry your frame rate.

Work through them in order, because each fails differently:

1. Supported list. The host's module list or firmware release notes must name your sensor part number at the firmware build you will ship.
2. Lane count. A 4-lane sensor cannot run on a host wired for 2 lanes, and sharing lanes between ports cuts the per-camera rate; the host side sets its own MIPI CSI camera resolution limits.
3. Pixel data format. RAW10 and RAW12 arrive packed, and the receiver must decode that data type; a mismatch gives noise bands and shifted colors, which the Bayer raw stream check tells apart from a wiring fault.
4. Connector and power. Same FFC pin count, same pin-1 corner, and supply and I/O levels that agree — a 1.8 V module on a 3.3 V host is a dead module or a short-lived one.
5. Bandwidth. The link's practical payload must carry width × height × bytes per pixel × your target frame rate, with margin. The arithmetic comes next.

How do you read a supported-sensor list before you buy?

Match the exact sensor part number and hardware revision, not the sensor family: a supported list is version-specific on both sides, and a same-family swap has ended more integrations than any cable fault.

Find the list where the host maker publishes it — the supported-modules page or the firmware release notes — then check three things.

• Exact part number. An entry for IMX178 does not cover IMX296; 'same series' is not an entry.
• Hardware revision. Lists track board revisions, and a module bought a year apart can differ from the first one. The hardware revision compatibility check walks the comparison.
• Firmware gate. A sensor added in one release does not exist on a board running an older build; ship the build that names your sensor.

Plan the exit too. Sensors go end of line, and a pairing that works today can lose its sensor supply. Decide the replacement module now, before a sensor going end of line forces the choice under deadline pressure.

How much bandwidth does the host link need to carry your frame rate?

Size the link in megabytes per second: width × height × bytes per pixel × frames per second, kept below the link's practical payload — about 118 MB/s on GigE and about 400 MB/s for USB3 on a normal host.

The two practical payloads do most of the deciding. GigE runs a 1,000 Mbit/s line rate and delivers about 118 MB/s of image data once protocol overhead is paid. USB3 is rated 5 Gbit/s (625 MB/s), and a normal machine sustains about 400 MB/s of it.

The ceiling shows up in printed specs across the area scan cameras range: the LS-CMR-0053 is specified at 9 fps with its 12 MP sensor on GigE. Small sensors live far from the ceiling: the MV-CB016-10GM-M-W records 1.6 MP, and a GigE link carries that payload many times over.

Decision rule: compute your frame size, divide the link payload by it, and compare with the frame rate the inspection needs. If GigE comes up short, cut bytes first — ROI, 8-bit output, binning — then step up to USB3. For a large sensor on GigE, the LS-BCM-0056 with its 12 MP sensor and 1.6 μm×1.6 μm pixels is the board camera to run this arithmetic on before you fix its frame rate.

When is the fault wiring or power, not the supported-sensor list?

Let the pattern decide: an empty camera list on every port points at an unsupported pairing, while a failure on one port with success on another points at the cable, the connector or that port's power.

Each row has a deeper guide: image corrupted: check format and wiring for the third row, and ribbon cable replacement: latch and length limits for the second and fourth. If the pattern is the first row, stop re-crimping cables: no cable adds a missing driver entry.

Which board-level cameras avoid the supported-sensor problem?

Cameras that speak USB3 Vision or GigE Vision enumerate on any host with the right port and runtime: the camera manages its own sensor, answers discovery and publishes its formats, so there is no host-side sensor list to fail.

That guarantee costs size and money. A standard-protocol module carries a bridge, its own memory and a lens mount, where a raw CSI board is a sensor on a carrier. Keep the raw module when the host is fixed, listed and stable. Keep the standard-protocol module when the host may change, when several machines share the design, or when you want one image pipeline everywhere. The full checklist lives in camera module interface compatibility: what to verify.

USB3 adds one pairing question of its own — the bridge chip on the module must be matched by the host's controller and driver stack — and the board-level camera and USB3 bridge board match guide covers it. For a global-shutter module on USB3, the LS-BCM-0003 pairs an IMX252 with a C-mount and streams at 120 fps.

These four cover the common host ports on our board-level range:

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

What should you verify on the bench before ordering quantities?

One bench hour before you order settles the whole pairing: confirm the list entry, capture raw frames, stream at your target frame rate for 30 minutes, and log the measured throughput against your budget.

1. Confirm the entry. Find the sensor part number and module revision in the host's list at the firmware build you will ship, not a newer one you hope to install.
2. Compute the budget. Frame size from the formula above, target rate from the inspection, payload from the link; keep 20% or so of headroom for overhead you have not measured yet.
3. Capture raw frames. Bring the stream up in the sensor's raw format and look for shifted lines; the raw image capture check shows what to look for.
4. Stream at rate. Run a clean half-hour at the target frame rate and log dropped or partial frames; a five-second demo proves little.
5. Measure the link. Log actual throughput against the budget; if it cannot reach the budget, the link is the limit and no firmware update moves it.

Then decide, case by case:

• Listed and bandwidth clear: order the pair and run the bench sequence before it goes into a machine.
• Not listed, and no release note adds it: change one side — a listed module on this host, or a host that lists this module.
• Bandwidth short at the target rate: cut bytes first (ROI, 8-bit output, binning), then step the interface up from GigE to USB3.

From there, the board camera evaluation checklist for inspection systems takes you from pairing to full station. Pick the module on the board-level cameras page or the camera finder, and pair it at the camera step of the configurator.

Every order includes free expert support: send us the host and module part numbers, and we will check the list, the lanes and the bandwidth with you. The cameras topic page collects the rest of the sensor and interface guides.