Depth stream has no data: USB 2.0 port fails the bandwidth check

Your depth camera starts cleanly: the driver finds the device, prints the serial number and port path, configures 640×480 at 30 fps and reports the node is up. Then the depth topic carries no frames at all, and the log fills with hardware-notification errors such as USB SCP overflow and USB CAM overflow. That combination — clean enumeration, repeated overflow errors, an empty topic — almost always means the camera sits on a USB 2.0 link that cannot carry the streams you enabled. You get the payload arithmetic that decides the case, a two-minute check of the negotiated link speed, the fix in the order that works, and the budget rule that keeps the problem from coming back.

The symptom: node up, topic empty, overflow errors

The launch sequence looks healthy. The device is found, the stream lines print the enabled modes — depth 640×480 at 30 fps in Z16, color at 30 fps in RGB8, infrared at 30 fps in Y8 — and the publishers report their expected 30 Hz. Seconds later the warnings start: USB SCP overflow from the stereo module, often joined by USB CAM overflow from the RGB sensor, repeating every second or two as Error-level hardware notifications. A frame-rate check on the depth topic shows nothing, or a trickle far below the configured 30 fps.

Read those overflow warnings as the camera reporting its own problem. They come from the camera's firmware: the USB link into the host cannot move the data the sensors produce, so the camera discards data mid-frame and tells you. Your code never receives the frames, so the topic stays empty.

Two other warnings in the same log are not the fault. A line about UVC metadata payloads not being available, and frame-metadata or timestamp-domain warnings, degrade timestamping only; fix them later. And if the log says a stream configuration is not supported and skips it, that stream simply reduces the load — the remaining streams still have to fit the link.

If the depth topic publishes black frames rather than no frames, that is a different failure with its own fix: see depth camera black image: fix USB bandwidth and power issues. No frames at all, with overflow errors, is the bandwidth case below.

The arithmetic: what your enabled streams cost

Every stream's payload is pixels × bytes per pixel × frames per second:

MB/s here means one million (10^6) bytes per second. At 640×480 and 30 fps:

Worked example, depth first: 640 × 480 × 2 B = 614,400 B per frame; 614,400 × 30 = 18,432,000 B/s = 18.43 MB/s; 18.43 × 8 = 147.5 Mbps. Color in RGB8 carries three bytes per pixel: 640 × 480 × 3 = 921,600 B per frame = 27.65 MB/s. Depth plus color alone is 18.43 + 27.65 = 46.08 MB/s (368.6 Mbps). Add the infrared stream and the total reaches 55.30 MB/s.

The same arithmetic budgets any multi-stream USB device; a worked USB bandwidth calculation for multi-channel streams walks it channel by channel in another context.

Now the ceilings. USB 2.0 signals at 480 Mbps, but framing, handshakes and device overhead leave roughly 280–320 Mbps of payload in practice — budget 35 MB/s and you stay safe. USB 3.0 signals at 5 Gbps and delivers around 400 MB/s of usable payload for streaming. Set the loads against those ceilings:

• 55.30 MB/s (442.4 Mbps) of payload is about 1.6× a USB 2.0 link's practical budget. The link fails by more than half, and the camera's firmware drops data — exactly the USB SCP overflow pattern.
• Depth alone at 18.43 MB/s is within reach of a good USB 2.0 link, which is why some modes limp along at a reduced rate instead of failing outright.
• On USB 3.0, the full 55.30 MB/s load sits at about 14% of capacity, leaving room for a point cloud, a second camera or higher resolution.

Resolution scales the same way. Depth Z16 at 848×480 and 30 fps costs 848 × 480 × 2 × 30 = 24.42 MB/s. At 1280×720 it costs 55.30 MB/s — that single stream already needs USB 3.0.

Confirm the negotiated link speed first

Work down this list; the first item settles most cases.

1. Read the negotiated speed. The OS's USB device tree prints the speed per device: 480M is USB 2.0, 5000M is USB 3.0. If your camera's entry reads 480M, you have found the cause. No launch parameter changes what a 480 Mbps link can carry.
2. Mind the path trap. The driver's start-up log prints a physical port path; a segment such as usb3 in it is the host controller's bus number, not a statement about speed. A camera on a 2.0-only port still sits under a bus labelled usb3.
3. Check what it is plugged into. Monitor hubs, docks, keyboard passthrough ports, front-panel connectors and one side of a laptop are routinely wired for USB 2.0 only. Prefer a port soldered to the motherboard — the rear I/O on a desktop.
4. Swap the cable. A cable wired for 2.0 enumerates at 480M on any port. If the same camera and port read 5000M with a different cable, the first cable was the bottleneck.

Decision: a 480M reading with depth and color enabled means the port is the cause. Stop debugging software and move the hardware.

The fix, in order

1. Move to a USB 3.0 port on the host itself. Not a hub, not a dock, not a monitor's downstream port. A desktop without USB 3.0 can take an add-in card.
2. Shorten the cable. Keep passive copper runs to about 3 m; longer passive runs show up as intermittent overflow errors, and the physics behind the limit is in USB cable length limits for 3D cameras. For a fixed or moving install, the LS-CBL-0219 is a purpose-built camera cable: 3 m, USB3.0, high-flex, drag-chain rated.

3. Disable the streams you do not use. A stereo module's default launch enables every stream the sensor can supply, and each one must fit the link. Turn off unused infrared, fisheye, gyro and accelerometer streams in the launch parameters; the depth topic does not care that they exist.
4. If the host has no USB 3.0 at all, plan around the ceiling: depth-only at 640×480 and 15 fps costs 9.22 MB/s (18.43 ÷ 2) and fits a 35 MB/s link with headroom. Multi-stream at 30 fps does not fit at any useful setting.
5. Then, and only then, software. List the published topics and echo the exact name your node uses — a namespace mismatch looks identical to no data. Keep the camera's firmware current using the manufacturer's own update tools. No firmware makes a 442 Mbps payload fit a 280 Mbps link, though: if the arithmetic fails, the hardware is wrong, not the settings.

Still empty on USB 3.0: the remaining causes, in order

If the negotiated speed reads 5000M and the depth topic still publishes nothing, work these in order — each has a one-minute test.

1. Marginal cable or extension. Intermittent overflows, frames that stop after minutes: swap to the shortest known-good cable, direct to the host, no passive extension. The failure signatures are in USB-C cable timeouts on a USB3 camera.
2. A shared, saturated host controller. Other cameras, disks or network adapters on the same controller steal the link. Unplug everything else and retest; if two cameras must live on one host, budget their combined payload as in multiple USB cameras on one host: bandwidth and power budget.
3. A virtual machine in the path. Hypervisor USB passthrough hands the camera small buffers and reintroduces overflows even on USB 3.0 hardware. Boot the same machine bare-metal; if the stream comes up, the fix lives in the VM's USB controller settings — see depth camera color stream timeout in a VM.
4. Power. A bus-powered module on a weak port browns out under load, with dropped-frame symptoms that mimic bandwidth failure. Test on a powered hub or a different port.
5. Driver-side causes. Frames published but stale, or a subscriber on the wrong namespace, all look like "no data" from the outside. Depth camera frames not updating: fix USB bandwidth stalls covers the stalled-publisher signature, and depth camera no frames after power loss covers the stale buffer after an unclean shutdown.

Budget the link before you deploy

The rule that prevents the next occurrence: add the payload of every stream you enable, and keep the total at or below 70% of the link's practical payload. The headroom is not conservatism for its own sake — USB moves data at frame boundaries in gulps (a 30 fps stream delivers a frame's worth every 33 ms, not smoothly), so peaks, not averages, are what overflow a camera's buffers.

Check the example against it. The 55.30 MB/s load on USB 3.0 is about 14% of 400 MB/s — comfortable, with room for a second camera. The same load on USB 2.0 is about 158% of budget, a guarantee of overflow errors. One planning line: a multi-stream depth camera on USB 2.0 is a failure waiting to be commissioned. Size the link for the streams you will actually enable.

The decision, per case

• 480M negotiated, depth plus color enabled. The port is the cause. Move the camera to a USB 3.0 port on the host with a short rated cable; the topic carries data the moment the link carries the payload. Expected load 46.08 MB/s against roughly 400 MB/s — about 12% of capacity.
• 5000M negotiated, still empty. Work the cable → host controller → VM → power → driver list above; each test isolates one cause in about a minute.
• USB 2.0 is the only option. Depth-only at 640×480: 9.22 MB/s at 15 fps is about 26% of a 35 MB/s link, and 18.43 MB/s at 30 fps is 53% — workable with no other load. Add color in RGB8 and the total is 46.08 MB/s, 132% of the link: no multi-stream configuration fits.

If the verdict is a different camera rather than a different port, pick by technology and task: projected structured light with the MV-DPS200P-02, ToF sensing with the MV-DT01WMU, laser profiling with the MV-DP4180-03P.

If the diagnosis ends in hardware, the 3D sensors category covers depth cameras from laser profilers to ToF and structured light, and the camera finder filters them; camera cables and the accessories finder carry the USB 3.0 cabling. To spec the whole chain, start the configurator at the accessories step, and the remaining depth-camera guides sit on the 3D topic page. If a link still misbehaves after the port fix, contact us with your launch log.