How Should Sensor Data Be Timestamped?

01 | A Timestamp Needs a Defined Event

Sensor data typically passes through several stages before reaching the application:

Aggregation can occur in a deserializer, FPGA, bridge, gateway, network switch, or at the compute platform ingress. It is a function in the data path, not a required standalone device.

A timestamp can be generated at any of these stages, or preserved from an upstream source. The table below describes timestamps generated locally at each stage.

A driver or application can also carry forward an acquisition timestamp created earlier. In that case, the timestamp's meaning comes from where it was generated, not where it was read.

02 | Synchronized Clocks, Different Measurement Events

Timestamp generation records when an event occurred according to a particular clock. Synchronization establishes how that clock relates to the time base used elsewhere in the system.

PTP or gPTP establishes timing relationships across participating networked devices, and hardware timestamping reduces the uncertainty that software processing adds to clock synchronization.

Consider two cameras operating on synchronized clocks:

Their timestamps share a comparable time base, but refer to different points in the image acquisition and delivery process.

The reverse situation also occurs. Two sensors may timestamp the intended acquisition events while using independent clocks with no established relationship. Their timestamps cannot be compared until that relationship is known.

When integrating GNSS-derived time, PTP clocks, and host timestamps, the system must also account for the time scale and epoch used by each source, including required UTC offsets or clock-domain conversions.

03 | When Arrival Time Replaces Measurement Time

Assume a physical measurement occurs at time t₀. Before the data reaches the application, it passes through sensor processing, aggregation, network transmission, buffering, driver processing, and OS scheduling.

If t₀ and the application timestamp use the same time base, and the delay terms represent non-overlapping stages, an arrival-based timestamp can be represented conceptually as:

Some delays can be characterized and compensated for. Others vary with network contention, buffering, interrupts, OS scheduling, and application workload.

Suppose Sensor A acquires a measurement 1 ms before Sensor B, but its data arrives with 4 ms more delay. Application arrival timestamps would place Sensor A's measurement 3 ms after Sensor B's, reversing their apparent acquisition order.

At 100 km/h, a vehicle travels approximately 8 cm in 3 ms and 28 cm in 10 ms. If measurements are associated with vehicle poses from the wrong instants, timing offsets affect their spatial alignment. The resulting error depends on vehicle motion, sensor geometry, and the compensation applied.

Clock offset and drift introduce separate errors when timestamps originate from different clock domains. Diagnosing the problem requires distinguishing data-path delay from clock relationship errors.

04 | Different Sensors Have Different Timing Models

Camera: Trigger Time and Exposure Time

A hardware trigger defines a trigger event. The relationship between trigger and exposure depends on the camera implementation.

Rolling-shutter cameras expose different image rows at different times. A single frame timestamp therefore identifies a defined reference within the frame timing, not the acquisition time of every pixel. On a moving platform, that difference affects how image measurements are associated with LiDAR, IMU, or vehicle pose.

LiDAR: One Scan, Multiple Acquisition Times

A LiDAR scan spans an acquisition interval, and the platform moves while individual points are collected.

When motion during the scan is significant, a single scan timestamp is insufficient. Deskewing uses finer-grained acquisition timing and platform motion estimates to transform points according to their measurement times.

GNSS: PPS and Time Context

A GNSS navigation solution has a measurement or solution epoch. PPS provides a precise timing edge for clock alignment, and associated time information identifies the absolute time of that edge. For example, a GNSS time message identifies which second a PPS edge represents.

05 | A Timestamping Strategy for Multi-Sensor Systems

Before selecting where to generate timestamps, trace the timing information carried by each sensor stream. Four questions establish the relevant timing relationships:

A well-defined timestamping architecture makes these relationships explicit during system design, rather than requiring them to be reconstructed after integration.

For sensor fusion, the preferred approach is to associate timestamps with defined acquisition events and preserve that timing information through aggregation, transport, and compute. Acquisition timestamps can travel with sensor data as embedded metadata, packet fields, or separately associated records. The implementation must preserve the relationship between each timestamp and its corresponding frame, sample, or measurement.

Generate timestamps at acquisition when the sensor supports it. Otherwise, use a timestamping mechanism with a known relationship to the acquisition event. Downstream arrival timestamps can be retained separately for latency analysis.

When acquisition-related timestamps are unavailable, characterize the delay between measurement and timestamp generation. Compensate for known systematic delays and account for residual variation. The resulting timing uncertainty must remain within the application's requirements.

Measurements from different clock domains require a defined time base, time scale, and documented clock conversions. Timestamp granularity should reflect the acquisition model: a frame-level timestamp is sufficient for some workloads, while rolling-shutter images or moving LiDAR scans can require row-level or point-level timing.

The two paths meet at the timestamp: the measurement path identifies the acquisition event, and the timing domain supplies the clock value.

In Practice: One Time Base for a 24-Camera Agricultural Retrofit

In a 24-camera agricultural machinery retrofit, Albatron built the timing architecture around a common GNSS-referenced time base.

A GNSS receiver in the AMR BOX controller provides the reference time, with the AMR BOX serving as the PTP grandmaster. Two FPGA-based Vision BOX units, each housing eight MIPI cameras, synchronize their FPGA clocks with the AMR BOX through PTP over fiber links and use that shared time base to trigger their cameras. The eight GMSL cameras connected directly to the AMR BOX receive PPS-referenced frame sync from the same controller.

Both camera acquisition paths therefore derive their timing references from the same GNSS-referenced clock architecture.

Validating the Timing Architecture

Validation should examine both clock relationships and measurement timing. Controlled visual events can help assess camera acquisition timing, while PPS comparisons can assess clock alignment. These tests address different parts of the timing architecture, so the validation method must match the event being measured.

The measured timing error and its variation must ultimately be evaluated against the application's alignment tolerance.