Five cameras on one Arduino square wave should capture in lock-step at 50 frames per second. Instead the recordings drift apart: some run 2x fast, some half speed, and rarely do all five agree. The fault is almost never the pulse itself. It is the race between the trigger period and each camera's exposure time, plus whatever sits between the pin and the camera input. This guide gives the timing rule with the arithmetic, the settings to apply on every camera, the wiring that keeps the edges sharp, and the bandwidth check the host has to pass.
What the 10 ms/10 ms wave actually sends
The period is the high time plus the low time: 10 ms + 10 ms = 0.020 s. A rising edge arrives every 0.020 s, which is 1 / 0.020 s = 50 edges per second, and a camera triggering on the rising edge captures one frame per edge. The high time matters on its own only when the exposure is set to follow the pulse width. The frame-rate field in the capture software is playback metadata: the wire, not the number in the settings box, sets the real capture rate. When 25 edges get through and the file claims 50 fps, every clip plays 2x fast.
The rule: exposure plus delay must fit inside the period
A hardware-triggered camera cannot start a new frame while the old one is still exposing. An edge that lands during exposure is ignored, not queued. The period is therefore a hard budget: exposure time plus trigger delay plus any readout overlap must fit inside it with margin. Just under the limit is not under the limit in practice — an exposure 1 ms short of the period leaves 1 ms of margin, and a camera with 1.5 ms of trigger delay misses every second edge anyway.
That is also why the cameras disagree with each other. Each input has a slightly different delay, so a thin margin makes each camera drop a different fraction of edges: some run at 50 fps, some at 25, and the recordings come out different lengths. Where a camera documents a TriggerOverlap mode you can trigger through a long exposure; where a camera lacks the option, the half-period rule is the setting that works across the whole set. The same mechanism is why GigE frame rates drop at longer exposure times on any triggered camera.
Worked example: an exposure as long as the period
The inputs:
- High time 10 ms, low time 10 ms — the generator setting, so T = 0.020 s.
- Exposure 20 ms — the camera setting at the edge of the limit.
- Activation on the rising edge, nominal trigger delay 0 ms.
The rule: the camera accepts an edge only while idle, and the next accepted edge starts the next frame. The arithmetic:
- Period: 10 ms + 10 ms = 0.020 s, so the trigger rate is 1 / 0.020 s = 50 Hz.
- Busy time per frame: 20 ms exposure + 0.1 ms trigger delay = 20.1 ms.
- The edge at t = T falls inside that window and is ignored; the camera catches the edge at t = 2T = 0.040 s.
- Real frame period 0.040 s: 1 / 0.040 s = 25 fps.
- Playback at the claimed 50 fps: 2x speed, half the duration.
The decision: set the exposure to 10 ms, i.e. T / 2. The margin is 0.020 s − 0.010 s = 0.010 s, ample against sub-millisecond trigger delays. If the scene truly needs the longer exposure, slow the wave so the high and low times each equal twice the exposure — T = 0.040 s, 25 Hz — and the margin returns to one exposure length.
Why the recordings disagree with each other
- Half duration and 2x speed: that camera accepted 25 edges per second while the file claims 50 — every second edge landed during exposure.
- Identical durations that still play 2x: the file carries the configured rate, not a measurement of delivered frames; playback speed is only as honest as that metadata.
- Half speed: the metadata claims fewer frames per second than were delivered, so the player stretches the real frames over a longer run.
- Cameras desynced while rates look correct: the trigger paths differ. A relay board closes its contacts milliseconds apart and bounces before settling, so each channel starts exposing at a different instant, and no software fix recovers that after recording.
Missed edges from an external pulse source are a whole fault class; the diagnosis runs the same way when the pulse comes from a PLC output instead of a microcontroller.
Set the trigger identically on all five cameras
On every camera: trigger mode on, source line set to the wired input, activation on the rising edge, exposure mode timed, overlap off unless you have read what it does on that model. Mixed settings across a five-camera set look exactly like random desync. When one camera ignores the wire completely, its line configuration is the first suspect: the hardware trigger source not detected checklist walks the GenICam line settings.
The self-protecting alternative is pulse-width exposure. The camera then exposes while the line is high, so the 10 ms high time becomes a 10 ms exposure that fits the period identically on every camera, with nothing to tune per unit. Why trigger pulse width sets your exposure time explains the mode, and trigger call versus exposure time shows how the intervals stack.
Wire the fan-out: direct or opto, never a relay
An electromechanical relay takes milliseconds to close and bounces before it settles, and the delay differs between channels and between closures. Exposures that must align far tighter than that cannot survive it. Drive each camera's opto-isolated trigger input straight from an Arduino pin, or through a transistor buffer once the combined input current approaches what a pin is specified to source — about 20 mA on an Uno. Tie the grounds for a direct drive and keep the wires short; the camera inputs bring their own isolation, so the relay adds nothing you need.
Long cable runs round the edges off, and a slow or noisy edge can double-trigger an input; conditioning the line with a Schmitt trigger restores a sharp square wave. The Arduino TTL fan-out guide covers the per-camera wiring.
Host ports and bandwidth for five cameras
Work the host budget before wiring. A 2.5 MP mono 8-bit frame is roughly 2.5 MB, so at 50 fps each camera pushes 2.5 MB × 50 = 125 MB/s — past a GigE link's usable share of its 125 MB/s line rate once protocol overhead is paid. Cut the frame rate, crop the sensor, bin the pixels, or move to 2.5G or 10G hardware: how much frame rate fits on GigE sizes one link, and two GigE cameras on one host extends the budget to several.
Give each camera its own port rather than a shared switch hop. Assigning cameras to ports keeps the mapping stable between boots, setting the packet size before acquisition prevents mid-frame drops, and multiple cameras on one trigger arriving incomplete is the failure this wiring prevents.
The MV-GE1104 is a 4-port GigE frame grabber. A five-camera set uses that card plus one more port from elsewhere on the host, or two such cards. The MV-GE2002P is a dual-port PoE NIC; the MV-GT2104 is a quad-port copper 10GbE NIC for a 10GigE step up. Both ranges live in the frame grabbers category.
- Interface
- GigE
- Ports
- 2 ports
- Interface
- GigE
- Ports
- 4 ports
- Interface
- 10GigE
- Ports
- 4 ports
Checks before you record
- Exposure at or below half the period — 10 ms on this wave — so the margin absorbs trigger delay on every camera.
- Identical trigger settings across the set: same source line, same rising edge, timed exposure.
- No relay between pin and camera; direct or opto-isolated drive only.
- Frame-count test: a 10 s run at 50 Hz must deliver 1 / 0.020 s × 10 s = 500 frames from every camera; 250 means every second edge is being missed.
- Flash test: fire one short flash mid-run; the lit frame must sit at the same index in all five recordings.
- Probe the wave at the last camera's input, not at the Arduino pin — voltage drop and edge rounding live on the wire.
When to change the design instead
Low light is the legitimate reason an exposure grows past half the period. Change the rate, not the rule: with an exposure equal to one period length keep the trigger at or below 1 / (2 × 0.020 s) = 25 Hz, set as 20 ms high and 20 ms low. You trade temporal resolution for edges that every camera catches.
Shutter type matters at these rates too. A rolling shutter exposes rows in sequence and skews fast marker motion, so choose a global shutter sensor for capture. The MV-CU020-90GC is a 2.5 MP GigE color camera with a global shutter and a C-mount.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- Up to 3 MP
For the wider choice, browse the area scan cameras range, use the camera finder, or start at the camera step of the configurator. If the frame budget will not close, send the exposure, resolution and camera count through the contact page and we will size the link with you.
Questions
Can one Arduino output drive five camera trigger inputs at once?
Only within the pin's current rating, about 20 mA on an Uno, and each opto-isolated camera input draws its own share of that. For five cameras use one pin per camera, or add a transistor or MOSFET buffer per line so the microcontroller only switches the buffer. Keep grounds common for a direct TTL drive, and never route the pulse through a relay board.
Why do triggered recordings play back at double speed?
The camera recorded 25 real frames per second because every second rising edge arrived while it was still exposing, but the file header still claims 50 fps. The player trusts the header, so 25 frames per second get shown as if 50: motion runs 2x fast and the clip lasts half as long as the scene did. Cutting the exposure to half the period restores the full rate.
Does trigger overlap remove the exposure limit?
Only on cameras that document the mode and what it permits. Overlap lets a new trigger take effect during the current exposure, so the full trigger rate can hold at longer exposures. In a mixed set, one camera without the option drops to half rate alone and breaks the sync, which is why the exposure-below-half-period rule remains the setting that works on every camera.
Should exposure follow the trigger pulse width or a timer?
Pulse-width exposure is the self-protecting choice for a shared square wave: the camera exposes while the line is high, so a 10 ms high time gives a 10 ms exposure on every camera, always shorter than the full period, with nothing to configure per unit. Timed exposure gives you control of the value, but you then own the delay-and-margin budget yourself.
What trigger rate fits an exposure as long as the period?
Apply the half-period rule in reverse: 1 / (2 × 0.020 s) = 25 Hz, configured as 20 ms high and 20 ms low. That leaves an exposure length of margin, which survives trigger delay and jitter. At 50 Hz the same exposure has no margin at all. Many motion capture set-ups tolerate 25 Hz markers far better than a half-rate stream that cannot be aligned.
How do I prove all five cameras are synchronized?
Two checks. First, counts: record 10 s at 50 Hz and require exactly 500 frames from every camera, because 250 means that one is missing every second edge. Second, an event: fire one short flash during capture, and the bright frame must occupy the same frame index in all five recordings. Together the checks catch both missed edges and per-camera start stagger.