Minimum exposure time in trigger mode: find the real cause

You arm a software trigger on frame start and the camera suddenly refuses any exposure below 195 µs, where free-run accepted 11 µs. The readback is not lying: an area scan camera recomputes the shortest exposure it will accept from its current readout timing, and something in that timing changed between your two writes. Arming a trigger, on its own, does not do this. This guide gives you the mechanism, the five settings that actually move the floor ranked by likelihood, a diff procedure that names the culprit in minutes, and a worked example on the reported 11 µs to 195 µs case.

The symptom and what the readback tells you

In free-run you write 11 µs of exposure and the camera takes it. You arm a software trigger on frame start, write the same value, and the camera lands at 195 µs — either clamping silently or reporting the new minimum straight back. Nothing is broken. The minimum the camera accepts is a live value derived from the sensor's present timing, and it moved between the two writes.

That makes this a cousin of register-level readback checks — reading GigE camera registers at runtime is the same discipline of trusting the camera's reported state: what the camera reports is the truth about its current state, so the useful question is which input to that state changed. The trigger is the change you watched; it is rarely the change that mattered. The ceiling behaves differently from the floor — why the maximum exposure limit exists covers that end of the range — but both ends are recomputed by the same timing engine.

Why a floor exists: exposure is counted in line periods

A sensor does not integrate light on a free-running stopwatch. Reset and readout happen row by row at shifted times, and the exposure you request is counted in whole ticks of the sensor's internal clock. On a rolling-shutter sensor that tick tracks the line period — the time to service one row — so the shortest accepted exposure is one or more whole line periods:

Arming a trigger changes none of that. But ordinary settings change f_line, because they change how fast the sensor paces itself: pixel format, on-camera ISP, the link bandwidth limit, the region of interest, binning and decimation, and the frame-rate cap. Camera timing guidance names exactly these levers, and the exposure floor rides along with them.

Keep the floor separate from the frame gap. Resetting pixels and reading the array out leaves a finite minimum time between exposures, on the order of hundreds of microseconds, and that caps how fast you can re-trigger — a different limit from how short one exposure may be. Trigger call versus exposure time walks that timing chain.

High-resolution rolling-shutter cameras show the coupling most plainly, because a full frame runs thousands of rows deep on one line clock. The MV-CS200-10UM is a 20 MP rolling-shutter camera on an IMX183 sensor, a common inspection-class example.

The five usual causes, in order of probability

1. Pixel format changed. Your code switched to a preview or display path — RGB8 for a live view, or a packed 12-bit mode — at the same moment it armed the trigger. Test: read the pixel format feature in both states. In the reported case the surface story was 11 µs to 195 µs, while a bench check on the same camera family held the floor at 263 µs in RGB8 with no trigger armed, and the 12-bit Mono16 path sat at 13 µs free-run, 237 µs armed.

2. On-camera ISP switched on. Debayering, lookup tables and format conversion ride the camera's timing engine and pull the line frequency down. Test: disable every processing block and re-read the floor. Pixel format and frame rate shows the same coupling from the frame-rate side.

3. Link bandwidth capped. A throughput limit set for a long or marginal cable makes the camera slow its readout so the receive buffer never overruns, and the line frequency drops with it. Test: restore full throughput on a short, rated cable from camera data cables and compare.

4. ROI, binning or decimation reset. Returning to full frame puts more rows on the same clock. Test: compare width, height and the binning features — BinningHorizontal and its neighbours — across the two states. Binning and sensor readout explains how readout itself, not just image size, responds.

5. Frame-rate or line-rate cap lowered. A ceiling left low paces the whole sensor. Test: set the acquisition frame rate to maximum and re-read the exposure floor.

Diff the feature tree and name the culprit

1. Put the camera in the good state — free-run, floor at its low value — and dump every feature with its current value to a text file. Vendor SDKs ship a node-map dump utility for this, and most GenICam tools list the full tree.

2. Arm the trigger exactly the way your code does: same calls, same order. Dump again.

3. Diff the two files. Every feature that changed appears in the diff; strike out the ones you set on purpose, such as the trigger selector, mode and source. If a node refuses to read, feature node readability tells you which values exist in which state.

4. Restore the changed features one at a time, re-reading the floor after each. The one whose restoration drops the floor is your culprit.

5. Fix the write order in your acquisition code — format, ROI, bandwidth and frame rate first, trigger last — so arming never rewrites the readout path again. Setting exposure through a GenICam API shows the disciplined sequence.

Worked example: the 11 µs to 195 µs jump

Inputs, each with its source:

• 11 µs — accepted minimum in free-run on the camera's native mono path (reported field case).
• 195 µs — floor after arming a software trigger on frame start, same camera (reported field case).
• 13 µs and 237 µs — the same two states on the 12-bit Mono16 path (reported field case).
• 263 µs — floor with RGB8 selected and the trigger off (bench check, same camera family).
• 26 µs — a published minimum for all triggered modes on one camera line (manufacturer sensor page), as a reference for what a genuine triggered-mode floor looks like.

Rule in words: the floor is a whole number of line periods, so it scales with the line period, and the same scaling in both trigger states points at the readout path rather than the trigger.

Arithmetic:

• 13 µs / 11 µs = 1.18 — the 12-bit path stretches the base clock about 18%.
• 237 µs / 195 µs = 1.22 — nearly the same stretch with the trigger armed.
• 195 µs / 11 µs ≈ 17.7, and 237 µs / 13 µs ≈ 18.2 — both states sit near an 18× step.
• 263 µs with the trigger off reproduces the jump with no trigger in the circuit at all.

Result: the two runs differ by a readout-path change of roughly 18×. A trigger arming cannot stretch a line clock eighteenfold; a format, ISP or bandwidth change can. A genuine triggered-mode floor looks like the 26 µs line item — small, steady and published.

Decision, with its threshold: restore the native mono path, switch ISP off and set the throughput limit to full. If the floor returns to the 11-13 µs band, keep the trigger and your exposure budget. If it stays high with everything restored, you are looking at a published triggered-mode limit in the 26 µs class, and the fix is a faster-readout camera, not more code.

Fixes that actually lower the floor

• Run the sensor's native mono format and convert to color on the host. On-camera RGB8 moves three bytes per pixel where 8-bit mono moves one.
• Switch every on-camera processing block off; keep lookup tables and debayering host-side.
• Give the link full throughput on a cable rated for the run, and re-check after any cable change.
• Crop to the part, not the frame — ROI cropping at the source trims readout along with bandwidth.
• Bin or decimate only while your smallest feature still spans enough pixels.
• Set the frame-rate cap to maximum and let exposure and trigger do the pacing.

When the floor is real: buy readout speed

Some sensors publish a higher triggered floor outright — 26 µs for every triggered mode on the line quoted above. When your exposure budget sits below a published floor, no setting bridges the gap. Motion sets the budget: smear equals object speed times exposure time, so a 1 m/s belt at a 26 µs floor smears 26 µs × 1000 mm/s = 26 µm of blur; weigh that against your pixel size on the object before blaming the camera.

Specialized high-speed options reach 95 ns minimum exposure at the extreme. Closer to mainstream, global shutter starts every row at once, so exposure is not paced by row-by-row readout. The MV-CU020-90GC is a 2.5 MP global-shutter GigE camera, and the MV-CH120-11UC is a 12 MP global-shutter USB3 camera in its high-speed version.

Filter area scan cameras by global shutter when the floor, not the pixel count, is your constraint, then carry the choice through the camera finder or the camera step of the configurator.

Checks before you order a different camera

• Feature diff done, and the only differences are the trigger features you set on purpose.
• Pixel format confirmed as the sensor's native mono path in both states.
• Throughput limit at full, on a cable whose length and flex class match the run.
• ROI and binning chosen for the part, not inherited from a default.
• Frame-rate cap at maximum; exposure and trigger doing the pacing.
• The exposure feature's minimum read at runtime in the armed state — discover the exposure feature before you write to it — and compared against the published floor for triggered modes.
• Smear budget computed in matching units: object speed × floor, against pixel size on the object.

If every box is ticked and the floor still stands above your budget, the camera is the limit. Bring your target exposure, object speed and current floor to the contact page and we will size the replacement, or run the configurator yourself with the same three numbers.