Depth camera frames not updating: fix USB bandwidth stalls

Your depth camera connects, the streams open, and for a few frames everything looks right. Then one stream freezes on a single image while the other keeps updating, and only unplug-and-reconnect restores it — briefly. This pattern can result from bandwidth limits, frame-buffer exhaustion or an acquisition fault. The displayed image alone does not distinguish them. This guide walks through the tests that separate a bandwidth stall from a software deadlock, in the order that finds the cause fastest, and ends with the settings that keep both streams running.

Confirm the symptom before you touch settings

First, pin down which stream stalls and when. Three questions narrow the cause:

• Does the same stream always stall, or does it vary between runs? Record the affected stream and its configuration; either pattern can involve bandwidth, host contention or software handling.
• Does the stall happen after a fixed number of frames? A count that repeats run after run suggests a queue or buffer in your code, not necessarily the wire.
• Does the camera still appear in the system's USB device list, and at what speed? If the operating system reports 480 Mbit/s, the device has negotiated USB 2. Check whether the selected stream configuration supports that connection.

Run the vendor's simplest capture example, with the default resolution, on the same machine. If the example streams both streams indefinitely, compare its settings and frame handling with your application. If the example also freezes, investigate the shared acquisition path: cable, port, power, bandwidth, driver and camera.

The bandwidth arithmetic

A 5 Gbit/s USB 3 connection has a raw signaling rate equivalent to 625 MB/s, not an application payload guarantee. Encoding and protocol overhead reduce the available throughput, and devices may share host-controller resources. Estimate a stream's uncompressed payload with:

Worked example: a 1280 × 720 depth stream at 16-bit, 30 fps needs

1280 × 720 × 2 × 30 = 55.3 MB/s

An RGB stream at 1280 × 720, 24-bit, 30 fps needs about 82.9 MB/s. Together that is roughly 138 MB/s — within the payload capability of many clean USB 3 connections. However, USB 2 has a raw signaling ceiling of 60 MB/s before overhead, so this combination cannot fit. Depending on the camera and SDK, insufficient bandwidth may cause rejected settings, dropped frames, transfer errors or stalled acquisition; repeated displayed pixels alone do not prove which occurred.

The same arithmetic explains why the symptom can appear after an SDK update or a settings change: a default that changed from 848 × 480 to 1280 × 720 roughly doubles the depth stream's cost. If frames froze right after a software or firmware change, diff the stream configuration first. Check the actual transmitted pixel format, too; displayed RGB may have been converted from a different transport format.

Fix the software side first: release frames before you wait

Before blaming the wire, rule out buffer exhaustion. Many SDKs hand you a frame object that holds a buffer from a limited pool. If your code keeps references — by storing frames in a list, or by failing to release them under an exception path — the pool can empty and new frames have nowhere to land. Acquisition may then block or fail while the display retains its previous image.

1. Wrap every frame read in a try/finally or using block, following the SDK's documented ownership rules, so the frame is released even on error.
2. Avoid retaining pooled frame objects across loop iterations unless the SDK supports it; copy the pixels you need, then release.
3. Poll for new frames by frame number or timestamp, and log it. If the number stops advancing while the connection stays up, check acquisition errors and queue ownership before blaming the wire.
4. Test with the vendor's minimal capture example against your machine. If the example survives an hour with matching stream settings, your application's frame lifetime handling is a suspect.

Where a large frame crosses a socket or inter-process boundary — a common pattern in graphical, managed-code or Python wrappers that forward frames over TCP on the same machine — the same stall can appear at the transport instead. If your pipeline does that, the article on troubleshooting TCP stalls with large local frames covers the receive-buffer mechanics behind it.

Fix the link: cable, port and host controller

If the minimal example also freezes, work through the physical layer.

• Cable. Use a short, USB 3-rated cable with screw locks where the camera supports them. A charge-only cable prevents data communication; a USB 2 cable limits the negotiated link speed. A high-flex USB 3 camera cable is available for drag-chain use. Confirm connector compatibility, routing and strain relief for your installation.
• Port. Plug directly into a motherboard port for the baseline test, rather than through a hub or a front-panel connector. Avoid pairing the camera with other high-bandwidth devices on the same controller; they may compete for shared resources rather than receiving equal bandwidth allocations.
• Host controller. In Device Manager or the operating system's USB topology tools, check which controller the camera landed on. Multiple ports may share one controller. Moving the camera to a port on a different controller can help isolate contention.
• Power. Verify the camera's documented power requirements against the port's capabilities. A suitable powered hub with a USB 3 data path, or the vendor's supported power supply, can help isolate power-related dropouts. Test the hub separately because it also changes the data path.

Read our camera GPIO wiring guide before wiring trigger and power lines alongside USB, and the article on USB camera detection failures on Linux if the device sometimes disappears from the bus entirely — detection loss and frame stalls share several cable and power causes.

Fix the budget: which stream to shrink

When the link is sound but two streams still do not fit, you have three levers, in order of preference:

1. Drop the stream you do not use. If your algorithm never reads RGB, close it. That removes its transport and processing load.
2. Lower depth resolution before frame rate when temporal sampling matters. Going from 1280 × 720 to 848 × 480 cuts the uncompressed depth payload by about 56% while keeping 30 fps. Verify that the lower spatial resolution still resolves the features you need.
3. Lower frame rate when the application permits it. Halving the rate halves the payload and doubles the interval between frames. It does not inherently double exposure blur, but it may require changes to tracking or encoder-based acquisition timing.

Compute the new total before you commit, using the formula above, and use 25% headroom as an initial planning allowance rather than a guarantee. If your application genuinely needs maximum resolution on both streams, compare camera interfaces and their supported acquisition modes against the measured requirement. GigE and CoaXPress are not interchangeable upgrades, and either needs a complete bandwidth check. The article on frame grabber acquisition for Camera Link and CoaXPress covers frame-grabber-based alternatives.

For new designs, the MV-DPS200P-02 is a projected structured-light 3D camera. Confirm its interface, supported output modes and processing architecture before selecting it as an alternative; a different camera does not automatically resolve host bandwidth limits.

A one-hour diagnostic routine

Work this list top to bottom; stop changing variables when the stall disappears, then verify the result over a representative operating period.

1. Reproduce with the vendor's minimal capture example at default settings.
2. Log frame numbers or timestamps per stream; confirm which stream stops advancing.
3. Check the reported USB link speed in the operating system; substitute a short, known-good USB 3 cable approved for the connection.
4. Move to a motherboard port on a different host controller, with nothing else on it where practical.
5. Close every stream except the one that stalls; if it now runs, compute the combined budget and shrink the other stream.
6. Reduce depth resolution to roughly 848 × 480 or the vendor's equivalent mid setting and retest for an hour.
7. Re-audit frame disposal in your application, including exception paths.

When the usual fixes do not help

If the example freezes on every tested port and cable at the lowest supported settings, investigate the camera, firmware and driver compatibility together. Contact the vendor's support with the USB controller model, cable type and a log of frame numbers.

If the stall appears only after long runs, look for temperature warnings or documented thermal limits rather than assuming a bandwidth fault. If it appears only when your process also does heavy CPU work, your callback may be starving the SDK's receive thread. Move pixel processing to a bounded worker queue and define what happens when processing falls behind. The general discipline is the same: measure the frame counter, budget the bandwidth and keep the frame pool available.

Before you order parts

• Confirm your host controller model and the number of free, independent USB 3 ports.
• Measure your longest cable run and specify a USB 3-rated cable of the right length and strain rating.
• Compute the combined bandwidth of every stream you plan to open, and check it against one controller's measured or documented budget.
• If the budget does not close, compare alternative interfaces or dedicated 3D sensors against the application's actual requirements.

The 3D sensors category lists laser profilers, stereo and structured-light cameras, and the camera cables category covers USB 3, GigE and I/O cabling. If you would rather have a second pair of eyes on the budget, send your stream settings through the system configurator or contact us — we help size the link before you buy. For more on depth streaming, see the guide to depth camera black image fixes for the related no-image symptom, and the article on depth to color registration once both streams are running reliably.