How to Choose a Camera Interface and Size the Bandwidth

The interface decides whether the data can be moved in time. Insufficient bandwidth does not appear as a sluggish or stuttering image; it appears as dropped frames, where a trigger produces no matching image and the verdict for that part is missing, while every other part of the system looks entirely normal. That makes it a quiet failure. It never shows up in a static bench test, rarely in a short acceptance run, and usually surfaces weeks later when somebody notices a gap in the traceability record. Which is why bandwidth belongs in the selection arithmetic rather than in post-installation guesswork.

Size the bandwidth first, then pick the interface

The arithmetic is simple. Width times height gives the pixel count; times the bytes per pixel gives the size of one frame; times the frame rate gives the bandwidth the link must carry. A monochrome image is one byte per pixel. A colour camera usually transmits unmosaiced Bayer data, also one byte per pixel, but if the conversion to colour happens in the camera or on the host, every later stage has to be counted at three bytes. That last point is frequently missed, and it makes a colour camera three times heavier than it first appears.

Take a worked example. A 2448 × 2048 monochrome camera at 30 fps: 2448 × 2048 = 5,013,504 bytes, about 5 MB per frame; times 30 gives roughly 150 MB/s. A gigabit link is 1 Gb/s in theory, that is 125 MB/s, and 110 MB/s in practice, so it is clearly short — the symptom is a dropped frame every few frames, varying with network load. Moving to 5GigE or USB3 gives 625 MB/s theoretical and roughly 350 to 450 MB/s usable, which leaves headroom. This is why the same sensor in a GigE body and in a USB3 body suit completely different situations.

Cameras on one link share the bandwidth

When several cameras connect to the same switch, they share a single pool of bandwidth. Four cameras each needing 150 MB/s behind one gigabit uplink will not fit, whatever the switch is rated at, because that uplink offers about 110 MB/s. The result is random dropped frames, and neither which camera drops them nor when is predictable. The correct approach is a dedicated port or network card per camera, or moving the whole link to 10 gigabit while checking the switch backplane capacity and packet forwarding rate as well — on some inexpensive switches, the rated port speed and the total forwarding capability are not the same thing. There is also a different way to think about the problem: rather than one camera per station, let a single camera serve several stations in turn, and the trade-off is set out in sharing one camera.

Cable, power and triggering belong in the same decision

• Cable length and routing. Gigabit Ethernet reaches about a hundred metres, USB3 becomes unreliable past five, Camera Link about ten. Where the camera sits on a gantry or a robot arm, cable length and drag chain life directly shape the design.
• Power delivery. A PoE camera needs only one cable and removes a power supply from the station, which means fewer failure points over the years. USB3 draws from the bus, but the supply capacity of the host and any hub has to be checked when several run at once.
• Host and controller. Several USB3 cameras running together are often limited by how the host controller allocates channels, which is similar to the situation with network card queues. This never appears in a demonstration setup and appears quite readily on an industrial PC with a handful of cameras.
• Triggering. A hardware trigger driven by a photoelectric sensor or an encoder signal goes straight into the camera trigger input and is far more consistent in timing than a command issued by software. Trigger jitter and its relationship to exposure time is covered separately in triggers and synchronisation.