Machine vision Ethernet bandwidth planning for cameras

A camera can expose at the required rate while its Ethernet connection cannot deliver every image on time. This becomes harder to diagnose when several cameras share a switch, images arrive in bursts, or a replacement pixel format increases the transmitted payload. For system designers, the useful starting point is a byte budget—not the connector or the advertised link speed. Calculate each stream, identify every shared connection, and then choose the speed and transmission medium independently.

Choose the link from the payload budget

Machine vision Ethernet bandwidth planning has two separate decisions: how much capacity you need and how that capacity reaches the host. Faster copper Ethernet addresses throughput. Fiber addresses transmission distance, electrical isolation, and interference exposure; it does not automatically increase throughput at the same nominal link speed.

Start with these rules:

• Keep a single stream below a deliberately conservative payload target for its camera connection.
• Add all streams that cross the same switch uplink or host connection.
• Check synchronized bursts separately from average throughput.
• Choose copper or fiber after checking the route and supported interfaces.

The broader GigE Vision camera selection guide covers the camera-selection context. Here, the focus is the calculation that determines whether a proposed network has enough capacity.

A reasonable initial design target is image payload below 80% of nominal Ethernet capacity. This is a planning allowance, not a standard or a guaranteed operating limit. Protocol overhead, packet configuration, retransmissions, host behavior, and other traffic determine the measured limit.

Calculate transmitted bytes, not sensor bit depth

For an uncompressed area scan stream, calculate the transmitted image size from the active image dimensions and the actual transport pixel format.

Here, MB means 1,000,000 bytes. Do not mix decimal MB/s with binary MiB/s when comparing application counters and network measurements.

Sensor bit depth alone does not establish transmitted bytes per pixel. A camera can transmit a sensor sample in a wider container, while packed formats arrange samples more tightly.

A raw color mosaic transmitted as one sample per pixel is not the same payload as transmitted RGB. Host-side color conversion can expand memory use without increasing camera-link traffic. The RGB camera frame-rate limits guide explains why this distinction matters.

These formulas estimate image payload only. Add transmitted metadata and row padding where applicable. Packet headers and other transport overhead consume additional link capacity; they are not included in the image-byte calculation.

Worked example: one camera and a shared uplink

Consider a hypothetical image measuring 4096 × 3000 pixels, transmitted as Mono8 at 15 frames/s. These are application assumptions, not specifications for a listed product.

A nominal 1 Gbit/s connection has a theoretical capacity of 125 MB/s before overhead. This stream cannot fit, regardless of packet-size tuning. A 2.5 Gbit/s connection has a theoretical capacity of 312.5 MB/s and an initial planning target of 250 MB/s, so it is a candidate for validation.

Now put three identical streams behind one switch uplink:

The aggregate exceeds the chosen planning target for a 5 Gbit/s uplink. It does not exceed that link's theoretical capacity, but it leaves less reserve than this design allows. A 10 Gbit/s uplink provides a more comfortable starting point.

Changing the original stream to a 16-bit container doubles its payload to 368.64 MB/s. Recalculate whenever you change pixel format, image dimensions, frame rate, or transmitted metadata.

For larger installations, the multi-camera host bandwidth guide extends this reasoning to shared host resources.

Compare copper speeds and fiber routes

Use the following table to screen link speeds. The payload targets are calculated design allowances, not measured camera performance.

For copper, check the Ethernet variant, cable category, installed channel length, connectors, and every intermediate component. For example, a compliant 1000BASE-T channel can reach 100 m using suitable Category 5e or better cabling. A compliant 10GBASE-T channel can reach 100 m with suitable Category 6A cabling. These are channel limits, not promises for every cable assembly or moving installation.

Fiber becomes attractive when the route exceeds the supported copper channel, crosses areas with strong electromagnetic interference, or requires electrical separation between endpoints. A nonconductive optical path does not carry ground current between endpoints, although conductive armor or other connections can change the installation's isolation behavior.

Fiber reach depends on the selected optics, fiber type, connector losses, and supported link standard. Do not assign a generic distance to every optical connection. An SFP+ cage alone also does not establish support for a particular module, fiber, or Ethernet implementation.

A copper Ethernet camera may connect through a supported switch with an optical uplink. That does not turn the camera's own connection into a faster interface. Confirm that the complete arrangement supports the required traffic and camera operation.

Budget line scan from motion

For line scan cameras, replace frame rate with line rate. The motion direction determines how frequently the system must acquire a new line.

Suppose an application uses 4096 active pixels across a 400 mm field of view. For approximately square object-space sampling, the desired along-motion pitch is 400 / 4096 = 0.0977 mm per line. At an object speed of 2000 mm/s, the required line rate is approximately 20,480 lines/s.

That image payload falls below the initial 100 MB/s planning target for a gigabit connection. However, a speed increase, additional transmitted channels, or wider sample containers can change the decision.

The camera observes one narrow strip while motion builds the image. Encoder timing should track material travel when speed varies, subject to the camera's supported trigger behavior.

Use the line-rate setup guide for acquisition timing. The line scan field-of-view guide covers the optical sampling calculation in more detail.

Check bursts and the complete data path

Average throughput can hide a queue that overflows during synchronized image transfers. Two cameras can expose together and then attempt to transmit together, even when their long-term average fits the uplink.

For a simplified queue estimate, compare incoming payload with the available forwarding rate:

If incoming payload exceeds forwarding capacity by 60 MB/s for 0.5 s, approximately 30 MB accumulates. This is an illustrative queue calculation, not a claim about a switch's buffer. The queue must also drain before repeated bursts accumulate further.

Supported transmission pacing or staggered transfer scheduling can reduce contention. Staggering exposure is a separate decision and may be unacceptable when images must represent the same instant. Clock synchronization does not allocate bandwidth.

Follow every shared stage:

• Camera port: Can the individual stream leave the camera at the required rate?
• Switch uplink: Does it carry the sum of all streams using that route?
• Switch buffers: Can they absorb the actual burst pattern?
• Host adapter and expansion connection: Can they sustain the aggregate traffic?
• Acquisition buffers: Can they absorb temporary delays without exhausting memory?
• Processing and storage: Can downstream work keep pace without an ever-growing queue?

Packet sizing can improve efficiency, but the complete route must support the selected setting. Follow the packet-size startup guide rather than treating a larger packet as a substitute for capacity.

Translate the budget into catalog candidates

Use the camera finder after establishing the required payload and link speed. Keep sensor, shutter, optics, and inspection requirements separate from the network decision.

For area scan cameras, the LS-CMR-0053 is a GigE catalog candidate. It is not the hypothetical camera used in the earlier arithmetic. Evaluate its own acquisition specifications against your image requirements.

For line scan cameras, the LS-LCM-0067 is a 10GigE catalog candidate. Confirm its supported line rate, transmitted format, trigger behavior, and complete connection requirements before selecting it.

Select camera cables by documented interface support as well as route length and connector arrangement. The LS-CBL-0199 is described as a 3 m GigE camera cable with high-flex construction and screw locks. Do not infer suitability for a faster Ethernet rate from those details alone.

The accessories finder helps narrow cable candidates. Confirm mating connectors, supported data rate, movement requirements, and manufacturer installation limits before ordering an assembly.

When a faster link is the wrong fix

Do not upgrade Ethernet solely because the displayed frame rate is low. First compare camera-generated, received, processed, and displayed image counts. A slow display can coexist with complete acquisition, while a growing processing queue can conceal an eventual failure.

Long exposure, sensor readout, trigger timing, or processing can limit throughput before the Ethernet link becomes busy. A faster connection does not remove those constraints. The external-trigger frame-rate guide helps separate trigger behavior from transmission capacity.

Likewise, an application that cannot open or configure a camera may have a software compatibility problem rather than a bandwidth problem. Use the GigE Vision software compatibility checks before replacing network hardware.

Reducing the region of interest, frame rate, or transmitted sample width can sometimes avoid an interface upgrade. Make those changes only when the inspection still meets its coverage, sensitivity, and timing requirements.

Verify the design and check before ordering

Validate the complete system at its maximum intended production workload:

1. Record actual image dimensions, transport pixel format, frame or line rate, and measured payload.
2. Confirm the negotiated speed at every Ethernet port. Do not assume fallback speeds are supported.
3. Run all cameras together using the intended trigger pattern and processing workload.
4. Monitor incomplete images, missing frame identifiers, resend counters, queue growth, and application latency where available.
5. Test repeated acquisition starts and the longest expected production run, not just a short live display.
6. Apply a controlled load increase, such as the highest specified conveyor speed, and confirm the reserved capacity remains adequate.

Before ordering, check these items against the system requirements:

• Per-camera budget: Each stream fits its own connection with the chosen reserve.
• Aggregate budget: Every shared uplink carries the combined payload.
• Burst behavior: Queues remain bounded during simultaneous transfers.
• Transmission medium: Copper channels or optical components match the route and supported interfaces.
• Host capacity: Acquisition, processing, and storage sustain the workload together.
• Acceptance criteria: Define permitted latency and image completeness before testing.

Start a configuration with the camera selection step, then add the required connections through the cable and accessory step. For a shared-link review, send your image dimensions, transport format, acquisition rate, camera count, and route details through applications support.