Camera timestamp clock rollover and monotonic time mapping

Periodic backward timestamps can break tracking, sensor fusion, and recording even when image delivery appears normal. The first decision is whether the raw device counter wrapped, the device restarted, or a conversion layer changed its clock mapping. Those require different fixes. This troubleshooting procedure separates counter unwrapping from clock-rate estimation, then checks the mapped timestamps against a monotonic host clock. Keep the original timestamp and frame identity throughout: a corrected timestamp should never erase the evidence needed to diagnose it.

1. Confirm the counter width, units, and timestamp event

Start with the documented raw timestamp rather than a value already converted to host time. Establish its counter width, tick period, clock domain, and timestamp event. A timestamp might describe exposure start, exposure end, or another acquisition event; those meanings are not interchangeable.

For an unsigned counter with a fixed tick period, the rollover interval is:

The following examples describe hypothetical counters, not particular cameras:

A fault repeating around the first interval suggests a different counter scale than one repeating around the second. Compare measured recurrence against the calculation before changing software.

Also establish whether image and auxiliary streams share a counter. The guide to camera and IMU timestamp clock domains explains why timestamps from one device can still require separate interpretation.

2. Separate rollover from other causes of backward time

Inspect the raw counter, mapped time, frame sequence, and connection history together. Use the symptom to prioritize these tests rather than assuming every negative difference is rollover.

For recordings with uncertain restart history, use the broader checks in diagnosing IMU timestamp jumps. A reset cannot reliably be distinguished from rollover using one negative difference alone.

3. Record evidence before applying a correction

Capture enough information to reproduce the decision offline. A log containing only the final timestamp cannot reveal whether unwrapping or drift correction failed.

Record these fields for every sample:

• Raw device counter, preserving its integer representation.
• Stream identity and frame or sample sequence identifier.
• Host monotonic receipt time, sampled as early as practical in the acquisition path.
• Device connection events and known timestamp-domain changes.
• Unwrapped counter and clock-segment identifier.
• Mapping version, estimated slope, mapped timestamp, and residual.

Keep wall-clock time as separate metadata if calendar alignment matters. Do not use a clock that can step with calendar corrections as the sole reference for elapsed-time mapping.

Check monotonic-clock behavior on the target operating system, particularly across suspend and resume. Monotonic does not mean perfectly accurate, and its relationship to an external time reference still needs validation.

Host receipt time includes transport and scheduling delay. The discussion of camera buffer timestamp latency helps separate acquisition timing from delivery timing. Sample both if the interface exposes them.

4. Unwrap the raw counter without hiding resets

Keep counter handling independent of the drift estimator. First establish sample order within each clock domain. Then calculate the modular forward difference:

That compact calculation needs an acceptance rule. Under a half-range rule, accept a forward difference only when it is less than half the modulus and consistent with the expected elapsed time. This assumes the true elapsed counter advance between accepted samples is less than half a cycle.

For the hypothetical microsecond counter above, half a cycle is approximately 2,147.48 seconds. A longer observation gap makes this particular rule ambiguous. Multiple complete wraps can also be invisible in the raw difference.

Handle exceptional cases explicitly:

1. Reject or flag reordered samples before advancing the unwrap state.
2. Treat a zero difference according to documented timestamp resolution and sampling behavior; it is not automatically an error.
3. Compare accepted increments against host elapsed time and expected acquisition intervals.
4. On a documented reset or reconnect, create a new segment rather than adding a guessed wrap.
5. After an ambiguous gap, reacquire the clock relationship instead of silently continuing.

Maintain separate unwrap state for independent counters. Shared housing or synchronized acquisition does not, by itself, establish a shared timestamp register.

5. Estimate clock rate with a centered fit

Once device time is unwrapped, convert it to seconds and fit its relationship to host monotonic time. A local affine model is a useful starting point:

Here, d is unwrapped device time in seconds, h is host monotonic receipt time, and a estimates their relative rate. Using relative times and centered differences reduces numerical cancellation compared with subtracting large absolute-time sums.

Retain raw ticks as integers during unwrapping. Convert differences to floating-point seconds afterward. Check that the fit has enough samples, meaningful time span, and nonzero device-time variance before accepting it.

Begin with an experimental fitting window of 60–300 seconds, then adjust it using recorded residuals and expected rate changes. This is a tuning range, not an accuracy guarantee. Short windows react quickly but amplify delivery jitter; long windows average more noise but respond slowly to changing clock rate.

Receipt-time fitting cannot determine acquisition offset independently of transport delay. A constant delay appears as an offset, while changing delay can bias the slope. Reject obvious delayed observations using a documented rule, retain rejection statistics, and validate against an independent reference when accuracy matters.

For the broader distinction between elapsed time and calendar alignment, use mapping camera timestamps to PC time.

6. Update the mapping without introducing a backward jump

A positive fitted slope does not guarantee continuity between successive fits. Replacing both slope and offset can move the next mapped timestamp backward, even when device time remains ordered.

For a live timeline, join each accepted rate update to the previous mapping at a defined boundary:

If the new slope is positive, the new segment advances continuously from that boundary. Apply the change before emitting affected samples and record the boundary and coefficient version.

Continuity alone does not correct an existing offset error. If the mapping must converge toward a better offset estimate, slew the correction gradually, with a rate limit that keeps the complete mapping strictly increasing. Define an acquisition phase during which timestamps are marked provisional rather than claiming settled accuracy immediately.

Avoid fixing the display with max(previous_time, current_time). That can hide the fault by creating repeated timestamps and distorted sample intervals. If strict ordering requires a separate sequence key, preserve it separately from measured time.

For an offline recording, a validated final mapping may be applied consistently to a complete segment. Do not mix that revised timeline with timestamps already emitted by a live mapping without recording the distinction.

7. Calculate the drift budget before tuning

Suppose a hypothetical device clock runs fast by 80 parts per million. Its uncorrected error after one day is:

If the required accumulated error is no more than 10 milliseconds per day, the equivalent average rate-error budget is:

That is an average rate requirement, not a guarantee about individual frame timestamps. Delivery jitter, timestamp resolution, event definition, and offset uncertainty need separate budgets.

A fit that looks smooth over a few seconds does not demonstrate this daily performance. Neither does agreement with the same host receipt timestamps used to fit it. Evaluate rate accuracy against held-out observations and, where required, an independent timing reference.

When measuring the software path itself, distinguish CPU time from wall-clock time. Processor consumption is not a substitute for elapsed acquisition time.

8. Validate across wraps, load changes, and restarts

Test the counter logic with synthetic sequences before waiting for a physical rollover. Include normal increments, a wrap, duplicate timestamps, late samples, resets, and gaps longer than the accepted ambiguity limit.

Then run a hardware recording across several expected rollover boundaries. For a rollover interval near 72 minutes, a 24-hour recording covers roughly 20 boundaries. This exercises recurrence, but it does not replace deliberate restart and delivery-delay tests.

Use an acceptance checklist with explicit thresholds:

• No unexplained backward step in unwrapped device time within a segment.
• No backward step in emitted mapped time for accepted, ordered samples.
• A new segment after each confirmed reset or unresolved clock discontinuity.
• No residual step specifically associated with a rollover boundary.
• Rate and offset error within the application's independently measured limits.
• Every rejected sample, coefficient update, and confidence transition recorded.

Plot raw increments, unwrapped increments, mapped increments, and mapping residuals separately. Calculate residual statistics away from resets and during transition periods rather than blending them into one average.

Repeat under expected processing load. If recording duration still disagrees with elapsed time, follow diagnosing recordings that run faster than real time; playback configuration can create a separate timing problem.

9. Choose hardware by timestamp evidence, not interface alone

Replacing a camera should follow evidence that the required timestamp event, counter access, or synchronization facility is unavailable. Changing transport alone does not establish better clock behavior.

When comparing area scan cameras in the camera finder, ask for documented answers about counter width, tick period, reset behavior, clock domains, and timestamp metadata. Confirm whether any synchronization facility affects exposure timing, timestamp interpretation, or both.

The catalog identifies the LS-CMR-0053 as a GigE area scan camera. Its listed interface does not establish its timestamp behavior.

The catalog identifies the LS-CMR-0166 as a USB3 area scan camera. Confirm its timing documentation before selecting it for a synchronization requirement.

These are interface candidates for further evaluation, not verified solutions to a particular clock fault. The supplied catalog information does not specify their counter widths or clock-mapping facilities.

If you need tighter event alignment than host receipt timing can establish, evaluate documented hardware synchronization or timestamp-latching capabilities. Software clock mapping alone cannot prove simultaneous exposure or provide a safety-rated timing function.

10. Close the fault with a reproducible timing specification

Before accepting the fix, record the timestamp event, counter modulus, tick period, unwrap assumptions, reset policy, fitting method, and continuity policy. Add the required test duration and independent accuracy limits.

Keep these final checks short and repeatable:

• Raw evidence remains available alongside corrected time.
• Unwrapping and rate estimation have independent tests.
• Ambiguous gaps produce a visible state change, not a guessed correction.
• Mapping updates preserve continuity without concealing offset uncertainty.
• Logs distinguish live timestamps from any later offline remapping.

If existing hardware provides the necessary metadata, correct and validate the software path before replacing it. For a new station, start with the camera configurator, or send the timing specification and representative logs through application support to identify which capabilities require confirmation.