I’m looking at the SYSTEM_TIME Mavlink message coming from my Ardupilot, and the Unix time field is ~1.3 seconds in the future from the Unix time on my desktop. I would expect them to be closer together since Ardupilot is presumably getting its time from GPS (BRD_RTC_TYPES is 1) and my desktop is ntp-synced to time.nist.gov. Any ideas where this is coming from? I was originally thinking leap seconds, but the Ardupilot code looks like it’s adding the right number (18). Communication latency could explain an Ardupilot time in the past, but not in the future.
As background, my system will have a companion computer with an inaccurate Linux time and a sensor that has a gps timestamp but a significant and variable amount of latency. I need to correlate the GPS timestamp from the sensor to the attitude message from Ardupilot. The attitude message is timestamped with the boot time from the FCU, but I can get the offset from the Unix time to the boot time from the SYSTEM_MESSAGE. The whole scheme falls apart if the time on the FCU isn’t accurate relative to the GPS timestamp, however, which explains my query. Is there a better way to do this?