Board-level camera and USB3 bridge board: match before you stream

You have a bare image-sensor module — say a 2.3 MP global-shutter part with a 1920 × 1200 array — and a USB3 bridge board that should turn it into a camera. The pair enumerates, the driver loads, and still no frames arrive. In most such cases the sensor is healthy: the module's physical interface, its lane count and data format, or the bridge's per-sensor configuration file does not match. This guide shows you how to identify what your module actually outputs, read the bridge's configuration set like a parts list, load or request the right file, and prove acquisition with a first-frame test whose byte count you can compute before the first power-up. Each mismatch case ends with a decision: fix the configuration, swap the module, or order a finished camera.

What has to match: interface, format and timing

A USB3 bridge board does three jobs. It initializes the sensor's registers over I2C at power-up, receives pixel data over the module's physical interface, and repackages that data as USB3 traffic for the host. A per-sensor configuration file drives all three jobs: it holds the register init plus the receiver settings — interface type, lane count, pixel format and bit depth, frame dimensions and frame timing.

Three things must agree:

• Physical interface. MIPI CSI-2 or parallel DVP. CSI-2 uses a differential clock pair plus one to four differential data lanes; DVP uses a wide single-ended data bus with a pixel clock, HREF and VSYNC. A two-lane CSI-2 module moves more data over fewer high-speed conductors than a comparable DVP design, and the two are not convertible by wiring.
• Format. Lane count, bit depth and resolution. A configuration written for a two-lane RAW8 stream will not decode a two-lane RAW10 stream, even when the sensor name matches.
• Timing. The register init sets the frame size and rate the sensor produces, and the receiver decodes exactly that stream. Register init from a different module variant produces a stream the receiver was never set up for.

When any of the three disagrees, the symptom is identical: enumeration without frames, or frames that decode to noise. What the bridge hardware itself must carry is its own checklist — what a MIPI CSI to USB UVC converter board must include — and the connector-level differences between the two interfaces are laid out in DVP versus MIPI CSI-2: why the connectors don't match.

Identify the module before you connect anything

Sensor part numbers hide the split. The AR0234, a common 2.3 MP global-shutter sensor with a 1920 × 1200 active array on a 1/2.6-inch optical format, ships in modules that expose either MIPI CSI-2 or the parallel port — the sensor data sheet documents both output paths. Same die, different module, different configuration file. Windowed output modes such as 1080p and 720p exist alongside the full array, so record which mode your module runs, not just which sensor it carries.

Settle the interface from the module itself, not from the shop listing:

• Connector and pin legend. A CSI-2 module breaks out differential lane pairs plus an I2C pair. A DVP module breaks out the wide single-ended bus with PCLK, HREF and VSYNC.
• The module's own marking or data sheet. It outranks the listing every time.
• Which connector on the bridge. Some bridge boards carry more than one module port, and the configuration file declares the port it drives; keep module and file on the same port.

If the interface is still ambiguous, camera module interface compatibility: what to verify walks the checks in order.

Read the configuration set as a parts list

Bridge vendors publish configuration files grouped by bridge hardware revision, then interface, then sensor. The file names read like a spec line; a documented example is OV5647_MIPI_2Lane_RAW8_8b_2592x1944_8fps.cfg — sensor, interface, lanes, format, bit depth, width × height, frame rate. Read the whole name before loading anything: the lanes and bit depth it declares must equal what your module streams, not merely share its sensor token.

Two conclusions follow directly:

• A configuration set that covers the parallel-port variant of your sensor but not the MIPI variant means that bridge cannot drive your module today. The fix is a file from the bridge vendor — vendors generate per-sensor configurations on request — not an adapter or a rewire.
• A file named for your sensor can still target different lanes, bit depth or frame rate than your module streams. Match the entire name against the module's spec line.

A lane-count mismatch is not only a decode problem: on embedded hosts it can break the sensor probe outright, which MIPI camera 2-lane vs 4-lane mode: why the sensor probe fails demonstrates.

Pair the module and the bridge in seven steps

You need the module, its data sheet, the bridge board with its configuration set and driver installed, and a host with the bridge's grab utility.

1. Write the module's spec line. Interface, lane count, bit depth, resolution, frame rate, taken from the module's marking or data sheet. For an AR0234-class module that line might read: MIPI CSI-2, 2 lanes, RAW10, 1920 × 1200.
2. Find the configuration for your bridge revision, interface and sensor. No entry for your interface? Request one from the vendor — generating a file from a sensor's register map is routine work.
3. Match the full file name. Lanes, bit depth, resolution and frame rate in the name must equal the module's spec line. A sensor-name match alone is not a match.
4. Connect the module to the port the configuration declares. Supply module power from the bridge's module-power pin at the voltage the module's data sheet states. Never mate a CSI-2 module to a header wired for DVP; the pinouts share almost nothing.
5. Apply the configuration and enumerate. The bridge writes its register init over I2C at power-up. If the sensor probe fails or returns a wrong ID, the I2C pair is the suspect: see MIPI camera sensor ID mismatch: diagnose the wrong I2C probe and I2C error -121 on a camera sensor probe: fix the physical link before touching the file.
6. Grab one frame and count its bytes. The expected number is arithmetic, not hope — the next section gives it.
7. Budget the USB3 bus before adding a second camera. The per-camera method is in the bandwidth section, and reduce USB3 camera bandwidth: the per-camera budget math carries the full treatment.

The first-frame test: byte counts you can check

The first frame carries the diagnosis in its size. Compute the expected value before the first power-up:

Worked example — 1920 × 1200 at 60 fps in packed RAW10, a representative stream for this sensor class, not a rated maximum:

• frame bytes = 1920 × 1200 × 10 ÷ 8 = 2,880,000 bytes (2.88 MB)
• stream rate = 2,880,000 × 60 = 172,800,000 B/s = 172.8 MB/s

Read the grab against those numbers:

• 2,880,000 bytes — packed RAW10 (four pixels in five bytes). The receiver matches the module; go on to content.
• 2,304,000 bytes — the frame arrived as RAW8. Load the RAW10 configuration or set the sensor output to 8 bits to match the file you have.
• Any other size — the resolution in the configuration is not what the sensor outputs; correct the file or the register init.
• Zero frames — back to the interface: the file declares DVP and the module speaks CSI-2, or no matching file exists yet.

Then point the module at an evenly lit, plain surface. A flat gray frame with low noise proves the decode chain. Stripes, diagonal shear or a horizontally shifted image mean lane count or bit depth still disagree. If raw formats are new to you, CSI camera with no ISP: what raw sensor output means explains what the bytes represent, and MIPI CSI camera no images: troubleshoot acquisition works the no-frame case stage by stage.

Bandwidth: the stream's cost on USB3 and on the module link

USB3 side. USB 3.0 signaling runs at 5 Gbit/s, which is 625 MB/s. 8b/10b coding spends a fifth of that, leaving 500 MB/s at the link layer; framing and protocol overhead bring practical bulk throughput to roughly 400 MB/s on a healthy host controller. The example stream takes 172.8 MB/s, about 43% of the bus, so one camera is comfortable. Two of them claim 345.6 MB/s, about 86%: it fits on paper and fails in practice whenever anything else touches the controller. Put the second camera on its own controller or lower its frame rate; USB hub drops camera frame rate: budget the bandwidth first shows the failure mode.

Module side. The same 172.8 MB/s crosses the CSI-2 link: on two lanes that is 86.4 MB/s each, or 691.2 Mb/s of payload per lane. CSI-2 packet overhead of roughly 10-20% puts the line rate near 0.8-0.9 Gb/s, which a standard 1.0 Gb/s D-PHY lane setting carries with margin. A single lane would need 1,382.4 Mb/s of payload and roughly 1.6 Gb/s of line rate, beyond what bridge receivers typically offer per lane. Two lanes are the minimum for this stream; four lanes buy headroom for higher frame rates. MIPI CSI-2 to USB bridge bandwidth: sizing the data path sizes the whole path end to end.

Keep the host link healthy in hardware too: a marginal cable shows up as frame drops under load long before it fails on the bench. The LS-CBL-0219 is a 3 m high-flex USB3.0 camera cable with a drag-chain rating for moving runs.

Common mismatches and what they look like

Three habits save the most time:

• Order and connect by the module's interface, never by sensor name alone.
• Compute the expected first-frame byte count before the first power-up.
• Reserve USB3 bandwidth per camera before adding hardware.

When to skip the bridge and order a finished board camera

Pairing makes sense when a configuration exists for your sensor and interface and the schedule absorbs bench time. Skip it when the vendor has no file for your variant, when trigger I/O and driver support carry the project, or when several engineers will maintain the machine. A finished board-level camera pairs sensor and interface at the factory: exposure, gain and trigger are SDK settings, not register-level files.

For a global-shutter module in the same performance class as the worked example, the LS-BCM-0003 is a finished board-level camera with a 3.1 MP sensor on a 1/1.8-inch optical format, C-mount, USB3 interface and 120 fps.

Two more finished USB3 modules cover other common cases. The MV-CB060-10UM-B carries a 6 MP mono sensor on a bare board with a 1/1.8-inch format, and the LS-BCM-0043 is a binocular module with global shutters delivering 1280 × 1024 over USB3 — check its data sheet for the frame rate at your exposure settings.

Decision: if the vendor can supply a configuration for your sensor and interface within the schedule, pairing is the leaner path. If not, or if the stream must be production-ready now, order the finished module — its interface work is done. The choice criteria are laid out in board level camera selection for embedded vision machines.

Checks before you order

• Module interface identified from its own documentation, not the listing.
• Configuration file exists for your bridge revision, interface and sensor, with the full file name matching the module's spec line.
• Expected first-frame byte count computed from resolution and bit depth.
• USB3 budget: sum of stream rates under about 400 MB/s per host controller.
• Cable rated for the installation — drag-chain stock for moving runs.
• For inspection duty, run board camera evaluation checklist for inspection systems before committing a module to the line.

To shortlist finished modules, start at the board-level cameras category or the camera finder; the camera step of the configurator narrows by sensor, interface and mount. For the host link, the camera data cables category carries the high-flex USB3 stock. Free expert support comes with every order if you want a second pair of eyes on a configuration, and the contact page reaches the team. More acquisition-side guides sit on the systems topic page.