Multiple depth cameras on one host: fix enumeration and USB bandwidth

You wired two or more depth cameras to one host: one streams perfectly, the second never appears in the device list, or every camera lists and the frame rates collapse the moment all of them run. Multi-camera USB trouble comes in two halves — enumeration and bandwidth — and each half has its own fix, almost always on the host side of the cable. This guide gives you the numbers to budget with: about 390 Mbps per stereo camera for depth plus colour at 848×480 and 30 fps, and about 3.2 Gbps of practical payload per USB 3 controller. It then walks the wiring topology that prevents enumeration fights and a two-minute verification order that separates a link fault from a code fault. The arithmetic applies to stereo and structured-light depth cameras on USB 3 and scales to any resolution and frame rate.

Why does only one depth camera show up when I plug in two?

Treat a missing camera as a link fault before you touch code: the usual culprits are a cable that fell back to USB 2.0, a hub without its own power supply, or a port that cannot deliver the 900 mA a USB 3 device may draw.

Enumeration happens before a single pixel moves. The host asks the device to identify itself and negotiates an address and speed over the same cable that will later carry hundreds of megabits; if power or signalling sags during that handshake, the camera never receives an address and no capture API can list it.

The signature worth memorising: camera A streams, you plug in camera B, and A vanishes while B appears. Both devices are reaching the host through one hub port, and the newest device wins the power budget.

Cables cause more of these failures than ports do. A charge-grade cable has no SuperSpeed wiring at all, and a worn or over-long one trains the link down to USB 2.0, whose roughly 320 Mbps of practical payload cannot carry a 390 Mbps depth-plus-colour stream. Read the negotiated speed in the OS tree: 480 Mbps means the cable is the fault, and the camera will fail the bandwidth check the moment it streams — the USB 2.0 port walkthrough covers that symptom end to end.

This class of fault lives on the host side of the cable, and the pattern reaches well beyond vision: builders of embedded controllers chase the same ghost, as this USB host enumeration fault walkthrough shows.

How much USB bandwidth does one depth camera stream use?

One depth camera streaming depth and colour at 848×480 and 30 fps moves about 390 Mbps — call it 49 MB/s — and with the colour stream compressed the same camera runs near 240 Mbps.

Both streams run at once, so the per-camera bill is the sum of two legs, and each leg is one line of arithmetic:

What moves the number: compressed colour at about 4:1 cuts the colour leg to roughly 50 Mbps, for about 240 Mbps per camera; 1280×720 doubles every leg, taking an uncompressed camera to about 885 Mbps; 60 fps doubles it again. Depth is the stream you paid for — keep it lossless — while colour is usually the leg to compress.

How many depth cameras fit on one USB 3 controller?

Budget about 3.2 Gbps per USB 3.0 controller — 5 Gbps of line rate minus encoding and protocol overhead — which carries two 390 Mbps cameras using only 24% of it and leaves a third and fourth inside the arithmetic.

The 3.2 Gbps figure is the one to plan with: USB 3.0 spends 20% of its 5 Gbps line rate on 8b/10b encoding, and framing, handshakes and retries take the sustained payload to roughly 400 MB/s. Divide the per-camera bill into it:

At 848×480 and 30 fps the arithmetic allows three or four cameras per controller, and a two-camera cell keeps three quarters of the controller free. The same table says three 720p cameras run at 83% with nothing in reserve, and four do not fit at all.

Count controllers, not sockets: four ports on one motherboard can hang off two controllers, and the OS tree in the verification section shows which. The design rule for cells that run all day: two cameras per controller, and the moment a third joins, give it its own controller — a PCIe USB 3 card adds an independent 3.2 Gbps domain, which costs less than one afternoon of intermittent frame drops.

Why does an unpowered hub stop depth cameras from working?

A bus-powered hub must divide the 4.5 W of its single upstream port — 5 V × 0.9 A — among everything below it, and one depth camera with its projector lit already takes 400-800 mA, so a second camera has no power budget left and never enumerates.

USB 3 certifies every port for up to 900 mA at 5 V. A hub without its own supply has exactly one port's worth to hand out, and a stereo depth camera is among the hungrier devices on the bus because its illuminator runs continuously. One camera on an unpowered hub sits at the edge; two are past it, and the second simply never appears.

A powered hub fixes the power half: its own supply funds a full 900 mA for each downstream port. It does nothing for bandwidth, because everything through the hub still funnels into one upstream 3.2 Gbps link. A hub is a splitter, not a multiplier.

Watch for hidden hubs too. Front-panel sockets, monitor-side USB ports and some docks insert a hub between the camera and the controller; the rear ports of a motherboard or an industrial controller's own panel are the ones to trust. The hub-starved stream walkthrough shows what a starved link looks like from the capture API.

What is the right way to connect multiple depth cameras?

Wire one camera per root-controller port with certified USB 3 cables, keep the bench diagnostic cable under 2 m, power any hub, and give camera three its own controller — that topology has carried multi-camera cells for years without enumeration fights.

1. Start at the host's own ports. Rear-panel ports on the motherboard or controller reach root controllers directly; skip docks and front-panel headers.
2. Diagnose short. While hunting a fault, use the shortest certified USB 3 cable you own — under 2 m — so cable signalling drops off the suspect list.
3. Install long only with quality. Three metres of properly shielded USB 3 cable on a camera's own port sits comfortably inside both the signalling budget and the 3.2 Gbps bandwidth budget; choose a drag-chain build when the camera rides a moving axis.
4. Power any hub. A powered USB 3 hub restores the full 900 mA per port; remember it still shares one upstream link.
5. Scale with controllers, not hubs. Cameras three and four each get a new controller, never a deeper hub chain.

Cable grade matters as much as length on a healthy link: SuperSpeed pairs need the shielding charge cables skip, and a latching connector survives vibration a friction-fit plug does not. The LS-CBL-0219 is a 3 m USB 3.0 camera cable with a high-flex, drag-chain build for exactly this job — the rest of the camera cable range covers GigE, Camera Link and I/O runs for the same cell.

How do I verify the host sees every camera before streaming?

Before the first stream starts, read the USB tree from the operating system and confirm every camera shows at SuperSpeed under the controller you expect, then open each camera by serial number in code — two minutes that replace an afternoon of guessing.

Every OS prints the tree, and each view answers the three questions that matter: is the camera present, at what speed, and behind which controller?

• Linux: lsusb -t prints the controller-to-hub-to-device hierarchy with the negotiated rate; two healthy cameras show at 5000M under separate controllers.
• macOS: ioreg -p IOUSB -w0 -l lists every device with its speed and location, the fastest way to expose a hidden hub.
• Windows: Device Manager, View, Devices by connection, shows the same hierarchy graphically.

A camera missing here cannot be listed by any code change — go back to the wiring table above. Two cameras listed under one controller with no hub between them means the bandwidth budget is shared before the first frame; the budget section above tells you how much room is left.

Then move to software. Enumerate devices by serial number and open one pipeline per serial, so a port change never remaps your cameras; the select-by-serial walkthrough shows the enumeration pattern. Start streams one at a time and read a couple of dozen frames from each pipeline before starting the next — a camera that delivers 30 fps alone and stalls when a neighbour starts is telling you the pair share one controller.

When is the capture code the problem instead of the USB link?

Suspect code only when every camera appears in the OS tree and behaves identically on a second host: the usual faults are one shared pipeline for all devices, round-robin reads slower than the 30 fps each camera delivers, and a loop that halts on the first device's error.

Isolate before you refactor. Stream camera one alone, then camera two, then both — the one-stream-at-a-time test turns a three-camera mystery into two single-camera facts. If each camera runs clean alone and both stall together on separate controllers, the loop is the fault, not the wire.

The recurring code faults, in the order we meet them: one capture pipeline handed every device, so all cameras queue behind a single reader; two devices answering the same open call because the code matches by index instead of serial; frame reads without a per-camera timeout, so one dead link freezes the whole loop; and streams started simultaneously before each pipeline has buffers ready.

Make the healthy pattern routine: open by serial, one pipeline and one reader per camera, a timeout on every read, colour compressed unless the measurement needs it raw. With that in place, adding camera three is a wiring task — one new controller port — not a debugging week.

More failure-mode walkthroughs for depth cameras sit on the 3D camera topic page. If the cell is still on the drawing board, budget before you order: send the camera count, resolution and frame rate through the contact page and we will check the controller math with you.