Multiple FireWire 1394 cameras: budget the 320 Mbps bandwidth cap

Four or five FireWire cameras on one card looks like a wiring exercise, but it is a bandwidth budget. An IEEE 1394a bus moves 400 Mbps in its S400 form, and the standard lets video streams claim at most 80% of that. Every choice you make — resolution, bit depth, frame rate, camera count — has to fit inside the cap that leaves. This page gives you the cap, the per-camera arithmetic, a worked four-camera example with the sums shown, and the decision rules for adding a second bus or moving the job to GigE. It is for anyone extending a multi-camera 1394 station and wondering why frame rates sag as each camera comes online.

How much of a 1394a bus do your cameras actually get?

Isochronous video may claim at most 80% of the 400 Mbps bus. That is a 320 Mbps ceiling shared by every camera on that bus, and the remaining 20% is reserved for asynchronous traffic such as camera control.

The split is written into the standard, not into any particular driver: isochronous transfers take at most 80% of bus bandwidth, leaving asynchronous traffic a guaranteed 20%. Video uses the isochronous slice because the bus delivers those packets at fixed intervals. Camera control — exposure, gain, trigger mode — travels asynchronously; the machine-vision drivers of that era streamed video isochronously while sending register traffic in the asynchronous lane. The two budgets do not borrow from each other, so loading the asynchronous side cannot starve video and video cannot crowd out control.

Throughput converts simply: 400 Mbps is 50 MB/s, so the isochronous ceiling is 40 MB/s of image payload per second, shared by every camera on the bus. That 40 MB/s figure is the one to keep on the whiteboard. The original 1394-1995 standard defined 100, 200 and 400 Mbps rates, and later revisions took buses to 800 Mbps and beyond (IEEE's 1394 topic page) — relevant when the question of 1394b comes up below.

How do you calculate the Mbps one camera stream consumes?

Multiply width in pixels by height, by bytes per pixel, by frame rate, then by 8 and divide by 1,000,000. A 1024 × 768, 8-bit mono camera at 15 fps consumes 94.4 Mbps of image payload against the bus budget.

These are payload figures: image bytes only, before packet headers. Bytes per pixel is 1 for 8-bit mono, 2 for the common YUV (4:2:2) color formats, 3 for 24-bit RGB.

Worked example, at the settings these cameras typically ran — 1024 × 768, 8-bit mono, 15 fps:

• Bytes per frame: 1024 × 768 × 1 = 786,432 B
• Payload per second: 786,432 B × 15 = 11,796,480 B/s ≈ 11.8 MB/s
• On the bus: 11.8 MB/s × 8 = 94.4 Mbps

One camera at these settings spends 94.4 Mbps of the ceiling, just under 30% of the whole bus for a single stream. That ratio is why two-camera FireWire stations were routine and five-camera ones were not.

How many FireWire cameras fit on one 400 Mbps bus?

Two of the example cameras fit with margin at 188.7 Mbps. Three just fit at 283.1 Mbps, and four miss the ceiling by 57.5 Mbps at 377.5 Mbps — so a four-camera plan at 15 fps must cut payload or add a bus.

If four cameras are fixed and 15 fps is negotiable, shrink payload per camera instead. Both changes keep a four-camera station inside the budget:

Any combination works the same way: payload tracks pixels × frame rate × bytes per pixel, so halving one factor halves the bill.

Why do streams start dropping before you reach the cap?

Because payload is not the whole story: packet headers, CRC and gaps between packets push real bus occupancy above the payload sum. The grant fails outright once requests pass the cap, so buses turn intermittent near roughly 300 Mbps of payload, not at the ceiling.

The bus grants isochronous bandwidth when each camera starts streaming. If the requests sum past the ceiling, the grant fails and the camera never streams — you get an acquisition error at startup rather than a graceful slowdown. If the sum lands just inside, packet headers, CRC and inter-packet gaps push actual occupancy past it, and frames drop intermittently under load. Users of these buses have long reported trouble beginning near 300 Mbps of payload, which is what the arithmetic predicts: the 20 Mbps gap between the planning line and the ceiling is about 6% of it, in line with packet overhead at these sizes. Smaller frames cost proportionally more, because more packets per frame means more header bytes.

Planning rule: sum the payload, then require each bus to stay at or below about 300 Mbps — 94% of the ceiling. The last 20 Mbps is not spare capacity; it is where overhead and control traffic live. For the symptom-side view of an overloaded bus, see diagnosing a 400 Mbps FireWire bus limit.

Does an IEEE 1394b bus double what you can stream?

On paper yes — an S800 bus moves 800 Mbps, so video's 80% share rises to a 640 Mbps ceiling — but only devices that negotiate 1394b get those rates, and legacy S400 machine-vision cameras are not among them.

1394b raised the rate ladder from 100, 200 and 400 Mbps to 800 and beyond, and the 80% isochronous share scales with it: an S800 bus budgets 640 Mbps for video and keeps 160 Mbps for asynchronous traffic. The catch is negotiation. A segment runs at the speed its devices agree on, and traffic to or from an S400 device moves at S400. The machine-vision cameras of the FireWire era are S400 devices, so an S800 controller card does not double the budget of a bus full of them — the legacy streams still consume bus time at legacy rates.

Decision: add a second controller before buying speed the cameras cannot use. An S800 card pays off only in an all-1394b chain — b-capable cameras, b-rated cabling and b-capable ports end to end.

When do you split cameras across two buses or move to GigE?

Split when the summed payload passes about 300 Mbps, when a fifth camera is coming, or when dropped frames will not reach zero. A second controller card creates an independent bus with its own full ceiling, and modern GigE ports give each camera a full link of its own.

A second controller card in the host creates a second, independent bus with its own isochronous budget; the buses share nothing. Balance them: five cameras at the example settings split as 283.1 Mbps on one bus and 188.7 Mbps on the other, and both hold under the 300 Mbps planning line. Keep the split stable in software, since camera identity on the bus has its own failure modes.

If the hardware is being replaced anyway, skip the shared bus entirely. A GigE area scan camera on its own network port has a dedicated link, so the four-camera station that overloaded one 1394a bus fits a single quad-port card. The budgeting habit transfers directly: see the multi-camera GigE bandwidth budget, the arithmetic for two GigE cameras on one host NIC, and the host-side view in multiple GigE cameras on one computer. The frame grabbers category holds the current multi-port cards, and for a bench migrating off FireWire one of them restores one independent link per camera:

What should you check before wiring the bus?

Keep each camera on its own 4.5 m cable where the layout allows, budget summed payload to about 300 Mbps per bus, and rebind any camera that enumerates as a generic device after a reboot — hubs and repeaters are the usual cause.

• One camera per cable where the layout allows; a standard 1394 cable segment runs 4.5 m per the specification.
• Use a powered hub or repeater for longer runs, and rebind the machine-vision driver to any camera that enumerates as a generic device after a host restart — repeater and hub chips are the usual trigger. Port stability has its own fixes: see assign cameras to ports reliably.
• Set format, resolution and frame rate explicitly on every camera; a free-running test stream counts against the budget exactly like a triggered one.
• Prove the budget by counting frames: run all cameras at the target rate for at least an hour and require zero missed or incomplete frames before trusting the station. The same budget-first logic governs USB hubs carrying multiple cameras if you later mix interfaces on a host.

If the budget says split and the 1394 cards are gone, the cameras finder and the configurator below are the quick way to a modern four-camera bench; questions about an existing 1394 station go through the contact page. More host-level planning lives on the systems topic page.