Arduino trigger multiple cameras: fan out one TTL pulse safely

Every rig that reconstructs motion or inspects a moving part from several angles needs the same thing at frame zero: every camera opening its shutter on the same electrical edge. An Arduino Uno makes a clean pulse source for that edge, but its output pins are small parts and each camera trigger input draws real current. Wire six cameras straight onto one pin and the usual failure is quiet, not dramatic: a pin that works on the bench and dies in the rig, plus a burst of phantom frames at every power-up. This guide gives you the current budget that decides direct-drive or buffered, the wiring order that keeps grounds first, a fixed-rate sketch, and the scope and frame-count checks that prove every camera fired together.

The current budget: 20 mA per pin, 200 mA per chip

The Uno's ATmega328P documentation sets three limits: 20 mA continuous as the recommended output per I/O pin, 40 mA as the per-pin absolute maximum, and 200 mA summed across the whole chip. Design to 20 mA. The gap up to 40 mA is fault margin, not headroom for one more camera.

A camera's opto-isolated trigger input is an LED behind a series resistor. Driven from a 5 V rail, most such inputs draw 2-10 mA. The LED itself tolerates far more — 60 mA is a common optocoupler forward-current rating — so an overloaded input usually survives while the Arduino pin does not. A non-isolated logic input at that level draws only microamps but demands a common ground and a genuinely 5 V-tolerant level.

The rule that follows: one pin drives inputs totalling 20 mA or less. At 5 mA per camera that is four inputs; at 10 mA per camera, two. Any count above that, or any input you have not measured, goes through a buffer.

Worked example: six cameras on one Uno pin

The case: a motion-capture style rig of six area scan cameras, each triggered on its opto-isolated input from one Arduino Uno pin driving at the rail voltage.

Inputs, with their sources:

• Six opto-isolated camera inputs driven at 5 V — the rig the capture software specifies, one shared edge for all six.
• 5 mA per input: the mid-point of the 2-10 mA typical range for opto-isolated trigger inputs.
• 20 mA recommended and 40 mA absolute maximum per pin, 200 mA per chip: the ATmega328P documentation.

The rule in words: keep the continuous current leaving one pin at or below 20 mA, counting each camera's input current once, because a paralleled pin sources every camera's LED current at the same moment.

Direct paralleling misses the design limit by half again, and the pessimistic draw is a dead output stage waiting for the middle of an experiment. Buffered, the Uno pin sees microamps, each channel runs at one per cent of its rating, and the chip total stays near zero.

Decision: above two unmeasured inputs, or above four measured 5 mA inputs, fan the pulse through one buffer channel per camera. Two cameras direct is the comfortable ceiling for an unbudgeted rig — even at a pessimistic 10 mA each, the pair sits exactly at the 20 mA design limit.

What you need

On the bench: one Arduino Uno or any 5 V logic board, one fan-out buffer with a channel per camera — an eight-channel darlington array handles eight cameras in one package — plus a 10 kΩ resistor for the input pull-down, a supply at the Uno's output level for the trigger side, and a terminal strip to land the wires.

Each camera needs a hardware trigger input and, for a shared edge to freeze the same instant across the whole frame, a global shutter. This 2.5 MP GigE model is the class of area scan camera the wiring below suits:

Between terminal strip and camera runs a power and I/O cable with open leads on the trigger side, so the pair lands on your terminals; the camera power and I/O cables page collects them. An M8 8-pin connector to open leads is the common layout:

Cameras whose I/O breaks out on a 12-pin connector take the same wiring on the matching cable:

Cable selection for a pulse source — shielding, length, when differential is worth it — has its own walk-through: camera trigger cable selection for a signal generator.

Wire the fan-out: grounds first, then signal

1. Map the chain before touching a wire: one Arduino output pin to the buffer input, then one buffer channel per camera, with a note of which camera hangs on which channel. A labelled map turns a six-camera fault into a one-minute probe job.
2. Power everything down and connect grounds first. Tie the trigger supply's ground to the Arduino's GND, and for any non-isolated input tie the camera's signal ground to the same rail before the signal wire lands. An opto-isolated input closes its loop entirely on the Arduino side, which is why it is the safer choice between bench gear and a machine.
3. Wire the chosen pin (the sketch below uses pin 2) to the buffer input and fit the 10 kΩ pull-down from input to ground. While the Uno resets after power-up its GPIO pins float; an unpulled buffer input chatters and fires a burst of phantom triggers into every camera.
4. Land each camera's open end: the input's positive wire to the positive rail of the trigger supply — or up to the camera input's rated maximum, commonly 24 V, the better choice on long runs — and the negative wire to that camera's buffer channel. A darlington channel holds roughly 1 V across itself when on, so the rail voltage reaches the camera about a volt lower, still above the 3.3 V minimum most inputs specify.
5. Keep camera cable lengths equal where skew matters. Signal moves about 5 ns per metre of cable, so metre-level differences cost nanoseconds; it is unmatched stubs and their reflections that double-trigger, and the scope check below catches them.
6. Configure every camera for external triggering: trigger mode On, trigger source set to the line you wired, activation on the rising edge — the standard GenICam feature names every SDK exposes under its own menus. The per-camera walk-through, including the free-run default that silently ignores your pulses, is in hardware trigger configuration per camera: stop the free run default.

The sketch: one pin, a fixed pulse rate

const int TRIG_PIN = 2;                // Arduino output to the buffer input
const unsigned long PERIOD_MS = 500;   // trigger period: 500 ms = 2 pulses per second
const unsigned int  PULSE_MS  = 1;     // high time per pulse

void setup() {
  pinMode(TRIG_PIN, OUTPUT);
  digitalWrite(TRIG_PIN, LOW);         // idle low before the loop starts
}

void loop() {
  digitalWrite(TRIG_PIN, HIGH);
  delay(PULSE_MS);                     // 1 ms high
  digitalWrite(TRIG_PIN, LOW);
  delay(PERIOD_MS - PULSE_MS);         // 499 ms low
}

All three values carry declared types and initial values: TRIG_PIN feeds the buffer input, PERIOD_MS sets the rate, PULSE_MS sets the high time. One millisecond is conservative — industrial trigger inputs commonly accept pulses a few microseconds wide — and it survives any cable. For sub-millisecond pulses, switch the high time to delayMicroseconds(), which takes microseconds and accepts up to 16383 µs in one call.

The test that proves the sketch: scope the camera end of the longest cable and measure 1.0 ms high and 499 ms low, repeating — exactly what PERIOD_MS = 500 and PULSE_MS = 1 specify. Without a scope, count frames: two triggers per second means every camera captures two frames per second, no more and no fewer.

delay() steps in whole milliseconds and digitalWrite adds a few microseconds per call, so the edge carries sub-millisecond wobble at most. Motion capture and most inspection never notice; the tighter options come at the end.

Verify every camera fired together

Three checks, ordered by what they catch:

• Level and timing at the worst cable: pulses at the drive level and the specified width at the far end of the longest run. A ringed or doubled edge is a reflection; add a series damping resistor at the driver (start near 33 Ω) or shorten the stub.
• One moving target, one frame index: sweep a marker through every field of view; each camera must catch it in the same numbered frame. A camera one frame late has missed or queued a pulse.
• Frame timestamps against the pulse period: what the stamps measure and how to read them is in camera buffer timestamp latency: interpret frame timing.

If one camera misbehaves, the good-bad swap sequence for a triggered pair is in dual camera hardware trigger troubleshooting.

Common mistakes

• Signal before ground: the undefined input level produces random triggers that look exactly like a software bug.
• No pull-down: a boot burst of throwaway frames in every camera, on every power cycle.
• Counting pins but not the chip: eight outputs at 25 mA each already total 200 mA, the whole-chip absolute maximum. A fan-out board never gets near that — one pin drives one buffer input — but mixed loads on one board can.
• Feeding six trigger LEDs from a shrinking rail: the Uno's 5 V rail shares a USB port's 500 mA with the board itself. Six inputs at 5 mA draw 30 mA and are fine; a heavier load moves to its own supply with its ground tied to the Arduino.

When the delay loop is the wrong tool

A delay()-paced loop holds trigger rates up to a few hundred per second steady, and motion capture and most inspection run well inside that. Three cases need more:

• Microsecond-level exposure alignment: move the pulse train onto a hardware timer in output-compare mode, so the edge comes from the timer rather than the loop.
• Pulse rate against camera frame time: pulses faster than the camera can complete an exposure are queued or dropped; the arithmetic between pulse period and achievable frame rate is in camera hardware trigger frame rate with external pulses.
• Long or electrically noisy runs: drive 24 V into the opto input instead of the rail level, or use a differential RS-422-style trigger where the camera accepts one — the higher swing and the balanced pair bury noise a single-ended edge cannot.

USB cameras take the same shared-pulse wiring in pairs; the direct two-camera case is in hardware sync two USB cameras: trigger both cameras together.

Build the rig

Count the cameras, allow 5 mA per input, and pick the fan-out from the worked example: direct below 20 mA of measured load, one buffered channel per camera above it. The camera finder filters by interface, shutter and resolution; the accessories finder lists I/O cables by connector and length.

If a rig still resists after the checks above, the contact page reaches the applications team.