Multiple USB cameras on one host: bandwidth and power budget

A depth camera never sends just one stream. Depth, color and infrared frames leave the camera together, and every stream costs megabits each second. Plug a second camera into the same host and two hard limits appear: the bandwidth one USB controller can move, and the watts its ports can deliver. The failures look like software faults - a second device that reports the interface as busy, or a stream that opens and then runs at half speed. This guide gives you the arithmetic to size the set-up in five minutes, the tests that separate a bandwidth stall from a power shortfall, and the fixes in order of cost, up to moving the camera set to PoE. The depth and ToF cameras in the shop follow the same rules.

Symptoms that point at the bus, not the software

Work through these four failures before you reinstall a driver. Each has a bus-level cause more often than a software one.

• The second camera reports the interface as busy. Camera one streams, camera two refuses to open, and the message names the device or resource as busy. Two capture paths are fighting over one exclusive interface. The test and the fix are in the interface claim error guide.
• Streams open, then the frame rate sags on its own. The counter drifts below the value you set and never recovers. The controller is discarding frames it cannot schedule. Three depth cameras dropping to low fps shows the isolation test: one camera, one stream at a time.
• Depth goes black or freezes while color keeps running. Depth is the heaviest stream set, so it starves first. A black depth image walks through the bandwidth and power causes behind it.
• The camera works alone on a laptop and fails on the host. The camera is innocent. The difference between the two machines is controller count and power budget, and that is what the rest of this guide sizes.

The two budgets a USB port gives you

USB 3.0 puts 5 Gbit/s on the wire. 8b/10b encoding takes a fifth of that and packet overhead takes more, so count on 3.2-3.8 Gbit/s of real throughput per controller - and every port hanging off that controller shares the pipe. A USB 2.0 link, the fallback when an older cable or port sits in the path, moves roughly 320-400 Mbit/s in practice.

Power has its own number, and it is the one to define once: a USB 3.0 port must supply 5 V at 0.9 A, which is the 4.5 W per-port limit. A bus-powered hub splits that single port's wattage across everything behind it. Compact embedded boards can budget less again - a small ARM vision host may cap its total output at that same one-port figure across all its ports together - so the board-level figure, not the per-port spec, is the one to size against.

These are uncompressed figures, which is what depth and infrared streams are; a compressed color mode cuts the color line severalfold. Plan to stay under about 70% of a controller's usable bandwidth, roughly 2.4 Gbit/s, so scheduling bursts have somewhere to go. The same channel-times-bitrate arithmetic is how a multi-camera video recorder is sized for bandwidth.

Worked example: two depth cameras at 640 × 480, 30 fps

Inputs. The camera runs its default four streams: depth at 640 × 480 and 30 fps in Z16 (2 bytes per pixel), two infrared feeds at 640 × 480 and 30 fps in Y8 (1 byte per pixel), and color at 640 × 480 and 30 fps in RGB8 (3 bytes per pixel). Draw is about 2 W per camera while it streams depth plus color at full resolution. The host offers one shared USB 3.0 controller, ports each rated at the full per-port output, and a board-level power budget capped at one port's worth in total.

Rule. Bytes per pixel × pixels × fps × 8 gives bits per second per stream. Add a camera's streams to get its cost, add the cameras to get a controller's load, then compare both totals with the usable bandwidth and the power budget.

Arithmetic. 640 × 480 = 307,200 pixels per frame.

• Depth, Z16: 307,200 px × 2 B × 30 fps = 18.43 MB/s, × 8 = 147 Mbit/s
• Each infrared feed, Y8: 307,200 px × 1 B × 30 fps = 9.22 MB/s, × 8 = 74 Mbit/s
• Color, RGB8: 307,200 px × 3 B × 30 fps = 27.65 MB/s, × 8 = 221 Mbit/s
• One camera: 147 + 74 + 74 + 221 = 516 Mbit/s
• Two cameras, one controller: 2 × 516 = 1,032 Mbit/s ≈ 1.03 Gbit/s, and 2 × 2 W = 4 W

Result. 1.03 Gbit/s is about 30% of one controller's usable midpoint of 3.5 Gbit/s, so two cameras fit with bandwidth to spare. Power is the tighter limit: 4 W against the board budget leaves 0.5 W of margin.

Decision. Two cameras at this setting run direct on ports rated at the full per-port output; on a host that caps all ports together at one port's worth, power one camera from a hub. A third camera is a power problem first: 3 × 516 = 1,548 Mbit/s is still only about 44% of the controller, but 6 W does not fit the board budget, so the fix is a powered hub rather than more bandwidth. Turning off the two infrared feeds drops each camera to 147 + 221 = 368 Mbit/s, and three cameras then cost 1,104 Mbit/s - comfortable on bandwidth, still needing the hub for watts.

Likely causes in order of probability

1. All cameras hang off one shared controller. Test: run camera one alone at full settings and confirm its frame rate; start camera two and watch camera one's counter. If it sags, the controller is the bottleneck. On Linux the device path (in the form /dev/bus/usb/002/002) carries the bus number, and cameras sharing that first number share the pipe. The startup checklist for multiple USB depth cameras on Linux shows how to map them.
2. The power budget is exceeded. The signature is failure at plug-in or at stream start, not a gradual sag. Test: move the suspect camera to a powered hub. If the fault disappears, it was watts.
3. The camera fell back to USB 2.0. A four-stream camera at this setting needs 516 Mbit/s, and a USB 2.0 link at roughly 320-400 Mbit/s cannot carry it, so depth stalls or dies while a single low-rate stream looks fine. Test: read the negotiated link speed in your operating system's USB view. Fix: a short, certified USB 3.0 cable straight into the host.
4. An exclusive-claim conflict. A viewer left open, or a process that crashed without releasing the camera, holds the interface, and the next application sees the device as busy. Test: stop every capture process, then open one application at a time.

Fixes in order of cost

1. Disable streams you do not use. Each 8-bit infrared feed costs 74 Mbit/s at this setting; a depth-plus-color camera drops from 516 to 368 Mbit/s.
2. Trade frame rate or resolution. Stream cost scales linearly, so 15 fps halves the bill and a four-stream camera falls to 258 Mbit/s. Two full-resolution cameras running depth plus color at 15 fps cost about 553 Mbit/s each, which is a known-good landing spot for a two-camera host. If both cameras sag together in a rhythm, that is timing rather than bandwidth - a shared timing event for multiple depth cameras fixes jitter, not throughput.
3. Fix power with a powered hub. Each downstream port then delivers its own full rated output, provided the hub's supply covers the sum of what you will draw.
4. Fix bandwidth with a second controller. Ports on separate controllers each get their own 5 Gbit/s pipe. On a host with a free slot, a PCIe USB card built with dedicated channels per port provides four independent pipes; put one camera per channel.

Whichever fix you pick, cable discipline is the same: passive USB 3.0 copper is specified to 3 m, and marginal cables produce dropouts that mimic bandwidth faults. On a moving axis, use drag-chain-rated flex. The LS-CBL-0219 is a 3 m USB 3.0 camera cable built for high-flex, drag-chain runs.

When to stop adding USB and go PoE

Draw the line at three cameras on tight power, four cameras, or any 720p-class 30 fps set. GigE Vision then wins on every count: each camera gets a link of its own, power rides the same cable, and runs reach 100 m. The arithmetic still applies, per link instead of per controller. A four-stream camera at 640 × 480 costs 516 Mbit/s and sits inside one 1 Gbit/s link; depth plus color at 1280 × 720 and 30 fps is about 1.1 Gbit/s and does not, so you would run 15 fps, compress the color stream, or step up to multi-gigabit links - the 5GBASE-T camera interface guide covers the fast options.

A vision controller clears the port count in one box. The MV-VC3301H-128G66 carries an Intel Core i3, 8 GB of memory, 5+ LAN ports, 3-4 USB 3 ports and 4 built-in light channels, with PCIe expansion supported. The MV-VC5525-256G70-NN steps up to PoE camera ports, 8 built-in light channels and 32 GB of memory on the same 5+ LAN port count. Each PoE camera then holds a full, uncontended link, and the USB budget conversation is over.

All 2 share: Humidity 20% RH to 95% RH (no condensation); Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The vision controllers page lists the range by LAN port count, PoE and built-in light channels.

Checks before you order

• Add the stream cost for every camera you plan to run and compare it with about 2.4 Gbit/s per shared controller - the 70% planning line.
• Total the watts against the board's all-ports budget where it publishes one; a per-port rating alone overstates a compact host.
• Map each camera's device path to its physical port so you know which cameras share a controller before something fails.
• Size a powered hub's supply above the sum of the port budgets you will actually use: four ports at the per-port limit is 18 W.
• On PoE, count watts too - standard PoE carries 15.4 W per port, ample for a 2 W depth camera but worth adding up on larger sensors.
• Sizing a host for several RGB-plus-depth streams follows the same arithmetic, stream by stream; sizing a four-camera RGB and depth host works it through.

The decision, per case

• One depth camera: any host with a USB 3.0 port; keep the cable at 3 m or shorter and straight into the machine.
• Two cameras at 640 × 480, 30 fps, four streams (1.03 Gbit/s, 4 W): run them direct on ports rated at the full per-port output; where the host caps all ports at one port's worth, power one camera from a hub.
• Three cameras (1.55 Gbit/s, 6 W): powered hub for the watts; bandwidth still sits under the 2.4 Gbit/s planning line.
• Four or more cameras, or 1280 × 720 at 30 fps: PoE GigE on a vision controller with 5+ LAN ports.

Size your own camera set with the stream formula above, then pick the hardware: the camera cable finder covers USB, GigE and power runs, and the 3D vision topic page collects the rest of the depth-camera guides. When the arithmetic says the set-up fits, the configurator's accessories step is where cables and hubs live: