Acquire from multiple USB cameras: bandwidth and sync

Three USB cameras on one host is a bandwidth and scheduling question before it is a software question. The payload decides whether the cameras can stream at all: bytes per frame times frame rate, summed across cameras, against what each USB controller sustains. Sync comes second, and it tiers cleanly: a hardware trigger if the cameras have trigger inputs, a software command if they do not, and arrival timestamps corrected for measured latency when the cameras are plain USB models with no trigger line. This guide gives the numbers for both halves, a worked example for three 720p cameras, and the checks that catch problems before anything is mounted.

The decision, up front

Sum each camera's payload, keep the total under 70% of a controller's sustained rate, and give any camera that approaches that line a controller of its own. Three 1280 × 720 8-bit cameras at 30 fps total about 83 MB/s and share one USB 3.0 controller with ease — plan on 400 MB/s sustained per controller. The same three cameras do not fit one USB 2.0 bus, whose isochronous ceiling is 24.6 MB/s and whose practical bulk throughput is about 35 MB/s.

Sync in one line: freeze the same instant with a hardware trigger; start recordings together with a software trigger; align playback of free-running cameras with arrival timestamps corrected for each camera's latency. Everything below is the arithmetic and the wiring behind those three sentences.

Budget the bus: the payload formula and the ceilings

Payload is arithmetic, not a vendor claim:

Bytes per pixel by format: 8-bit mono = 1, YUY2/YUV422 colour = 2, RGB 8-bit = 3, 12-bit packed mono = 1.5.

The ceilings, per host controller:

The 70% line exists because retries, OS scheduling and the display pipeline eat bursts on top of the average. On USB 3.0 that line is 280 MB/s per controller.

Plain UVC webcams and USB3 Vision area scan cameras obey the same payload maths. The difference is control: USB3 Vision models expose trigger lines, precise exposure control and predictable uncompressed formats, which is what the sync tiers below need. The MV-CS200-10UM is one example of the class, a 20 MP mono model on USB 3.0 with a 1" rolling-shutter sensor and a C-mount.

Worked example: three 1280 × 720 cameras at 30 fps on one host

Inputs, and where each comes from: three cameras (the case being sized), 1280 × 720 pixels at 8-bit mono, so 1 byte per pixel (the common generic-USB camera class), 30 fps per camera (the standard monitoring rate), and a desktop host with USB 3.0 ports at ≈ 400 MB/s sustained per controller. The fallback checked is USB 2.0 at 24.6 MB/s isochronous and ≈ 35 MB/s bulk.

Rule in words: payload equals pixels times bytes per pixel times frame rate, and the sum over all cameras on one controller must stay under that controller's 280 MB/s planning line (70% of 400 MB/s).

Arithmetic:

• Frame size: 1280 × 720 = 921,600 pixels → 921,600 bytes ≈ 0.92 MB per frame.
• Per camera: 0.92 MB × 30 fps = 27.6 MB/s.
• Three cameras: 3 × 27.6 MB/s = 82.9 ≈ 83 MB/s.
• Controller load: 83 ÷ 400 = 21%.

Result: 83 MB/s combined, 21% of one USB 3.0 controller. Decision: the three cameras share one controller, with 280 ÷ 83 ≈ 3.4× headroom to the planning line — this rig could nearly triple before the plan changes. On USB 2.0 the same rig fails twice over: 83 MB/s against a 24.6 MB/s isochronous ceiling, and even one camera alone (27.6 MB/s) exceeds it. USB 2.0 carries only reduced streams — 640 × 480 YUY2 at 30 fps is 18.4 MB/s per camera and fits.

Give bandwidth-heavy cameras a controller of their own

The sharing decision has a second branch. A 4000 × 3000 8-bit mono stream at 30 fps is 12,000,000 bytes per frame and 360 MB/s — 90% of one USB 3.0 controller's sustained rate and clear of the 280 MB/s planning line. The LS-CMR-0166 is a 12 MP USB 3 camera in exactly this class, rated 30 fps at 4000 × 3000. Plan it onto a dedicated controller, or cap the frame rate at 20 fps for 240 MB/s and a 60% load.

A hub adds ports, not bandwidth. Every port on a hub shares the hub's single upstream link, so three cameras on one hub hold exactly the budget they held before the hub — and one camera that misbehaves can stall the segment. That is why a hub can drop the frame rate of every camera on it. Small streams share happily: the 83 MB/s rig fits one 5 Gbit/s upstream link with room to spare.

Desktop chipsets expose several controllers, but adjacent ports often share one, and laptops route many ports through internal hubs. Two fixes: pick ports that enumerate on separate controllers (the OS device tree shows which bus each camera landed on), or add a PCIe USB 3.0 card per extra controller. Port power is the second budget, and the bandwidth and power budget for several USB cameras works both sides. The same host-side logic applies to depth cameras — see enumeration and USB bandwidth fixes for several depth cameras; the 3D sensor category lists them.

Pick the sync tier

Decide by what the frames must agree on:

• Frames must freeze the same instant — moving parts, weld pools, impact tests: hardware trigger, paired with a global shutter, because a rolling shutter still scans lines sequentially inside each frame. For moving parts the MV-CH120-11UC fits this tier: 12 MP, global shutter, USB 3.0.
• Frames must start together but need not freeze — recording sessions, review footage: software trigger from one loop.
• Cameras are plain UVC with no trigger input: arrival timestamps.
• Cameras run GigE on one network: PTP, and the trigger lines come with the interface.

For two triggered USB cameras, triggering both from one source shows the wiring, and a test that proves the sync works closes the loop. The triggered grab loop itself is the same in any SDK — acquire and save each triggered frame walks it through.

Timestamps that hold: one process, one clock, measured latency

1. Grab all cameras in one process. One process is one clock domain; separate processes stamp frames on separate clocks and must be reconciled later.
2. Stamp each frame on arrival, inside the acquisition callback, on a monotonic clock. Stamping after the processing queue adds queue time to camera time — see acquisition time versus arrival time.
3. Store the driver-reported exposure and frame timing alongside each frame where the SDK provides it.
4. Measure each camera's latency once: flash one lamp in view of all cameras while recording, then latency = arrival timestamp − flash instant. The spread between cameras is the systematic correction you apply when aligning.
5. Align playback by nearest corrected timestamp, and re-lock periodically, because free-running cameras drift. Two cameras running 30.00 and 29.97 fps sit 0.1% apart, which is one full frame of offset after 1000 frames — about 33 seconds.

The stakes are motion, not clocks. At a 250 mm/s belt speed, a 5 ms latency spread between two cameras is 5 ms × 250 mm/s = 1.25 mm of scene motion — decisive for gauging, invisible for monitoring at 33.3 ms frame periods.

When USB is the wrong interface

• Distance. Passive USB 3.0 copper cables are practical to about 3 m. A rig whose cameras sit 3-4 m from the host — the two-camera welding-cell monitoring case — is already past that. GigE runs 100 m on one copper run and brings trigger lines and PTP with it: NIC ports and bandwidth for two GigE cameras plans that host, and timed acquisition on GigE covers rate control. Active optical USB 3 cables bridge the gap when USB must stay.
• Scale. Past roughly four cameras, or a combined payload near the 280 MB/s planning line, add controllers or move to 2.5G/10GigE, where each NIC port adds budget. Rates that outrun Ethernet move to CoaXPress over a frame grabber.
• Clock sync. Only the GigE Vision stack gives PTP across cameras; USB has no equivalent. If sub-millisecond agreement matters and trigger lines are absent, changing the interface beats fighting timestamps.

Safety, one line: a camera looking into a laser welding cell is not a safety device — filter it for the weld wavelength and leave personnel protection on the interlocked cell system.

Decision: monitoring, four cameras or fewer, cable runs under 3 m, no freeze-frame requirement — USB 3.0. Distance, triggered inspection, PTP, or a growing camera count — GigE first, frame grabber when rates outrun it.

Checks before you commit

• Payload per camera from the formula, summed, against 280 MB/s per USB 3.0 controller — the 70% line.
• Any camera above about 100 MB/s on a controller of its own; no hubs in a sustained-stream path.
• Certified USB 3.0 cables, each passive run under about 3 m.
• Sync tier chosen against the motion requirement: freeze → hardware trigger; start-together → software trigger; replay → timestamps.
• A ten-minute recording on all cameras at once with zero dropped frames on each camera.
• A half-hour drift check: the timestamp spread stays inside one frame period (33.3 ms at 30 fps).
• Latency spread measured with the lamp flash, and the numbers recorded with the rig.

Where the usual answer is wrong

"One PC cannot take multiple USB cameras." Wrong at 720p: 83 MB/s sits at 21% of one controller's budget. It becomes right when single cameras reach 12 MP at 30 fps (360 MB/s) or the count climbs past the planning line — and then the fix is controllers and interface, not impossibility.

"MJPEG solves the bandwidth problem." It cuts payloads typically five to ten times at usable quality, which makes recording easy and measurement dishonest: compression moves edges and pixel values stop tracking scene brightness. Use it for review streams, never for gauging.

"Add a hub to add cameras." A hub adds ports, not budget; the upstream link is the ceiling. Add a controller — a PCIe USB 3.0 card — to add budget.

Parts and the next step

If the payload maths says the cameras are the constraint, shortlist from the USB 3.0 area scan families: the area scan camera category filters by interface, resolution and shutter, and the camera finder narrows by the same payload-relevant specs. The cards below are the classes this guide used — a 12 MP USB 3 model rated 30 fps at 4000 × 3000, a 12 MP global-shutter model for moving parts, and a 20 MP USB 3 model for wide fields.

Size the rig end to end — camera, lens, trigger extras — in the configurator:

And if the numbers point at USB 2.0, or the sync tolerance is tighter than timestamps can hold, change the interface rather than the software. For a second pair of eyes on a multi-camera payload plan, send resolutions, formats and frame rates through the contact page.