FCU time inaccurate?

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?

Nevermind. Looking more closely at the Ardupilot code, I see that the clock is only synchronized once and subsequently adjusted to be monotonically increasing. I somehow need to get a hold of rtc_shift…

Any chance you could update this if you find a solution in the future? I had a similar issue in the past although my time gap was closer to 10 seconds even with my desktop synced to time.nist.gov. I forget the work around that we came up with but it wasn’t getting the times to match.

I tried changing the Ardupilot SYSTEM_TIME message to report the Unix time without the offset but ended up with something nonsensical. It seems like that approach should be possible. I’ll probably circle back to that if I have time, but in the meantime, I’m trying to get a PPS signal from our onboard sensor.

1 Like