Camera power: USB vs external 5V, which should you use?

Two instructions collide on every small streaming camera that carries both a USB socket and a 4-pin auxiliary input: the quick-start says power it from a clean 5 V supply through the red wire, the vendor's page says USB is always required, and both sound absolute. They are not in conflict. The USB cable is the data link and stays connected whatever you decide about power; the auxiliary input decides where the current comes from, and it exists for loads a USB port was never sized for. What follows settles the argument with numbers: what each port delivers, what a camera plus servos really draw, why two supplies on one rail are a fault, and the wiring that keeps a pan-tilt rig from resetting.

Does the camera need USB power or the external 5 V input?

Both instructions are right, because they govern different wires: USB stays connected for data whatever you decide about power, and the 4-pin auxiliary input feeds loads that exceed the port's 500 mA (USB 2.0) or 900 mA (USB 3.x) budget. When a vendor page says the USB connection is always required, it is talking about the link, not the rail: video, configuration and serial-over-USB all ride that cable, and they keep riding it after the board's power moves to the 4-pin header.

The tutorial that powers the camera through the red wire of its 4-pin connector from a clean regulated supply contradicts nothing. It moves current, and the noise of everything sharing that rail, off the host port. Copy that arrangement whenever servos or lights share the machine. A camera alone, drawing roughly 0.5 A (about 2.5 W) for a small streamer, sits inside any USB 3.x port with room to spare; the moment the rail serves anything else, decide with the numbers below.

How much current can a USB port actually deliver?

Everything here is on a nominal 5 V rail. A USB 2.0 high-power port delivers 500 mA (2.5 W), a USB 3.x port 900 mA (4.5 W), and a Type-C source 1.5 A or 3 A from the level its CC pull-up advertises, before any Power Delivery negotiation starts. These limits are contracts, not wire ratings. Before a device is enumerated it may draw only 100 mA, which is why a camera that charges large input capacitors at plug-in can pull a port low and never finish enumerating. A dedicated charging port of the BC 1.2 kind offers up to 1.5 A but carries no data, so it runs nothing that must stream. Above 3 A you are inside a Power Delivery contract, which negotiates over the CC line and needs a Type-C plug at both ends.

What is the 4-pin connector for if USB stays plugged in?

The 4-pin header is the auxiliary power and I/O port: the red wire the tutorial names is the supply input, it shares ground with the board, and the other pins carry the serial link that steers the pan-tilt controller while USB streams the video. It exists because the host port was sized for the board, not for the machine around it. Powering through the header lets the camera and its load share one regulated supply you chose, over wire you chose, while the USB cable carries nothing but data.

That is also why the video keeps flowing with the 4-pin wired: the header does not replace the data link. Run the rig headless later and that same header, with its serial pins, becomes the whole interface.

Can I leave USB and the external 5 V supply connected together?

Connect both cables, but let only one source drive the rail: two supplies tied to one rail back-feed each other, and the loser is often the host's USB port, unless the vendor's wiring for your board explicitly states the inputs are combined. The plug's geometry works against you here. A USB plug's power contacts are longer than its data contacts, so VBUS mates first and signals after; that is what makes hot-plug safe, and standard USB hardware connector design is where the recessed data pins are spelled out. It also means a back-fed VBUS is live the instant the shell seats. If a board ties its 4-pin input and USB VBUS to the same rail with no ORing, whichever rail sits higher drives reverse current into the other through milliohms of trace, and the host port is usually the side that loses.

When a vendor's own tutorial wires the board exactly this way, 4-pin power while USB streams, that instruction is the authority for that board's input stage. For any board whose guide makes no such statement, one source at a time; if both connectors must stay in, break VBUS in the USB path with a data-only cable or adapter and keep ground continuous.

For the damage side of this ledger, ports, pins and power faults, camera GPIO wiring: prevent damage and triage power faults walks the checks.

How do I budget the current for camera plus servos?

Add stall currents, not idle currents: a small streaming camera near 0.5 A plus two 9 g servos at 0.7 A stalled each totals 1.9 A, or 9.5 W on the rail, more than double the 4.5 W a USB 3.x port offers. Work the rig with example values, then replace them with your measured ones: camera 0.5 A; two 9 g servos, 0.2 A moving freely and 0.7 A stalled; a 2 m servo harness.

• Camera: 0.5 A → 2.5 W
• Servos at stall: 2 × 0.7 A = 1.4 A → 7.0 W
• Total: 0.5 A + 1.4 A = 1.9 A → 9.5 W
• Camera alone on a USB 3.x port: 0.9 A − 0.5 A = 0.4 A spare, 44 % headroom

Cable drop decides the harness. At 0.084 Ω/m, a 2 m harness is a 4 m loop: 4 m × 0.084 Ω/m = 0.336 Ω. Stall current drops 1.4 A × 0.336 Ω = 0.47 V, so the servos see 5.00 V − 0.47 V = 4.53 V, below the 4.75 V floor a port is required to hold. The same loop in 20 AWG, about 0.033 Ω/m, is 4 m × 0.033 Ω/m = 0.13 Ω and drops 1.4 A × 0.13 Ω = 0.18 V, leaving 4.82 V. Servo runs get 20 AWG or heavier.

Size the supply at 150 % of the stall-sum: 9.5 W × 1.5 = 14.3 W, which a 3 A (15 W) regulated supply covers with margin. The decision for this rig is the tutorial's wiring: camera and servos fed from the clean supply through the 4-pin, USB for data, every ground tied at one point. With the camera alone, USB power carries it at 44 % headroom and the auxiliary input stays empty.

Which parts make this wiring clean?

Four parts carry the whole job: the USB data cable that stays connected, an open-end power and I/O cable for the auxiliary rail, the camera itself, and a proper supply for every rail beyond 5 V. For the data link, a drag-chain-rated USB3 camera cable such as the 3 m LS-CBL-0219 survives the bending a moving head deals out without opening the braid.

Many machine vision cameras bring auxiliary power out on a circular connector rather than a header. For that rail, a power and I/O cable such as the LS-CBL-0300, M8 8-pin male to open end, 8 cores, 7 m, drag-chain use, turns the connector into solderable leads for supply and ground.

When the streamer is a full machine vision camera, the same test applies to its port: a USB3 area scan model such as the LS-CMR-0166, 12 MP at 30 fps, streams over one link, and the arithmetic above decides whether that link also feeds it.

Lights and controllers usually run their own 12, 24 or 48 V rails. The enclosed LRS-75-48 delivers 48 V at 76.8 W.

Pick leads by connector and length in the cables category, compare sensors in area scan cameras, and filter by plug in the accessories finder. The camera rail itself comes from a clean regulated supply sized to the 150 % rule above.

What checks catch a bad power arrangement before it ships?

Three measurements catch almost every USB-versus-external-power fault: voltage at the board under full stall, current on the rail at plug-in, and continuity from host ground to supply ground, in that order.

• Measure the rail at the camera with the servos stalled. Hold above 4.75 V, the floor a USB 2.0 port must keep; anything under 4.6 V under load is the fault you were chasing.
• Watch current at plug-in. Input capacitors can pull 2-3× the running draw for milliseconds, and a port that browns out during enumeration never finishes it.
• Confirm one common ground, host, external supply, servo controller and camera, with a continuity meter. Without it, serial lines and triggers float, producing garbage characters, missed pulses and resets, the pattern camera trigger common reference: diagnose missing pulses works through.
• Camera powered but never enumerated? The fault is the data path, not the rail: camera has power but not detected: USB link checks after a cable swap is the sequence.
• Frame dies the instant a servo twitches? That is rail sag: return to the stall budget and the heavier gauge. A black frame instead of a dropped device points to the power-and-bandwidth split that depth camera black image: fix USB bandwidth and power issues covers.

Once power is clean and the link still misbehaves, troubleshooting USB faults on a robot vision camera walks that fault tree end to end.

When is USB power the wrong choice altogether?

Drop USB power the moment the rail serves more than the camera: servos, LED rings, fans, or any run past about 3 m push the port, its contacts and its thin conductors past what they are rated to carry. Distance alone rules it out on numbers: a 3 m USB cable with 24 AWG power conductors is a 6 m loop, 6 m × 0.084 Ω/m = 0.504 Ω, and even the camera's 0.5 A drops 0.5 A × 0.504 Ω = 0.25 V, so a 5.00 V port delivers 4.75 V at the board, zero margin. Unpowered hubs pool every port against one weak supply, so adding a second device sags both; USB hub drops camera frame rate: budget the bandwidth first shows that arithmetic. Transients share the physics everywhere: diagnose PoE camera illumination droop during exposure is the wire-power version of the same dip.

For a stationary machine, the robust pattern is a short USB run for data and a dedicated rail for everything that moves or lights, split exactly as budgeted above. Start the parts list in power supplies, run the configurator's camera step, read more under cameras on the learn hub, and if your numbers land between two supplies, bring the budget to us through the contact page.