Sensor Timestamping

One of the critical aspects of data acquisition on systems with multiple sensors for real-time processing is to obtain accurate timestamping of the data. NVIDIA^® DriveWorks relies on the system time source of Xavier, in particular, the CLOCK_MONOTONIC time source. This time source adjusted to the UNIX epoch time is used internally to timestamp all sensors and events, and the application can get the current time via the function:

dwStatus dwContext_getCurrentTime(dwTime_t *time, dwContextHandle_t ctx);

Timestamps within the same context are guaranteed to be in sync. One thing to note is that this time source is relative to UNIX epoch time on Unix based platforms. Any NTP/PTP time corrections will influence this clock.

DriveWorks computes timestamps for each sensor when data arrives to the Xavier, so sensor data recevied via Sensor Abstraction Layer always has a timestamp associated with it. In particular:

• GMSL Cameras: timestamping is done by the kernel driver triggered by the hardware when full frame has been written into memory.
• SocketCAN: timestamping occurs by the kernel driver when the full message is captured from the hardware by the driver. When hardware timestamping is used, timestamping is performed at the hardware level, by the TegraCAN hardware. The hardware counters are synced to the software clock.
• AurixCAN: messages through this interface are timestamped by the Aurix safety OS. gPTP must be running and Aurix+Xavier clock must be synced to make CAN messages timestamped by Aurix be in sync with DriveWorks timestamps.
• Serial port sensors (GPS): timestamping occurs when packets arrive to DriveWorks, at the software level.
• Xsens IMU/GPS proprietary mode: clock of the Xsens devices are synchronized to DriveWorks clock, making timestamps to be in sync with DriveWorks timestamps.
• Lidar: Lidar generated point clouds provide a DriveWorks timestamp (taken when the Ethernet packet was read), the sensor provided timestamp at start of capturing the packet, and the duration of the packet capture. If the particular sensor does not provide timestamps, both host and sensor timestamps are identical.

Timestamps may be modified depending on the sensor parameter output-timestamp. This parameter supports four options as follows:

output-timestamp=	Description
host	Default host time as described above.
raw	If sensor provides timestamp embedded in payload, host time is overwritten with the raw sensor timestamp. This option also enables simulated sensors to supply an external timestamp.
synced	If valid Time Sensor is active and sensor provides timestamp embedded in payload, perform SW time synchronization to convert to host domain. If successful, this timestamp is preferable as it is closer to time of data capture. If unsuccessful or vendor timestamps unavailable, DW will fallback to host time. This is the default option if parameter is not set.
smoothed	If sensor supports time smoothing, apply on host timestamps. This option reduces jitter by averaging host/sensor timestamp deltas based on a predetermined window.

Note

For a list of supported timestamp options per sensor, see:

• Timestamp options
• Timestamp options
• Timestamp options
• Timestamp options
• Timestamp options

Output options are used in the following sample:

• Time Sensor Sample

Sensor timestamping is used in multiple samples:

• CAN Message Logger Sample
• VehicleIO Sample