Frame trigger ready timeout: set up a USB stereo trigger pair

You wired the master camera's output to the slave's trigger input, everything worked in the vendor's viewer tool, and the moment your acquisition program starts, the master grabs at full rate while the slave reports a frame trigger ready timeout. That pattern has one dominant cause: the parameters your program actually runs are not the ones you tuned by hand, and an automatic exposure routine is fighting the trigger. On a moving rig — a vehicle, a cart, a robot arm — the fix is to stop relying on saved camera sets and set every trigger and exposure parameter explicitly at startup. This guide gives you the wiring, the exact GenICam parameters, a worked timing example for a car-mounted stereo pair, and the checks that prove both cameras capture on the same edge.

What the frame trigger ready timeout means

With TriggerMode On, every grab request puts the camera into the frame trigger wait state, and no image exists until an accepted edge arrives on the trigger source. A frame trigger ready timeout means that edge never arrived — or arrived while something else wrestled the camera for control. The second line of the error is the tell. A driver that reports it can't calculate current brightness is running an automatic exposure loop: the loop asks for frames to measure brightness, a triggered camera cannot deliver frames without edges, and each grab burns through to the timeout. The brightness message is a symptom, but it names the fight.

In order of likelihood, the causes are:

1. Auto exposure or continuous brightness is on in the program. You set ExposureAuto Off by hand in the viewer; the program turned it back on from its own configuration file or driver defaults.
2. The saved user set did not survive the program start. A driver that loads a startup set and then writes its own parameters leaves the slave with TriggerMode Off, the wrong trigger source, or exposure control back on auto.

Less often, the edge genuinely never reaches the slave, which is a wiring or line-selection fault; the checks near the end cover it. If a single camera times out with no trigger wired at all, that is the software-trigger variant — see camera trigger ready timeout: diagnose software triggering.

What you need

• Two identical USB3 Vision cameras, each with a trigger input and at least one programmable output line. Pick from the area scan cameras and buy two of one model; a mixed pair doubles the parameter work for no gain.
• One trigger and power cable plus one data cable per camera — the camera cables range covers both. On a vibrating platform choose drag-chain rated builds, so movement works the connector rather than the solder.
• A multimeter or an oscilloscope, to prove the strobe exists on the wire before you blame the software.

For a rig that moves, choose a global shutter on both cameras. The MV-CH120-11UC pairs a 12 MP global shutter with USB3 on a 1.1" sensor and C-mount — buy two of it.

For bench rigs or slow scenes, a rolling shutter costs nothing: the LS-CMR-0166 raises resolution to 4000 × 3000 over USB3 on a 1/1.7" sensor. The shutter paragraph in the worked example explains where it belongs.

The LS-CBL-0208 carries trigger and power between the two cameras; the LS-CBL-0219 feeds each camera's USB3 data link and is high-flex rated for drag chains. Order two data cables, one per camera.

Set the pair up: eight steps

The scheme: the master free-runs at your chosen rate and raises its ExposureActive strobe for every exposure, while the slave sits in trigger mode and fires on that strobe's rising edge. One edge starts both exposures, so the pair runs locked to within a few microseconds. The hardware sync two USB cameras: trigger both cameras together walkthrough covers a second wiring variant worth knowing.

1. Reset both cameras. On each camera set UserSetSelector to Default and run UserSetLoad. Everything that matters is set explicitly below, so nothing tuned by hand survives to surprise you.
2. Take exposure control away from the camera — both units. Set ExposureAuto to Off and GainAuto to Off. On the slave this single step removes the brightness loop behind most frame trigger ready timeouts.
3. Choose the numbers before you type them. Work the timing from speed and a blur budget; the worked example below lands at ExposureTime 1.8 ms and 20 fps for a rig moving at 10 km/h.
4. Make the master free-run and strobe. On the master set TriggerMode Off, AcquisitionFrameRateEnable On and AcquisitionFrameRate 20. Then select the output line you wired with LineSelector and set its LineSource to ExposureActive, so the line rises for every exposure the master starts.
5. Make the slave wait for that edge. On the slave set TriggerMode On, TriggerSource to the input line you wired, TriggerActivation RisingEdge and TriggerDelay 0. Set ExposureTime 1800 µs here too — trigger mode does not free you from choosing an exposure.
6. Wire the pair. Master output pin to slave trigger input pin, and ground to ground between the two connectors. Without the shared ground the slave's input has no reference and never sees an edge. The ExposureActive pulse is as wide as the master's exposure — 1.8 ms here, 18 times the 100 µs floor to hold on any trigger line.
7. Make the program own the parameters. This step fixes the timeout. Remove the startup-user-set load from your launch configuration — a ROS launch file, a YAML config, whatever your driver reads at start — then write, from the program itself on every start: ExposureAuto Off and GainAuto Off, ExposureTime, the slave's TriggerMode, TriggerSource, TriggerActivation and TriggerDelay, the master's frame rate and LineSource. Give each camera a DeviceUserID, left and right, so the program binds the right camera to each role. If the driver runs its own brightness control, switch that off as well: one writer per parameter, and it must be you.
8. Verify before you trust it. Start the program and read the parameters back; log TriggerMode, TriggerSource and ExposureAuto from both cameras. The slave's frame counter should advance one for one with the master's rate across a few thousand frames. Compare camera-embedded timestamps, not host arrival times: the USB stack adds milliseconds between arrival and delivery, while a shared edge with TriggerDelay 0 holds the two exposures within single-digit microseconds.

A worked timing example at 10 km/h

The rig: a vehicle at 10 km/h, a stereo pair feeding a matching algorithm, and a blur budget of 5 mm.

• Speed: 10 km/h ÷ 3.6 = 2.78 m/s.
• Exposure: 5 ÷ 2.78 = 1.8 ms. Check it: 2.78 m/s × 1.8 ms = 5.0 mm of blur — the budget, exactly.
• Frame period: 1000 ÷ 20 = 50 ms at 20 fps. The exposure takes 1.8 ÷ 50 = 3.6% of the period, so readout has margin and the master holds 20 fps without dropping frames.
• Pulse width: ExposureActive makes the strobe as wide as the exposure, 1.8 ms — well clear of the 100 µs floor.
• Sync skew: one rising edge with TriggerDelay 0 starts both exposures within a few microseconds. At a 10 µs skew the scene moves 2.78 m/s × 0.01 ms = 0.03 mm between the two frames, about 170 times smaller than the blur budget and irrelevant to matching.

One more term belongs in the budget: shutter type. A global shutter exposes every row at once, so both cameras see the whole frame at the same instant. A rolling shutter reads rows sequentially, of order 20-30 ms across a 6 MP sensor at usual readout clocks, so at 2.78 m/s the scene shifts roughly 55-85 mm between the first and the last row of one frame. The sync arithmetic still holds per row, but dense stereo matching degrades — which is why the moving-rig pick above is a global shutter camera and the rolling shutter model suits bench work and slow scenes.

Bandwidth, because stereo doubles the data rate. A 12 MP mono frame at 8 bit is about 12 MB, so 20 fps costs roughly 240 MB/s per camera. Run one camera per USB3 host controller, since a port sustains about 350-400 MB/s in practice; 30 fps would demand about 360 MB/s, right at that ceiling. A 6 MP pair needs about 120 MB/s per camera at 20 fps and is comfortable on one controller each.

Decision for this case: global shutter on both cameras, ExposureTime 1.8 ms on both, AcquisitionFrameRate 20 on the master only, the strobe as the slave's trigger source, one USB3 controller per camera. Blur and skew then sit far inside the budget at 10 km/h, and the arithmetic scales: halve the budget to 2.5 mm and the exposure halves to 0.9 ms. The wider arithmetic for triggered rates is in camera hardware trigger frame rate with external pulses, and trigger call versus exposure time: understand capture timing explains why the exposure window, not the request moment, defines the blur.

Saved sets versus runtime parameters

Why did the viewer work and the program fail? A user set is a snapshot. The viewer wrote your settings into it and applied them, then touched nothing else, so the camera stayed in the state you tuned. Your program is a second writer: it loads the set — or not — and then applies driver defaults, a config file and often an auto exposure. The last writer wins, and the last writer is rarely you.

Keep a saved set as the bench baseline if it helps; save camera parameters as a user set that loads on startup shows the mechanics. For the triggered slave, the capturing program must write the control parameters itself on every start: exposure control off, trigger parameters on, then readback. If TriggerMode, TriggerSource or ExposureAuto reads back as anything other than what you set, a second writer is still active — find it in the driver's configuration before touching the camera again. Camera trigger mode source readback mismatches is the diagnostic for exactly that disagreement.

Write the capture side as a bounded wait: request one frame, wait for the edge, fail loudly on timeout rather than hanging. Hardware triggered image acquisition in Python shows that loop shape.

If the slave still times out

Work down this list; each test costs a minute.

1. No common ground. Measure continuity between the two connectors' ground pins. A floating input sees nothing; this is the most common wiring miss.
2. The master is not strobing. LineSource may still sit at Off. Measure the master's output wire against ground while it free-runs.
3. Wrong line selected. TriggerSource must name the line you actually wired. Check against the connector drawing in the camera's I/O documentation, and check the cable matches the connector on both ends.
4. Activation mismatch. The slave wants RisingEdge and the master's ExposureActive strobe delivers a rising edge — if either side is set differently, the edge is never accepted.
5. Pulse too short for the line. Raise the pulse to 1 ms. At a 50 ms period that costs 2%, nothing.

Damage or not, a line that refuses to fire needs the electrical triage in camera GPIO wiring: prevent damage and triage power faults, and a line the driver cannot see at all is usually a camera-side setting — hardware trigger source not detected: check GenICam line settings walks that fault.

Pre-flight checklist

Run this list before the first run at speed:

• Same model on both cameras; defaults loaded, then program-written parameters only.
• Global shutter on both for the moving rig; rolling shutter accepted only for bench or slow scenes.
• ExposureAuto and GainAuto Off on both; ExposureTime numeric on both.
• Slave: TriggerMode On, TriggerSource correct, TriggerActivation RisingEdge, TriggerDelay 0.
• Master: TriggerMode Off, AcquisitionFrameRate set, LineSource ExposureActive on the wired output.
• Common ground measured between the two connectors.
• Strobe proven on the wire — the multimeter trick counts.
• No startup-user-set load left in the launch configuration.
• Readback logged after startup: TriggerMode, TriggerSource and ExposureAuto as set.
• Slave frame counter tracks the master's rate over a few thousand frames; camera-embedded timestamps within microseconds; first run at reduced speed, then full pace once blur stays in budget.

That is the whole build: a wired edge, parameters the program owns, and a timing budget the speed dictates. Choose the pair in the camera configurator, which matches sensor, mount and cable options as you decide, or browse the USB3 area scan cameras finder. For the neighbouring subjects — exposure control, GPIO wiring, trigger timing — the cameras topic page collects the set, and the contact page reaches the applications team when you want a parameter list reviewed; expert support is included with every order.