Depth camera fails on a USB hub: why raw streams refuse to start

A depth camera that runs fine on a host port but refuses its depth and IR streams behind a USB hub is almost always up against a link that fell back to USB 2.0. The camera enumerates, color starts on its own, and the two raw streams are declined at start-up because a 480 Mbps link cannot reserve their bandwidth. This guide gives you the arithmetic behind that refusal, a test sequence that separates a topology fault from a camera or driver fault, and the fixes in the order that costs least.

What the failure looks like

The failure has a fixed shape, and every part of it carries information:

• The camera enumerates and appears in the SDK or viewer device list, so detection and drivers are alive.
• Color starts on its own through the hub.
• Depth refuses to start, alone or alongside color, with a UVC stream-start error.
• IR refuses the same way, because it is a second raw mono stream from the same device.
• On a host root port with a short cable, the same camera starts every stream at full resolution and frame rate.

That pattern — raw streams declined only behind the hub — is the fingerprint of a bandwidth reservation the host controller rejects. It is not a damaged camera, and no driver reinstall will clear it. Error text differs between SDKs and operating systems; the cause underneath is identical, and the fix is in the wiring.

The numbers: what a 480 Mbps link can reserve

USB 2.0 high-speed signaling runs at 480 Mbps, but a camera never sees anything close to 60 MB/s of payload. Periodic transfers, isochronous and interrupt together, may claim at most 80% of the bus, and after protocol overhead the usable payload lands near 40 MB/s. One isochronous endpoint is capped harder still: a controller that supports high-bandwidth transfers moves 1024-byte packets, up to three per 125 µs microframe, at 8000 microframes per second.

So 24.6 MB/s, about 197 Mbps, is the most any single video stream can reserve on a fallen-back link. Depth and IR ship as raw 8- or 16-bit mono frames; color ships MJPEG-compressed on nearly every UVC depth camera, a fraction of what raw color would need. That split is exactly why color starts where depth refuses. MB/s means millions of bytes per second throughout.

A healthy SuperSpeed link is a different world: 5 Gbps of signaling, 8b/10b encoding, about 500 MB/s of raw payload — roughly 20 times the ceiling above.

Worked example: 1280 × 720 depth and IR at 30 fps on a fallen-back link

Inputs. Color, depth and IR from one depth camera, behind a USB 3.0 hub whose uplink has negotiated high-speed — the case this guide treats. Depth and IR run 1280 × 720 pixels, 8-bit mono (1 byte per pixel), 30 fps, a mode this camera class commonly offers; color is MJPEG-compressed at the same resolution. Link facts: 480 Mbps signaling, about 40 MB/s of usable payload, and the USB 2.0 framing constants — 125 µs microframes, 8000 per second, 1024-byte maximum packet, up to three packets per microframe.

Rule. A raw stream starts only if one isochronous endpoint can reserve its full rate, and the ceiling there is 1024 B × 3 × 8000 = 24.6 MB/s. The whole stream set must also fit inside the link's usable payload, about 40 MB/s.

Arithmetic. Depth: 1280 × 720 × 1 B × 30 fps = 27,648,000 B/s = 27.6 MB/s (221 Mbps). IR is identical. Each raw stream is therefore 27.6 − 24.6 = 3.0 MB/s over the per-endpoint ceiling, about 12%, and is refused before the second stream is even counted. Together they need 55.3 MB/s (442 Mbps) against about 40 MB/s of usable payload, 15.3 MB/s over the entire link. Compressed color sits well inside the ceiling, which is why it starts alone.

Result. The controller declines the depth reservation on the fallen-back link. On a host root port, the same camera puts the same question to a 5 Gbps link whose payload after encoding is about 500 MB/s: depth plus IR take 55.3 MB/s, about 11%, and even uncompressed color at 55.3 MB/s lifts the total only to 110.6 MB/s, about 22%. Everything starts.

Decision. A raw stream above 24.6 MB/s cannot start on a high-speed link, and a stream set above about 40 MB/s cannot fit it at all. Restore the SuperSpeed path, or cut each raw stream under the ceiling: 640 × 480, 8-bit, 30 fps works out to 9.2 MB/s (73.7 Mbps) per stream, and two of those fit with margin.

Likely causes, most probable first

1. The hub uplink negotiated high-speed. A USB 2.0-rated cable fits the same jack as a SuperSpeed one, and so does a USB 2.0 extension, a dock passthrough or a port that carries only the older pair. Everything behind it then shares 480 Mbps. This is the cause whenever direct connection works.
2. The periodic budget is already spent. Another isochronous device on the same controller, often a second camera behind the same hub, holds part of the budget, so the remainder cannot fit the depth stream. Multi-camera rigs hit this first.
3. Power, not bandwidth. A bus-powered hub carrying a current-hungry camera can brown out its ports. The symptom is disconnects and re-enumeration, not a clean refusal of one stream while another runs. A powered hub fixes this class and only this class.
4. The camera or its driver. Least likely when direct connection works. If every stream fails on every port, move to the software causes below.

The test sequence

1. Run each stream alone through the hub. Color yes, depth no, IR no is the bandwidth pattern; every stream failing is a detection or driver pattern.
2. Repeat on a host root port with a short cable. A full start here clears the camera and its driver, so stay with the wiring.
3. Read the negotiated speed from the operating system's USB inspector, which lists each device with its link speed. The hub and camera should show SuperSpeed-class entries at 5 Gbps; a high-speed entry names both the fault and where it sits.
4. Swap the cable for a certified SuperSpeed cable and re-read the speed. This one-minute check settles the top cause before any software changes.

The last row is a different failure wearing the same parts: the USB hub frame-rate guide budgets that case, and the depth and color stream timeout check covers streams that die mid-run.

Fixes, cheapest first

1. Move the camera to a host root port. This removes the shared uplink entirely and doubles as the confirmation test.
2. Rebuild the chain as certified SuperSpeed: one hub whose uplink enumerates at 5 Gbps, one SuperSpeed cable to the camera, no USB 2.0 extensions in between. The fix is proven only when the camera still reads as SuperSpeed behind the hub.
3. Shrink the stream set to the link you actually have. On a fallen-back 480 Mbps link, run depth at 640 × 480, 8-bit, 30 fps — 9.2 MB/s (73.7 Mbps) per stream — and both raw streams fit under the 24.6 MB/s ceiling with margin. Halving the frame rate halves the number the same way; the per-camera bandwidth math shows how to cut a stream without losing the measurement.
4. Give the rig real ports. A machine-vision vision controller puts several camera ports on one unit instead of a hub chain. In a robot cell, where a camera often hangs off the controller's own hub beside pendant peripherals, USB hub camera-detection behavior on robot controllers is worth checking before you rewire the cell.

When it is not the hub

If every stream refuses on every port, including a direct short-cable connection, bandwidth arithmetic will not fix it. Two software classes produce the same symptom. On Linux, a kernel without support for the camera's pixel format rejects the stream at open; the pixel-format rejection fix on Linux walks that path. On Windows, a stream set-up that requests a mode the camera does not advertise fails with a media-type error; the media-type fix for stream set-up on Windows covers it. A camera whose color device goes missing while the mono devices enumerate is its own case: color camera not detected while monochrome streams work.

True detection failures, where the device is absent from the USB tree altogether, sit one step further back; driver-level detection failures on structured-light depth cameras is the reference for that class.

Prevent it on the next build

• Budget before you wire: sum width × height × bytes per pixel × fps for every stream and keep the total inside about 40 MB/s per high-speed link.
• Give each multi-stream camera its own host root port; hubs are for low-rate devices, not raw depth.
• Read the negotiated speed at commissioning, after the final cable routing, and record it at the cabinet.
• Use certified SuperSpeed cables, keep passive runs short, and label both ends so a USB 2.0 cable cannot sneak back in.
• Re-run the full three-stream test after any cabling change; link speed changes silently.

For whole multi-camera trees, the USB3 hub bandwidth guide budgets the hub itself, and the multi-camera USB power and budget guide counts power next to bandwidth.

The decision in one line: a depth camera that refuses depth and IR only behind a hub is telling you the uplink is high-speed — fix the link or fit the streams to it, and prove either with the negotiated-speed readout. If you are specifying hardware instead, the 3D sensors range covers laser profilers, structured-light stereo and ToF cameras, the camera finder filters them by type and series, and the 3D camera guides collect the integration topics around them.