Camera has power but not detected: USB link checks after a cable swap

You replaced a failed cable, the camera's LED ring lights up, and the controller still reports the camera as not detected. That combination looks contradictory, but it is the signature of one specific fault: power reaches the camera while the data lines carry nothing. This guide is for engineers bringing a USB 3 machine-vision camera back after a cable swap. You will map what the host shows to which conductor failed, size the replacement against the passive-cable length limit, prove the port and the camera with a one-device-at-a-time test, and decide when the fault is genuinely in the camera.

Why the LED can glow on a dead link

A USB 3.0 camera cable carries three separate paths: a 5 V power pair (VBUS and ground), the USB 2.0 differential pair, and the SuperSpeed differential pairs that carry the 5 Gb/s data. Power and signaling fail independently. A crimp that lifted when the old lead was pulled out, a connector that is not fully seated, or a charge-only cable with no data conductors at all leaves the LED lit while the host hears nothing. The camera boots, its ring glows, and the enumeration handshake that would announce it never begins.

The power figures set the expectation for "has power": a SuperSpeed port supplies 5 V at up to 900 mA, which is 4.5 W, while a USB 2.0 port supplies 500 mA, or 2.5 W. An LED ring draws a few tens of milliamps, so a lit ring proves the 5 V conductor and little else. The verdict lives on the data pairs.

What the host shows tells you which conductor failed

Read the device list before swapping anything else — each failure state maps to a conductor:

The 480 Mb/s line is the trap. A camera falls back to the USB 2.0 pair when the SuperSpeed pairs are broken, so "it appears, so the cable is fine" is wrong exactly when the cable is half dead. Do not move on to software until the device lists at 5000 Mb/s.

The passive length limit for USB 3 cables

Engineered limits for passive copper, by generation: USB 3.0 (renamed USB 3.2 Gen 1, 5 Gb/s) is good for 2–3 m, USB 3.2 Gen 2 (10 Gb/s) for about 3 m, and USB 2.0 (480 Mb/s) for around 5 m. The standards set no hard maximum — the USB 3.0 standard summary records that the specification requires electrical compliance rather than a length figure — which is why a longer passive cable sometimes works and sometimes corrupts frames. Design to 3 m for a passive SuperSpeed camera run; every mention of a "rated" cable below means a USB 3.0-marked cable at or under that length.

Beyond that length, go active-optical or change interface: GigE area scan cameras cover 100 m on one cable when the run is genuinely long, and USB cable length limits for 3D cameras works through the per-generation trade-offs in practice.

For a camera run, the replacement should be built for the job from the start:

The LS-CBL-0219 is a 3 m USB3.0 camera cable with high-flex, drag-chain construction — the class of cable that survives a moving axis as well as a static bench. Keep one rated spare per camera in the drawer; the camera cables category filters by length and interface.

Isolate it: one camera, one cable, one port at a time

1. Strip the chain. Connect the camera alone to a PC's rear motherboard port — no hub, no other devices on that controller. A wrist camera is tested on the bench, never on a live robot.
2. Use a rated cable. USB 3.0 (3.2 Gen 1) marked, at or under the passive limit set above. If the suspect new cable is the only one at hand, this step is the whole test — an unrated replacement is the most common cause of this symptom.
3. Watch the list while plugging in. Device Manager on Windows, lsusb on Linux: refresh it as the connector goes in. The table above then gives a conductor-level verdict instead of a guess.
4. Prove the port. Put a known SuperSpeed device — a USB 3 flash drive is enough — into the port under test and confirm it negotiates 5000 Mb/s. Depth cameras fail this way too; a 3D camera USB troubleshooting walkthrough follows the same port-and-cable order.
5. Prove the camera. Repeat on a second host. A camera invisible on a rated cable, on a proven port, on two hosts has a damaged USB port — whatever killed the first cable often travels through the connector during the short.
6. Read the negotiated speed. 5000 Mb/s closes the hardware case; 480 Mb/s sends you back to step 2.

Worked example: a 4000 × 3000 USB3 camera at 30 fps

Inputs, each with its source (MB = megabytes, Mb = megabits):

• Resolution 4000 × 3000 px (12 MP), frame rate 30 fps, interface USB3 — the listing of the LS-CMR-0166, a 12 MP USB3 area scan camera.
• Bytes per pixel: 1 B, an 8-bit mono stream (assumption — 8-bit color carries the same payload; 10- and 12-bit scale it by 10/8 and 12/8).
• Line rate 5 Gb/s, the USB 3.2 Gen 1 rate from the generation table above; usable bulk payload about 400 MB/s (estimate: the coded line carries 500 MB/s and protocol overhead keeps roughly 80 percent).
• Fallback line rate 480 Mb/s (USB 2.0); usable bulk payload about 40 MB/s, on the same basis.

Rule: the link carries the stream only while the stream rate stays under the usable payload.

Arithmetic:

• 4000 × 3000 = 12,000,000 px per frame
• 12,000,000 px × 1 B = 12 MB per frame
• 12 MB × 30 fps = 360 MB/s, which is 2.88 Gb/s of the 5 Gb/s line
• margin = 400 MB/s ÷ 360 MB/s ≈ 1.11, about 11 percent
• On the USB 2.0 fallback: 40 MB/s ÷ 12 MB per frame ≈ 3.3, so about 3 fps

Decision: on a healthy rated cable within the passive limit the stream fits with about 11 percent headroom. This camera needs a true SuperSpeed link, not one that mostly works.

The signature cuts both ways. A camera that enumerates and then delivers about 3 fps at full resolution is running on the USB 2.0 pair — the SuperSpeed pairs are open, so replace the cable or remove the USB 2.0 hub in the path. At 12-bit the payload rises by half, to 18 MB per frame and 540 MB/s, beyond the roughly 400 MB/s a Gen 1 link delivers; cut the frame rate to about 22 fps or drop the bit depth.

Keep a compact USB3 camera on the bench as a reference device for tests like this:

For a lighter known-good load, run a 6 MP USB3 mono camera on the same port: 3000 × 2000 px × 30 fps × 1 B = 180 MB/s, a margin of roughly 2.2 times on the 400 MB/s link — a useful second load when a port needs proving without saturating it.

When the data path is fine: power budget and host faults

A device listed at 5000 Mb/s with a full-rate stream has a healthy link; what remains is power and software. A bus-powered camera owns a whole port's budget — 4.5 W at 5 V, 900 mA — and an unpowered hub in the path shrinks that budget to zero. Several cameras on one controller share power and bandwidth too, which we budget in multiple USB cameras on one host: bandwidth and power budget.

Two more host-side signatures are worth naming. A camera that died after a wiring short elsewhere in the machine may be held off by latched port protection; isolate and re-power the host cleanly as the camera-fault-after-a-short guide sets out. A link that dies mid-run rather than refusing to enumerate is a different animal — the camera-disappears-after-a-capture-crash guide covers the recovery side. And a camera that enumerates correctly but stays invisible to your SDK has moved from hardware to software; the lsusb-versus-SDK checklist walks that split.

On a robot wrist, flexing kills the cable first

The field version of this failure is a camera on a moving wrist or sliding axis whose cable flexes every cycle. Cable rated for static benches cracks its conductors at the strain relief after a few thousand cycles, and the first casualty is usually a signaling pair — which produces exactly this symptom: powered, glowing, never detected. Replace with drag-chain-rated high-flex cable, leave a service loop so the flex lands inside the cable's rated bend radius rather than at the connector, and clamp the cable so motion bends the cable, not the connector.

Wrist cameras that pair to their controller through a USB dongle fail the same way as cabled ones, and a wrist camera USB not-detected walkthrough works the pairing side of that fault.

The checks before you blame the camera

• Rated cable at or under the passive limit. An unrated or USB 2.0-only replacement is the most common cause after a swap.
• Direct host port, hub removed. Takes power-sharing and fallback hops out of the equation.
• Port proven. A second SuperSpeed device negotiates 5000 Mb/s on the same port.
• Second host tried. Separates "camera dead" from "this machine's port or driver stack".
• Negotiated speed read. 5000 Mb/s expected; 480 Mb/s means the SuperSpeed pairs are still open.
• Full-resolution stream opened. Enumeration proves little; a stream at the listed frame rate proves sustained throughput.
• Power budget counted. One bus-powered camera draws on the port's full 4.5 W (900 mA at 5 V); a hub in the path may not pass it on.

All seven pass and the host still lists nothing: the camera's USB port is damaged. Arrange service or replacement through the contact page.

The decision, case by case

• Nothing listed anywhere — rated cable, proven ports, two hosts. The camera port is damaged; service or replace it.
• Suspect cable lists nothing, rated cable lists 5000 Mb/s. The new cable was the fault — unrated, charge-only, or over length. Bin it and stock rated spares.
• Listed at 480 Mb/s. The SuperSpeed pairs are open — a USB 2.0-only cable or a lifted crimp. Replace with a rated cable within the passive length limit.
• Listed as an unknown device. A marginal USB 2.0 pair — re-seat, clean the contacts, shorten the run.
• Listed at 5000 Mb/s with the listed frame rate, but the SDK finds nothing. Software side; the lsusb-versus-SDK checklist above is the next read.
• Bench PC sees it, the robot controller does not. Controller port, its power budget, or its driver stack — test another SuperSpeed device on that controller port before ordering anything.

If you are equipping the bench for these tests, the accessories finder filters camera cables by interface and length, and the system configurator assembles cable, camera and controller in one pass. More host-and-link fault guides sit on the systems topic page.