USB camera not enumerating: diagnose the host path

A camera application reporting 'no device' leaves the failure layer open: cable, connector, port, controller or software stack. On Linux, lsusb settles that question in the first minute, because USB enumeration happens in the host controller before any camera driver, SDK or ROS node runs. This sequence is for Linux vision stations where a USB camera produces no usable connection after software installation. You will read the kernel log for three failure signatures, isolate cable, port and controller one variable at a time with a 3-of-3 cross-test, and check the negotiated link speed against the camera's real payload before changing any software.

Read the failure layer from lsusb and the log

Enumeration is the host detecting the device, assigning it an address and reading its descriptors. The camera's driver plays no part in that step; the port's power, the cable's data conductors and the host controller do. A camera with no entry in lsusb is therefore a connection or host fault, and reinstalling camera software is the wrong first move. Work the table top to bottom: the rows are ordered by where these faults actually sit.

The two error codes come straight from the kernel log: -110 is a connect timeout and -71 a protocol error on the bus. Resets that hold the link but corrupt images belong in USB camera signal-integrity troubleshooting; resets that drop the device entirely belong in the disconnection guide below.

Take the bus baseline

1. Stop camera viewers, acquisition services and ROS camera nodes so nothing holds the device.
2. With the camera unplugged, run lsusb and save the output.
3. Open a live kernel log:

sudo journalctl -kf

4. Connect the camera with its own data cable, directly to a host port — no dock, hub or extension.
5. Run lsusb again and compare the four-hex-digit vendor and product pair, not the human-readable name; cameras often enumerate under a name you do not expect.
6. Run lsusb -t and record the negotiated speed: 5000M is SuperSpeed, 480M is high speed.

If permission is refused, run the log under sudo; without it you are blind to connect events. Bus and device numbers change at every replug, so track the serial string instead — a USB3 Vision camera identifies itself by a serial string that starts with UV, which makes the match certain. Keep the log running across several replugs: the difference between no event, a descriptor failure and a completed enumeration is worth more than the application's final error message.

Cause 1: the cable — test it first

Cables cause most no-enumeration faults, and they fail in two quiet ways. A charge-only cable leaves every data conductor unconnected, so the host records nothing at all: USB 2.0 carries power plus one D+/D- pair, and a USB 3 Standard-A plug adds 5 SuperSpeed contacts for 9 in total — a cable built without them lights the camera but moves no data. Length is the second failure: the USB 2.0 spec allows a 5 m cable segment at 480 Mb/s, while passive SuperSpeed cables meet the Gen 1 loss budget only to about 3 m. Every extension and adapter in the path adds a connector pair that erodes that budget.

For the baseline, use one short data cable direct to the port. Then swap in a known-good cable and hold everything else constant. Keep a sealed data cable as the reference for exactly this test; the LS-CBL-0219 is that reference cable for USB camera stations.

Order replacements from the cables category or the accessory finder against the camera's socket, locking style and length class. Inspect both connector ends while you are there: bent shields, contamination and half-seated plugs all produce the same silent no-event failure, and an unsupported cable hanging off the camera receptacle works the joint loose over a shift. If the device returns for a few seconds and drops again, continue with USB camera disconnection fault isolation — one cable swap splits that symptom cleanly between a damaged cable and a marginal receptacle.

Cause 2: port power and the controller

USB 2.0 commits a port to 500 mA at 5 V, which is 2.5 W; USB 3.x raises that to 900 mA at 5 V, which is 4.5 W. A camera that draws past its port's budget browns out mid-enumeration, and the log shows it as descriptor read failures of -110 or -71 rather than as a clean absence. If the camera manual lists an external supply, use it for the baseline, and disconnect other bus-powered devices from the same path while testing.

Adjacent front-panel sockets often sit behind one internal hub, so moving one socket over tests the connector and leaves the controller unchanged. Read the lsusb -t tree and pick a port on a different controller. If every port on the machine fails with known-good devices, add a USB 3 PCIe controller for an independent path — shut the machine down and follow its service procedure for the install. Do not disable security protections or install unsigned controller drivers to force detection.

Cause 3: the link is up, but the class is wrong

A camera can enumerate at 480 Mb/s and still never deliver a frame: enumeration moves kilobytes of descriptors, while streaming moves the image payload. Estimate that payload before blaming drivers:

Here width and height are the active pixel counts, bytes_per_pixel is 1 for an 8-bit mono format, and frame_rate is in frames per second.

Compare it with the ceiling the link must carry it over:

At 69.1 MB/s, that 2.3 MP mono stream exceeds USB 2.0's 60 MB/s signaling ceiling before a byte of protocol overhead, so no driver setting will save it — that camera belongs on a SuperSpeed port. USB 3.2 Gen 1 signals at 5 Gb/s:

The 8/10 term is the 8b/10b encoding USB 3.x uses on the wire, and the result is the payload budget before protocol overhead; plan on 350-450 MB/s sustained for cameras on one Gen 1 controller. Read the negotiated speed from lsusb -t, never from connector color, and when several cameras share a host, work through multiple-camera connection-limit checks before adding hardware.

Cause 4: software, once the bus is stable

When lsusb shows the same vendor:product pair after every replug, the connection is proven and the fault sits above it. Move up in this order:

1. Open the camera in the vendor's own viewer, obtained from the manufacturer or an authorized distributor, with the automation stack stopped.
2. Accept an empty /dev/video* list for industrial USB3 cameras, which stream through a vendor acquisition stack rather than the USB video class; only UVC-class cameras must appear there.
3. Only then start the ROS stack, and check device filters, serial selection and package compatibility — a launch file cannot open what the host never enumerated.

For the integration route, follow camera acquisition software compatibility checks. A device visible to the OS but missing from the SDK is a different failure boundary: Linux SDK detection troubleshooting. Broken package configuration goes to camera driver package recovery checks, and a patched video driver that must come off goes back with video-driver rollback after patch failures rather than another layer of patches. In virtual machines, confirm host enumeration first and guest pass-through second; the guest cannot see what the host does not hand it.

The 3-of-3 cross-test

Change one variable at a time, three attempts per condition:

The numbers make the logic plain. The camera and cable fail 3 of 3 on host A and pass 3 of 3 on host B: 6 observations with camera and cable constant, so work host A's path. A USB 3 card on host A then passes 3 of 3, making 9 observations total, and the fault sits in host A's onboard path: that socket, its internal hub or its controller. Three attempts is a station screen, not a reliability qualification — size the count to the production duty cycle once the layer is known.

Fix, then prove it

Replace the part the matrix implicates, not the part named in the last error message. A cable that failed the swap becomes an order from the accessory configuration step against the camera's socket and length class; a camera that failed across two known-good cables is an RMA decision, not a repair attempt. Never reflash firmware or rework connectors to force detection.

When the camera itself is the replacement, choose from area scan cameras with the camera finder on shutter, resolution and interface, then set the shortlist with the camera configuration step.

The LS-CMR-0166 is a 12 MP USB3 area scan camera: a 1/1.7" rolling-shutter sensor, 4000 × 3000 at 30 fps over USB3.

A 4000 × 3000 mono stream at 30 fps is about 360 MB/s, so give a camera of this class a dedicated Gen 1 port rather than a hub shared with drives.

Prove the repair before the station goes back:

• The same vendor:product pair appears after each replug and after a full power cycle.
• lsusb -t reports the negotiated speed the stream needs: 5000M for a Gen 1 camera.
• A full shift of running adds no descriptor errors, resets or reconnects to the log.
• The vendor viewer opens, then the full stack, then the production stream settings, in that order.
• Other devices go back one at a time, with the camera rechecked after each.
• The record names the final cable, port, topology, software versions and attempts per condition.

If the failing layer is still open after the matrix, send the lsusb output, the lsusb -t tree and the cross-test table through application support — that package replaces another blind reinstall.