No CSI camera for your SBC? When to switch to USB3 Vision

Your product plan sits on a single-board computer, the board carries a MIPI CSI-2 connector, and no camera in the maker's catalog fits it. That gap is normal on x86 and ARM SBCs alike, and waiting for the vendor is usually the wrong call. This page is for the engineer choosing between an unwritten MIPI driver, an indefinite wait and a switch to USB. You get the decision rule with its volume threshold, the bandwidth arithmetic that shows a switch costs almost nothing in throughput, the UVC-versus-USB3 Vision split, and the checks to run before ordering. By the end you can order a camera this week and leave the CSI footprint free for a module that may never arrive.

Why does my SBC have a CSI-2 connector but no camera?

Because a connector is only copper: a MIPI CSI-2 port moves images after someone writes a per-sensor driver, matches the SoC receiver to it and validates one specific module — and on many boards that work has not been done for any camera you can order.

Wiring the connector to the SoC's receiver costs a board maker a few cents of layout at design time. Supporting a camera costs a driver, a device-tree binding, receiver lane settings and a validation program with a module partner — months of software for a peripheral most buyers never touch. One SBC vendor answered the question in public: its CSI camera was still in validation, the minimum order for validation was 10,000 pieces, and the future module was expected to serve the successor board as well. Until that program lands, the connector is decoration.

Treat 'supported' as a list, not a pinout: a named camera module, a driver in the vendor's BSP or the mainline kernel, published lane and power settings, and a tested combination. If the board's documentation names none of that, plan the product as if the port were unpopulated, starting with the mechanical footprint. MIPI CSI-2 camera compatibility: beyond the connector covers what a real compatibility claim must include, and sensor support decides module compatibility shows why the sensor, not the connector, is the decision.

What does bringing up my own MIPI camera take?

Four deliverables, all yours: the sensor's power-up register sequence, a kernel driver for that sensor, a device-tree fragment matching lanes, clocks and I2C address, and the receiver's lane settings in the SoC — budget four to twelve engineering weeks the first time.

• The init sequence is hundreds of register writes that set the sensor's mode, exposure type and lane rate. Sensor makers release it to volume customers, often under an NDA; without it you are guessing.
• The driver is a V4L2 subdevice exposing exposure, gain and format controls, bound to the receiver through the device tree.
• The lane settings must match the sensor's output exactly. A mismatch gives torn frames or silent timeouts, and separating I2C from MIPI failures is the diagnostic split. On one widely used SoC family, a four-lane sensor only produced stable frames after explicit lane remapping — check the lanes first on the carrier board.
• The maintenance lands after bring-up: BSP updates break custom camera drivers, third-party carriers add install traps, and a camera that pulls too much current can freeze the whole board. Driver install failing on a third-party carrier and a board that freezes: test the power supply first are the two recurring stories.

Even validated rigs fail late: CSI links that drop after hours of stable streaming are a known failure class on mature platforms — a CSI camera timing out after a working period is a representative case. A driver you own is a maintenance line item for the life of the product.

Wait for the vendor's module or switch to USB now?

Switch now unless your program clears the vendor's validation MOQ — the public answer above sits at 10,000 pieces — and your schedule can absorb a quarter-year of bring-up; below that volume there is no CSI camera you can actually order.

• Program total under 10,000 units: USB. There is no purchase order you can place for the CSI path, at any price.
• Over 10,000 units with schedule room: order the validated module when it exists — and still prototype on USB, because USB cameras are catalog products today and your image processing does not change.
• Sustained rates past what one port moves, or microsecond-class trigger latency: step past USB entirely. CoaXPress serves that end — the most reliable camera interface: GigE, USB3, Camera Link or CoaXPress compares them.

UVC or USB3 Vision: which USB camera fits the task?

UVC when you need pixels today and can accept 8-bit, mostly compressed video with automatic exposure; USB3 Vision when the task needs raw Bayer, 10- or 12-bit depth, a hardware trigger line and deterministic exposure control.

UVC is the webcam class: the kernel's uvcvideo driver is in mainline, the device appears as a standard video node, and you are streaming within the hour. The price is the format list — YUYV or MJPEG at 8 bits, auto exposure by default — plus software-only timing: no trigger input, no frame-level sync across cameras. UVC on an embedded board: driver-free support covers the bring-up, and what UVC plug-and-play really means sets expectations for manual controls.

USB3 Vision is the industrial class: a GenICam feature tree over a standard transport, raw Bayer at the sensor's native bit depth, opto-isolated I/O lines for trigger and strobe, and deterministic exposure. On Linux you acquire through a GenICam path such as Aravis rather than V4L2 — USB3 Vision has no V4L2 support: pick the acquisition path — and if your pipeline wants raw Bayer either way, MIPI CSI vs USB3 for a raw Bayer stream compares the two transports on exactly that.

Distance changes the answer. Passive USB3 holds to about 5 m; GigE runs 100 m on Cat5e and can carry power on the same cable where both ends support PoE — does my camera support PoE: check the port before you buy lists what to look for. A gigabit link moves about 125 MB/s after encoding. The LS-BCM-0020 is a 6.3 MP board-level camera, 1/1.8" rolling shutter, CS-mount, GigE at 18 fps; the MV-CB016-10GM-M-W is a 1.6 MP mono board camera, 1/2.9" global shutter, M12 mount, on a WTB GigE port.

Bandwidth check on the 6.3 MP stream: 6.3 million pixels at 8 bits is 6.3 MB a frame, and 6.3 MB × 18 fps ≈ 113 MB/s — 90 percent of a gigabit link, so one camera per cable and no doubling up.

Will one USB3 link carry my frame rate and bit depth?

Yes, up to roughly 400 MB/s (3.2 Gbit/s) of usable bandwidth per port: a 3.1 million pixel sensor at 120 fps and 8 bits streams at 372 MB/s with about 7 percent headroom — one camera fits, two on the same controller do not.

Worked example at 8 bits: 3,100,000 px × 1 B = 3.1 MB per frame. Then 3.1 MB × 120 fps = 372 MB/s, which is 372 × 8 = 2,976 Mbit/s ≈ 3.0 Gbit/s. The budget behind it: USB3 signals at 5 Gbit/s, 8b/10b encoding keeps 80 percent of that (4 Gbit/s), and protocol plus host overhead bring a realistic streaming plan to 3.2 Gbit/s, or 400 MB/s, per port. Headroom here is 400 − 372 = 28 MB/s, about 7 percent.

Same pixels at 10 bits: 3,100,000 × 10 ÷ 8 = 3.875 MB per frame, and 400 ÷ 3.875 ≈ 103 fps is that port's ceiling. Bandwidth is not the only clock either: at 120 fps the frame period is 1 ÷ 120 = 8.3 ms, so any exposure longer than 8.3 ms caps the frame rate on its own.

For contrast, an uncompressed UVC stream of 1920 × 1080 YUYV at 30 fps is 2,073,600 px × 2 B = 4.15 MB a frame, × 30 = 124 MB/s ≈ 1 Gbit/s. One USB3 port carries several of those.

For a camera that mounts on your own carrier, the LS-BCM-0003 is a 3.1 MP board-level camera with a 1/1.8" global shutter, a C-mount and USB3 at 120 fps — the numbers in the example above.

If a finished housing suits the job better, the MV-CU020-90GC is a 2.5 MP area scan camera on GigE, Color, 1/1.7" global shutter, C-mount.

Above one camera, add controllers rather than ports. The MV-GU2204 is a quad USB3.0 adaptor with 4 ports; map ports to controllers before you assign cameras — assigning cameras to ports reliably in a multi-camera system — and on the host side, USB3 bandwidth and CPU budget on an ARM SBC shows where the second bottleneck usually sits.

What do you lose by leaving the CSI port unused?

Unit cost, connector space and about a millisecond of transport latency — not bandwidth: two CSI-2 lanes at a typical 0.8-1.5 Gbit/s per lane move 1.6-3.0 Gbit/s, the same order as the 3.2 Gbit/s a USB3 port really delivers.

Cost. Past the volume where a validated module becomes orderable, a soldered-down module with a flex undercuts an industrial USB camera on per-unit cost, and the driver you already paid for amortizes across the run. Below that volume, the driver effort sits on top of every unit you ship. That is the whole trade.

Space. A USB camera needs a connector and a cable exit where a CSI flex needed a 15-30 cm ribbon and little else, and a housed camera adds a lens and a mount. Budget the enclosure before you commit.

Latency. Both paths land in single-digit milliseconds from trigger to host memory; USB adds controller hops and buffering. Only a closed-loop servo notices the difference.

Power. A bus-powered USB3 device may draw up to 900 mA at 5 V — 4.5 W — from the port, where a CSI module sips. Count it against the SBC's supply budget.

What you keep matters as much: cameras you can swap without a driver project, serviceable cables, and a CSI footprint that stays free. If volume later justifies a validated module, adopting it becomes a cost-down rather than a redesign.

What to check before ordering a USB camera

Seven checks before the order: one camera per USB3 controller, a kernel path for the standard you pick, cable runs inside 3-5 m, power inside the 4.5 W bus budget, trigger wiring for the PLC, a mount and lens plan, and a revision story.

• Controller mapping. Ports are plentiful; controllers are the resource. Confirm which physical ports sit on which controller and put one high-rate camera on each. Some embedded boards silently drop a USB3 port to USB2 depending on the connector — troubleshooting USB3 camera fallback on an embedded board walks that diagnosis.
• Software path. A UVC device binds to the kernel's video driver out of the box; a USB3 Vision device needs a GenICam acquisition stack in your software plan. Decide before you order, not after.
• Cable and interference. Shielded USB3 cable with ferrites, routed away from drives and contactors; 3-5 m passive, active or optical beyond.
• Power. A bus-powered camera may draw 900 mA at 5 V, or 4.5 W; board-level cameras often want their own rail instead. Measure rather than assume.
• Trigger and strobe. Industrial cameras expose opto-isolated input lines; take the PLC's 24 V through them, never straight onto the camera I/O. Keep exposures inside the 8.3 ms frame period at 120 fps, or accept a lower rate.
• Mount and mechanics. A board-level camera needs your carrier and housing — housing design from maker STEP files — and the mount thread decides the lens family, as board camera lens mount thread sizes: M12 or M6 breaks down.
• Longevity and evaluation. Ask for the hardware revision story before any reorder — hardware revision compatibility before you reorder — and run the board camera evaluation checklist over the shortlist.

The lens is the item CSI users forget: the module shipped with one, the C-mount camera does not. Example: a 200 mm wide field on a 1/1.8" sensor (about 7.2 mm across) needs a magnification of 7.2 ÷ 200 = 0.036, and a 12 mm lens then sits at 12 ÷ 0.036 + 12 ≈ 345 mm working distance. Pixels on a 3 MP version of that format run about 7.2 mm ÷ 2048 px = 3.5 μm, and the Airy disk at f/2.8 is 2.44 × 0.55 μm × 2.8 ≈ 3.8 μm — already pixel-sized, so faster glass buys almost nothing there. Run your own numbers in the lens focal length calculator.

Start with board-level cameras for an embedded build or area scan cameras for a finished USB3 or GigE unit; add ports and controllers from frame grabbers and USB adaptors once you pass one camera. The camera finder and the camera configurator shortlist in minutes, and for a multi-camera cell or a volume program, send the requirements through the contact page and the team will size links and controllers with you.