Camera sync pulse missing: fix the acquisition timeout

You start the synchronized driver for a master/slave camera pair and the log repeats two lines: 'acquisition timeout, restarting!' and 'waiting for accurate frequency, current estimate: -1'. The master camera streams; the slave sits in hardware trigger mode and no pulse ever reaches it. This guide decodes that message, ranks the causes, gives the line settings and wiring that fix them, and shows the arithmetic that tells you timing is not the problem.

What an estimate of -1 is telling you

A synchronized driver does two things a single-camera driver does not. It puts the slave camera into hardware trigger mode, and it measures the frequency of the shared pulse train to prove the pair is locked. The estimator starts at -1 — its no-measurement value — and only climbs when pulses arrive.

When no pulse reaches the slave, no frames come back, the grab times out, and the driver restarts the acquisition. That is the repeating 'acquisition timeout, restarting!' warning. The master, which nobody triggered, keeps free-running the whole time and quietly hides the fault: half your rig looks healthy. Both cameras need their own parameter set because of exactly this free-run default trap.

Watch for a second trap after a crashed run: the slave can stay parked in trigger mode, so even the SDK viewer shows no image. Stop acquisition cleanly before you close any test program — the USB camera timeout on reopen fix shows the pattern — and power-cycle before you conclude the hardware is broken.

The causes, ranked by probability

Three causes cover almost every one of these timeouts:

1. The master never emits a strobe. Launch files for synchronized drivers usually assume an external pulse generator feeding both cameras. With no generator and no strobe configured, the slave starves. Master and slave need different line settings; a symmetric configuration cannot work.
2. The slave's trigger source points at nothing. Line names and counts differ between camera families, and the default in your parameter file may name a line with no wire on this camera.
3. The wiring or the edge is wrong. Conductor on the wrong pin, no common ground, an opto-isolated input whose return path is open, or a TriggerActivation watching the opposite edge of the strobe.

A rarer fourth cause: a trigger filter on the slave set high enough to swallow the strobe. Rule it out after the first three.

If a readback shows values you did not write, something else wrote them: the trigger mode and source readback fix shows how to find the value the camera actually holds.

Fix the pair in seven steps

1. Reset both cameras. Power-cycle or load factory defaults so no stale trigger settings survive from the crashed run.
2. Prove each camera alone. Free-run both cameras one at a time in the SDK viewer, on the cables and exposure settings you plan to use. A camera that will not stream untethered will not trigger either.
3. Configure the master's strobe. LineSelector picks the line, LineMode sets it to Output, LineSource drives it. ExposureActive gives a pulse exactly as long as each exposure; a fixed-width pulse gives you any width you choose. Note the idle level. The same master-strobe scheme is how you trigger two USB3 cameras from one pulse.
4. Wire the strobe to the slave's trigger input and tie the two grounds together. If the slave input is opto-isolated, its return pin completes the circuit — one wire is not enough. A power-and-I/O cable with one core per line keeps this tidy; the camera cables category lists them by connector and length.
5. Configure the slave's trigger. TriggerMode on, TriggerSource at the wired line, TriggerActivation on the strobe's edge, TriggerDelay 0, filter off or minimum. Then set AcquisitionMode to Continuous — the slave still acquires continuously, with each pulse starting one frame. A camera that ignores its trigger is usually in the wrong acquisition mode; the acquisition mode check takes two minutes.
6. Read everything back. Write, then read the trigger and line parameters from the camera and compare against intent; the camera's answer is the truth, not your parameter file. The GenICam line settings checklist walks the readback.
7. Launch and watch the estimate. It should leave -1 within a few pulses, settle at your configured frame rate, and the restart warnings stop.

Worked example: 30 Hz pair, 2 ms exposures, exposure-active strobe

Take the numbers before you blame timing. Inputs, straight from a typical configuration:

• Target frame rate f = 30 Hz per camera, a common rate for vision-guided pick and place.
• Master exposure t_exp = 2 ms, from the master camera's exposure setting.
• Strobe width t_strobe = 2 ms, because an ExposureActive pulse lasts as long as the exposure.
• Slave trigger delay t_delay = 0 µs, the starting value.

The rule: each pulse period must fit the busy window — strobe plus delay plus exposure — with margin, or a pulse lands while the sensor is still busy and the slave drops a frame.

Arithmetic:

• T = 1 / 30 Hz = 0.0333 s = 33.3 ms
• busy = 2 ms + 0 µs + 2 ms = 4 ms
• margin = 33.3 ms - 4 ms = 29.3 ms, so 88% of each period sits idle
• f_max = 1 / 4 ms = 250 Hz

Decision: at 30 Hz the pair holds 29.3 ms of slack, so an estimate stuck at -1 is not marginal timing. No pulse is arriving at all; go fix configuration and wiring, not the pulse period. The threshold that matters is 250 Hz: above it, this strobe scheme cannot work because the period is shorter than the busy window. If you need that rate, cut the strobe to a fixed 1 ms pulse and recompute. As a working rule, keep the busy window under half the period — 16.7 ms here — so jitter never eats the margin.

Wiring checks that catch silent failures

Meter at the slave end, not the master end. A pulse present on the master's pin but absent at the slave's connector convicts the cable, the crimp or the pin choice.

Grounds first. A strobe referenced to the master's ground and a slave input floating on its own ground reads noise, not signal; tie the grounds and the pulse cleans up.

Short runs win. Keep the sync line to a metre or two of shielded cable, with about five metres as the sensible ceiling, routed away from servo drives; a logic pulse run next to a motor cable picks up edges nobody sent.

One core per function. Strobe, ground and, for an opto input, its return each get their own conductor: the LS-CBL-0300 M8 8-pin power and I/O cable breaks out all eight cores to open ends over 7 m of drag-chain cable.

Then close the loop electrically before touching software again. Run the slave in trigger mode in the viewer while the master free-runs and strobes: it should deliver exactly one frame per pulse. A slave that does this is configured correctly, and any remaining fault sits on the master's output side.

Prove the lock before you calibrate

• The frequency estimate reads your pulse rate — about 30 Hz in the worked example — instead of -1.
• Restart warnings stop, and the two frame counters advance together.
• Header stamps arrive in matched pairs: the synchronized driver stamps matched frames identically. Stamps that drift apart mean a dropped pulse or a slave that fell back to free-running; the stream recovery check covers the failure modes.

Then calibrate. A rig that jolted during capture calibrates badly and keeps missing the same small patch of the scene; if accuracy got worse after hardware syncing, the calibration-versus-trigger fix names the trigger parameters behind it.

Still timing out: isolate the half that fails

Swap the roles. Make the other camera the slave. If the new slave locks at once, the original slave's configuration was at fault; if it starves too, the master's output line or I/O port is the problem.

Drive the slave from a pulse you control — a signal generator or a PLC output — with the master out of the circuit. A slave that locks to your pulse is proven good. The TTL fan-out wiring guide shows how to drive several cameras from one pulse source safely, and the serializer-board trigger routing covers one input feeding six cameras.

Separate software errors from camera errors. A container line such as 'Could not find requested resource in ament index' means the launch file references a node or package your workspace never built: remove the outdated nodes, rebuild, retest — no camera or wire involved.

And keep the launch honest as the rig grows: both cameras' line settings, trigger parameters and calibration files belong in one parameter block, as the multi-camera ROS launch planner lays out.

Without a wire: clock sync is not exposure sync

PTP over GigE aligns the two cameras' clocks, which makes timestamps comparable across the streams — the PTP setup for GigE cameras walks through master, slave and timestamp checks. What clock sync does not do is start both exposures together; sensor timing still differs by the gap between each camera accepting its own start. For stereo overlap, keep the shared strobe and treat PTP as the timestamp layer underneath it. On a static or slow scene, a software trigger at a modest rate is a workable compromise, with a few milliseconds of skew from host scheduling.

Parts for a reliable triggered pair

Both cameras need a global shutter: a rolling-shutter sensor exposed by a short strobe smears any motion in the scene. The camera finder filters by shutter type, interface and resolution.

The MV-CU020-90GC is a 2.5 MP GigE camera with a global shutter on a 1/1.7-inch sensor — a proven master or slave for a triggered stereo pair.

When the disparity map needs more pixels, the MV-CH120-11UC moves the pair to 12 MP over USB3, still global shutter.

For the data runs, keep them short and flex-tolerant where the camera moves: the LS-CBL-0219 is a 3 m USB3.0 camera cable with high-flex, drag-chain construction.

Once both cameras lock to one pulse, the rest is ordinary engineering: mount, light, calibrate. Start from the area scan cameras and the cable finder, match the whole chain in the camera configurator, or send us your trigger diagram through the contact page. The systems topic page collects the rest of the trigger fault-finding guides.