- Host Configuration
- Runtime Node Configuration
- SDF Configuration
- Logfile Management
- Managing the Runtime
- Application Code Portability
- Building C Examples
- Building C++ Examples
- Building a Node
- Clone Example Repos
- Coordinate Frames
- Diagnostic Trouble Codes
- Extending the Data Model
- IDE Setup
- Logged vs Source vs Published Video Parameters
- MATLAB to Export - BETA
- PolySync Messages
- ROS Bridge
- Release Notes
- Standard Units
- Dynamic Driver/HW Interface Development
- Application Development
Multiple timestamp fields are housed within the predefined message types from the data model. There are a variety of contexts within which they are implemented.
The message publisher is always responsible for setting each of the available fields.
Message header timestamp
The message header timestamp is populated for every message before it’s published to the bus. This is applied by the node before publishing the message to the PolySync bus.
The message header timestamp represents the UTC microsecond time when the message was published to the bus
The message timestamp represents when the data was read on the native bus─Ethernet, CAN, Serial─from the sensor, by the PolySync Dynamic Driver interface.
This timestamp represents the PolySync time domain and can be compared to any other message timestamp.
Native message timestamp
The native message timestamp is populated when the sensor or hardware device provides the data.
This format is always sensitive to the sensor or hardware device.
Use the ps_native_timestamp.format field to determine whether absolute UTC microseconds are used─or relative milliseconds/microseconds─since power-ups are used as well.
With LiDAR, there is occasionally start and end timestamp values too, like the Velodyne HDL-32E. This is also context sensitive with respect to the sensor. For Velodyne, this represents the number of microseconds past the hour, per UTC time.