You launch the stack, the depth and infrared topics publish, and the color image never appears. The camera enumerates, it powers, and the log may show a control transfer failing with No data available (error 61). In nearly every case like this the camera is healthy and the USB link is not: the device negotiated USB 2 High-Speed — 480 Mbit/s — instead of the 5 Gbit/s of USB 3, and the driver refuses to start the streams that no longer fit. This guide shows you how to read the negotiated speed out of lsusb and dmesg, why the color stream is always the first casualty of the arithmetic, and which cable, connector or port to change, in the order that finds the fault fastest.
The symptom: everything starts, the color stream never does
The pattern is the same on depth cameras and USB3 Vision cameras. The launch completes, depth and infrared publish, and the color topics — paths ending in something like color/image_raw — never appear. Two log lines often ride along. One is a control transfer failing with error 61, No data available (ENODATA). The other notes that frame timestamps use the hardware clock; that warning is expected whenever hardware timestamping is on and it is not part of this fault.
The line that matters reports the connection type: the camera logged on as a USB 2.1 connection rather than USB 3.x. That single line explains the missing stream — nothing is wrong with your code, your wrapper or the launch. Depth cameras and other 3D sensors show this most often, because their color stream is uncompressed and large.
Read the negotiated speed before changing anything
Two commands settle it in under a minute. lsusb -t prints the USB tree with the speed of every link: 5000M is USB 3, 480M is USB 2. In a second terminal, dmesg --follow shows the kernel line at plug-in: a new SuperSpeed USB device, or a new high-speed USB device.
Trimmed lsusb -t output:
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 6, If 1, Class=Video, Driver=uvcvideo, 480M
The camera on Port 2 sits under a 5000M root hub but runs its own link at 480M: fallback confirmed. For a longer walk through the tree — root hubs, hubs in the path, what each column means — read why lsusb -t shows 480M. On Windows, USBView from the Windows Driver Kit lists the same speed per device, and most camera tools print the connection type at start-up.
Why USB 2 kills the color stream first
When a USB3 camera lands on a 480 Mbit/s link, the driver adds up what fits and enables only that. Nothing runs slowly; the streams that do not fit never start. The arithmetic is short:
An uncompressed 720p30 color stream in YUYV carries 2 bytes per pixel: 1280 × 720 × 2 B × 30 fps = 55,296,000 B/s, about 55.3 MB/s, or 442 Mbit/s. That is 92% of USB 2's 480 Mbit/s raw signaling rate before protocol overhead, before the depth stream, before anything else on the bus — it can never start. A depth stream of 640 × 480 at 2 bytes and 30 fps is 18,432,000 B/s, about 148 Mbit/s, which fits. That is why depth publishes while color is absent, and why the failure looks like a software fault.
| Stream | Pixels | Bytes per pixel | fps | Rate | Fits USB 2 at 480 Mbit/s? |
|---|---|---|---|---|---|
| Color 1280 × 720 | 921,600 | 2 | 30 | 442 Mbit/s | No — 92% of raw, alone |
| Depth 640 × 480 | 307,200 | 2 | 30 | 148 Mbit/s | Yes |
| Both together | — | — | — | 590 Mbit/s | No; only 12% of USB 3's 5 Gbit/s |
USB 3 — 5 Gbit/s, sold at various times as USB 3.0, USB 3.1 Gen 1 and USB 3.2 Gen 1 — carries both streams with room to spare, which is why the same camera behaves on another machine.
Cause 1: the cable
Start here. In field reports of this exact symptom the replacement lead is the usual fix, and the pin layout explains why: USB 3 adds dedicated SuperSpeed pairs on their own contacts, separate from the USB 2 pins. A lead with a broken SuperSpeed pair, a worn or contaminated plug, or a USB-C cable that only carries the USB 2 pair will enumerate at 480 Mbit/s on every USB 3 port you try.
Test in this order. Unplug the camera-end connector and inspect the receptacle for debris, then reinsert it firmly. On a reversible USB-C plug, insert it the other way round once — a worn receptacle can contact the USB 2 pins in one orientation and miss the SuperSpeed pins. Then swap in the shortest known-good USB 3 cable you have and watch dmesg while you plug in. If the link jumps to 5000M, the old lead was the fault: replace it and you are done. When a marginal cable escalates to the camera vanishing entirely, the camera link checks after a cable swap are the next step.
Cause 2: the port and the path
A blue receptacle does not guarantee a SuperSpeed path. Front-panel ports are fed by an internal header cable that can be loose or left on the wrong header; extension leads and adapters quietly drop the SuperSpeed pairs; and any hub in the path caps the camera at that hub's own link speed. The lsusb -t tree shows the whole chain — if the hub your camera hangs under reports 480M, nothing behind it can do better.
Move the camera to a rear port soldered to the board, with no hub, extension or adapter anywhere in the path, and re-read the tree. When several cameras share one host, plan the topology instead of discovering it: USB hub drops camera frame rate: budget the bandwidth first shows the summing, and USB3 hub bandwidth for multiple machine vision cameras covers the multi-camera case. If the link degrades until the camera stops enumerating entirely, troubleshooting a depth camera's USB connection walks the host-side checks that come next.
Cause 3: controller mode and firmware
Older boards can hand SuperSpeed-capable ports to the USB 2 controller. In the firmware setup, set the USB mode to xHCI rather than an auto or compatibility mode, and confirm in lsusb -t that the camera's root hub is driven by xhci_hcd. Beyond that, run the vendor's own firmware-update procedure once: a camera that a second computer also reports at 480 Mbit/s, on two known-good cables, points at its own connector or firmware rather than at your host.
The fix, in order
- Run
lsusb -tand read the camera line: 480M confirms the fallback; 5000M means your fault is elsewhere. - Replug the camera-end connector, flip a reversible plug once, and inspect the receptacle for debris.
- Swap in a known-good USB 3 cable, the shortest you have.
- Move the camera to a rear board port with no hub, extension or adapter in the path.
- Confirm
lsusb -tnow shows 5000M and dmesg logs a new SuperSpeed USB device. - Relaunch and let the color stream run several minutes at full frame rate with no transfer errors.
- Still 480M on a second host with two cables: run the vendor's firmware update, then send the lsusb -t output and the camera model through the contact page.
Cables that hold SuperSpeed
Once the link is clean, keep it that way. Use a lead specified for the camera's connector, with a lock or screw fitting where the camera offers one, and a high-flex rating when the camera rides a moving head. Keep passive USB 3 runs at about 3 m or less: attenuation on a long passive lead is the classic slow fade into fallback, and past that length an active or optical USB 3 lead is the reliable route. For a machine-vision camera with a lockable USB connector, keep a spare specified lead on the shelf:
The LS-CBL-0219 is a 3 m USB3.0 camera cable in a high-flex (drag chain) build.
Camera data, power and I/O cables
401 models · from $22.00Browse the camera cable finder for other lengths and connector types, and the area scan camera finder when the station outgrows what one USB link can carry.
When USB 2 fallback is not the fault
If lsusb -t already shows 5000M and the color stream still misbehaves, work the other bandwidth limits. Streams that start and then time out point at host-side allocation: depth and color stream timeouts: the USB bandwidth check. Frames that arrive with transfer errors point at buffers and the link itself: USB3 Vision transfer errors: diagnose bandwidth and buffers. If the control-transfer error 61 appears only with several cameras on one host, the cause is host-side concurrency, not the link: see multi-camera USB control transfer freezes: serialise and recover. Also confirm that the stream you enable matches the topic the wrapper publishes — some stacks start color by default under a different namespace. The wider set of host-side faults is collected on the systems topic page.
Sixty-second checklist
-
lsusb -t: the camera line reads 5000M, not 480M. - dmesg at plug-in logs a new SuperSpeed USB device.
- Camera-end connector inspected, reseated, and flipped once if reversible.
- A known-good USB 3 cable of 3 m or less, with no hub, extension or adapter.
- Camera on a rear board port, not a front-panel header.
- Color stream holds full frame rate for several minutes with no transfer errors.
That is the whole fix: prove the speed, clean the path, replace the lead. If a second host still negotiates 480 Mbit/s, the camera needs the vendor's firmware bench rather than your cable drawer — send the lsusb -t output through the contact page and we will take it from there.
Questions
Can software force a USB 3 link that enumerated at 480 Mbit/s?
No. Link speed is fixed during enumeration by which pins made contact; no driver flag, udev rule or SDK setting raises it afterwards. Replugging re-runs the negotiation, so fix the physical path — connector, cable, port — and plug in again. What software can do is read the negotiated speed and disable the streams that exceed it, which is exactly the symptom you are seeing.
Why does depth keep publishing when color disappears?
Because of size, not priority. A 640 × 480 depth stream at 2 bytes per pixel and 30 fps is about 148 Mbit/s, which fits inside USB 2's 480 Mbit/s; the same camera's 1280 × 720 color stream at 2 bytes per pixel and 30 fps is about 442 Mbit/s and cannot start. The driver keeps what fits and never starts what does not.
How do I check the negotiated speed on Windows?
USBView, part of the Windows Driver Kit, lists every device with its speed — High-Speed means 480 Mbit/s. Most camera vendor tools print the connection type in their start-up log too. If the camera runs in a virtual machine, test on the native host first: the pass-through layer adds its own enumeration and can mask the real link speed.
How long can a passive USB 3 camera cable be?
Plan on 3 m as the practical limit for a passive SuperSpeed lead; longer passive runs lose the link margin that negotiation needs and drift into fallback. Beyond that, use an active or optical USB 3 cable, or choose a camera with a networked interface — GigE reaches 100 m on standard cabling.
Will a USB 3 hub fix a USB 2 fallback?
No. A hub never raises a device's negotiated speed; the camera negotiates with the hub port below it, so a 480 Mbit/s camera stays at 480 Mbit/s behind any hub. Fix the cable and connector first. Hubs solve the opposite problem — sharing one host controller between several cameras — where you budget each camera's rate against the uplink.
Is the control transfer error 61 part of the same fault?
Usually yes. The same marginal contact that loses the SuperSpeed pairs can make control transfers fail with ENODATA, printed as No data available, error 61. Treat it as a symptom of the link, not a separate software fault; once the camera negotiates 5 Gbit/s these transfers normally succeed again. If they persist with several cameras on one host, the cause is host-side concurrency.