Depth camera disconnects when the IR stream starts: USB power budget

A depth camera that enumerates cleanly and then vanishes the moment you open the IR stream is not a broken camera in most cases. The color stream runs because the camera sits inside its port's power budget. The IR stream turns on the projector and, on stereo cameras, the second imager; the draw jumps past what the port must deliver, and the host cuts the link. Below are the numbers behind that budget, a worked example with the arithmetic shown, a test sequence that separates a power problem from a bandwidth or cable problem in about ten minutes, and the fixes that hold on the bench and in the cabinet.

Why the IR stream is the trigger

A configured USB 3.0 device may draw six unit loads from its port: 900 mA at 5 V, about 4.5 W. USB 2.0 supplies 500 mA, about 2.5 W; the USB 3.0 power limits on Wikipedia summarize the specification values. Before configuration a device gets one unit load, which is 900 mA ÷ 6 = 150 mA. That is why the viewer lists the camera, the sensors answer queries and everything looks healthy before a single stream opens.

The step change comes from the projector. On a structured-light or speckle depth camera the IR projector fires only when the depth or IR stream opens, and on stereo cameras the second imager starts at the same time. The illuminator is among the largest single consumers in the housing, so color alone keeps the draw under budget while the IR stream is the event that crosses it.

When the margin goes negative, one of two things happens. The host port trips its overcurrent protection and removes the device, or the rail sags until the camera's own regulators drop out. Both look identical from the chair: the status LEDs blink for about a second and the camera vanishes from the device list.

The arithmetic on an example camera

The 900 mA and 4.5 W limits above are documented; the camera wattages here are illustrative inputs, so substitute your own camera's figures.

Color stream only: the camera draws 3.1 W, so the current is 3.1 W ÷ 5 V = 0.62 A = 620 mA. That sits under the 900 mA budget and the stream runs all day.

Depth plus IR: the projector adds 1.8 W and the second imager 0.6 W. Total draw is 3.1 + 1.8 + 0.6 = 5.5 W, which is 5.5 W ÷ 5 V = 1.1 A = 1100 mA. That is 200 mA over the contract, and the disconnect follows within about a second of the stream start.

Cable drop stacks on top. Assume a thin 3 m cable at 0.2 Ω per conductor per metre. The round trip is 2 × 3 m = 6 m, so 1.2 Ω of series resistance sits between port and camera. At 1.1 A the drop is 1.1 A × 1.2 Ω = 1.32 V, and the camera end sees 5 V - 1.32 V = 3.68 V. Regulators that need roughly 4.5 V of input give up well before the host's protection reacts.

The same camera on a short cable: assume 0.08 Ω/m and 1 m, giving 2 × 1 m × 0.08 Ω/m = 0.16 Ω round trip. The drop is 1.1 A × 0.16 Ω = 0.18 V, leaving 4.82 V at the camera. Voltage is healthy, but 1.1 A still exceeds the port's 900 mA contract, so a strict host can still cut the link. The powered hub removes that residual risk: size the adapter from the camera's full draw, 1.1 A × 1.25 = 1.4 A per port, which is 1.4 A × 5 V = 7 W. Four ports need 4 × 7 = 28 W, plus roughly 2 W for the hub's own logic, so a 30 W adapter covers the example with margin.

Likely causes, most probable first

Given the exact pattern — fine until the IR stream opens — rank the causes this way:

1. Port budget exceeded when the projector fires. The signature: color runs for hours, IR kills the link within a second.
2. Cable resistance. Long or thin cables sag the 5 V rail under load; the symptom worsens with every metre and every extension.
3. Link trained down to USB 2.0. The budget halves to 500 mA and a bandwidth problem arrives with it.
4. A bus-powered hub dividing one upstream 900 mA between the camera and everything else plugged in.
5. USB selective suspend or autosuspend cutting power when a second interface opens.
6. Electrical noise from a motor or drive starting on the same bench or in the same cabinet.
7. The camera itself. It is the last suspect, not the first, and the tests below clear it in minutes.

Tests that isolate the cause in about ten minutes

Run them in order; each one either clears a cause or convicts it.

1. Rear-panel port. Move the camera to a port on the motherboard's own panel — not the front of the case, not a monitor — and start the IR stream five times. Five clean starts clear the port.
2. Short cable. Swap to a shielded, USB 3.0-rated cable a metre long or shorter, straight into the port with no extension. If the stream now survives, resistance was the trigger.
3. Link speed. In Windows Device Manager, or with lsusb -t on Linux, confirm the camera trains at SuperSpeed rather than 480 Mbps. At 480 Mbps the budget is 500 mA and no cable will be enough.
4. Powered hub. Give the camera a hub with its own mains adapter and nothing else connected. A full afternoon of clean IR streams convicts the original port rather than the camera.
5. Meter. Put an inline USB power meter between cable and camera and read the voltage under load. About 4.75 V or higher is healthy; a reading that sags toward 4.5 V confirms the drop, and current above the port's contract confirms the budget breach.
6. Logs. On Linux, read dmesg around the disconnect timestamp — diagnosing USB disconnect error -71 in dmesg decodes that code — and on Windows, check Event Viewer for the device error at the same moment.

Fixes that hold up

Fix the supply and the camera almost always stays.

The desk case wants a short, shielded cable. The moving-axis case wants high-flex construction, because a rigid cable fatigues and shorts after a few thousand drag-chain cycles. The shop's USB 3.0 camera cable is the LS-CBL-0219, 3 m long, high-flex and rated for drag-chain service.

Give each depth camera its own host-controller port where you can, rear panel over front, and never chain bus-powered hubs — every hop divides one upstream port again. Why a depth camera fails on a USB hub covers that failure in detail.

Exempt the camera from USB power management as well: selective suspend in the Windows power options, autosuspend on Linux. A device that gets suspended when a second interface opens shows the same one-second blink; the accelerometer stream that fails on the second run is that mechanism wearing a different hat.

When it is not the power budget

Route by symptom before you order anything:

• The camera is detected but never produces an image at all: check the USB power budget first.
• The stream starts, then frames drop once recording begins: bandwidth, not power. Why a USB extension cable fails only when you record the depth stream walks that case.
• No data from a port that only does USB 2.0: start with the USB 2.0 bandwidth check.
• The camera enumerates at 480 Mbps: fixing a link that trains as USB 2.0, because the power budget halves along with the speed.
• Detected, but the depth image comes back black or empty: USB power and bandwidth checks for a black depth image.
• Startup failures right after a firmware or SDK change: the header version mismatch fix.
• Disconnects that line up with a large motor, spindle or drive starting nearby are noise conducted down the cable, not the budget. Reroute the camera line away from motor leads and see the same mechanism behind USB disconnects that start when a variable-frequency drive kicks in.

If a healthy rear-panel port, a short cable and a powered hub all fail with the same one-second blink, treat the camera as faulty and start the vendor's return process.

Prevent it on the next station

Work the budget into the design instead of discovering it on the bench:

• Read the camera's total draw from its data sheet before you pick ports, and keep the sustained draw at or under 720 mA on a shared port — 80% of the 900 mA contract.
• Any depth camera over 4.5 W of total draw gets a powered hub by design, sized at full draw plus 25% per port as in the worked example above.
• One camera per controller port, one metre of cable at the desk, and drag-chain-rated cable on anything that moves.

When you are specifying rather than repairing, choose the camera in the 3D sensors category or the camera finder, and pick the cable at the same time from camera cables or the configurator's extras step. The surrounding depth-camera fixes live on the 3D camera topic page.