IMU timestamp jumps: diagnose resets in long recordings

A long camera recording can appear healthy while its inertial timestamps suddenly move backward. That discontinuity can invalidate integration, calibration windows and camera-to-motion associations, even when acceleration and angular velocity still look plausible. For acquisition and sensor-fusion developers, the first task is identifying which clock changed—not immediately replacing hardware or adding an offset. Compare the original device counter, published message time and host monotonic arrival time, then test recording and playback separately.

Preserve the evidence before changing timestamps

Keep an untouched recording and export a diagnostic copy. Do not sort samples by their published timestamps before investigating: sorting can conceal a reset and rearrange genuine measurement order.

Capture the following fields wherever the acquisition interface exposes them. Record unavailable fields as unavailable rather than reconstructing them without evidence.

Capture host arrival time near the acquisition callback, before expensive processing. A timestamp taken after a long processing queue measures processing progress instead of initial delivery.

Host monotonic time is useful for elapsed intervals within the same host session. It is not a shared clock between computers, and it does not identify the physical measurement instant.

For ordinary alignment after continuity is established, use the separate guide to camera and IMU exposure synchronization. A stable offset cannot repair an unexplained clock restart.

First separate acquisition faults from playback faults

Start with the least disruptive tests. A jump seen only during replay should be investigated differently from a jump already present in raw acquisition data.

1. Inspect adjacent stored records in their original recording order, without running the fusion or calibration application.
2. Replay the same interval once, with looping disabled and no seeking. Record message timestamps and playback callback arrival times separately.
3. Compare the replayed message fields with the stored fields. Establish whether playback preserves timestamps or regenerates them.
4. During a new live recording, capture raw device time, message time and host monotonic arrival time together.
5. Compare the same boundary across inertial and image streams, using stream identifiers rather than a single merged callback sequence.

A replay pause creates a gap in playback arrival time without proving that acquisition paused. Seeking backward can repeat older messages even though their stored timestamps are correct. Looping can return to the recording's beginning by design.

Also check callback concurrency. If several workers append records independently, output order may differ from acquisition order. A lock protects shared memory, but does not automatically establish sensor sequence order.

A program that logs once every fixed number of callbacks is not necessarily logging at fixed elapsed intervals. At an illustrative 400 samples/s, 24,000 samples represent 60 s only if delivery is complete and the actual sample rate matches that assumption. Use timestamps and sequence counts together.

Classify the discontinuity by its signature

The following order starts with delivery and conversion checks before more invasive hardware investigation. It is a diagnostic sequence, not a universal ranking of failure frequency.

Evaluate every stream independently before comparing streams. Alternating messages from separate clocks can look like backward motion even when each individual sequence is valid.

Plot adjacent timestamp differences, not just absolute timestamps. Small ordering faults and large epoch changes become easier to distinguish. Retain enough records around each event to reveal whether the sequence recovers immediately or begins a new timeline.

If camera streams also pause or reconnect, the checks in camera acquisition stalls under load can help separate transport interruption from timestamp arithmetic.

Test a rollover hypothesis with explicit arithmetic

A finite-width counter eventually wraps. Its period depends on its width and tick duration—not on a universal camera recording limit.

As an illustrative example, an unsigned 32-bit counter with a 1 microsecond tick wraps after:

These are hypothetical counter properties, not specifications for any catalog product. A recording failure near that duration is a clue only if the documented timestamp representation matches.

Suppose adjacent raw values are 4,294,966,000 ticks and 1,204 ticks. The counter appears to move backward, but a single rollover gives:

That interval is consistent with an illustrative 400 samples/s stream because 1 / 400 = 0.0025 s. Confirm it against surrounding intervals, sequence continuity and host arrival evidence.

Do not apply modular correction merely because the result looks plausible. A device restart can produce a similar backward jump. Long outages can also span multiple wraps, making reconstruction ambiguous without independent timing evidence.

Sparse console logs are insufficient for measuring the exact jump. Two printed timestamps may have thousands of intervening samples. Inspect adjacent original records at the boundary.

Inspect clock conversion when raw time stays continuous

If the raw device counter remains valid but the published timestamp changes discontinuously, investigate the mapping layer before changing hardware.

A common mapping model is:

Here, device time has already been converted into a documented unit. The scale factor a represents relative clock rate, while b maps the device epoch into the message clock domain.

Check for these errors:

• A milliseconds-to-seconds conversion applied twice or omitted.
• Integer overflow before conversion into a wider representation.
• Signed interpretation of an unsigned counter.
• Shared conversion state accidentally used by separate devices or streams.
• An offset reinitialized during reconnect or stream restart.
• A host wall-clock adjustment propagated into message timestamps.
• Floating-point precision lost by storing large epoch timestamps in insufficient precision.

Preserve original integer counters where available. For elapsed-time calculations, subtract a nearby reference using checked, sufficiently wide arithmetic before converting to floating point. Treat verified rollover separately rather than relying on accidental integer overflow.

Record the SDK, wrapper and firmware versions involved, plus the actual library loaded at runtime. An installed version list alone does not establish which conversion implementation your process used. Obtain updates and supported compatibility information through manufacturer or authorized distributor channels.

After correcting the mapping, regenerate derived timestamps in a separate output with a documented transformation. Keep the original values available for comparison.

Investigate genuine device or session restarts

A restart becomes more likely when several independent signals agree: the raw clock returns toward its initial range, sequence numbers restart, initialization messages appear, or the connection is re-established.

Correlate the boundary with host device events, acquisition logs, power events and application recovery actions. Check approved power arrangements, cable retention, connector condition and manufacturer installation requirements. Change one condition at a time so the result remains interpretable.

Application recovery can itself start a new timestamp epoch. If a watchdog restarts acquisition, record that action explicitly and assign the restarted stream a new session identifier. Do not assume that a successful reconnect preserves the previous clock mapping.

For Linux capture systems, distinguish reconnection and device-access problems using camera device permissions and node checks. That investigation is relevant when access changes accompany the restart, not when only converted timestamps are wrong.

When measurement time across a restart cannot be recovered, split the dataset into independently timed segments. A continuous-looking timeline created by adding an arbitrary offset does not restore missing measurements or prove camera-to-IMU alignment.

Validate recovery over a sufficiently long recording

A short successful test does not resolve a failure that appears after extended operation. Define acceptance checks before running another recording.

For an illustrative fault recurring near 70 min, a 180 min recording crosses more than two suspected recurrence intervals. This is a useful diagnostic duration, not a reliability guarantee. Repeat under representative acquisition rates, transport load and storage conditions.

Check each session for:

• Negative timestamp differences after any documented, verified rollover handling.
• Duplicate timestamps and duplicate sequence numbers.
• Missing sequences and positive timing gaps.
• Changes in timestamp units, clock domains or conversion parameters.
• Arrival bursts that reveal queueing rather than measurement-time changes.
• Camera-to-inertial alignment changes on either side of a boundary.

For an illustrative 400 samples/s stream, 180 min corresponds to 400 × 180 × 60 = 4,320,000 expected samples. Compare counts with the documented stream behavior and actual acquisition duration. Count agreement alone does not establish correct timing.

Do not use playback callback arrival times to estimate the original sensor rate. Replay scheduling, decoding and storage performance can alter those intervals.

For calibration or long-duration noise analysis, select continuous segments with known measurement timing. Do not silently join segments across unexplained resets. After temporal continuity is established, use multi-camera point-cloud synchronization checks if the wider system also combines several depth streams.

Check timing requirements before replacing a camera

Replacing a depth camera is not the first remedy for a conversion or replay fault. If hardware replacement becomes necessary, write a timing requirements sheet before comparing 3D sensors in the camera finder.

Require documented answers about timestamp units, counter width, epoch behavior, raw-clock access, restart handling and synchronization methods. If your application requires inertial measurements, confirm that capability explicitly. Depth sensing alone does not establish an integrated IMU or a shared camera–inertial clock.

For depth-technology comparisons, the MV-DLS300P-04 is listed as a laser galvanometer stereo camera.

The MV-DT01WMU is listed as a ToF sensing camera.

These are depth-camera comparison candidates, not validated replacements for an inertial recording system. The supplied catalog descriptions do not establish inertial sensing or timestamp continuity behavior. Confirm those requirements before selection, then use the camera configuration step to organize compatible components.

Final evidence and recovery checklist

Before accepting the affected data or closing the investigation:

• Preserve the original recording and acquisition configuration.
• Identify every clock domain and its units.
• Inspect adjacent samples in original order, separately for each stream.
• Locate the first layer where continuity fails.
• Verify rollover against documented counter properties, not appearance alone.
• Mark real restarts as new sessions and retain uncertain boundaries.
• Revalidate long recordings and downstream estimator behavior.

If the diagnosis remains unresolved, prepare a short boundary excerpt containing raw counters, message times, arrival times, sequence identifiers and connection events. Use application support to discuss timing requirements and camera selection without discarding the evidence needed to identify the fault.