USB camera not detected: check the cable before you swap hardware

A USB camera that lights its status LED but never appears in the device list stops the cell: no images, no inspection, and the software side looks fine. The cause is usually in the cable or the port's power budget, not in the camera and not in your code. This page gives the order that finds it fastest: a two-minute cable swap, the 5 V power arithmetic for the port, then the host controller checks. You finish knowing which part to replace - cable, hub, host or camera - before you order anything.

What "not detected" means

Detection happens in two steps. First, the port powers the device over its 5 V power pin; the status LED is fed from that line. Then the host controller enumerates the device over the data pair: the operating system lists it, and your SDK finds it. "Not detected" means step two never completed. A camera can be perfectly powered and still invisible, because power and data travel on separate conductors.

Three near neighbours are different faults with different fixes. If the camera lists, streams and then drops mid-run, that is the USB camera connects then disconnects case. If it lists but runs at USB 2.0 speed, work through the camera enumerates as USB 2.0 checks instead. If it only misbehaves after a reconnect, wake it before you stream: see camera stuck in standby after reconnect.

Likely causes, most probable first

Work down the list; each cause carries its test.

1. Damaged or charge-only cable. A crushed or flexed run can keep the power conductor alive while a SuperSpeed data pair is broken, and a charge-only lead looks identical to a rated one. Test: swap in a short, known-good USB 3.0 cable (next section).
2. Run longer than a passive cable supports. Past about 3 m a passive USB 3.0 cable runs out of margin; USB 2.0 holds about 5 m. Test: try 1-3 m on the same camera.
3. Port power budget exhausted. A bus-powered hub, a front-panel socket or a port already carrying another device cannot deliver a second unit load. Test: move the camera to a rear host port, alone.
4. Host controller or driver stack. Some onboard controllers and stale driver stacks never enumerate a device a second PC lists at once. Test: same cable, same camera, second PC.
5. Connector seating or standby state. A half-seated plug powers the LED and misses the data pins. Test: reseat both ends and power-cycle the camera.
6. Camera fault. Rare, and last on the list. Test: a known-good host still sees nothing.

The swap test that settles it

1. Connect the camera to a rear host port directly, with a known-good USB 3.0 cable 1-3 m long: no hub, no extension, no front-panel socket.
2. Open the system device list - Device Manager on Windows, lsusb on Linux - and keep it open.
3. Plug the camera in and watch for ten seconds. The device should appear, and your SDK should list it on rescan.
4. It lists: stop. The old run is the fault; go to the fix section below.
5. It stays hidden: repeat on each rear port in turn. A camera that appears on one port only convicts that port or the hub behind it.
6. Hidden on every port: run the same cable and camera on a second PC. Listed there, the first machine's controller or driver stack is the suspect. Blind there too, the camera itself goes back.

For UVC-style cameras, the built-in troubleshooter adds one more check: Start > Settings > System > Troubleshoot, then Other troubleshooters.

Worked example: a USB 3.0 camera and a USB 2.0 gripper on one hub port

This is the classic robot-cell pattern: camera and accessory share one USB run, both LEDs come on, and the software lists neither. The inputs come straight from the USB 2.0 and USB 3.0 specifications:

• Host port: a USB 3.0 port supplies one unit load, 0.9 A at 5 V.
• Camera: a USB 3.0 device may draw up to 0.9 A.
• Gripper: a USB 2.0 device may draw up to 0.5 A.

The rule: a bus-powered hub passes on only the allocation it draws from its own upstream port, less its own overhead. So add the device currents, then compare the power the chain needs with the power the port can give:

The arithmetic:

• I_total = 0.9 A + 0.5 A = 1.4 A
• P_available = 5 V x 0.9 A = 4.5 W
• P_needed = 5 V x 1.4 A = 7 W
• Shortfall = 7 W - 4.5 W = 2.5 W

The chain passes only when P_needed is at most P_available. Here it fails by 2.5 W, so whichever device requests power last browns out and never enumerates - the exact "not detected" symptom, with a cable that is perfectly healthy. The fix is not a better cable: give the camera its own root port, or use a powered hub whose supply covers 0.9 A per port plus the hub's overhead.

A 12 MP, 30 fps USB3 area scan camera such as the LS-CMR-0166 is the kind of device this budget exists for:

The same arithmetic explains a related symptom: a depth camera that disconnects when the IR stream starts is usually a port running out of current, not a bad sensor.

Fix the run

If the swap test convicted the cable, rebuild the run once, properly, instead of replacing like with like:

• Length. Keep a passive USB 3.0 run at 3 m or less; USB 2.0 buys about 5 m. For longer distances, use an active or optical USB extension or move the host closer - the USB cable length limits for 3D cameras page works through the numbers.
• Rating. The replacement must be marked USB 3.0 (SuperSpeed), not charge or 2.0; read the printing on the moulding, not the colour.
• Motion. If the run crosses a moving axis, use a cable rated for drag-chain flexing, with a strain-relieved service loop at the fixed end.

The cable we reach for on moving axes:

For power, connect the camera to a rear root port or a powered hub, and keep one device per port until the budget is proven. Once the run is settled, the cable step of the configurator matches cable, length and connector to the camera.

When it is not the cable

• The host. Front-panel sockets route through thin internal cables, and add-on hubs share one controller between several sockets. Prefer the rear board ports; if several cameras share one machine, check how many USB cameras one controller can feed before adding hardware. When a machine drops links under load, the bus-level checks for a camera that randomly disconnects apply. If the host itself is the weak point, a dedicated machine with proper ports - one of the industrial mini PCs built for this duty - removes the variable.
• The driver stack. A device that lists on PC B but not PC A points at the controller driver, not the hardware: update the chipset and USB controller drivers from the board vendor before anything else.
• The camera state. Ran the swap and it still hides? The checks for a camera with power but not detected after a cable swap continue from exactly there.

Decision, case by case

More enumeration and link faults, and the fixes that follow them, are gathered on the systems topic page.

Checks before you order a replacement

• 3 m or less, passive and USB 3.0: the length a copper run holds in industrial noise. Longer means active or optical.
• SuperSpeed-rated, not charge-only: read the printing on the cable, not the colour of the moulding.
• Shielded and locking: screw-lock or snag-proof connectors so a knock cannot undo the data pair.
• Drag-chain rated if the run crosses a moving axis; a fixed-office cable will not survive the cycle count.
• The right connector for the camera - full-size USB-B, Micro-B or USB-C - matched before ordering, not at the machine.
• One spare on the shelf, labelled and tested, so the next swap test starts immediately.

Pick the replacement from the camera data and power cables category, or check the camera side in the camera finder. If a second host also stays blind, the camera is the fault: contact us and we will help you pin it down.