GPS week roll-over April 6th

[rmackay9]

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

[rmackay9]

For those Trimble GPS users out there, this discussion on Trimble.com seems to indicate that it would be a good idea to double check that the GPS’s firmware is a recent version. If you scroll down in the discussion there is a table from Alexander Holsteinson which includes the minimum version that should be used.

[ThomasSFL (Thomas Stone)]

Thanks @rmackay9 !

Have you recently checked the same GPS to see if the Gwk incremented by 1 (to 2047)?

i checked a Here+ Rover today, and I got Gwk = 2048. I guess that means that our GPS firmwares were compiled during the same week. (i.e., my Gwk was 2046 when your Gwk was 2046) Or perhaps, the ublox reference rollover week number is set such that Gwk is the same across all ublox units.

[rmackay9]

@ThomasSFL,

I have not tested the exact FlightController+GPS unit since the roll-over but @gmorph did a test and his logs, like yours, show the week has incremented to 2048 (as expected). Grant went the extra mile and actually flew the vehicle through the roll-over which was great proof that it handled the roll-over event properly.

As a side note, now that I understand this whole thing a bit better, I think that even if the UBlox GPS firmware is compiled a different week, all Ublox units will show 2048 now. Different firmwares have a different gps-week offset hard-coded into them, but the final calculation produces a number that is an offset from a date in 1984 so the result has to be the same across all units. I.e. they are either the same as what our units are showing or they are incorrect.

I’m glad this all has gone smoothly (knock-on-wood).