FireWire camera low frame rate with an external trigger

You trigger a FireWire machine-vision camera at 25 Hz and collect 6.8 frames per second. Internal triggering runs at full rate, the camera attributes all look reasonable, and the fault survives a restart — because it is not in the camera. A 1394a bus moves a fixed number of isochronous packets per second, and the packet size the driver negotiated is small enough to starve the link. This walkthrough shows the arithmetic that turns a 388-byte packet size into a hard frame-rate ceiling. It also gives the packet size that sustains your rate and the trigger-pulse width that keeps external triggering from dropping frames silently. The numbers use a 640 × 480 8-bit mono frame; swap in your own width, height and pixel depth and the method holds.

Why is the frame rate lower than the trigger rate?

Your camera is bus-limited, not trigger-limited. A 1394a bus moves a fixed 8000 isochronous packets per second, and a 388-byte packet size carries only about 3.1 MB/s — enough for roughly 10 frames of 640 × 480 mono, never the 25 your pulse asks for.

Two limits stack on this fault, in order of likelihood. The payload ceiling sets the magnitude: at 388 bytes per packet, 25 fps is out of reach at this frame size, and no exposure or gain setting changes that. The trigger input takes the remainder: a 50 µs pulse on a long I/O line is marginal. Every pulse the input misses is a frame that never starts, with no error raised anywhere.

A sanity check confirms the shape: 6.8 fps × 307,200 B = 2,088,960 B/s ≈ 2.1 MB/s of delivered payload, about two thirds of the 3.1 MB/s ceiling. That is what a bandwidth cap looks like, not what a camera refusing triggers looks like.

How many packets per second does a FireWire bus carry?

Exactly 8000, fixed by the bus architecture and independent of your camera, driver or link speed. Each bus cycle is one scheduled slot for isochronous channels. The payload you load into that slot — the packet size — is the only variable you control.

The bus runs at S100, S200 or S400: 100, 200 or 400 Mbps, which is 12, 25 or 50 MB/s gross. Isochronous traffic — the class cameras stream in — may reserve up to 80% of the cycle budget, so an S400 bus grants about 320 Mbps (40 MB/s) to streams; plan on roughly 38 MB/s of usable payload. The specification allows an isochronous payload of up to 4096 bytes per packet at S400, and 8000 × 4096 B = 32,768,000 B/s ≈ 32.8 MB/s, inside that reservation.

The packet count is the constant; the packet size is your bandwidth dial. Format 7 changes what you put in each packet — region of interest and packet size — never how many packets the bus schedules.

What frame rate does your current packet size allow?

With 388-byte packets the bus gives you 8000 × 388 = 3,104,000 B/s ≈ 3.1 MB/s of payload, and a 640 × 480 8-bit mono frame is 307,200 bytes — a ceiling of 3,104,000 ÷ 307,200 ≈ 10.1 fps. Your measured 6.8 fps sits under that once cycle overhead is paid.

Run the failing case. Payload: 8000 packets/s × 388 B = 3,104,000 B/s ≈ 3.1 MB/s. Frame: 640 pixels × 480 pixels × 1 B = 307,200 B. Ceiling: 3,104,000 ÷ 307,200 ≈ 10.1 fps. The 25 Hz trigger asks for frames the bus cannot deliver, and the acquisition stack silently drops what never arrives.

The measured 6.8 fps sits below even that ceiling, and the shortfall is the bus's overhead: cycle-start gaps, packet headers and driver buffering each take a share, and isochronous traffic gets no retries. Treat 10.1 fps as the payload-only ceiling and any rate near it as the same fault.

What packet size sustains 25 fps?

At least 960 bytes per packet: 25 fps × 307,200 B = 7,680,000 B/s of demand, and 7,680,000 ÷ 8000 packets/s = 960 B. In practice set 1024 bytes, or on a single-camera bus the maximum the driver reports — the specification ceiling at S400 is 4096 bytes.

Work it backwards. Demand: 25 fps × 307,200 B = 7,680,000 B/s = 7.68 MB/s, about 61 Mbps of payload. Per packet: 7,680,000 ÷ 8000 = 960 B. That 960 bytes is the mathematical minimum, and 1024 bytes is the practical setting — an 8.19 MB/s ceiling against a 7.68 MB/s demand, about 7% margin. On a single-camera bus, skip the arithmetic and apply the maximum the driver reports; at 4096 bytes the ceiling for this frame size is 106.7 fps.

If you run more than one camera on the bus, budget before you tune: multiple FireWire cameras on one bus share the same 8000 cycles, so the per-camera packet sizes must sum below the per-cycle payload budget.

How do you set the packet size in Format 7?

Stop acquisition, open the camera's Format 7 attributes, raise the packet size to the maximum the driver accepts, then restart the stream. On one camera per bus that value clears 25 fps with margin, and only a deliberate multi-camera budget justifies less.

1. Stop acquisition and close the stream; Format 7 region and packet changes apply cleanly only on a stopped stream.
2. Open the camera's attribute tree and find the Format 7 Mode 0 controls: region of interest, packet size, and a query or scan action.
3. Run the bus probe and read back the maximum packet size it reports for the current topology; that number already accounts for the cable and the other nodes.
4. Apply the reported maximum, restart the stream, and re-check the delivered frame rate.
5. Write the value into the commissioning record so the next integration starts from it.

If the probe reports less than you expect, believe it: it measures what this bus, this cable and these nodes actually sustain. A smaller region of interest in Format 7 also shrinks bytes per frame, which raises the ceiling without touching the packet size — useful when the bus is shared.

Is a 50 µs trigger pulse too short?

Treat 50 µs as unreliable: it is a marginal width for an opto-isolated input at the end of a long I/O cable, and a missed pulse is a silent dropped frame. Widen the pulse to at least 1 ms, and to 10 ms on 10 m runs in noisy plants.

An opto-isolated input needs enough current, for enough time, to cross its threshold; cable capacitance rounds the pulse edge. A 50 µs pulse can arrive under threshold or inside the input's response time, and the camera raises no flag — the frame simply never starts.

Make the source deliver 1 ms as the floor. On I/O runs around 10 m through an electrically noisy plant, 10 ms is the width that stops the occasional lost frame; treat that as a field rule of thumb, not a specification. If the controller cannot widen its pulse, put a retriggerable one-shot timer at the camera end of the line.

One check before widening: if the camera is in a pulse-width-controlled exposure mode, active time is exposure — a 10 ms pulse is a 10 ms exposure, fine for static parts, wrong for a moving web. In edge-triggered mode the width only has to be detected, and you set exposure separately; why the trigger pulse width sets your exposure time covers the modes. For camera-side trigger diagnostics once the bus is fixed, this triggered frame-rate troubleshooting walkthrough covers the attributes one level deeper.

How do you verify the fix?

Count frames, not impressions: log acquired frames over a 10 s window with the trigger at 25 Hz and demand 250 of 250. If the count is short, scope the trigger line and check exposure-plus-readout time before touching the packet size again.

1. Arm a counter on the trigger source and a frame counter in software; run 10 s at 25 Hz. Pass: 250 triggers, 250 frames.
2. Short by whole frames at random times: scope the pulse at the camera connector — amplitude against the input threshold, width at the far end of the cable.
3. Short in a regular pattern: the camera is the limit — exposure plus readout must fit inside 40 ms per frame, and the maximum frame rate on a hardware trigger shows that arithmetic.
4. Review 100 saved frames for corrupted strips: isochronous errors are not retried, so they appear as artifacts, not as lost frames.

Log timestamps instead of trusting a live display — measuring the delivered frame rate rather than the requested one is what makes the count mean anything.

When should you migrate off the FireWire bus?

When you need more than the bus can ever give: the isochronous budget tops out near 38 MB/s net on S400, and a modern GigE camera moves the same frame over Category cabling with power on the wire, longer runs and a current driver stack.

Compare ceilings before you spend an afternoon tuning. This bus tops out near 32.8 MB/s of payload; 1394b doubles the link to S800 but keeps the same legacy stack and shrinking driver support; a GigE camera moves the same 640 × 480 frame over a 1 Gbps class link with power on the same cable. If the camera model is at end of life or the region of interest must grow at rate, the decision makes itself.

For the camera, filter area scan cameras by interface and resolution. The MV-CU020-90GC is a 2.5 MP GigE camera, color, global shutter, with a 1/1.7" sensor format and a C-mount.

For the host and the link, frame grabbers lists interface cards — the MV-GE2002P is a dual-port PoE NIC, full height, V2.0 — and camera cables lists locked data cables such as the LS-CBL-0117, a 15 m camera data cable with locking-stud RJ45 ends.

Size the replacement in the camera finder or the camera step of the configurator. And if your symptom is the camera vanishing from the bus rather than running slow, start with 1394 FireWire camera detection troubleshooting instead.

What belongs on the final checklist?

Four items close this ticket: packet size at 1024 bytes or above, a trigger pulse 1 ms or wider, a 250-of-250 frame count over 10 s at 25 Hz, and the final packet size written down so the next integration does not rediscover the cap.

• Packet size at 1024 bytes or above — below 960 bytes, 25 fps at 640 × 480 mono is arithmetically impossible.
• Trigger pulse at 1 ms minimum, 10 ms on 10 m I/O runs — a missed pulse drops a frame silently.
• 250 frames counted in 10 s at 25 Hz — measure delivered frames, not the requested rate.
• Exposure plus readout inside 40 ms — otherwise the camera, not the bus, caps you.
• A 100-frame review free of corrupted strips — isochronous errors surface as artifacts.
• The final packet size and pulse width written into the commissioning record — the next integrator should not rediscover this cap.

If the ceiling still binds with the packet size at maximum, the bus has told you its answer: shrink the region of interest, lower the rate, or move to GigE — or send the frame size and target rate through the contact page and we will size it with you.