The public regulated data types already include a basic time synchronization protocol that is similar in its construction to IEEE 1588, except that the communication is strictly one-directional, from the time sync master to slaves. This comes with certain trade-offs: the algorithm scales better but the worst-case jitter bound is substantially higher. If higher precision is desired, IEEE 1588 should be implemented as-is.
Time synchronization
As mentioned earlier, the currently defined time synchronization algorithm hinges on the assumption that the frame propagation latency throughout the whole bus is much less than a single bit period. This is true for CAN and similar physical bus topologies but does not hold for star or tree networks.
In the case of Ethernet-based networks, the problem of precise time synchronization is addressed well by IEEE 1588. Nearly every modern Ethernet-enabled microcontroller supports IEEE 1588 in hardware (all modern MCUs from NXP, STM, and Microchip seem to support it, according to my quick look-up), and the theoretical performance of this protocol exceeds that of UAVCAN.
Other transports, however, may not have such well-defined and well-supported standard solutions. In these cases, the algorithm defined in UAVCAN can still be used if augmented with the Olson latency recovery algorithm. The resulting solution will be less accurate than the native CAN-based one or IEEE 1588 but it is likely to still be sufficient for most distributed control needs.
The core assumption of the Olson algorithm is that the message propagation medium adds an unknown and variable latency to the message, but it is assumed that occasionally the medium will exhibit the minimal latency. The Olson algorithm can identify such low-latency packets and use them to establish synchronization with minimal clock skew. The algorithm is implemented entirely on the receiving side and requires no slave-to-master communication. Therefore, unlike IEEE 1588, it scales very well for large networks. The short-term attainable accuracy equals the best-case (minimal) packet propagation delay from the master to the slave (the long-term accuracy is also dependent on the drift rate of the slave’s local clock); the worst case error is bounded by the worst case propagation delay.
The described algorithm can be implemented without any modifications to the synchronization protocol; the changes will be limited to slave-side logic only.
Where can I find the paper of Olson latency recovery algorithm?
Here: olson_sensor_synchronization.pdf (202.7 KB)
A basic implementation is available in the legacy PyUAVCAN v0 library:
class TimestampEstimator:
"""
Based on "A Passive Solution to the Sensor Synchronization Problem" [Edwin Olson 2010]
https://april.eecs.umich.edu/pdfs/olson2010.pdf
"""
DEFAULT_MAX_DRIFT_PPM = 200
DEFAULT_MAX_PHASE_ERROR_TO_RESYNC = 1.
def __init__(self,
max_rate_error=None,
source_clock_overflow_period=None,
fixed_delay=None,
max_phase_error_to_resync=None):
"""
Args:
max_rate_error: The max drift parameter must be not lower than maximum relative clock
drift in PPM. If the max relative drift is guaranteed to be lower,
reducing this value will improve estimation. The default covers vast
majority of low-cost (and up) crystal oscillators.
This file has been truncated. show original