A rig with six cameras on three hubs, one of them missing from the SDK's device list after every cold boot, is not haunted: it has run past what one USB controller channel can enumerate and feed. This guide gives you the two budgets that set a safe camera count — streaming payload and power. You get the arithmetic, a worked example at 1080p30, the reboot test that separates a bandwidth ceiling from an enumeration fault, and a decision ladder: shrink the payload, split the channels, or move cameras to GigE.
How many USB cameras can one controller run before it drops one?
Budget it, do not count it: one USB 3.0 / 3.1 Gen 1 controller channel moves about 400 MB/s of real payload, and with 20 percent headroom your combined streams must stay under roughly 320 MB/s — three to five typical HD cameras, or one high-speed camera.
The number comes from the link rate. USB 3.0 / 3.1 Gen 1 signals at 5 Gbit/s, and 8b/10b encoding leaves 4 Gbit/s — 500 MB/s — for data. Hosts and cameras in practice sustain 350-450 MB/s of bulk payload, so 400 MB/s is the design value and 320 MB/s is what remains once you hold 20 percent for overhead, spikes and the camera you will add later.
There is no fixed camera count because payload per camera spans a factor of more than twenty. A 720p stream at 15 fps costs 13.8 MB/s; a 12 MP camera at 30 fps costs 360 MB/s. The count is the budget divided by your own streams, nothing more.
Timing tells you which limit you have hit. A camera that disappears the moment a stream opens is the budget closing. A camera missing at boot, before any stream runs, is an enumeration or power fault, and it needs the different fix described below.
Why does a hub add ports but no bandwidth?
A hub multiplies connectors onto one upstream link. Its seven downstream ports share the same 5 Gbit/s channel and the same enumeration path, so a seven-port hub gives you seven sockets, not seven channels.
Every byte any camera sends crosses that single upstream link, and three cascaded hubs still total one pipe. The USB3 hub bandwidth math for multiple cameras lands on the same 400 MB/s whether the camera sits on a root port or the seventh slot of a third hub. Enumeration is serialized too: the host walks the tree and brings devices up in turn, and each hub level adds a stage to that walk.
So a hub solves the shortage of connectors and silently fails to solve the shortage of channel. A rig that streams three cameras cleanly and still loses one at boot is showing that second problem, not the first.
How much bandwidth does each camera actually need?
Multiply the frame: width × height × bytes per pixel × frame rate. A 1920 × 1080, 8-bit mono stream at 30 fps costs 62.2 MB/s, so five fit one channel on paper and four fit it with the 20 percent headroom.
Worked example at 1080p30, mono 8-bit. The frame is 1920 × 1080 = 2,073,600 px, and 1 byte per pixel makes it 2.07 MB. At 30 fps the stream is 2.07 × 30 = 62.2 MB/s, or 498 Mbit/s. Six cameras draw 62.2 × 6 = 373 MB/s, past the 400 MB/s ceiling once packet overhead lands — the sixth stream is the one that fails. Five draw 311 MB/s: inside 400 but over the 320 headroom figure. Cut the frame rate to 24 fps and each camera costs 2.07 × 24 = 49.7 MB/s, so five cameras draw 249 MB/s and the budget closes with margin. Colour triples the bytes per pixel: 186.6 MB/s per camera at 1080p30, where one leaves margin and two fit only by giving up the headroom.
The same division works from a data sheet. The LS-BCM-0003 is a USB3 board-level camera with a 3.1 MP global-shutter sensor rated at 120 fps. At full rate in 8-bit mono its stream is roughly 3.1 Mpx × 120 fps × 1 byte ≈ 372 MB/s — most of a channel in one camera — so it wants a port of its own. The MV-CB060-10UM-B is a 6 MP USB3 board camera with a mono sensor. Run it at 15 fps in 8-bit and it moves about 90 MB/s: three such cameras draw 270 MB/s and sit inside 320 with margin, four draw 360 MB/s and break the headroom budget.
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Sensor format
- 1/1.8"
- Interface
- USB3
Why do cameras show in lsusb but vanish from the SDK after a reboot?
lsusb and the SDK answer different questions. lsusb reports whatever enumerated on the bus; the SDK then scans that list and claims devices, so a camera that enumerated late, woke on a late hub or fell back to USB 2 shows in one and not the other.
Two checks separate the failure modes. First, read the speed from the USB tree with lsusb -t: every camera line should read 5000M, and a 480M line means the port negotiated USB 2, where real payload tops out near 40 MB/s and a 62 MB/s stream cannot exist at all. The why lsusb -t shows 480M walkthrough covers that fallback in detail.
Second, cold-boot twice and compare the SDK device list each time. A missing camera that moves — number four today, number two tomorrow — is an enumeration or power fault; a camera that drops at the same moment every run, when the last stream opens, is the payload budget. If enumeration is the suspect, shorten the tree first: cameras on root ports or one hub level deep, a powered hub on that one level, then staggered stream starts so each camera reports ready before the next opens. The device-list diagnosis and the enumeration checklist pick up the host-side steps from there.
How much power can the bus give each camera?
A USB 3 port guarantees 900 mA at 5 V — 4.5 W — and an unpowered hub must ration that single upstream allocation across all its ports. Past two bus-powered cameras, plan a powered hub that gives each port its own 900 mA.
Power faults look like enumeration faults because a camera that browns out while six devices power up together vanishes from the scan, and which one vanishes moves between boots. A utility such as uhubctl reports per-port power state, and an externally powered hub takes the whole question off the table. Power was not the culprit in a rig whose hubs were already powered and still lost cameras — that signature points back to the shared channel. Intermittent drops that follow a flexed or moving cable are wiring, not bandwidth: the LS-CBL-0219 is a 3 m USB3.0 high-flex camera cable built for drag-chain duty, and a stiff cable bent hard at its connector is a classic dropout source. For the detection traps after a cable swap, the power-but-not-detected checks apply.
What do you change first: settings, wiring, or the interface?
Cut the payload first, then split across real channels, then move cameras to GigE. Halving frame rate halves a stream's share of the channel, each extra controller channel adds a fresh 320 MB/s, and every GigE NIC port adds an independent 1 Gbit/s.
- Shrink the payload. Crop ROI at the sensor, bin pixels, drop to 8-bit mono or lower fps; the source-side ROI guide and the per-camera bandwidth math show the levers and their savings.
- Find the real channels. Boards group physical ports onto shared channels, and the technical reference lists the mapping; moving one camera to a port on a different channel doubles what the rig can carry.
- Add a channel. On a host with a free slot, a USB controller card brings its own 400 MB/s and its own enumeration path, independent of the built-in one.
- Move cameras to GigE. Every NIC port is an independent 1 Gbit/s, with power available over the same cable through a PoE switch; the two-cameras-one-host port plan shows the budget. Area scan cameras can be filtered by GigE interface when you shortlist.
The decision per case: combined payload under 320 MB/s means one channel and a powered hub, done. Over budget with shrinkable payloads means cut fps or ROI until the sum sits under 320. Payload fixed and over budget means a second channel, or GigE for everything past the first two streams. Budget fine but boots still miss cameras means fix power and hub depth, not bandwidth.
What do you check before adding camera number four?
Run the arithmetic, then prove the topology: every stream's payload summed under 320 MB/s, each camera at its rated speed in the USB tree, power from a powered hub, and a complete SDK device list across two cold reboots.
- Budget: each camera's width × height × bytes × fps computed, the sum compared against 320 MB/s, with 400 MB/s as the hard wall.
- Topology: one hub level maximum, and the heaviest camera on a root port where the board offers one.
- Speed: lsusb -t shows no 480M line for any camera.
- Power: externally powered hub, 900 mA available per port, no camera sharing a slim host-port supply.
- Stability: two cold reboots with the full device list, then one full streaming session with no camera lost.
- Cabling: passive camera cables kept near 3 m, connectors reseated, nothing under tension.
When the count refuses to fit, the answer is interface, not stubbornness. Shortlist cameras by interface and resolution in the camera finder, skim the systems topic page for the neighbouring bandwidth guides, and assemble the whole chain in the configurator below. The bandwidth and power budget for multiple USB cameras on one host goes deeper on the host-side power split.
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
Questions
Does a USB 3.2 Gen 2 controller double the camera count?
Mostly yes. Gen 2 doubles the line rate to 10 Gbit/s and switches to 128b/132b encoding, so real payload lands near 850-950 MB/s instead of 400 MB/s; design to 800 MB/s and keep the same 20 percent headroom. Check the board wiring first: if two ports share one channel, the doubling applies to the channel, not to each port.
Do I need a separate USB controller for every camera?
No. One controller serves several cameras when the payload sum fits the 320 MB/s budget with headroom. What you should not share is a channel between stations that must never interfere: give each independent cell its own controller channel so a reboot or a fault on one rig cannot stall the stream of another.
How many cameras fit on one channel at 720p and 30 fps?
About eight to ten. One 1280 × 720, 8-bit mono stream at 30 fps is 921,600 px × 30 = 27.6 MB/s, and 320 ÷ 27.6 ≈ 11 on paper. Plan eight to ten, because hubs, power-up order and per-device overhead eat the rest, then prove the count with two cold reboots before you freeze the design.
Do USB cameras reserve bandwidth before their stream starts?
Almost nothing. A camera that has enumerated but is not streaming reserves no payload bandwidth; the reservation is granted when the host opens its streaming interface. That is why a six-camera rig can boot with a complete device list and then drop one camera the moment the last stream opens: the reservation for it cannot be granted.
Can USB and GigE cameras share one host?
Yes, and it is often the cheapest fix for an over-budget USB channel. Put the one or two heaviest streams on USB and the rest on a multi-port NIC, where every port is an independent 1 Gbit/s and a PoE switch carries power over the same cable. Budget each GigE port at roughly 118 MB/s of payload.
How long can a USB 3 camera cable be?
Plan on about 3 m for dependable passive copper runs; beyond that, signal integrity and the 5 V supply both fade, and disconnects start looking random. For longer runs, use an active optical USB 3 cable or change interfaces — GigE over a switch reaches 100 m per segment, which is why fixed multi-camera cells often end up on Ethernet.