On April 6th/7th 2019 (depending upon your timezone) the GPS week will roll-over back to zero. The ArduPilot development team has done some investigation and we think that there is very little chance of issues for our users. We base this on the following points:
- ArduPilot’s internal calculations mostly use the system time since boot which is not affected by the GPS time. Examples of this can be found in the code in many places (look for AP_HAL::millis() and AP_HAL:micros()) including in our Scheduler’s loop function.
- There are a few places where we use the real date/time (based on the GPS time). The AP_RTC (real-time clock) library provides functions including get_utc_sec and get_system_clock_utc but a review of the consumers of these calls shows it being used for logging, the NAV_DELAY command (which allows the user to specify an hours, min, sec that the next command should be executed) and Jitter Correction (corrects for differences between the system clock and external computers or sensors) and these all appear to safely handle a roll-over.
- UBlox (by far the most commonly used GPS) handles the roll-over for us ensuring that the week sent to the flight controller will not wrap back from 1024 to 0. You can see this yourself by opening a dataflash log and checking the contents of the GPS. Below shows the GPS week from one of my recent flights and we can see it is already 2046 (beyond the roll-over of 1024).
The Ublox GPS manuals include a nice blurb on the subject which I’ve copied below. You can see the original in the UBlox M8 receiver manual on page 27 (Section 7.7).
For those who want to avoid (or perhaps live stream the roll-over) here are the exact times for various timezones:
- Los Angeles: Sat Apr 6th 5pm
- New York: Sat Apr 6th 8pm
- GMT: Sun Apr 7th 0am (i.e. midnight between Apr 6th and Apr 7th)
- Johannesburg, SA: Apr 7th 2am
- Beijing, China: Sun Apr 7th 8am
- Tokyo, Japan: Sun Apr 7th 9am
- Canberra, Australia: Sun Apr 7th 10am