Three depth cameras drop to low FPS: test one stream at a time

You have three USB depth cameras on one host. Some sessions deliver a steady 29 to 30 FPS on every camera; other sessions, on the same rig with the same cables and the same script, deliver about 4 FPS on average while one camera runs far ahead of the other two. The swing is not random, and it is not your code. This guide gives you the one test that names the cause in ten minutes, the arithmetic that predicts why two cameras survive and three collapse, and the fixes ranked by what they cost in resolution and frame rate.

The one test that names the cause

Turn off every stream except depth on all three cameras and measure for a full minute. If all three return to 30 FPS, the cause is aggregate USB bandwidth: depth alone fits the controller, depth plus color on three cameras does not, and no processor upgrade or code change will fix a transport that is already full. If depth-only still sags, bandwidth is exonerated and you move to exposure, power or cable. The test is decisive because it removes about two thirds of the demand — 124 of the 179 MB/s per camera — while changing nothing else.

Host load is the other suspect, and it is quick to clear: if the CPU sits below about 50 percent while the rate sags, processing is not the wall. The signature — two cameras fine, the third collapses the rig — points the same way. A processor limit degrades smoothly with each added camera; a bandwidth limit snaps at a specific count. For a single camera that stalls rather than a rig that collapses, start with depth camera frames not updating: fix USB bandwidth stalls.

The bandwidth arithmetic every rig obeys

Every stream costs width times height times bytes per pixel times frames per second on the wire:

USB 3.0 runs a 5 Gbps line rate, about 500 MB/s after 8b/10b encoding, and a single host controller sustains 350 to 450 MB/s of real camera traffic. Budget 400 MB/s per controller and the tipping point will not surprise you. The same ceiling binds large area scan frames; bandwidth and interface limits for 4K machine vision at 60 FPS works that case through.

Worked example, using a typical stereo depth camera: depth at 1280 × 720, 16-bit, 30 FPS, and color at 1920 × 1080, 30 FPS, in a packed 2-byte format.

• Depth: 1280 × 720 = 921,600 pixels × 2 bytes = 1.84 MB per frame; × 30 FPS = 55 MB/s.
• Color: 1920 × 1080 = 2,073,600 pixels × 2 bytes = 4.15 MB per frame; × 30 FPS = 124 MB/s.
• One camera, both streams: 55 + 124 = 179 MB/s.
• Two cameras: 2 × 179 = 358 MB/s — inside the 400 MB/s working limit, so 30 FPS holds.
• Three cameras: 3 × 179 = 537 MB/s — 34 percent over, so frames queue and the rate collapses.
• Three cameras, depth only: 3 × 55 = 165 MB/s — ample headroom, so 30 FPS returns at once.

That is the whole mystery: two cameras fit, three do not, and depth-only always fits. If your color stream is unpacked RGB at 3 bytes per pixel, color alone is 186 MB/s and the wall arrives at the second camera instead of the third.

Where the tipping point sits

Any row that keeps the three-camera total under about 400 MB/s per controller will hold 30 FPS. Rows that exceed it collapse to single digits, and every camera on that controller shares the collapse.

Why the rate changes between runs

Three effects make an unchanged rig behave differently from day to day.

Enumeration order. Cameras enumerate in a different order at each boot and can land on different controllers. When two share an overloaded controller, both throttle together while the third, alone on its own controller, holds 30 FPS. That is the one-camera-outruns-the-others signature. Print the USB device tree at the start of every session and compare a slow run with a fast one; the controller assignment will differ. Streaming that depends on which physical port you use has its own failure pattern, covered in diagnosing a USB camera color stream timeout across host ports.

Exposure coupling. The frame period at 30 FPS is 33.3 ms. If the color auto-exposure settles above that and the camera lets the frame rate float with exposure — the Auto-Exposure Priority mode on camera families that expose the toggle — the delivered rate follows the room lighting down. Not every model offers the toggle; where it exists, disable it and cap exposure manually.

Bulk transfers. Camera streams move as bulk endpoints. When total demand passes what the controller sustains, transfers retry and every camera on that controller slows together instead of one stream failing to open. That smooth, shared slowdown is exactly what a 4 FPS average looks like from outside.

The diagnostic, step by step

1. Log FPS per camera, not the average. The camera that still holds 30 FPS tells you which controller is overloaded.
2. Watch CPU use while the rate is sagging. Below about 50 percent clears processing as the cause.
3. Enable depth only on all three cameras and measure for a full minute. A return to 30 FPS convicts bandwidth.
4. Read the USB device tree and write down which camera sits on which controller.
5. Re-enable color at 640 × 360 and 30 FPS. If the rig is stable, step up to 960 × 540 and re-measure; keep the largest format that holds.
6. Cap exposure at 30 ms, below the 33.3 ms frame period, or fix it manually.
7. Move one camera to a port on a different root controller and re-measure. If that fixes it, the rig was one controller short, not one camera short.

Fixes, ranked by what they cost

1. Drop color. If the deliverable is a point cloud or a depth ROI, color was decoration; the rig settles at 165 MB/s total and a steady 30 FPS.
2. Shrink color. Going from 1920 × 1080 to 640 × 360 cuts color from 124 to 14 MB/s per camera, nine times less, and the three-camera total falls from 537 to 207 MB/s. Color-to-depth registration still works; the texture is coarser.
3. Halve the frame rate. Bandwidth scales linearly with frame rate, so 30 to 15 FPS takes the rig from 537 to 269 MB/s. The cost is motion sampling, so weigh it on conveyors and moving robots.
4. Split controllers. One camera moved to a port on a different root controller takes a third of the load with it. Confirm the assignment in the USB device tree, not from the port labels on the housing.
5. Compress color. An MJPEG color stream is roughly an order of magnitude lighter on the wire than raw, and the host pays the decode. Watch CPU after enabling it.
6. Fix exposure below the frame period so the sensor never waits for light mid-frame.

When the bandwidth answer is wrong

If depth-only still sags, work this list in order of likelihood:

• Exposure longer than 33.3 ms, usually auto-exposure chasing a dim scene. Improve the lighting or cap the exposure; USB3 camera low frame rate and latency: fix usbfs memory and exposure covers the host-side settings that compound it.
• Power. An underpowered bus hub browns cameras out into black frames rather than slow frames — see depth camera black image: fix USB bandwidth and power issues.
• Two cameras claiming the same interface. That surfaces as an explicit error rather than slow frames: two depth cameras USB busy: fix the interface claim error.
• Genuine host load. If the sag deepens as you add point cloud work on the same host, read point cloud camera processing load: diagnose stream failures before buying anything.

If the rig is growing rather than failing, multi-camera RGB depth bandwidth: size a four-camera host sizes the next step up, and long waits for frames in a multi-camera rig: switch to polling covers the software side of waiting on many cameras at once.

Checks before you add a third camera

• Add the streams before the cameras. Any total under 400 MB/s per controller holds 30 FPS; anything over it will not, whatever frame rate the sensor lists on paper.
• Count controllers, not ports. The host has a fixed number of root controllers, and only those carry bandwidth.
• Fix exposure below the frame period at the frame rate you promise the line.
• Cable the rig once, properly. A short shielded USB3 lead removes a whole class of dropouts. The USB3 camera cables range includes drag-chain-rated lengths. The LS-CBL-0219 is a 3 m USB3.0 camera cable rated for drag-chain use.

• Plan the exit to Ethernet when USB cannot carry it. Ethernet depth acquisition removes the shared-controller ceiling. The depth and ToF cameras range spans laser profilers, stereo and time-of-flight units, and 3D scanning method selection for inspection compares the technologies. The MV-DT01WMU is a time-of-flight sensing camera from that range.

• Run the same arithmetic for plain area scan cameras. A 12 MP USB3 camera such as the LS-CMR-0166 is specified at 4000 × 3000 and 30 fps. The MV-CH120-11UC is a 12 MP USB3 color camera with a global shutter. Both obey the same controller limit. Filter the area scan cameras category by interface, or step through the camera finder and the system configurator with your bandwidth total in hand.

At 4000 × 3000 and 30 fps, a single mono camera at 1 byte per pixel already moves 360 MB/s. One sensor nearly fills a controller; two need a plan.

Add up your streams with the formula above before the next purchase order. If any controller's total beats 400 MB/s, bring the stream list to the contact page and we will size the interface with you.