You plugged a USB3 camera into a blue connector and lsusb -t still prints 480M under a USB 2 root hub. The camera enumerates and streams, but the link negotiated USB2 speed: it runs USB 2 High-Speed, so usable bandwidth is about 40 MB/s instead of about 400 MB/s and the frame rate collapses. This troubleshooting guide shows how to read the tree, isolate the cause in order of likelihood — port, cable, hub, interference, or a camera that is USB 2 by design — and restore the 5 Gbit/s link. The commands work for UVC cameras under uvcvideo and for USB3 Vision cameras, on desktop Linux and on single-board hosts.
What does 480M in lsusb -t actually mean?
It means the camera enumerated on a USB 2.0 High-Speed link of 480 Mbit/s: the SuperSpeed pairs never came up, so the device runs on the two USB 2 wires that every connector carries and cannot use the 5 Gbit/s pairs at all. The tree lists each root hub with its speed and each device beneath it. A USB 3 host shows at least one 5000M root hub. In one single-board host, two of them — one per USB 3 connector — sit alongside the slower buses, and a depth camera with several uvcvideo interfaces hangs under a USB 2 hub; every interface line beneath it shows the same fallback, because all interfaces of a device share one link speed.
A camera on a USB 2 link often still gives images, because the SDK quietly switches to a smaller format. That silent renegotiation and the dark image it produces inside ROS tools are covered in USB3 camera dark image in ROS tools: fix bandwidth fallback; the rest of this guide fixes the physical link underneath it.
Why did the link negotiate USB 2 instead of SuperSpeed?
Because one of five things broke the SuperSpeed path: a USB-2-only connector, a cable without SuperSpeed conductors, a hub or dock in between, interference or a half-seated plug, or a camera whose interface is USB 2 by design — in roughly that order of likelihood.
| Cause | One-minute test | Fix |
|---|---|---|
| USB-2-only connector | Move the plug to another connector; the tree flips to the SuperSpeed hub | Use a connector on a 5 Gbit/s root hub |
| Charge-only or damaged cable | Swap a certified SuperSpeed lead; the tree flips | Replace the cable |
| Hub, dock, extension or adapter | Connect the camera directly to the host | Take it out of the camera path |
| Marginal link: electrical interference, seating, length | dmesg shows repeated enumerations; drops track vibration | Shorten the run, reroute away from drive wiring, lock the plug |
| Camera is USB 2 by design |
bcdUSB reads 2.x on a desktop USB 3 port |
Keep the fallback speed, or change the camera |
Hubs earn their own line. A USB 2 hub forces the fallback on everything downstream, and even a USB 3 hub shares one 5 Gbit/s uplink across all its ports. A camera hung on a robot controller's built-in hub meets both problems at once; camera detection through a cobot's USB hub works that variant end to end.
A link that reaches 5 Gbit/s and later falls back points at seating, interference or cable length rather than topology. The isolation procedure in USB camera keeps disconnecting: isolate cable and hardware faults applies step by step.
Which port on the host actually runs at 5000M?
Only connectors wired to a SuperSpeed root hub do, and you count them in lsusb -t: a single-board host such as a Raspberry Pi 5 exposes two 5000M buses — one per USB 3 connector — alongside slower buses that carry the USB-2-only connectors and any SuperSpeed link that failed to come up.
Physical markings narrow the search: USB 3 connectors carry a blue tongue or an SS mark, and USB-2-only connectors are usually plain black. The tree is the authority. Move the plug to the next connector, re-run the tree, and stop where the camera appears under a 5 Gbit/s hub. If the camera stays on the 480 Mbit/s bus in both USB 3 connectors, the fault is the cable or the device, not the port.
Embedded GPU modules pair ports in their own way; USB3 camera fallback on Jetson modules covers that family's port mapping.
How do you prove the camera itself is a USB 3 device?
Read bcdUSB from the descriptor: lsusb -v -s 004:027 | grep bcdUSB prints 2.00, 2.01 or 2.10 for a USB 2 device and 3.00 or higher for a SuperSpeed-capable one — a 2.x value on a desktop USB 3 port settles it, because that camera can never exceed the High-Speed rate.
Test on a desktop you trust: a known-good USB 3 port with a short certified cable removes host and cable from the experiment. Plenty of stereo depth modules ship with USB 2 interfaces by design, so this result is common, not exotic. Your decision is then to keep the fallback — sound when the stream fits, as the last sections show — or to move to a USB3 or GigE camera. A GigE link carries about 100 MB/s over 100 m of Cat6, more than twice what USB 2 delivers, and our USB3 area scan cameras and 3D sensors pages list both interfaces.
What kind of cable holds a 5 Gbit/s camera link?
One with all nine contacts — power, ground, the USB 2 pair, two SuperSpeed pairs and a drain wire — so use a certified SuperSpeed lead of 3 m or less in static installs, and the fallback disappears when the cable was at fault.
Charge-only leads omit the SuperSpeed pairs, and the camera still runs — at the High-Speed rate — which is why a borrowed phone cable is the most common single cause of this symptom. Where the camera uses Micro-B, the count is visible: a USB 3 plug carries ten pins, a USB 2 plug five. Keep passive runs at 3 m or less near electrical noise; 5 m usually survives in a quiet cabinet; past that, use an active repeater or an optical cable. Hold 300 mm of separation from motor and drive wiring where the layout allows.
On a moving axis, use a drag-chain-rated lead with screw locks, because vibration walking a plug half a millimetre out of its socket drops SuperSpeed while USB 2 keeps working. The LS-CBL-0219 is a 3 m USB3.0 high-flex drag-chain cable, and the camera data cables range covers other lengths and connector styles. Adapter and OTG-port signal faults that mimic this symptom are covered in USB camera signal integrity: diagnosing OTG port image errors.
How much frame rate does the 480M link really cost?
Take a 12 MP mono camera at 30 fps: each 4000 x 3000 frame is 12 MB, so the camera pushes 360 MB/s; a USB 2 link delivers about 40 MB/s and the frame rate collapses to roughly 3 fps, one tenth of the specification.
The LS-CMR-0166 is exactly that camera: 12 MP, 4000 x 3000, 30 fps over USB3. Colour multiplies the load — unpacked RGB is 3 bytes per pixel, YUYV 2 — and a 20 MP USB3.0 model such as the MV-CS200-10UM scales the payload up again.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Sensor format
- 1"
- Lens mount
- C-mount
The depth camera behaves differently, and the arithmetic explains why. A VGA depth stream — 640 x 480, 2 bytes per pixel, 30 fps — is 18 MB/s, which fits USB 2. Add a 1280 x 800 colour preview in YUYV at 30 fps and you add 61 MB/s; the 79 MB/s total does not fit, so the SDK silently drops the colour stream or the frame rate. Stalls of that shape are worked through in Depth camera frames not updating: fix USB bandwidth stalls. One safety note while you test: structured-light depth cameras project infrared patterns that are invisible — do not stare into the emitter at close range.
Why is the frame rate still low after the tree shows 5000M?
Because the transport is no longer the limit: at 30 fps the exposure must stay under 33 ms (1000 / 30), and on Linux, libusb-based USB3 Vision transfers are capped by the kernel's 16 MB usbfs buffer until you raise it.
Exposure is arithmetic, not a fault: any exposure longer than the 33 ms frame period caps the frame rate on its own, whatever the link does. The buffer cap is the kernel's usbfs_memory_mb parameter, 16 MB by default. Raise it with echo 1000 | sudo tee /sys/module/usbcore/parameters/usbfs_memory_mb; the setting resets at reboot, and uvcvideo devices are not affected by it. Both limits, with their measurements, are worked through in USB3 camera low frame rate and latency: fix usbfs memory and exposure, and the transfer errors that appear once the link runs at full speed are handled in USB3 Vision transfer errors: diagnose bandwidth and buffers.
When is staying on USB 2 the right decision?
When the whole stream — every camera, every format on that port — stays under about 35 MB/s with headroom: a single compressed or VGA-size stream qualifies, and a USB-2-only camera leaves no choice; every raw stream above roughly 1 MP at 30 fps does not qualify.
The decision per case:
- Depth-only stream on a USB-2-only module: keep it. The 18 MB/s stream has margin on a 40 MB/s link, and the camera cannot do better anyway.
- Depth plus colour preview: fix the link. The 79 MB/s total does not fit, and the silent stream loss costs more than the repair.
- 12 MP and larger raw inspection: fix the link first. At 360 MB/s the camera needs the SuperSpeed link by a factor of nine.
- Several cameras on one host: fix link and topology together. Two 12 MP cameras at 30 fps total 720 MB/s and saturate a single 5 Gbit/s bus.
What order should you check before buying anything?
Work this six-step list from the top; each step takes about a minute and needs no parts, and you spend money only after step 4 (a cable) or step 6 (a camera) names the part that failed.
- Confirm the symptom:
lsusb -tshows the camera under the 480 Mbit/s bus, and dmesg reportshigh-speed, notSuperSpeed. - Count the 5 Gbit/s root hubs, then move the camera between connectors until it lands under one.
- Take every hub, dock, extension and adapter out of the path and connect directly.
- Swap in a certified SuperSpeed cable of 3 m or less — high-flex on a moving axis.
- Read
bcdUSBon a known-good desktop USB 3 port; a 2.x value means the camera is USB 2 by design. - Check the power budget: 900 mA at 5 V, about 4.5 W, per USB 3 port.
If the list leaves you at the fallback speed with a USB 2 camera, the camera is the part to change. Start from the camera finder, or open the system configurator at the camera step and carry the bandwidth answer into lens, light and controller choices. For a station you would rather talk through, the contact page reaches the applications team — expert support is free with every order.
Questions
What do 10000M and 20000M mean in lsusb -t?
They are 10 and 20 Gbit/s links, USB 3.1 Gen 2 and USB 3.2 Gen 2x2. A standard USB3 Vision camera negotiates the 5 Gbit/s rate even on those buses unless camera and cable both support the higher rate, so a camera showing the 5 Gbit/s rate under a faster root hub is running normally.
Is a blue USB connector a guarantee of 5 Gbit/s?
No. Blue tongues and SS marks state intent, not wiring: some blue ports on budget hubs and docks are USB 2 inside, and front-panel connectors can route through headers wired for USB 2 only. Trust the tree. A device on a 5 Gbit/s bus has the link; one on the 480 Mbit/s bus does not.
Can I leave the camera on USB 2 if it still produces images?
Only if the total stream stays under about 35 MB/s. A VGA depth stream at 640 x 480, 2 bytes per pixel and 30 fps is 18 MB/s and fits; adding a 1280 x 800 colour stream at 30 fps adds 61 MB/s and does not. Raw mono above roughly 1 MP at 30 fps belongs on USB 3.
Do USB-C docks and hubs cause the same fallback?
Yes, in three ways: the dock's uplink cable can omit the SuperSpeed pairs, the downstream port you land on can be wired for USB 2, and every device on the dock shares the single 5 Gbit/s uplink. Give a machine-vision camera a direct host port and leave docks to keyboards and displays.
How much power can a camera draw from a USB 3 port?
900 mA at 5 V, about 4.5 W, against 500 mA at 5 V, 2.5 W, on USB 2, and bus-powered hubs often deliver less than the label. If the camera renegotiates or drops when its light or projector fires, power, not bandwidth, is the limit: use a mains-powered hub that keeps the SuperSpeed path or a dedicated supply.


