Camera randomly disconnects while running: bus-level checks

A camera that runs for an hour and then vanishes — gone from the device list and the SDK, back the moment you replug, no reboot needed — is not an imaging problem. The sensor, the exposure and the driver are healthy; the bus has dropped the device. This guide is for anyone wiring USB, legacy FireWire or GigE cameras into a machine, rig or test bench. You will read the failure signature to narrow the fault, test the three bus-level causes in order of likelihood — cable, power budget, suspend — fix the one you find, and prove the repair with a 48-hour soak test instead of waiting for the next unexplained drop.

What the failure signature tells you

A replug-only recovery is the strongest clue you have. The enumeration was lost at the bus, not in the software stack, so the fault lives in the cable, the port power or the power management — in that order most of the time. Score your symptom against this table before touching anything, because it decides which section to read first.

The causes, most common first

In practice the causes rank this way, most common first. Work down the list; each section below gives the test and the fix.

1. A marginal cable or connector. Over-long or low-grade cable, friction-fit connectors, or a data cable fatigued by months on a moving axis.
2. An exhausted bus power budget. Cameras sharing one unpowered hub, or a port whose allowance is already spoken for by its neighbours.
3. OS suspend. Windows selective suspend or Linux autosuspend idling a port your acquisition still needs.
4. A shared or failing host controller. Several cameras on one controller chip, or a controller that resets when a load switches on.
5. The camera itself. A failing internal converter or a loose power input — the least common, and the last to test.

Cable and connector faults: test and fix

Start here because the checks cost nothing. Signal strength and supply voltage both dissipate along a copper run, and an over-long cable is a classic route to a camera that vanishes mid-run. The limits to design against:

• USB 2.0: 5 m maximum for a passive cable segment.
• USB 3.0: about 3 m for passive copper.
• FireWire (IEEE 1394): 4.5 m per copper cable, per the FireWire (IEEE 1394) reference; longer runs need repeaters.
• GigE: 100 m per Ethernet segment — a GigE fault usually shows as a stalled stream rather than a vanished device, and the network camera reachability checklist covers that side.

Length is only half of it. A connector held in by friction alone will run all morning on the bench and drop on the machine, where vibration and thermal movement are part of the day. Run the acquisition, then press the cable gently sideways at each connector: a drop that follows the wiggle is found. Confirm the cable with the swap test — if the drops follow it onto another host, it is proven. The USB connect-disconnect cable fix and the power-but-not-detected link checks walk both tests step by step.

Bench the replacement short and clamped. For a GigE camera the fix is a 3 m high-flex cable with screw locks:

For a USB3 camera the same logic applies, with the drag-chain jacket carrying the flex:

Screw locks matter more than jacket grade: an RJ45 that clicks but does not clamp survives the bench and fails on the machine. Both leads above are high-flex and rated for drag-chain duty, which is what a moving axis needs; a fixed-installation cable opens under continuous flexing.

Power budget faults: test and fix

A USB port is a power supply with a contract. USB 2.0 guarantees 5 V at up to 500 mA — 2.5 W. USB 3.0 raises the allowance to 900 mA — 4.5 W. An unpowered hub holds nothing of its own: everything plugged into it shares the single upstream port's allowance.

Worked example — two USB3 cameras on one unpowered hub. Each camera may draw up to 900 mA, so the pair wants 2 × 900 = 1,800 mA. The upstream port supplies 900 mA. The deficit, 1,800 - 900 = 900 mA or 4.5 W, appears the instant both streams open: one or both cameras brown out, drop off the bus and return on replug. The sensor, the driver and the cable quality are all innocent.

The test takes two minutes: move each camera to its own root-hub port. If the drops stop, you had a budget fault, and the permanent fix is to take the camera off the bus-power contract.

The cable itself also spends voltage. With the 28 AWG power pair many cables use — about 0.21 Ω per conductor per metre — a 5 m run at the full USB 2.0 budget works out as:

3.9 V sits below the 4.4 V floor the USB 2.0 specification allows a device to receive, so the converter inside the camera cuts out under load. That arithmetic is the classic pattern: the camera enumerates cleanly, then disconnects the instant exposure or a strobe pulse raises the current.

Put the power path on its own connector so vibration loads the latch on the power lead, not the data link. Most industrial area scan cameras take power on a separate connector beside the data cable:

Feed that rail from an enclosed industrial supply rather than a multi-way wall adapter:

The LRS-75-48 is rated 48 V and 76.8 W. Through a step-down converter at about 90% efficiency that is 76.8 × 0.9 ≈ 69 W, so roughly 69 ÷ 12 ≈ 5.7 A at 12 V — enough to run a camera chain and its lights with the bus carrying data only. Where a camera accepts USB power alone, a powered hub fed by its own supply is the next best. The USB versus external power trade-off and the continuous-shooting external power guide lay out the routing options, and the IR-stream power budget failure shows the same brown-out signature on a 3D camera.

Suspend and power management: test and fix

Windows ships balanced for battery life, not for an unattended camera, and two settings undo it:

• USB selective suspend: the OS may park an idle USB device on its own. In Power Options → advanced power settings → USB settings → USB selective suspend setting, set it to Disabled on the power plan the machine actually runs.
• Root-hub power-down: in Device Manager, under Universal Serial Bus controllers, open each USB Root Hub's Power Management tab and untick 'Allow the computer to turn off this device to save power'.

On Linux the equivalent is runtime autosuspend: write on to the camera device's power/control file while the acquisition runs.

The test is the timestamp. Suspend faults correlate with idle, so drops that cluster after quiet periods — lunch breaks, shift changes — point here rather than at the cable. The legacy FireWire bus adds its own mechanism: IEEE 1394 is cooperatively managed by the devices on it, so any topology change triggers a bus reset that interrupts every camera briefly. A two-camera 1394 rig therefore needs bus power and topology planned together — see the FireWire bus power fix and the 400 Mbps bus speed diagnosis.

Shared controllers and multi-camera hosts

One host controller chip serves several ports, and a controller that resets takes every device on it down together. The signature sits in the table above: all USB devices blip at once, keyboard included, which points upstream of the camera. Spread cameras across controllers — a desktop board usually exposes more than one — or move the long runs to GigE.

Keep the bandwidth arithmetic honest while you do it: a 12 MP camera at 30 fps and 8 bits per pixel moves 4,000 × 3,000 × 8 × 30 ≈ 2.9 Gbit/s, close to the practical ceiling of a USB 3.0 link, so one high-rate camera per controller is the sound starting point. The multi-camera bandwidth and power budget guide works the shared-bus math through, and the link bandwidth latency floor guide explains why a saturated link degrades before it dies.

The fix, in order

1. Swap the data cable for a known-good one — the shortest length that reaches, with locking connectors. This clears the most common cause in one move.
2. Give each camera its own root-hub port. If the drops stop, the fault was the power budget; make the change permanent with external power.
3. Take the camera off bus power with a separate power lead and an enclosed supply, so exposure and strobe current spikes never sag the bus.
4. Disable USB selective suspend and root-hub power-down on the deployed machine image, not only on your bench profile.
5. Spread cameras across host controllers where the host offers more than one.
6. Soak-test before sign-off — the next section sets the bar.

Prove it with a soak test

Run the rig unattended for 48 hours before you call the fix done — a weekend covers it — and a full production week on a line that runs around the clock. Instrument it: log every device-removal event with a timestamp from your acquisition code, and read the Windows event log for USB errors next to your own record. The pass bar is zero unplanned removals. A single drop means the cause is still in the machine: a soak test that drops once is a test that found the fault, not a near-pass.

Prevent it on the next machine

• Locking connectors on every camera port. Friction fits are the root of most intermittents; screws or bayonets remove the failure mode.
• Drag-chain-rated cable on anything that moves. Fixed-installation cable opens under continuous flexing.
• External power for every camera that runs all day. Bus power is for bench experiments, not production shifts.
• One high-rate camera per host controller. The 2.9 Gbit/s arithmetic above is the reason.
• Suspend settings off in the deployed image, so a software update or a new power plan cannot reintroduce the fault.
• A spare locking cable on the shelf, so the swap test is only ever minutes away.

When it is not a disconnect

If the camera stays in the device list while the image freezes or the frame rate halves, the link is up and something else is wrong: exposure overrun, trigger wiring or bandwidth — the sudden frame-rate drop diagnosis sorts those by symptom. A board-level camera on a ribbon or FFC has its own connector and length rules: the ribbon cable replacement guide covers the latch, and the FFC swap test shows how to isolate a suspect flex. And if you have been replugging the same camera every day for a month, stop: the fault is not transient, it is waiting for a fixture. Order the locking cable, make the power change, turn the suspend settings off, soak it, and sign the machine off.

What to do next

Measure the cable run, count the cameras per host controller and check whether the camera accepts a separate power lead — those three answers decide the parts. The cameras finder and the camera configurator narrow the camera side, the camera cables category holds the locking data leads, the power supplies category covers the enclosed rail, and the area scan cameras category is where a replacement search starts if the swap test lands on the camera. Send us the drop pattern through the contact page if you want it checked before you order, and the neighbouring faults live under the cameras topic.