Usage of Mavlink's TIMESYNC message
979 views
Skip to first unread message
Sriram Sami
May 20, 2016, 4:45:43 AM5/20/16
to MAVLink
Hey all, does anyone know how the Mavlink TIMESYNC message works? I can't quite find any documentation for it beyond the provided description of "Time synchronization message" and the arguments "tc1" and "ts1" don't quite tell me how they are used. What does each of these arguments indicate and what's a normal use-case for this message? Thanks!
Thomas M
Jun 10, 2016, 2:45:22 AM6/10/16
to MAVLink
Hi
Let me try to explain how I understand this:
The timesync message is sent back and forth between to systems. For instance from an onboard computer to a pixhawk autopilot and back, to determine the offset of the autopilot clock from the onboard clock.
when first sending the message to the remote system, the local system sets ts1=now(). Upon reception on the remote system, tc1 is set (by the remote system), and the message sent back.
When receiving the timsync message from the remote system, the local system then knows:
- the "ping" time (round trip time): how long it took the message to be sent to the remote system and back
- assuming that both ways take the same amount of time, the offset of the remote clock to the local clock.
If you do this continuously and average the offset, effects caused by the channel (e.g. delay until the message actually gets sent as it is buffered) should be smoothed out.
BTW: I derived most of that by looking at the implementation in MAVROS: https://github.com/mavlink/mavros/blob/master/mavros/src/plugins/sys_time.cpp#L243
Let me try to explain how I understand this:
The timesync message is sent back and forth between to systems. For instance from an onboard computer to a pixhawk autopilot and back, to determine the offset of the autopilot clock from the onboard clock.
when first sending the message to the remote system, the local system sets ts1=now(). Upon reception on the remote system, tc1 is set (by the remote system), and the message sent back.
When receiving the timsync message from the remote system, the local system then knows:
- the "ping" time (round trip time): how long it took the message to be sent to the remote system and back
- assuming that both ways take the same amount of time, the offset of the remote clock to the local clock.
If you do this continuously and average the offset, effects caused by the channel (e.g. delay until the message actually gets sent as it is buffered) should be smoothed out.
BTW: I derived most of that by looking at the implementation in MAVROS: https://github.com/mavlink/mavros/blob/master/mavros/src/plugins/sys_time.cpp#L243
Reply all
Reply to author
Forward
0 new messages