mavlink
mavlink copied to clipboard
mavlink
common.xml:TIMESYNC docs and extensions
This adds documentation to the TIMESYNC message including information about timestamp units (ns) and format, and the message sequence.
As discussed in https://github.com/mavlink/mavlink-devguide/pull/433 the original message was broadcast. That means that, in the case that there might be multiple components requesting timesync, it is not possible to tell if a response is to a particular request. ArduPilot encode the system id in the request timestamp (ts1), which is perfectly "safe". However this is not 100% reliable because it is more common to sync multiple components within a single system, so you still can't be sure if a response is intended for a particular component.
Therefore this adds extension fields for target_system and target_component, which allows robust determination of the intended recipient, and timesyncing to specific targets (eliminating unwanted respones).
@peterbarker @auturgy @julianoes FYI - TBD.
On Thu, 11 Aug 2022, Hamish Willee wrote:
Therefore this adds extension fields for target_system and target_component, which allows robust determination of the intended recipient, and timesyncing to specific targets (eliminating unwanted respones).
What does a system do when it receives a timesync with a target sydid/compid of 0/0?
?> What does a system do when it receives a timesync with a target sydid/compid of 0/0?
@peterbarker
If the response has
target_system==target_component==0the remote system has not been updated to use the component IDs and cannot reliably timesync; the requestor may report an error.
What else can it do? It knows that it is working with an old-style timesync. It could in theory still do the timesync thingy with the data it has but the whole point of this is to move to a reliable protocol.
What does a system do when it receives a timesync with a target sydid/compid of 0/0?
If the response has
target_system==target_component==0the remote system has not been updated to use the component IDs and cannot reliably timesync; the requestor may report an error.
What else can it do? It knows that it is working with an old-style timesync. It could in theory still do the timesync thingy with the data it has but the whole point of this is to move to a reliable protocol.
We discussed this in the mavlink 20220818 dev call. It should always report an error, but there are several things it might do:
- stop syncing (the current proposal)
- only sync whether there is low probability of clash. For example, monitor for all messages (whether addressed to you or not). If you get any with
tc1=0there is a possibilty of clash. Wait X seconds before time syncing. - treat all messages as sync responses and throw away all significant outliers.
The second option is more work than just updating your receiving systems and is still susceptible to small race errors.
The third option might work particularly if combined with the ardupilot approach of encoding the system id in the ts1 timestamp. The whole thing is statistical anyway - if you have two significantly different source timestamps you'd easily eliminate the wild outliers. The thing is whether it would work "well enough" for most purposes. Again, I think finding out and verifying this would be more effort than just making the changes in the systems. Even after doing that, you'll still have some greater level of doubt, and you'll still have more traffic from every single system that responded that did not have to.
Last option is not do anything. It isn't reliable, we live with it.
@peterbarker I think @auturgy was inclined to accept this. Do you have any other suggestions?
CI fails until https://github.com/ArduPilot/pymavlink/pull/721 is merged.
