Depth camera shows a black window: fix the USB dock and hub path

The symptom always has the same shape: the SDK lists the 3D camera, webcam apps show its color feed, and every depth-viewer sample draws an empty black window. Move the camera to a port on the computer itself and the image appears. That pattern points at the dock or hub sitting between camera and host, not at the camera, the SDK or the driver. The five-minute test below isolates the failing path, the bandwidth and power arithmetic explains why depth plus color cannot fit a throttled link, and the port, hub and cable choices finish the fix. The same budget decides how many depth cameras one host can carry, so it is worth computing once and writing down.

Why does my depth camera show a black window through a dock?

In almost every case the dock, not the camera, is the cause: the dock's internal hub drops the link to USB 2.0 speed or starves the camera's power, so the SDK enumerates the device and the viewer draws a black window.

The signature rules out half the suspects at once. Enumeration proves the control connection, the driver and the cable's power pins. Webcam video proves the sensor and its color path. What fails is only bulk streaming of uncompressed frames, which is exactly the traffic a dock is most likely to strangle.

Rank the causes by how often they turn out to be true:

1. The dock's downstream port negotiated at high speed (480 Mbit/s) or hangs off an internal hub wired that way.
2. The camera sits on a bus-powered hub whose single upstream power budget is already spent.
3. The link is SuperSpeed, but depth plus color plus the IR stream together exceed what the shared hub can carry.
4. The cable between dock and camera was never rated for USB 3.0.
5. The SDK build itself: some macOS releases shipped color samples that stayed black regardless of port, so the depth viewer is the one that tests the path.

Causes 1 to 4 die in one direct-port test. When the camera does not even enumerate, the fault sits earlier in the chain and has its own triage: see wrong port, wrong cable or wrong power. For the wider black-image symptom set, the USB bandwidth and power checklist covers the cases this page compresses.

How much USB bandwidth do depth and color streams actually need?

Uncompressed, a 1280 × 720 depth stream at 16 bits and 30 fps needs about 442 Mbit/s on its own, and a color stream of the same size adds 664 Mbit/s, so depth plus color totals roughly 1.1 Gbit/s — well past what a USB 2.0 link can carry.

Take a mid-resolution depth camera as the worked example: 1280 × 720 pixels, 16 bits per depth sample, 30 fps, plus a color stream of the same geometry at 24 bits per pixel.

Two things move these numbers. A camera that also pushes its raw IR frames adds a third 442 Mbit/s channel, taking the total past 1.5 Gbit/s. Most cameras compress color to MJPEG, which cuts that channel several-fold, but depth stays uncompressed, so 442 Mbit/s is the irreducible floor. Either way the verdict holds: a USB 2.0-class link cannot carry depth at full rate, and USB 3.0 carries depth plus color with room to spare. A throttled dock is a USB 2.0 link wearing a USB-C connector, and what a camera does on one follows the host's bandwidth check: see why USB 2.0 stops streams starting.

How do I test whether the dock is the cause in five minutes?

Plug the camera into a port on the computer itself, run only the depth-viewer sample, and read the negotiated link speed: if depth streams on the direct port and stays black through the dock, the dock is the cause.

Work down the list and stop at the first step that changes the result:

1. Connect the camera straight to a port on the computer: no dock, no hub, nothing else on that port.
2. Run only the depth-viewer sample from your SDK; leave the color and multi-stream viewers for later.
3. Open the operating system's USB device tree and read the speed listed for the camera: SuperSpeed or USB 3.x, not 480 Mbit/s.
4. If the direct port still fails, swap in a short USB 3.0-rated cable, 3 m or less, and repeat.
5. Re-run the depth sample through the dock. Direct port works, dock stays black: the dock is the cause, and no SDK setting will change it.

The webcam check everyone runs first is false comfort. UVC video is compressed and sized to fit a high-speed link, so video-call apps stream happily across the very dock that chokes raw depth. A working webcam feed proves the sensor, not the pipe. What a camera does on a 2.0-class link shows in the device tree and the behavior: see what changes when the camera is detected as USB 2, and the low-resolution symptom when the stack silently downsizes instead of failing.

What fixes work when the dock throttles the link?

Move the camera to a direct host port first; if port count forces a hub, use a powered USB 3.0 hub and a short USB 3.0 cable and keep the camera alone on it — no software setting recovers bandwidth the port never negotiated.

Ranked by how much of the problem each removes:

• Direct host port. On a desktop take a rear-panel port; on a laptop, a side port. This removes the internal hub entirely and is the only fix that restores a full 5 Gbit/s path with nothing shared.
• Powered USB 3.0 hub. One with its own mains supply resets both budgets: the uplink carries SuperSpeed and every downstream port gets its own guaranteed 4.5 W instead of a share of one.
• Short USB 3.0 cable. Keep camera-to-host copper to 3 m or less. Longer passive runs lose margin at SuperSpeed rates, and some cables sold as USB-compatible are wired for high speed only.
• An empty path. A dock also feeding drives, displays and chargers shares whatever hub it has; 1.1 Gbit/s of depth streams is happier alone.

The same physics catches extension leads: a passively wired extension can pass enumeration and low-rate traffic all day, then fail the moment recording starts — see why the extension cable fails only when you record.

A black path is often just a cable that was never built for USB 3.0. Where the bench or axis moves, use a drag-chain-rated one:

Does power draw matter as much as bandwidth?

Yes, and it fails the same way: a USB 3.0 port guarantees 900 mA at 5 V (4.5 W) per port, a USB 2.0 port only 500 mA (2.5 W), and a bus-powered hub splits one upstream budget across everything hung on it.

Enumeration survives on the low-power default, which is why a starving camera still appears in the SDK and then fails, or vanishes, the moment both streams open and the IR illuminator switches on. Budget power alongside bandwidth:

• USB 3.0 port: 900 mA × 5 V = 4.5 W guaranteed per port
• USB 2.0 port: 500 mA × 5 V = 2.5 W
• Bus-powered hub: one upstream budget, shared by every downstream device

Worked budget: a depth camera drawing 800 mA wants 4.0 W and fits a direct USB 3.0 port with 100 mA to spare. Behind a bus-powered hub that also feeds a 200 mA wireless receiver and a 500 mA portable drive, the same camera asks for 1,500 mA against a 900 mA budget. Something browns out, and the symptom is a black window or a camera that disappears when the streams open. A powered hub ends the contention because each port carries its own 4.5 W.

The two classic power symptoms have their own pages: disconnects when the IR stream starts and detected but no image, power budget first.

How do I confirm the camera is on a real USB 3.0 path?

Read the negotiated speed in the operating system's USB device tree before blaming the SDK: a camera on a working SuperSpeed path reports USB 3.x, while one parked on a high-speed port reads 480 Mbit/s and cannot carry depth plus color at full rate.

Every operating system labels the field differently, but the USB device tree lists the negotiated speed per device. Look for SuperSpeed or USB 3.x next to the camera's entry. A 480 Mbit/s reading means the port, the dock's internal wiring or the cable paired the camera down, and no amount of retry logic in software recovers it.

Three things commonly park a camera at high speed:

1. A dock USB-A port whose internal hub is wired for 2.0: docks differ, so read which of its ports carry 3.x before assigning cameras to them.
2. A USB 2.0-only cable, which includes most long cables and anything sold as a charge cable.
3. A SuperSpeed-capable port that sits behind a 2.0 hub upstream.

When the speed reads right and streams still misbehave, the remaining suspect is contention: other cameras and devices sharing the same pipe. That is a budgeting exercise with its own worked numbers: budgeting the hub's bandwidth first.

When should I stop fighting USB and change the set-up?

Change the set-up when the constraint is structural: runs longer than passive copper, hosts whose every port sits behind one internal hub, or cells already carrying several cameras — those argue for a GigE Vision 3D sensor on its own network link.

USB carries depth happily once the path is direct and powered, so treat the move as a design decision rather than a cable swap. A GigE Vision 3D sensor gets a dedicated gigabit or better, up to 100 m on Cat 5e or better, power over the same cable where the switch delivers PoE, and no dock hub between it and the host. Browse the 3D sensors category, filter profiler, stereo or ToF types in the camera finder, and cover the camera side from the cables category and accessories finder.

Keep the camera-side run drag-chain rated where the cell moves:

Whatever the interface, budget before wiring: total the stream rates against the pipe and the amps against the supply, and write both numbers on the cell drawing. Multi-camera enumeration and bandwidth live in their own guide.

Once the path is right, these cameras are dull in the best way: they enumerate at SuperSpeed, both streams open first time, and the black window becomes a depth map. If the arithmetic says your host cannot carry the streams, move the camera rather than the software. When the choice between repairing the USB path and moving to an Ethernet sensor is close, the contact page puts the applications team on the case, and the rest of the depth-camera triage sits on the 3D topic page.