4. Trigger and strobe generation

In a high-speed video system, the trigger is the moment the acquisition pipeline commits to capturing a defined window of time. Everything downstream — exposure, sensor readout, strobe illumination, timestamping, and multi-camera alignment — is anchored to that decision. A trigger that arrives late, jitters, or is misinterpreted by even a few microseconds will corrupt the entire capture, because at 1,000–10,000 fps a single frame interval is only 100–1,000 µs. This chapter explains how triggers and strobes are generated, how exposure is synchronized to them, and how to compensate for the latency that inevitably accumulates between the electrical event and the photons hitting the sensor.

Hardware triggers: deterministic by construction

A hardware trigger is an electrical edge delivered directly to the camera's trigger input (typically a TTL/RS-422 line, an opto-isolated input, or a dedicated GPIO on the frame grabber). Because it bypasses the host operating system, it avoids the scheduling jitter that plagues software paths. The camera's trigger controller latches the edge and starts the exposure sequence within a specified trigger-to-exposure latency, usually documented as a fixed value plus a small uncertainty window.

Three hardware trigger modes dominate high-speed work:

  • Edge trigger — a rising or falling edge starts one acquisition. The camera captures a fixed number of frames (or a fixed duration) and then re-arms. This is the workhorse mode for impact, drop, and fracture tests.
  • Level/gated trigger — acquisition runs while the input is asserted. Useful when the event duration is unknown and you want to record continuously until the signal de-asserts.
  • Trigger with pre-trigger buffer — the camera continuously records into a circular buffer; the trigger marks a point in that buffer, and a configurable number of pre-trigger frames are retained. This is essential when the event of interest occurs before the trigger edge can be generated (for example, a crack initiating before the acoustic emission sensor crosses threshold).

For multi-camera rigs, the trigger source should be a single master clock or a dedicated trigger generator that fans out one edge to all cameras simultaneously. Daisy-chaining triggers through cameras introduces cumulative propagation delay and should be avoided; use a star topology from one generator instead.

Software triggers: flexible but jittery

A software trigger is issued by the host application — a function call, a network packet, or a scheduled task. It is convenient for bench testing and for events that originate in software (a GUI button, a scripted sequence, a machine-vision result). The cost is latency and jitter: the call must traverse the OS scheduler, the driver stack, and the camera's command interface. Typical software-trigger latency on a well-tuned Linux system with a real-time kernel is on the order of hundreds of microseconds to a few milliseconds, with jitter that can exceed the frame interval itself.

Software triggers are therefore appropriate when the event is inherently software-defined or when timing tolerance is loose (say, ±5 ms). They are inappropriate as the primary trigger for a 5,000 fps capture of a ballistic event. A common hybrid pattern uses a software trigger to arm the system and a hardware trigger to fire it, combining operator convenience with deterministic capture.

Exposure synchronization

Exposure synchronization means aligning the sensor's integration window with the illumination window and with the trigger edge. In high-speed cameras, exposure is controlled by an electronic shutter: the sensor integrates charge for a defined exposure time, then reads out. The critical parameters are:

  • Exposure time — must be short enough to freeze motion. A rule of thumb: exposure ≤ (pixel displacement tolerance) / (subject velocity × magnification). For a 1 m/s subject at 0.1× magnification with a 2-pixel blur budget on a 5 µm pixel, exposure ≤ 2 × 5 µm / (1 m/s × 0.1) = 100 µs.
  • Strobe duration — should be ≤ exposure time so the illumination is fully contained within the integration window. If the strobe is longer, you waste light and may cause motion blur from ambient contribution; if shorter, you lose signal.
  • Strobe-to-exposure offset — the delay between the trigger edge and the strobe pulse must be calibrated so the pulse lands inside the exposure window, not before it or after it.

The figure below shows the timing relationship between the trigger edge, the camera's exposure window, the strobe pulse, and the readout phase, including the latency terms that must be compensated.

Trigger → Exposure → Strobe → Readout Timing Chain t Trigger edge Exposure integration window Strobe light pulse Readout sensor readout t_trig-exp t_exp-strobe t_exp-read

Latency compensation

Every element in the chain contributes delay: the trigger generator's output stage, cable propagation (roughly 5 ns/m for coax, negligible at these scales), the camera's input opto-coupler, the sensor's internal trigger-to-exposure delay, and the strobe driver's turn-on time. The sum is the system latency, and it must be measured, not assumed.

A practical calibration procedure for a single camera and strobe:

  1. Set the camera to a known exposure time (e.g., 50 µs) and the strobe to a short pulse (e.g., 10 µs).
  2. Feed the trigger edge and the strobe pulse into two channels of an oscilloscope, and use the camera's exposure-active output (many high-speed cameras provide a "strobe out" or "exposure active" TTL) as a third channel.
  3. Measure the delay from trigger edge to the rising edge of exposure-active. This is t_trig-exp.
  4. Measure the delay from exposure-active rising edge to strobe rising edge. This is t_exp-strobe. Adjust the strobe generator's delay setting until the strobe pulse is centered within the exposure window.
  5. Record the values. They are stable for a given camera, cable set, and temperature, but should be re-verified after any hardware change.

For multi-camera synchronization, the same procedure is repeated per camera, and the per-camera t_trig-exp values are used to apply individual delay offsets in the trigger generator so that all exposure windows align to within a fraction of the frame interval. A typical target is alignment within 1–2 µs, which at 10,000 fps (100 µs frame period) is 1–2% of a frame — acceptable for most motion analysis.

Practical note: When using a pre-trigger buffer, the trigger latency does not affect the captured frames' content, but it does affect the timestamp assigned to the trigger event. Record the trigger edge's timestamp from the same clock domain as the frame timestamps, or the pre-trigger frames will be misaligned in post-processing.
Common failure: A strobe that fires before the exposure window opens produces a dark frame with no motion blur — the illumination was wasted. A strobe that fires after the window closes produces the same result. If frames are intermittently dark, check t_exp-strobe first; it is the most frequent culprit in newly assembled rigs.

Putting it together: a worked example

Consider a drop-test rig capturing a 20 mm steel ball impacting a plate at 4 m/s, imaged at 8,000 fps (125 µs frame period) with a 30 µs exposure and a 20 µs LED strobe. The camera's t_trig-exp is 12 µs; the strobe driver's delay is set to 25 µs after the trigger edge, placing the 20 µs pulse from 25 to 45 µs, well inside the 12–42 µs exposure window. The ball moves 4 m/s × 30 µs = 120 µm during exposure — at 0.5× magnification and 5 µm pixels, that is 12 pixels of blur, which may be too much. Reducing exposure to 10 µs cuts blur to 4 pixels, but then the strobe must be shortened to ≤10 µs and its delay re-centered to 17 µs. This trade-off between motion blur, light budget, and timing margin is the central engineering decision in high-speed trigger design, and it is resolved by measuring the actual latency terms rather than estimating them.

← Previous 📖 Contents Next →