Camera video shares a robot link with control traffic, and many of those links carry a hard cap of a few megabits per second — the worked example below uses the classic field figure. Exceed it and the stream stalls, pixels drop out, and the picture only re-syncs after seconds of clean data, usually at the worst possible moment. The fix is arithmetic done at the bench, not luck during the run: compute the raw ceiling for your resolution and frame rate, measure what the compressed stream actually sends, then hold the measured rate at or under half the cap. This guide gives you the formula, a worked example for the most common oversized setting, the measurement methods, and the levers that cut the rate fastest.
The raw ceiling: pixels per second times bits per pixel
Every bandwidth estimate starts the same way. Multiply the pixels in one frame by the frames per second, then by the bits each pixel needs.
Use decimal megabits, the way link caps are quoted: the field cap means 7,000,000 bits per second, not 7 × 1,048,576.
Bits per pixel follows the pixel format:
| Pixel format | Bits per pixel | Rate at 800 × 600, 15 fps |
|---|---|---|
| 1-bit black and white | 1 | 7.2 Mbps |
| 8-bit mono | 8 | 57.6 Mbps |
| 24-bit RGB color | 24 | 172.8 Mbps |
The right-hand column is the ceiling: what a stream would need if every pixel crossed the wire in full, with no compression. Real traffic sits either far below that ceiling (a compressed dashboard stream) or exactly at it (a raw machine-vision stream). Which case you are in decides whether the formula is a loose bound or the whole answer.
Worked example: 800 × 600 at 15 fps on the capped link
This is the setting that keeps showing up on saturated robot links: a modest-looking camera feed that the raw math proves cannot fit.
Inputs
- 800 px wide × 600 px high — the camera's resolution setting in the streaming software
- 15 frames per second — the camera's frame-rate setting
- 8 bits per pixel — 8-bit mono; color is 24, three times the mono figure
- 7 Mbps — the cap the field link enforces, continuously, in every operating mode
The rule in words
Pixels per frame times frames per second gives pixels per second; multiply by bits per pixel for the raw ceiling in bits per second. The ceiling is not a forecast. Compression cuts it by a scene-dependent factor, so the number you budget is the number you measure.
The arithmetic
- 800 × 600 = 480,000 pixels per frame
- 480,000 × 15 = 7,200,000 pixels per second
- Mono, 8-bit: 7,200,000 × 8 = 57,600,000 bits/s = 57.6 Mbps
- Color, 24-bit: 7,200,000 × 24 = 172,800,000 bits/s = 172.8 Mbps
- Even the 1-bit floor: 7,200,000 × 1 = 7.2 Mbps — already at the cap
The result
The raw ceiling is 57.6 Mbps mono, about 8× the cap (57.6 ÷ 7 = 8.2). Compression must shrink the stream by more than that factor just to fit; in color it needs 24.7× (172.8 ÷ 7).
The decision
A compressed stream at this setting runs at 86–100 % of the cap on capped field links and saturates the link as soon as the scene turns busy. Set the budget at half the cap: 3.5 Mbps steady, which tolerates the roughly 2 Mbps jump a detailed background adds and still peaks near 5.5 Mbps. If the measured rate sits above 3.5 Mbps, cut frame rate or resolution until it drops below; 320 × 240 at 15 fps and 800 × 600 at 10 fps are the first two settings to try, in that order. Keep the raw 57.6 Mbps figure out of any "it should fit" argument — the measured number is the only one that crosses the wire.
Compression makes it a ceiling; raw vision streams make it exact
Between the ceiling and the wire sit two very different streams.
A dashboard stream encoded as MJPEG or H.264 throws away most of those bits, and how many it keeps follows scene detail: a blank wall compresses almost to nothing, a checkerboard or a bin of parts resists. Measurements on capped field links show the rate moving by around 2 Mbps as the camera pans across backgrounds, and teams that left a stream near the cap watched the link saturate mid-use. The same ceiling-then-measure discipline, with the compression trade-offs worked through, applies to depth data streamed over a network.
Machine-vision cameras are the other case. GigE Vision and USB3 Vision carry raw pixels on the wire, with no inter-frame compression, so the formula is the exact rate the link must sustain. That is why high-resolution GigE cameras quote modest frame rates: the LS-CMR-0053 streams 12 MP frames at 9 fps over GigE with a 1/1.7" rolling shutter. The raw math explains the frame rate: 12,000,000 pixels × 9 fps × 8 bits = 864 Mbps, about 86 % of GigE's 1,000 Mbps line rate — any more and the link would stall on headers, trigger traffic and retries.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- 12 MP
USB 3.0's 5 Gbps carries far more raw pixels, which is how USB3 cameras reach higher frame rates at full resolution; the per-camera USB3 budget math walks the numbers. Two raw cameras never share one gigabit NIC — plan a second NIC and port before the second camera arrives. When the alternative is a longer Ethernet run, the 5GBASE-T camera interface adds bandwidth and distance over the same cabling family.
Measure the real rate before the run
Three tools; use whichever is at hand:
- Packet capture. In Wireshark, open Statistics → Conversations, TCP tab, and sort by rate — the video stream stands out at once. Statistics → Summary gives totals for the capture; divide total bytes by capture seconds for the average rate.
- Windows Resource Monitor. The Network tab lists bytes per second for every process with network activity.
- Task Manager. The Ethernet graph is a coarse but instant sanity check.
Then the discipline: measure the worst case, not the bench. Point the camera at the busiest, most detailed background it will ever face, with every other device and process doing its job, and record the peak, not the average — the average hides the 2 Mbps scene jump that kills the link.
If the link is already failing mid-run — stalls, reconnects, a picture that only re-syncs after seconds — that is a diagnosis job, and the two USB cameras robotics connection guide walks the failure case. Budgeting happens before any of that.
Set the budget: targets per link type
The rule that survives the field: steady state at or under half the cap. The other half absorbs the scene-detail jump.
| Link | Cap | Steady target | Expect peaks near | Re-size when measured hits |
|---|---|---|---|---|
| Capped robot/field link | the field cap (see inputs) | 3.5 Mbps or less | 5.5 Mbps (3.5 + 2 Mbps jump) | 6 Mbps |
| 100 MbE shared with control traffic | 100 Mbps | 50 Mbps or less, all streams summed | measured peak plus jump | 80 Mbps |
| 1 GbE, one raw camera | 1,000 Mbps | 870 Mbps or less (one 12 MP, 9 fps stream) | 864 Mbps plus headers and trigger traffic | second camera: add a second NIC |
Read the middle row hard: shared fast Ethernet has no room for raw machine-vision streams at all. One 640 × 480, 30 fps mono feed alone needs 73.7 Mbps raw (307,200 × 30 × 8), so shared 100 MbE carries compressed streams only, summed before comparing to the target.
Cut the rate: levers in order
Ordered by good done per unit of pain:
- Frame rate. Linear, and least painful for a viewing stream: 15 fps down to 10 is a 33 % cut. A rate that collapses only when exposure climbs is a different failure, covered in the FPS-drops diagnosis.
- Resolution. Linear in pixels: 640 × 480 removes 36 % (307,200 vs 480,000 pixels); 320 × 240 removes 84 %. At 320 × 240 and 15 fps the raw mono ceiling is 76,800 × 15 × 8 = 9.2 Mbps, and a stream that measured 6 Mbps at 800 × 600 scales to roughly 1 Mbps (6 × 76,800 ÷ 480,000 = 0.96) — a scaling estimate, but the right order of size.
- Mono instead of color. Drops the chroma data, trims compressed rates, and cuts the raw ceiling to a third.
- Encoder target. If the stream exposes a target bitrate, set it to the budget and let quality float; the FAQ below has the constant-versus-variable catch.
- On demand instead of continuous. Stream a region of interest or single frames on a trigger, and the average rate collapses.
When the right stream rate is zero
If the decision can run on the device, the lowest-bandwidth video is the video you never send. A smart camera or vision sensor inspects on board and returns a result — pass/fail, position, a code string — in kilobytes per event. The MV-SCB007EC-12S-WBN pairs a 1.6 MP color sensor with a fixed 12 mm lens on Fast Ethernet, built to decide where the pixels are and send only the answer.
- Interface
- Fast Ethernet
- Resolution
- Up to 3 MP
- Sensor format
- 1/2.9"
- Shutter
- Global
Stream video only while you tune the inspection, or when a human genuinely needs eyes on the scene. If the feed ends at an operator dashboard, that station belongs to the cell: an industrial panel PC at the station keeps the display mounted and wired like the rest of the kit. The feed side — live video plus metrics to a custom dashboard — is covered in the smart camera dashboard streaming guide.
Checks before the next run
- Raw ceiling computed for the current width, height, frame rate and bits per pixel; keep the number — every measured rate is judged against it.
- Measured rate recorded at the worst-case background, peak not average.
- Steady measured at or under half the cap; peak including the jump still under the cap with margin.
- Byte counts converted to bits (× 8) before any comparison.
- Port confirmed negotiating at 1 Gbps: a degraded link drops to 100 Mbps, a 10× capacity cut that looks like a software fault.
- Re-measured after any camera, encoder or network change — a budget is tied to the settings that produced it.
Moving runs need a cable built for flex: the LS-CBL-0199 is a 3 m GigE camera cable with screw locks and drag-chain-rated high-flex construction, and the camera cables or the accessories finder filters the rest.
Next step
Pick the camera and the link as one decision. The area scan cameras page and its camera finder filter by interface, resolution and frame rate, so a 12 MP model gets paired with the gigabit run it needs. The configurator starts at the camera step:
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.
Then re-run the three numbers for your settings — pixels per frame, frames per second, bits per pixel — and hold the measured rate to half of whatever the link allows.
Questions
My tool reports bytes per second and the cap is in Mbps — how do I compare?
Multiply bytes by 8 to get bits. 875,000 B/s equals 7,000,000 bits per second — the cap exactly. The other direction: divide bits by 8, so a 3.5 Mbps budget shows as 437,500 B/s in Resource Monitor's B/sec column. Wireshark's Conversations table can display bits/s per stream directly, which skips the conversion entirely.
Can I add a second camera stream without saturating the link?
Sum the measured rates, then compare the sum to half the cap. Two streams at 1.5 Mbps each plus 1 Mbps of other traffic is 4 Mbps, about 57 % of the capped field link — room for a 2 Mbps scene jump. Raw streams are different: one 12 MP, 9 fps, 8-bit mono stream is 864 Mbps on its own, so each raw camera needs its own gigabit run.
Does raising the frame rate always raise the stream rate?
For a raw stream, yes, and linearly: double the fps and the bits double. For a compressed stream, usually but not always — encoders repeat or skip frames when nothing in the scene changes, so a static view at 15 fps can cost little more than at 5 fps. The moment the scene or lighting moves, every frame carries new detail and the rate tracks fps again.
What bitrate target should I set in the encoder?
Set it to the stream's share of the budget: 3 Mbps for one stream on the capped field link, 1.5 Mbps each for two. Use a constant or constrained bitrate mode, not pure variable — a variable encoder ignores the target exactly when the scene gets detailed, which is when the cap matters most.
Is it better to inspect on the camera and send only the result?
If the decision runs on the device, yes. A smart camera or vision sensor returns pass/fail, position or a code string — kilobytes per event — and streams video only while you tune it. That converts a permanent multi-megabit feed into occasional small bursts. Reserve continuous streaming for jobs that truly need human eyes on live video, and give those the same half-cap budget.