Camera enumerates as USB 2.0 on a USB 3.0 port: fix the link

You plug the camera into a port you know is USB 3.0, open the capture software, and find one format on offer: 1280 × 720 at 10 fps. The full-resolution modes never appear in any application. That is the fingerprint of a device that enumerated on the USB 2.0 path: SuperSpeed link training failed quietly somewhere between the host controller and the module, the camera fell back to 480 Mbps, and its descriptor now exposes only the reduced format list a High-Speed link can carry. Here you will confirm the negotiated speed, work through the four causes in order of probability - cable, port power, host controller driver, damaged connector or faulty module - and finish with a clear rule for when the module itself is the fault.

Confirm the negotiated speed before changing anything

A blue port proves nothing: the color is cosmetic and says nothing about the link. The speed comes from negotiation between the host controller, every cable and hub in the path, and the device. A USB 3.0 device that fails SuperSpeed training does not error out. It silently enumerates as a High-Speed device at 480 Mbps and keeps working, which is why the image looks fine and only the format list gives the fault away.

Three ways to read the negotiated speed. Many machine-vision SDKs print the link speed when they enumerate devices. Device Manager may group the module under 'Universal Serial Bus devices', but the grouping alone does not prove the speed. For a definitive reading, run a USB bus viewer utility: it lists every device under every hub with its negotiated speed, and a healthy link shows SuperSpeed (5 Gbps) where the failed one shows High-Speed (480 Mbps).

The format cap is the second confirmation. Dual-mode UVC modules behave in a documented way: on the USB 2.0 path the camera tops out at 1280 × 720, and the full format list appears only in USB 3.0 mode. The video class does not change between the modes - only the bus speed does - so labels such as 'UVC 2.0' and 'UVC 3.0' describe the link, not two different cameras.

The same diagnosis written from the port side is in a depth camera stuck at low resolution: check for a real USB 3.0 port.

The four causes, in order of probability

Work top to bottom. Each test costs minutes, and the first two causes should be cleared before you touch drivers or suspect the hardware.

1. A USB 2.0 cable in the path

A USB 3.0 Micro-B plug carries ten contacts: the five USB 2.0 contacts, then five more for the SuperSpeed pairs behind them at the plug face. A USB 2.0 cable has only the five, so the SuperSpeed lanes are physically absent and nothing on the host can negotiate beyond 480 Mbps. Cables bundled with modules are sometimes USB 2.0 constructions, so do not trust the in-box cable by default.

Test and fix: swap in a cable sold as USB 3.0 or USB 3.1 Gen 1 - the same 5 Gbps - and watch the format list expand the moment the device re-enumerates. The link checks that belong with any cable swap are in camera not detected after a cable swap: USB link checks. For a fixed machine layout, use a cable built for cameras - locking connectors, drag-chain rated, 3 m:

2. Port power too weak for SuperSpeed training

SuperSpeed negotiation draws a start-up current spike, and a marginal port can fail the handshake and drop the device onto the USB 2.0 path. Typical weak points are front-panel headers wired through a case, overloaded or worn hubs, and ports throttled by power saving. The budget is specific: a USB 3.0 port supplies up to 900 mA at 5 V (4.5 W), a USB 2.0 port 500 mA (2.5 W).

Test: move the camera to a rear-board port on the motherboard itself, with no hub in between. If it enumerates at SuperSpeed there, the first port was the problem. Fix: run the camera through a good-quality powered USB 3.0 hub, which supplies its own 900 mA per port, and never through an unpowered one. When several cameras share a host, budget the power explicitly - multiple USB cameras on one host: bandwidth and power budget walks that arithmetic.

3. Host controller driver problems

The host side must enumerate the camera through its USB 3.0 (xHCI) controller with a current driver. After a major OS update, a chipset driver rollback, or on an add-in card running a generic driver, SuperSpeed devices enumerate inconsistently or fall back to High-Speed.

Test: in Device Manager, check which controller the camera sits under, then update the chipset and host controller driver package from the board maker and reboot. If the camera shows a generic name instead of its own, reinstall the device entry - USB camera shows a generic UVC name: reinstall the device entry covers that case. Acquisition software can also hold the class driver; the pattern is worked through in a walk-through of USB3 camera driver conflicts with LabVIEW IMAQdx.

Embedded hosts add their own variables, mostly controller firmware and power routing; there is a dedicated walk-through of USB3 camera fallback on an embedded host for that case.

4. Damaged connector, debris or a faulty module

The USB 3.0 Micro-B receptacle is small and its extra contacts sit deep inside, so debris, a bent contact or a worn plug can block just the SuperSpeed pairs while the USB 2.0 contacts keep the device alive. Test: inspect the camera receptacle and both plug faces under a light, wiggle the connector during streaming, and repeat the whole sequence on a second known-good USB 3.0 host. Fix: clean the contacts with isopropyl alcohol, let them dry fully, re-cable, and only then suspect the module. Handle bare-board modules by the edges and discharge yourself first - the SuperSpeed PHY is easily damaged by ESD.

A module failing electrically usually shows it in enumeration errors before it shows it in link speed: device descriptor request failed: a USB camera that died electrically is that signature.

The numbers: why the cap is 1280 × 720 at 10 fps

The cap is not arbitrary; it is the arithmetic of a High-Speed isochronous pipe, worked here for the full mode a USB3 camera offers once the link is healthy. Inputs:

• Camera mode on SuperSpeed: 4000 × 3000 pixels, 8-bit Bayer, 1 byte per pixel, 30 fps - the full-resolution mode of the 12 MP camera class shown below.
• High-Speed path: 480 Mbps line rate; UVC video runs as isochronous transfers, and the USB 2.0 ceiling for a high-bandwidth isochronous endpoint is 3 × 1024 bytes × 8000 microframes per second = 24.6 MB/s.
• SuperSpeed path: 5 Gbps line rate, 8b/10b coding, 500 MB/s of payload.

• Frame: 4000 × 3000 × 1 byte = 12,000,000 bytes ≈ 12 MB.
• Required: 12 MB × 30 fps = 360 MB/s.
• High-Speed check: 24.6 MB/s ÷ 12 MB ≈ 2 frames per second. The full mode cannot run on the USB 2.0 path, so the module's High-Speed descriptor does not even list it.
• Cross-check the capped mode: 1280 × 720 × 2 bytes (uncompressed YUYV) = 1.84 MB per frame; × 10 fps = 18.4 MB/s, inside the 24.6 MB/s ceiling with room to spare. The 1280 × 720 at 10 fps mode is exactly what a High-Speed isochronous pipe carries, which is why dual-mode modules cap their USB 2.0 list there.
• SuperSpeed check: 360 MB/s is 72 % of the 500 MB/s payload, leaving 140 MB/s for overhead and other traffic. It fits, and cameras of this class sustain it.

Decision rule: any stream needing more than 24.6 MB/s cannot run on the USB 2.0 path, whatever the software tries. Industrial USB3 Vision cameras use bulk rather than isochronous transfers, which on USB 2.0 reach roughly 35-45 MB/s in practice (the 60 MB/s line rate less protocol overhead) - better, still far below a full camera mode. A link that was healthy and then starts dropping frames has its own next diagnosis in camera FPS drops suddenly: exposure, USB link, bandwidth, and two cameras on one controller move the limit to host buffers: two USB3 cameras at full resolution stream: raise the host USB buffer. The mechanics of throughput against link speed and queuing are set out in a piece on USB camera throughput and queuing.

The camera class this arithmetic describes - 12 MP, 4000 × 3000, 30 fps, USB3:

Frame rate scales the same way: 3.1 MB × 120 fps ≈ 372 MB/s, again SuperSpeed-only. The board camera specified for exactly that rate (3.1 MP, global shutter, 120 fps):

Why no driver can restore the missing formats

The format list is not a setting. It lives in the descriptors the camera enumerates with, and a dual-mode module exposes a different list depending on which path came up. No driver, registry edit or application preference can add a format the current descriptor does not declare, which is why every capture app shows the same 1280 × 720 ceiling. Fix the link and the formats reappear on their own; they were never lost from the camera.

Resolution limits inside acquisition software follow the same logic - what the driver reports, what the application filters - and using a USB camera in LabVIEW: drivers, VIs and resolution limits covers that side. A module that enumerates at SuperSpeed yet still lists fewer formats than its documentation needs the maker's firmware update, not a driver change.

A module of this class, bare board for building into a machine (6 MP, USB3, mono):

When to replace the module

After a certified USB 3.0 cable, a rear-board port or a powered hub, current host controller drivers, and at least one other known-good USB 3.0 host, the enumeration result decides the case:

• SuperSpeed on the other host, High-Speed only on yours: the fault is your host - port, hub or controller driver. Keep working the host side.
• High-Speed on every capable host with cables and power verified: the module's SuperSpeed path is faulty. Replace it and send the module back for exchange.
• High-Speed everywhere and every cable tried was the in-box one: buy one certified USB 3.0 cable first. It is the cheapest possible fix.

Prevent it at commissioning

1. Use cables sold as USB 3.0 with locking connectors, and keep passive runs at 3 m or less; the practical numbers for longer runs are in USB cable length limits for 3D cameras: keeping the data link alive.
2. Record the negotiated speed (SuperSpeed, 5 Gbps) at commissioning, so a regression after a driver or OS update is obvious the day it happens.
3. Give each camera its own host port or a slot on a powered hub, and hold the 900 mA per-port budget as devices are added.
4. Re-read the negotiated speed after every OS or driver update.
5. For bare-board designs, confirm the module's connector is the 10-contact USB 3.0 type before the housing is laid out.

Where to go next

If you are specifying hardware rather than repairing a link, the camera finder filters by interface, resolution and shutter, and the category pages behind this guide are area scan cameras, camera cables and board-level cameras. To match camera, cable and host in one pass, start the camera configurator, or bring the layout to us through the contact page.