You have a ToF camera module that was built to plug into a single-board computer's CSI connector, and your application runs on a PC. The tempting shortcut is a CSI-to-USB adapter board that presents a camera as a standard USB webcam, because the connector physically fits. Here is the decision and the numbers behind it: why such an adapter enumerates one image sensor only, why depth data has no format in the USB video class, what the bandwidth arithmetic says about USB 2.0 and USB 3.0, and how to specify a depth camera that connects to a PC correctly on the first order.
Can a CSI-to-USB UVC adapter bridge a ToF camera to a PC?
No — the adapter enumerates a single, factory-programmed sensor: its bridge firmware locks to one MIPI CSI-2 lane configuration and advertises one fixed set of UVC descriptors, and a ToF module matches neither, so the host never lists it as a video device.
Plug the combination in and the adapter still enumerates, because the USB side of the board talks to its bridge chip, not to your module. What the host then expects is the one sensor the bridge was built around. A ToF module drives a different image sensor, usually at a different link frequency and lane count, so the deserializer never locks and no frames arrive. The ribbon fitting the socket is mechanical compatibility, not protocol compatibility.
Expect one of two outcomes. The system shows the adapter's own camera and streams black frames from a sensor that is not connected, or the board fails to bring up its video interface at all. Neither state is a PC driver problem, so reinstalling camera drivers changes nothing. The anatomy of a converter board that works starts with firmware and descriptors matched to one part number.
Why is a CSI-to-USB adapter tied to one image sensor?
Because the bridge is firmware, not wiring: the MIPI CSI-2 clock and lane count, the sensor's register sequences and the descriptor set it advertises to USB are all compiled in for one specific image sensor.
Three layers are baked in. The receiver needs the exact link frequency and lane mapping that sensor drives. The control path needs its I2C initialization sequence, register by register. The output needs the ISP settings that turn that sensor's raw bayer data into a picture, plus UVC descriptors advertising its resolutions and frame rates. A sensor that outputs raw data with no ISP in the path already shows how much of the image pipeline lives outside the sensor die; a bridge board carries that pipeline in firmware, tuned to a single part.
Swap the sensor and all three layers break at once: the PHY never trains on an unfamiliar clock, the control bus writes registers that do not exist, and the descriptors describe frames the module will never send. The capture pipeline from sensor to host, step by step shows the dependency chain at every stage.
What does a ToF camera actually output on its connector?
Depth, not an image: the module captures several raw phase frames, converts them on board using its factory calibration, and hands the finished depth map, amplitude and confidence data to the host through its own vendor protocol.
A continuous-wave ToF sensor modulates near-infrared light and reads the phase shift of the returned signal. Four phase samples per modulation cycle give the shift, and a second modulation frequency resolves distance ambiguity. None of that traffic is a picture. The module's processor applies per-pixel calibration for temperature drift, unwraps the ambiguity, and produces a matrix of 16-bit distance values plus an amplitude map for quality gating.
That depth map is what your PC application wants, and the conversion from a 2.5D height map to a 3D point cloud is straightforward once the values arrive. Getting them to arrive is the whole problem: the vendor protocol wraps depth, amplitude and confidence into packet formats that no webcam stack anywhere speaks. The image sensor and its processor ship calibrated as one module, so depth is a property of the module, not of the sensor alone.
Does the UVC standard define a depth format?
No: the USB video class defines standard payload formats such as uncompressed YUV and RGB, MJPEG and H.264, all of which a generic webcam stack knows how to decode, and none of which describes a depth map.
UVC works by advertising payload formats in the device descriptors; the class specification summarized on Wikipedia lists what a host may assume. Depth is not on the list. The class does permit vendor-specific formats, but a generic host ignores any descriptor it cannot parse, so the depth interface sits idle until the vendor driver claims it.
This rules out every bridge design, not just one model. A board that moved the module's bytes perfectly would still hand the host a format with no decoder. The mirror image explains why some depth cameras show a color stream on UVC or V4L2: their color cameras use standard formats, so those streams pass through, while depth stays behind the SDK.
How much USB bandwidth does a depth stream need?
A 640 × 480 depth map at 30 fps and 16 bits per pixel is 147 Mbit/s, which USB 2.0 can carry, but the four raw phase frames behind it add up to 590 Mbit/s, which only USB 3.0 carries.
The depth stream alone fits inside USB 2.0 high-speed, whose 480 Mbit/s nominal rate yields roughly 35–40 MB/s in bulk-transfer practice. Add the amplitude stream at the same size and you sit at 36.9 MB/s, at the top of that range. Switch to the raw four-phase capture and 73.7 MB/s does not fit at all. USB 3.0, nominally 5 Gbit/s with around 400 MB/s of practical throughput, carries raw capture plus IR plus color with room to spare.
Bandwidth is a real constraint for anyone designing a bridge — it is the reason native depth cameras moved to USB 3.0 — but it is not the blocker here. A depth map small enough for USB 2.0 still fails on descriptors and formats. The same arithmetic rules live systems: when depth and color stream timeouts point at the USB link, run these numbers, and sizing the data path for a CSI-2 to USB bridge applies them frame by frame.
When does a depth camera show up as a UVC device anyway?
Only partly: some USB depth cameras expose their RGB or infrared cameras as standard UVC streams that video apps list, while the depth data itself travels a vendor-defined format that only the vendor SDK can open.
So the camera appears in a browser-based viewer or a conferencing app, and that gets read as proof of USB support. It is proof of one stream. The depth interface needs the vendor driver and the SDK before it starts; until then the host may list the interface but refuse to open it, which is what a UVC SET_CUR control failure on a depth camera looks like in a log. A generic UVC name in place of the model is another sign that only part of the device is claimed.
The working rule: use webcam enumeration as an aiming aid for mounting and focus, and use the SDK as the only supported read path for depth. Keep the color camera on the generic capture path if you like, pull depth through the SDK, and align color pixels to depth values in software afterward.
What is the supported way to run depth sensing on a PC?
Buy a depth camera built for a PC port: a native USB 3.0 or GigE or PoE interface with a vendor SDK for Windows and Linux that delivers depth maps, point clouds and confidence data as documented outputs.
Machine-vision 3D cameras have shipped this way for years: a USB-C or Ethernet connector on the camera body, an SDK that opens depth, amplitude, confidence and point-cloud streams, with Windows and Linux builds on the support page. The 3D vision topic page collects the integration guides around these cameras.
Decision rule. A fixed station within cable reach of the PC: take USB 3.0, the simplest single-camera setup. Several cameras, runs past a few meters, or power needed at the camera: take GigE with PoE, which puts data and power on one cable to 100 m — the IEEE 802.3 twisted-pair segment limit — while USB 3.0 copper stays practical to about 3 m. If the deeper question is 3D versus 2D rather than which depth camera, the 3D versus 2D system comparison settles that first. Robot guidance adds one more check: which depth cameras output a pose stream.
Five checks before you order:
- Interface and reach: USB 3.0 for bench distances, GigE/PoE past about 3 m or for multi-camera cells.
- SDK coverage: your operating system and language, with depth, amplitude, confidence and point-cloud outputs documented.
- Depth output form: 16-bit depth map, point cloud, or both, and the units — normally millimeters.
- Triggering: hardware or software trigger if the scene moves.
- Optics and stand-off: field of view and depth range against your mounting distance.
Which 3D sensors suit a PC-based depth station?
Three families cover most PC depth work: depth/ToF cameras for room-scale scenes and volume checks, stereo and structured-light cameras for millimeter-grade surfaces, and laser profilers for the tightest profile accuracy.
The shop's 3D sensors category lists 170 products across those families: 75 laser profilers, 34 stereo and structured-light cameras, 33 line-scan and dome 2.5D inspection systems, 15 logistics and volume cameras, and 13 depth and ToF cameras. The choice becomes a filter, not a hunt: pick the family that matches the scene, then the interface your PC has free.
For parcel and pallet dimensioning, filter the logistics and volume family for speckle structured-light cameras built around volume measurement. For close-range surface and dimension work at a bench, a projected structured-light 3D camera such as the MV-DPS200P-02 fits the stereo case. For ToF depth on a PC, the MV-DT01WMU sensing camera sits in the depth and ToF family. Each card shows the maker's printed figures.
- Type
- Stereo / structured light
- Type
- Depth / ToF camera
Where the scene moves — extrusion, web, conveyor profiling — a line-scan 2.5D system locks the depth capture to the motion. The MV-HLVS-16K100-L60, for example, reads a 16K profile at a 120 kHz sampling rate across a 600 mm emitting area length.
Send your working distance, depth range and free PC interface through the camera configurator or the camera finder. If you are migrating an embedded module design to a PC station, contact the team with your scene first — a camera with a documented PC path is the shorter project than any bridge.
Questions
Will a firmware update make a CSI-to-USB adapter accept a ToF module?
No. The mismatch sits in compiled bridge firmware, the MIPI deserializer settings and the advertised USB descriptors, none of which an end user can reconfigure. Supporting a different sensor means a new board design and new firmware from the adapter maker, and a depth output would still need a host-side driver, so no update can rescue the combination.
Will a USB 3.0 depth camera behave like a plug-and-play webcam?
Only for the streams that use standard formats. The RGB or IR cameras of many depth cameras enumerate as ordinary UVC devices, so a generic app shows live video for mounting and focus checks. The depth stream keeps its vendor-defined format, so your code opens it through the vendor SDK; a depth interface that will not start in a webcam app is expected behavior, not a fault.
How long can the cable to a depth camera be?
Plan on about 3 m for a passive USB 3.0 copper cable, the usual reliable reach for SuperSpeed links; active optical USB cables go further. Past that, GigE or PoE is the cleaner answer: a twisted-pair Ethernet segment runs to 100 m under IEEE 802.3, and PoE carries camera power over the same cable.
Is Gigabit Ethernet fast enough for a depth stream?
Yes for computed outputs. Gigabit Ethernet moves about 118 MB/s in practice, and the worked example's 640 × 480, 16-bit, 30 fps depth map needs 18.4 MB/s, so depth plus amplitude plus a compressed color stream fits with margin. Even the raw four-phase capture at 73.7 MB/s fits, though most SDKs hand you processed data rather than raw phase frames.
Should my application consume a depth map or a point cloud?
A depth map is compact 16-bit distance values on a pixel grid and suits 2D-style processing: volume checks, region gating, blob analysis. A point cloud carries true XYZ per sample and suits 3D matching, bin picking and pose work. Most vendor SDKs deliver both from one capture, so choose per algorithm and let the SDK convert rather than writing your own projection.