USB camera connects then disconnects: fix the cable and link

The pattern is maddening and familiar: you plug in a USB camera, lsusb lists it, the kernel registers its video interfaces, and seconds later the device is gone — then it comes back, and goes again. Nothing in your acquisition code is wrong, because the camera never stays up long enough to open a stream. If you are wiring a USB 3 camera — most often a depth or 3D sensor — to a Linux host, an embedded board or an industrial controller, the checks below find the faulty stage in minutes: read the kernel signature, swap the cable, then work through port, power and host power management in that order.

Why does my USB camera connect and then disconnect seconds later?

When a camera enumerates, registers its video interfaces and then vanishes within seconds — usually in a repeating loop — the fault sits in the physical link or the port's power delivery, not in the camera's sensor or your software. That cycle of enumerate, register, drop and repeat is the host renegotiating a link it cannot hold, and it is the opposite fault from a camera that never appears at all: if lsusb shows nothing and there is no /dev/video* node, follow the never-detected checks in camera has power but not detected: USB link checks instead.

For the loop, four causes cover nearly every case, in this order:

1. The cable and its connectors.
2. The port and its wiring — front-panel header, hub hop, USB 2.0-only socket.
3. The port's power delivery — unpowered hub, shared budget.
4. Host USB power management — autosuspend, selective suspend.

The camera itself sits last because a device that enumerates cleanly has already proved its firmware boots and its data path carries traffic; the fault lives in everything around it.

What does the connect-disconnect loop look like in dmesg?

The signature is a repeating block of kernel lines in which the device number climbs by one on every pass, ending with the controller's own diagnosis: Cannot enable. Maybe the USB cable is bad? Capture the log while the camera misbehaves — dmesg on Linux — and look for this block:

usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
uvcvideo: Found UVC 1.10 device
input: <camera> as /devices/.../input/input7
usb 2-1: USB disconnect, device number 2
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
usb 2-1: new SuperSpeed USB device number 3 using xhci_hcd

Three details tell you everything. The device number increments on every pass — 2, then 3, then 4 — because each drop is a full re-enumeration, while a link that has held since boot keeps one number forever. The uvcvideo lines show the video interfaces registering before the drop, which proves the data pairs carried traffic and the firmware booted. The closing line is the hub driver's verdict: the port would not come back up, and the kernel names the cable first.

Lines reading xhci_hcd ... port 0 resume PLC timeout scattered before the attempts belong to the power-management cause below. A mid-stream read error ending in -71 is a different signature — the device stays enumerated while transfers fail — and has its own walkthrough in diagnosing -71 in dmesg.

Is the cable really the most likely cause?

Yes — start there, because SuperSpeed signalling puts a full 5 Gbit/s on thin twisted pairs with almost no timing margin, and a cable that is marginal at USB 3 speeds produces exactly this enumerate-then-drop loop while still working at USB 2 speeds. A kinked jacket, a crushed section, a worn latch or simple age shifts the impedance far enough that link training fails after a few seconds of traffic. A charge-only cable, by contrast, would never enumerate at all — so the fact that yours appears means its data pairs exist but are marginal: thin gauge, a damaged shield or a loose crimp.

The test takes two minutes. Swap in a short, shielded USB 3 cable — 1 to 3 m — plugged straight into the host, then watch the log while you gently flex the connector at both ends. If the loop stops and stays stopped, you have your answer. If drops appear only while you flex, the conductors are intermittent and the cable goes in the bin. Test with one continuous lead; extensions and adapter stacks each add an impedance break and a latch to work loose.

For a machine that has to run all day, fit a cable specified for the job. Our LS-CBL-0219 is a 3 m USB3.0 camera cable with a high-flex, drag-chain-rated jacket, built for repeated motion on robots and gantries.

Keep the run short: passive USB 3.x copper is assured to 3 m, and past roughly 5 m this loop tends to return on thin cables. The length arithmetic is in USB cable length limits for 3D cameras, and the cable finder filters camera data cables by length, connector and flex rating.

Could the port or the host controller be at fault?

It can be: the two most common host-side faults are a port wired for USB 2.0 only — front-panel headers and unpowered hubs — and a host-controller driver or power setting that drops the SuperSpeed link. Rear motherboard sockets are wired to the board with short, controlled traces; front-panel headers run through unshielded leads inside the chassis, and a camera that loops on a front socket is often stable on a rear one, which is the diagnosis in itself.

If the device enumerates but at 480 Mbit/s, the link is up and the bandwidth is not, and an oversized stream stalls it. Here is the arithmetic for an illustrative depth-camera mode of 848 × 480 pixels at 30 frames per second:

• depth, 16 bit: 848 × 480 px × 2 B × 30 /s = 24.4 MB/s
• colour, 8-bit RGB: 848 × 480 px × 3 B × 30 /s = 36.6 MB/s
• both together: 61.1 MB/s, before any third stream

USB 2.0 supplies 480 Mbit/s ÷ 8 = 60 MB/s of raw rate — roughly 40 MB/s usable after protocol overhead — so a 61.1 MB/s load does not fit, the stream stalls and the device can drop. USB 3.0 supplies 5 Gbit/s ÷ 8 = 625 MB/s, which carries the same load with room to spare. Why a camera lands on the slow mode, and the fixes, are in camera enumerates as USB 2.0 on a USB 3.0 port.

Finish the host check with the controller software: fit the current host-controller driver for your board from its vendor, then re-test. A host that still loops with a new cable, a rear socket and a current driver has moved the suspicion to power or power management.

How much power does the camera actually need?

A USB 3.0 port guarantees 5 V at 0.9 A — 4.5 W — while an unpowered hub splits that same 900 mA across every downstream socket, so a multi-sensor depth camera that draws more than its share enumerates on the low-current handshake and drops the moment its sensors power up. Enumeration hides the problem: an unconfigured device may draw only a single unit load of 150 mA, so the handshake succeeds even where full operation cannot.

An unpowered hub adds no power; it forwards its single upstream budget to every socket. Take one hub on a 900 mA upstream port feeding four cameras that each draw up to 500 mA — an illustrative rating at the classic USB 2.0 maximum. Demand: 4 × 500 mA = 2000 mA. Supply: 900 mA. Deficit: 1100 mA — the voltage sags, and every camera drops in a loop.

The fix is per-port power. A powered USB 3 hub gives each socket its own 900 mA; a camera with an external 5 V input should take it. On any shared port, keep at least 225 mA — a quarter of the 900 mA budget — unused. The full sizing method for multi-camera hosts is in multiple USB cameras on one host, and the trade-offs between bus and external power in camera power: USB vs external 5 V.

Does USB power management cause the drop?

It can: the host controller powers idle USB ports down to save energy, and the kernel line 'port 0 resume PLC timeout' means the controller timed out waiting for a port to come back from one of those low-power states, which points at link training rather than the data conductors. Drops that cluster after idle periods — the camera stable while streaming, then gone after a pause — fit this cause.

For the test, disable suspend for USB devices: the selective-suspend option in the OS power settings on a desktop, or the kernel's per-device autosuspend controls on Linux. Cold-boot and re-test. Resume bugs in controller firmware are a classic source of these timeout lines, so fit the current driver or firmware from the board vendor as well. A production machine gets a standing setting, not a test hack: disable USB suspend in the power plan, and check it again after OS updates, which like to turn it back on.

When is it the camera after all?

Blame the camera only when the same loop follows it to a second computer with a new cable in a direct motherboard port; the likely faults are then a worn socket, a broken wire in the camera's tail or a failed internal regulator. Run the differential one change at a time:

1. Stable on the second computer with the same new cable — the host is at fault; go back over rear sockets, the controller driver and power management on the machine that loops.
2. Loops on every host with the new cable — inspect the camera's socket under good light for a bent or pushed-in pin, and flex the tail where the cable enters the housing while watching the log.
3. Never appears anywhere — that is the never-detected case, not this one; follow camera shows in lsusb but no video device.

A camera that loops everywhere with a known-good cable has an internal fault — a cracked socket joint or a failed regulator — and needs service, not configuration.

How do I keep the link stable for good?

Fix it once with hardware choices, not settings: a short, shielded, drag-chain-rated USB 3 cable with a locked connector, a direct motherboard port, a power budget with at least 25% headroom and no unpowered hubs in the final build. The list, with the reason each item matters:

• One continuous shielded USB 3 cable, 3 m or shorter — vibration works plain latches loose, so use a locking connector where the camera offers one.
• A direct rear motherboard port, or a powered USB 3 hub when ports run short.
• At least 25% headroom on any shared power budget.
• A drag-chain-rated cable with strain relief on any moving axis.
• USB suspend disabled in the production power plan.

The acceptance test is quiet: stream the camera for a full shift and confirm the device number in the log has not incremented since boot. For a new station, match cable to camera and host in one pass:

More USB link walkthroughs sit on the systems topic page. If a log still will not give up its fault, send the capture through the contact page and we will read it line by line.