How is TIMESYNC supposed to be used?

[hamishwillee]

How and when is the TIMESYNC message supposed to be used - insufficient documentation to guess.

The underlying use case that this query originates from is in mavlink/MAVSDK#798, where the user wanted a GPS timestamp in order to be able to sync a swarm of drones.

[julianoes]

Good question.

[hamishwillee]

@mhkabir I see you provided the PX4 implementation of TIMESYNC MAVLink message. Can you help confirm behaviour?

I infer from the source:

• From message, we have to timestamps in message tc1 (timestamp 1), ts1

Steps

1. Sender sends message to remote system with tc1 = 0, and its ts1 = timestamp "now" *1000 (as a long long)
2. Receiver checks messages.
   • If it gets a message with tc1 == 0 it sends back a message with tc1 = its timestamp (now*1000ULL) and the timestamp from the sender message into ts1.
   • If it gets a message with tc1 <> 0 it knows this is a reply to its message. This contains the original timestamp and the timestamp of the remote system. From this the system gets the round trip time and an estimated offset between the systems.

Looking at PX4 implementation there is some code I don't understand. But I assume that the calculated offset can vary over time and this does work to keep the sync accurate? ie it discards messages with too great RTT, and also accumulates values to make sure that the estimate and observed offsets are similar - and some sort of filtering?. @mhkabir perhaps you can explain how/why this stuff works?

Is that about right?

This message is broadcast. How do you know that a response is to "your" timesync and not from some other random system?

[hamishwillee]

From @mhkabir

• explanation accurate
• multi-vehicle use-cases not handled (the current PX4 implementation also assumes 1 timesync agent per link)
• The robust filtering is needed since the observed offsets are pretty noisy.

[patrickelectric]

Any update ? This message is pretty important and there is no documentation or comments around the code that could explain the use case and functionality.

[hamishwillee]

@mhkabir

• Can you please expand on the use cases for this message?
• For the multi vehicle use case wouldn't the solution just be to add target and component ids to the TIMESYNC message. Outwards bound it could still be broadcast, but the return would address to the specific original emitter? These could be added as extensions IMO - right?

@patrickelectric The #194 (comment) above explains how it estimates the functionality. Kabir confirms this is correct.