3D visionExplainer

Subordinate sync mode: first frame timing and rolling shutter

Why the first frame in subordinate sync lands one to two trigger periods late, how a rolling shutter spreads one frame over 33 ms, and how to read an LED test.

LumaSpec Vision10 min read Share on LinkedIn

On this page 9 sections
  1. 01What subordinate sync locks — and what it does not
  2. 02Rolling shutter turns a frame into a timeline
  3. 03The LED test, read the right way
  4. 04Worked example: LED test on a 30 Hz frame with a 500 µs exposure
  5. 05Design rules that survive the sweep
  6. 06When subordinate sync is the wrong tool
  7. 07Cameras for sweep-free frames
  8. 08Checks before you order
  9. 09Questions

You lock the camera to an external pulse in subordinate (slave) sync mode, run a 30 Hz signal, switch an LED at a known instant, and the captured frame still disagrees with your timing. Two effects explain almost every such result. First, subordinate mode locks the frame rate, not the phase: the first frame lands one to two trigger periods after the pulse, and the count can change with a firmware update. Second, a rolling shutter exposes rows one after another across roughly one frame period — about 33 ms at 30 frames per second — so a frame is a timeline stacked into an image, not a snapshot. This guide gives you the arithmetic to locate the real exposure window and the rules for a sync test that reads true.

What subordinate sync locks — and what it does not

In subordinate (slave) sync the camera does not free-run: it derives its frame timing from the pulse on its sync input, so the frame rate equals the trigger rate. What the pulse does not set is phase. The camera arms its internal timing from the edges it receives, and the first frame it hands you lands one to two trigger periods after the first pulse. That count is not fixed hardware behavior: one depth camera family delivered its first frame after the second 30 Hz pulse on one firmware build and after the third on the next, so an offset measured before an update can be wrong after it.

The working rule: budget one to two trigger periods of first-frame latency, send dummy pulses until frames come steadily, and only then judge timing. The multi depth camera synchronization guide covers the trigger and slave-mode setup itself, and a dark or odd first frame has other causes too — see first camera frame dark: exposure settling or light timing?.

Rolling shutter turns a frame into a timeline

A rolling shutter sensor exposes and reads one row after another. Each row integrates for the set exposure time, but the rows start at staggered times, and at full frame size the sweep spans roughly one frame period. At 30 frames per second the last row starts about 33 ms after the first, so the top of the picture was exposed while the bottom was still waiting.

T = 1 / f_trigger t_sweep ≈ T (full-frame readout) row duty = t_exposure / T

The consequence for sync testing: a frame has no single exposure instant, so it cannot confirm or deny an event at the trigger edge. It records a timeline about one period long, stacked as an image. On fast scenes this same mechanism shows up as motion skew — rolling shutter blur limits depth accuracy on fast 3D scans works through that case — and it is why the global vs rolling shutter choice comes before any timing-critical design.

The LED test, read the right way

The test itself is sound: drive the sync pulse and an indicator LED from the same board, switch the LED a known time after a rising edge, capture, and look at which rows show it lit. What breaks is the interpretation. The lit rows mark where the sweep was during the LED-on window — a phase measurement — not a verdict about exposure at the edge.

Read the picture as a timeline. If some rows are lit and some dark, the boundary between them is the event, and its position gives the sweep offset. If the whole frame flips between two switch-off settings — one shows the LED, the other does not — you have bracketed the sweep start between the two settings. That is exactly what the 20 ms and 22 ms runs did in the worked example below.

Two settings get misread as sync faults here: the trigger pulse width, which on some cameras sets the exposure directly (why trigger pulse width sets exposure time), and a minimum exposure floor that keeps very short events from registering at all (minimum exposure time in trigger mode).

Worked example: LED test on a 30 Hz frame with a 500 µs exposure

Inputs, all from the bench setup above: trigger rate 30 Hz from the pulse source driving the sync input; per-row exposure 500 µs, the camera's minimum exposure in that test; LED switch-off 22 ms after the second rising edge in one run and 20 ms in the next; first delivered frame after the second pulse on the firmware under test.

Rule in words. A row shows the LED lit when its exposure window overlaps the LED-on window. The LED-on window runs from the rising edge to the switch-off instant; the row windows sweep through roughly one frame period.

Arithmetic.

  • Frame period: T = 1 / 30 Hz = 33.3 ms.
  • Row duty: 0.5 ms / 33.3 ms = 1.5% of the sweep per row.
  • Sweep start: the 22 ms run shows lit rows, so the sweep begins before 22 ms; the 20 ms run shows none, so it begins at or after 20 ms. Sweep start is 20-22 ms after the edge, or 0.60-0.66 of a period.
  • Lit band in the 22 ms run: (22 − 20) ms / 33.3 ms ≈ 6% of rows, all at the start of the sweep.
  • Sweep end: about 22 ms + 33.3 ms ≈ 55 ms after the edge, with the third pulse arriving later still, at 66.7 ms.

Result. The delivered frame integrates from about 21 ms to about 55 ms after the rising edge — a phase offset of roughly two thirds of a period, not an exposure at the edge.

Decision. Judge events against the sweep, not the edge. Any event shorter than one sweep (here under 33 ms) is readable only row by row: the 2 ms sliver in the 22 ms run lit about 6% of rows. To make every row see one state, hold the state for offset plus sweep, 22 ms + 33.3 ms ≈ 55 ms after the edge. For measurements, use trigger edge + ~21 ms as the frame's reference instant, and re-measure that offset after every firmware update.

Design rules that survive the sweep

  1. Prime, then count. Send dummy pulses and measure from the second or third frame onward; first-frame latency is one to two periods and can move with firmware.
  2. Zero the offset setting. If the SDK exposes a delay offset for the subordinate input, leave it at zero while you measure, so the offset you find is the camera's phase, not the setting's.
  3. Hold states for one full sweep. A lamp, valve or LED state held for offset plus sweep (about 55 ms in the example) is seen by every row as one state.
  4. Read rows, not the frame. If the event must land inside the capture, find the transition row: lit-row fraction × sweep time gives the event time relative to sweep start.
  5. For one shared instant, change hardware or trick the shutter. A global shutter sensor exposes all rows at once. The rolling shutter global reset with flash technique makes a rolling sensor integrate all rows during one short flash, and external flash sync on depth cameras applies the same idea to depth output.
  6. Scope it where you can. Many industrial cameras provide an exposure-active output that switches while the sensor integrates; its rising edge marks the sweep start more precisely than any LED test.
  7. Share one pulse deliberately. When two devices take the same trigger, phase each one on purpose — the depth camera and third-party camera on one external pulse guide covers the wiring and the offset budget.

When subordinate sync is the wrong tool

Subordinate sync locks a continuous frame rate to a machine rate — a conveyor, a robot cycle, a second camera. That is the right tool when every frame matters at a steady cadence. It is the wrong tool for event capture: a part arriving, a strobe firing, a stop pulse. For those, choose a camera whose trigger starts the exposure, so the rising edge and the first row share a known microsecond-scale relationship, and pair it with a global shutter sensor so every row sees the same instant. The edge-controlled exposure scheme on line scan cameras is the same principle in its strictest form.

If the trigger misbehaves on a camera you already own, the cause is usually configuration rather than phase — check the acquisition mode first, as in GigE camera ignores external trigger: check acquisition mode.

Cameras for sweep-free frames

If a shared exposure instant is the requirement, shortlist global shutter sensors in the area scan cameras category. The MV-CU020-90GC is a 2.5 MP GigE camera with a global shutter and a C-mount — the shape that makes trigger-edge timing readable straight off the image.

Area scan camerasHikrobot MV-CU020-90GC 2.5 MP Area Scan Camera, GigE, GMAX4002, ColorMV-CU020-90GC
Sensor format
1/1.7"
Lens mount
C-mount
Interface
GigE
Resolution
Up to 3 MP
$309.00View partBuild a system with it

If the build keeps a rolling shutter, the arithmetic transfers unchanged. The LS-CMR-0166 reads 12 MP at 30 fps with a rolling shutter. One frame period at 30 fps, 33.3 ms, is the sweep scale the worked example used.

Area scan cameras12 MP USB3 area scan camera, IMX226, 1/1.7" rolling shutter, 30 fps, 4000 × 3000 resolution (LS-CMR-0166)LS-CMR-0166
Sensor format
1/1.7"
Interface
USB3
Resolution
12 MP
Shutter
Rolling
$560.00View partBuild a system with it

For depth rigs that share one external pulse across cameras, the MV-DPS200P-02 projected structured-light 3D camera is that class of part, and the 3D sensors category lists the rest of the family.

3D sensorsHikrobot MV-DPS200P-02 Projected structured-light 3D cameraMV-DPS200P-02
Type
Stereo / structured light
$8,829.00 · quotedView and quote

Checks before you order

  • Shutter type on the datasheet line: Global or Rolling. That one word decides whether a frame has an exposure instant at all.
  • Trigger mode list: edge-triggered exposure (trigger starts exposure) versus slave frame-rate sync. Event capture needs the first kind.
  • Exposure-active output on the I/O connector, so you can scope the sweep instead of inferring it from an LED.
  • Minimum exposure time. A 500 µs-class floor is common; an event shorter than the floor leaves no trace on the sensor.
  • First-frame behavior. Whatever the latency is on day one, re-measure it after a firmware update before you trust a timing budget again.

The camera finder filters by shutter type, interface and resolution, and the configurator walks the camera-lens-light chain in order. The 3D topic page collects the other timing and sync guides. If you are matching a camera to an existing trigger chain, send the pulse diagram and the timing budget through the contact page and we will check the phase math with you.

Questions

Why does my LED turn-off test disagree with the trigger edge?

Because the frame is assembled row by row. Each row integrates in its own short window, and the sweep of windows spans roughly one frame period. An LED that switches mid-sweep is lit for the rows scanned before the switch and dark for the rows after it, so one picture holds both states. Read the boundary between lit and dark rows instead of judging the frame as a whole.

How many trigger pulses does a subordinate camera need before the first usable frame?

Expect one to two full trigger periods of silence before frames start. In a recorded case, a camera needed two 30 Hz pulses before its first frame, and a firmware update pushed that to three, so the number is not something to hard-code. Send dummy pulses, begin measuring from the second or third frame, and repeat the count check after each update.

How can every row of the image see the same instant?

Use a global shutter sensor, which exposes all rows at once, or use the global-reset technique, in which a short flash is combined with a special reset so all rows integrate during the flash. With an ordinary rolling shutter, a short flash lights only the rows being read out during it, so the flash freezes motion in a band, not in the whole frame.

Does the LED test measure exposure time?

No. The 500 µs figure is each row's integration window; it sets how wide a smear a moving edge leaves in the picture. The LED test brackets the sweep start instead: in the worked example the frame's exposure sat about 20 to 22 ms after the rising edge, a phase offset of roughly two thirds of a period — a different quantity from the per-row exposure time.

Can I read event timing directly from a single rolling-shutter frame?

Yes, if you treat the frame as a timeline. Find the row where the state changes, then multiply the lit-row count by the row time — sweep time divided by row count. With a 33 ms sweep across 3,000 rows, one row is about 11 µs, so a 100-row lit band marks an event window of roughly 1.1 ms. That row-time method is how the 20 to 22 ms bracket was found.

How do I confirm the sweep without an LED?

Use the camera's exposure-active output. It switches while the sensor integrates, so the rising edge timestamps the sweep start and the pulse width timestamps its end. Fire your event from that output rather than from the input pulse and the phase offset drops out of the measurement.