Reduce USB3 camera bandwidth: the per-camera budget math

Three USB 3.0 cameras behind one hub, frames arriving late or not at all: the link is carrying more than it can. The fix is not in your image publisher. It is in the four numbers the camera itself streams — width, height, bytes per pixel and frame rate — and in one budget number for the port they share. This guide gives you the equation, the budget, and the order in which to reduce settings so the inspection survives. It is written for anyone wiring two or more USB3 Vision cameras, area scan or board-level, into a single host or hub and needing the total to fit with headroom.

One equation, one budget

A USB3 Vision camera reserves bus bandwidth for exactly one product:

Change any factor and the reservation moves in proportion: halve the frame rate, halve the stream. The only factor you look up rather than measure is bytes per pixel, and the pixel format set on the camera decides it:

USB 3.0 advertises 5 Gbit/s per port. Its 8b/10b line coding leaves 4 Gbit/s for data, and the device keeps further headroom for packet headers and handshakes, so plan image payload at 3.2 Gbit/s — call it 400 MB/s — per port. Reservation readouts sit a few percent above the pure arithmetic for the same reason.

Everything behind one external hub shares the hub's single upstream link, so the check is always the sum: all reservations on a shared link stay under 400 MB/s. Separate ports wired to their own controller carry separate budgets — but on embedded boards, read the documentation first, because several visible ports sometimes hang off one internal hub. The hub-side arithmetic gets its own treatment in USB hub drops camera frame rate: budget the bandwidth first.

Reduce it at the camera, in this order

Work through the camera settings in this sequence; each step costs less than the next.

1. Read the current reservation. Open your camera vendor's viewer and note the device throughput or bandwidth reservation of every camera. Most tools show it in Mbit/s, and many include a bandwidth manager that does the sum for you and refuses settings over budget.
2. Set the cheapest pixel format that still answers the inspection. MONO8 on a mono sensor; raw Bayer on a color one, converted in your own code. This lever alone divides the stream by two or three and costs no geometry.
3. Crop the sensor. Height first: rows above and below the part are bytes without information, then width. Keep the crop to multiples of the increment the driver reports — commonly 2, 4 or 8 pixels — or the setting is rejected or silently rounded. For deeper region strategy, see Camera ROI cropping at the source: reduce bandwidth before the host.
4. Match the frame rate to the process. Set the acquisition frame rate to what the inspection needs plus margin, not to the sensor maximum. The period arithmetic is strict: at 54 fps the period is 18.5 ms, so exposure plus readout must fit inside it, and a long exposure is the usual reason a lower rate gets refused. If the rate menu looks empty, see Camera frame rate mode missing: verify advertised modes.
5. Trigger instead of streaming continuously. The reservation stays at the configured frame rate, but average traffic falls to the trigger rate: a line delivering two parts per second at a 54 fps setting carries 54 fps of capacity and about 2 fps of actual frames.
6. Re-read every reservation and add them up. The total per shared link must stay under 400 MB/s. Then run the machine for a few minutes with the frame counters open: if the sum fits and frames still drop, the host side is the cause — see Two USB3 cameras at full resolution stream: raise the host USB buffer.

The arithmetic, twice

Example 1: a small mono camera

Illustrative inputs, not a catalog camera: 1280 × 1024 pixels, MONO8, 54 fps.

• Pixels per frame: 1280 × 1024 = 1,310,720 px
• Bytes per frame: 1,310,720 px × 1 B = 1,310,720 B ≈ 1.31 MB
• Stream: 1.31 MB × 54 fps = 70.8 MB/s, times 8 = 566 Mbit/s ≈ 0.57 Gbit/s

Two of these plus a depth camera whose own tool reports 0.9 Gbit/s come to 1,132 + 900 = 2,032 Mbit/s ≈ 2.0 Gbit/s — comfortable inside a 3.2 Gbit/s plan. Let the frame rate drift to 100 fps, though, and each mono camera alone crosses 1 Gbit/s (1,310,720 B × 100 fps = 131 MB/s = 1,048 Mbit/s), and the set no longer fits.

Example 2: a 12 MP camera at the port ceiling

A real camera shows how quickly a full-resolution sensor closes on the budget.

The LS-CMR-0166 streams 4000 × 3000 pixels at 30 fps over USB3. In MONO8:

• 4000 × 3000 = 12,000,000 px = 12 MB per frame
• 12 MB × 30 fps = 360 MB/s, times 8 = 2,880 Mbit/s = 2.88 Gbit/s

That is 90 percent of the 3.2 Gbit/s payload plan, so one camera fits a port with little spare. Two of them behind one hub ask for 5.76 Gbit/s and will not fit. Halve the frame rate to 15 fps and each falls to 1.44 Gbit/s — 2.88 Gbit/s for the pair, which fits. Cropping to 2,000 rows has the same effect as halving the rate; doing both drops each camera to 0.72 Gbit/s, and three of them still share one link at 2.16 Gbit/s.

Which lever pays most

The settings are not equally painful: pixel format is free, geometry costs field of view, frame rate costs cycle time, and triggering costs a trigger wire. Move them in that order.

When you combine several regions and wonder what the sensor really delivers per frame, the multi-ROI frame rate arithmetic breaks the readout down.

Specifying parts that leave headroom

If you are choosing hardware rather than rescuing a live link, three properties keep the reservation small: an 8-bit mono or raw-Bayer path, a frame rate matched to the process, and a sensor no larger than the inspection needs. A bare-board camera keeps both the reservation and the mechanics small on embedded hosts.

The MV-CB060-10UM-B is a 6 MP mono, bare-board camera with a USB3 interface. In MONO8 a 6 MP frame is about 6 MB, so each 10 fps costs roughly 60 MB/s (480 Mbit/s); at a common 30 fps inspection rate the whole camera sits near 1.4 Gbit/s, under half a port.

For a lens-based station or a high-rate line:

The MV-CS200-10UM is a 20 MP mono camera with C-mount optics over USB3.0, with the same MONO8 arithmetic as the board camera above. A 20 MP frame in MONO8 is about 20 MB, so at 15 fps it streams 300 MB/s (2.4 Gbit/s) and at 10 fps 200 MB/s (1.6 Gbit/s) — give it its own port unless you slow it further. The LS-BCM-0003 runs a 3.1 MP global-shutter sensor at 120 fps over USB3 through a C-mount. In an 8-bit format that high rate is 3.1 MB × 120 fps = 372 MB/s ≈ 3.0 Gbit/s — nearly a whole port on its own; at 60 fps it falls to 186 MB/s (about 1.5 Gbit/s) and two cameras share a link again. Compare interface, resolution and frame rate across the area scan cameras and board-level cameras ranges before you commit.

Common mistakes

• Throttling in software. The driver grabs at the camera rate whatever your code does downstream; the link never notices.
• Selecting 16-bit for more detail. MONO16 doubles bytes per pixel. Use a packed 10- or 12-bit format (1.25 or 1.5 B/px) when you need the depth, and MONO8 when you do not.
• Cropping below the increment. The driver refuses the value or rounds it up; read the increment it reports and crop to it.
• Forgetting the third device. Depth and stereo cameras stream image data too; read their reservation from the same kind of viewer tool and add it to the sum.
• Settings lost after a power cycle. Save the configuration into a user set and read the values back at startup; Camera startup frame rate: verify saved settings and readback shows the readback discipline.

Final checks before you call it done

• Every camera's reservation read and written down, in Mbit/s
• Sum per shared link at or under 400 MB/s (3.2 Gbit/s)
• Pixel format the cheapest one that answers the inspection question
• Width and height cropped to the region, increment respected
• Acquisition frame rate equals the process rate, with exposure inside the period
• Configuration saved to a user set and read back after reboot
• A few minutes of run time with zero dropped frames

The decision, per case: one camera at full rate gets its own port; two cameras share a link only when their combined reservation stays under 400 MB/s; and any camera that will not fit gives up bytes in this order — pixel format, geometry, frame rate. Pick parts in the camera finder, step through the configurator from the camera stage, or bring the awkward link to us through the contact page. More camera-side guides sit under the cameras topic.