Depth camera detected but no image: check USB power budget first

A depth camera that appears in the device list but never delivers a frame is usually a power problem, not a camera problem. Enumeration runs at a low default current; opening the depth stream switches on the illuminator, the projector and the sensor rails at once, and that current jump is where weak ports give up. This page is for anyone connecting depth cameras to laptops, docks, hubs or single-board computers. You will budget the power with real numbers — 2 W per camera, 4.5 W from a USB 3.0 port, about 12 W from a mains-powered hub — then run the tests in the order that finds the fault fastest, and end with a decision for each set-up.

What the symptom already proves

If the operating system lists the camera — in Device Manager on Windows, in lsusb on Linux — the data pairs and the power handshake both work at low current. The failure happens later, at stream start. That is a different fault from a camera the host cannot see at all; for that case, the USB link checks after a cable swap and the Linux SDK detection checks cover the no-detection path.

Clear two software causes first, because they cost two minutes. In the operating system's privacy settings, confirm that both system-wide camera access and per-application camera permission are on. If the machine also has a built-in webcam, disable that entry in Device Manager (right-click, Disable device), retest the depth camera, then re-enable it. A second capture stack can collide with the depth camera's own interface and produce the same detected-but-silent result.

Then isolate the host. Run the same camera, same cable, on a second computer. If it streams there, the camera is healthy and the fault lives in the first host's ports, hub or power delivery. For a model-specific walkthrough of the USB-side checks on one compact depth camera, the D405 camera not-detected troubleshooting guide covers the connection tests step by step.

Why streaming fails when plug-in succeeds

USB power is a contract in two numbers, voltage and current, and their product is the budget a device can rely on.

A freshly inserted device draws only about 150 mA until the host configures it, which is why enumeration never trips a weak port. Opening the depth stream is different: the illuminator and projector switch on together with the sensors, and demand can jump several-fold within milliseconds. On a port that cannot supply the jump, the 5 V rail sags, the camera's processor browns out, and the device either vanishes from the list or hands the viewer an acquisition error.

The signature is unmistakable once you look for it: a disconnect chime, or the device flickering out of the device list, at the exact moment the stream opens. A long or thin cable makes the same sag worse, because every metre of cable adds resistance between the port and the camera.

The budget that decides pass or fail

Plan on 2 W per depth camera. Treat it as a budget rather than a measured draw — actual consumption varies with camera model, resolution and illuminator setting — with the margin already inside it, so a stream starting on top of other loads does not brown out the rail.

Two rows decide most benches. A single USB 3.0 port covers one camera with room to spare. A mains-powered hub covers a whole camera cluster, because its supply does not depend on the host at all.

Worked example: two cameras on a laptop

Two cameras need 2 × 2 = 4 W. On a bus-powered hub, that 4 W still comes from the laptop's one upstream port: 5 V × 0.9 A = 4.5 W, before the hub takes its own share. The margin is under 0.5 W, cable losses eat into it, and the streams fail intermittently — exactly the detected-but-no-image symptom.

The same two cameras on a mains-powered USB 3 hub draw from a budget of about 12 W. The load is 4 W, leaving 12 − 4 = 8 W. Add a third and fourth camera: 4 × 2 = 8 W of load, leaving 4 W. At five cameras the load reaches 10 W and 2 W stay spare for the hub itself. Same cameras, same cables, different supply — only one of the two set-ups streams reliably.

Test in this order

1. Direct port, no hub. Plug the camera into a USB 3.0 port on the host itself, nothing else on the adjacent ports, shortest cable you have. If it streams, the camera is fine and everything you removed was part of the fault.
2. Read the power signature. Open the stream and watch the device list or listen for the disconnect chime. A re-enumeration exactly at stream start is a brown-out, and no software setting will fix it.
3. Clear the software checks anyway. Camera privacy permissions on, built-in webcam disabled for one test. They are free and remove the non-power causes from the list.
4. Swap the cable. Use a short, rated USB 3.0 cable, 3 m or less. An unmarked cable may be USB 2.0 only, which starves both power and bandwidth, and the camera then enumerates as USB 2.0 on a USB 3.0 port. The length limits behind this step are covered in keeping the data link alive.
5. Move to a mains-powered USB 3 hub. Give the camera its own hub port and keep the hub's adapter in the wall. If the fault disappears, the old port or bus-powered hub was the budget problem.
6. On a single-board computer, change the architecture. The four USB-A ports share 6 W in total, so even one camera can exceed its share; a powered hub moves the camera onto the 12 W supply and leaves the board's rail for the board.
7. If everything above fails, retest on the second computer. A camera that streams everywhere except one host points at that host's controller or power rail, not at the camera.

Step 4 only works if the replacement is genuinely a USB 3.0 cable. The LS-CBL-0219 is a 3 m USB 3.0 camera cable with high-flex, drag-chain construction — short enough to keep the link inside its dependable length, and built for the motion on a bench or robot.

The fix that fits each set-up

Where the camera offers a separate power connector, take it. Taking power off the data cable removes the budget question entirely. The LS-CBL-0300 is an M8 8-pin camera power and I/O cable, 7 m, drag-chain rated, that runs power and trigger signals on cores of their own; the camera power and I/O cables include other lengths for permanent installs.

When the budget is clean and it still fails

If the camera streams on a powered hub, from a short rated cable, on every computer you can reach, power is no longer the suspect. Work down this list, in the order these causes usually bite:

• Shared controller, out of bandwidth. A second depth stream on the same controller starves the first. The one shared controller timeout and the hub frame-rate budget walk that path.
• A hub that refuses raw depth streams even when properly powered: why raw streams refuse to start on a USB hub.
• A USB 2.0-only link, which usually shows up first as a forced low resolution: depth camera stuck at low resolution.
• A stream that starts and returns a black depth image, a bandwidth-and-power-quality fault rather than a dead sensor: depth camera black image.
• Firmware or driver mismatch after swapping cameras on one bench: depth camera firmware mismatch after a shared camera swap.

Prevent it on the next bench

• Write the budget before wiring: cameras × 2 W against the hub's supply, keeping at least 20% spare. Five cameras on a 12 W hub is 10 W of load and 2 W of headroom — inside that rule.
• Give every camera its own hub port and label which port feeds which camera, so the next fault takes minutes to isolate.
• Keep camera loads off single-board computer rails; the board's 6 W is for the board.
• Switch off aggressive USB power management on bench hosts: a port that parks between runs reproduces the same symptoms, as in the USB autosuspend fault.
• If a bench behaves differently on mains than on battery, stream first and then measure across the camera's 5 V feed: a reading that falls as the stream opens is the sag, and no idle measurement will show it.

For the full bandwidth-plus-power arithmetic when several cameras share one host, the multi-camera bandwidth and power budget guide extends the same method. If you are speccing a set-up from scratch, start at the depth sensors category or the camera finder, and the system configurator walks the camera-to-host decisions in order; more depth-vision guides sit on the 3D topic page. For a bench that keeps dropping streams, send us your set-up and we will run the budget with you.