External trigger rate vs camera preset: the internal clock fallback

You wired the camera as a trigger slave, the pulse source runs at 40 fps, and the host logs a frame every 33.3 ms. The camera is not broken and the wiring is probably fine: a camera whose sensor supports fixed frame-rate presets treats an off-preset trigger rate as unusable and quietly reverts to its internal clock. This guide is for engineers syncing depth cameras, area scan cameras and IMUs on one line. You will confirm the fallback from logged timestamps, choose a pulse rate the sensor actually lists, and align streams whose rates never divide evenly, such as a 200 Hz IMU against 30 fps depth, in software.

The symptom: the camera ignores your pulse rate

Frames keep arriving, timestamps look plausible, and nothing raises an error. But the interval between frames never matches your source: you pulse every 25.0 ms and the host receives a frame every 33.3 ms, the camera's own 30 fps preset. Both clocks are stable, so depth-to-color registration stays internally consistent while every comparison against the outside world, robot pose, IMU samples or a second camera, drifts through alignment and back out on a cycle set by the beat between the two rates.

The tell is that nothing you do to the pulse rate changes anything. Sweep the source faster or slower and the frame spacing does not move. That is the opposite of a bandwidth or trigger-source ceiling, where frames stop or arrive late as the rate rises; camera hardware trigger frame rate with external pulses covers that failure. Here the camera has simply stopped listening.

Why slave mode falls back to the internal clock

Slave mode on a preset-locked camera does not mean 'capture whenever a pulse arrives'. It means 'phase-lock my frame start to a periodic signal whose period equals one of my enumerated frame rates'. Exposure and readout timing are built around that list, so firmware validates the incoming cadence against it. When the incoming period matches no preset, the line is treated as unusable and frames are generated from the internal timer at the configured preset. The fallback is silent: no error flag, no status bit you would notice, just frames at a healthy rate that is not yours.

Depth and ToF cameras with a sync input are where this bites hardest:

A second, quieter variant exists. Some slave modes listen for a pulse only during a bounded window of each frame period; when the window closes with no pulse, the camera captures anyway, unsynced. Off-cadence pulses then land inside the window only occasionally, so alignment drifts in and out instead of failing cleanly. On stereo depth cameras the sync circuit drives the depth sensor directly and the paired color stream follows it, which is why depth-to-color registration survives while sync to the outside world is lost.

The rate math: send the period the preset implies

Convert both sides to periods and compare.

Worked example: your source runs at 40 fps, so it pulses every 1 / 40 s = 25.0 ms. The sensor offers 15, 30, 60 and 90 fps, implying periods of 66.7, 33.3, 16.7 and 11.1 ms. No preset matches 25.0 ms, so the camera generates frames at its configured preset on the internal clock. In the listen-window variant the same numbers produce visible drift: 33.3 ms - 25.0 ms = 8.3 ms of slip per frame, and 33.3 / 8.3 is about 4 frames for alignment to travel one full cycle.

Set the generator to the exact period, 33,333 µs for 30 fps, from a crystal-controlled output. Do not plan to live inside a tolerance window: the fallback gives no warning, so 'close enough' is indistinguishable from 'ignored'.

Four tests that pinpoint the failure

1. Log host-side frame timestamps for 10 s and compute the deltas between consecutive frames. Spacing pinned to one preset while the source runs somewhere else is the fallback, proven.
2. Put a counter or scope on the trigger line at the camera connector and read the true period, level and pulse width against the input spec in the camera's manual. A marginal level or a too-narrow pulse imitates a rate mismatch.
3. Sweep the source onto a listed preset, then to the next one. Deltas that follow the source mean the path works and the original rate was unsupported; deltas that never move mean the camera is on its own clock.
4. Pair depth and color timestamps frame by frame. Both streams stepping at the same steady period while your pulses are ignored means the pair is internally consistent and unsynced to the world, the classic silent fallback.

The fix for each case

You control the pulse source. Divide it to a preset from the table above and the fallback disappears. Function generators, PLC high-speed outputs and small microcontroller boards all hold a crystal-accurate period; the pattern in a square-wave trigger source driving several cameras sets one period for every listener on the line.

A master camera at an unlisted rate must drive a preset-locked slave. Set the master to a preset both share, or drop the wire and align by device timestamp as sync RGB and depth frames by device timestamp, not queue order shows. Never split the difference by pulsing the slave off-list; that is the failure this guide describes.

You truly need 40 fps. Trigger an area scan camera per frame instead. One pulse exposes one frame, there is no preset list, and the only ceiling is the frame budget: exposure plus readout must fit inside the pulse period. Pick the shutter for the scene:

A global shutter freezes motion on a moving line; a rolling shutter serves static scenes at higher resolution.

You need frames only when an event happens. Some industrial depth cameras offer an external-event mode: the sensor free-runs at its preset and the camera transmits a frame only when the event fires. That is gated readout, not a new cadence; the frame rate stays on the list and your event decides which frames reach the host.

Align the IMU in software, not with pulses

The IMU has no trigger input; it free-runs at a fixed output rate such as 200, 250 or 400 Hz. Pulse division cannot work: at 30 fps the frame spans 33.3 ms while the IMU sample period is 1 / 200 s = 5.0 ms, so a frame covers 33.3 / 5.0 = 6.67 samples, never a whole number. That is exactly why timestamps exist. For each image time t, keep the two IMU samples bracketing it: the nearest sits at most 5.0 / 2 = 2.5 ms away, and interpolating between the pair tightens the error further at the cost of waiting one sample. At 250 Hz the bound becomes 4.0 / 2 = 2.0 ms.

The syncer in the camera SDK pairs depth with its registered 2D stream for point-cloud work and passes high-rate streams straight through, so IMU fusion is your code's job. Paired-stream latency lands near half the period of the slower stream, about 33.3 / 2 = 16.7 ms at 30 fps; depth and RGB out of sync: alignment latency and the fps fix covers what to do when it grows. For the method itself, IMU and depth image timestamps: interpolation for alignment works the math, and when a second camera joins the line, sync a depth camera and a third-party camera on one external pulse shows the wiring.

Checklist before the sync design ships

• Copy the slave camera's preset list from its integration guide onto the sync schematic, so the rate decision is made once, on paper.
• Set the pulse source to an exact preset period from a crystal-controlled output; software-timed loops drift by milliseconds.
• Log 10 s of frame timestamps on the bench and confirm the deltas equal the pulse period before the rig leaves the bench.
• Lock the acquisition mode and trigger source into the power-up configuration you actually tested.
• Mount the camera on a rigid camera stand so mechanical jitter is not debugged as sync error.
• Budget the IMU interpolation hold: fusion waits at most one sample period for the bracketing pair.
• Assign time ownership once, a shared hardware preset for cameras that support it and device timestamps for everything else. Multi depth camera synchronization: slave mode and trigger setup extends that to several heads.

When the design is settled, the camera finder lists trigger-ready models and the system configurator walks camera, cable and trigger as one build. If your preset list and your pulse source refuse to agree, send both through the contact page and we will pick the rate with you. More sync and trigger write-ups sit on the systems topic page.