*GPS Time is a continuous counting time scale beginning at the January 5, 1980 to January 6, 1980 midnight. It is split into two parts: a time of week measured in seconds from midnight Sat/Sun and a week number. The time of week is transmitted in an unambiguous manner by the satellites, but only the bottom 10 bits of the week number are transmitted. This means that a receiver will see a week number count that goes up steadily until it reaches 1023 after which it will "roll over" back to zero, before steadily going up again. Such a week rollover will occur approx. every 20 years. The last week rollover occurred in 1999 and the next one will be in 2019. It is up to the GNSS receiver to correctly handle the ambiguity of the transmitted week numbers and the associated rollovers.*

**u-blox GNSS receivers** solve this problem by assuming that all week numbers must be at least as large as a reference rollover week number. This reference rollover week number is hard-coded into the firmware at compile time and is normally set a few weeks before the s/w is completed, but it can be overridden by a configuration message to any value the user wishes. The following example illustrates how this works: Assume that the reference rollover week number set in the firmware at compile time is 1524 (which corresponds to a week in calendar year 2009, but would be transmitted by the satellites as 500). In this case, if the receiver sees transmissions containing week numbers in the range 500 ... 1023, these will be interpreted as week numbers 1524 ... 2027 (CY 2009 ... 2019), whereas transmissions with week numbers from 0 to 499 are interpreted as week numbers 2028 ... 2526 (CY 2019 ... 2029).

With that u-blox receivers print out the correct date for 20 years after the firmware was compiled (reference week in **UBX-CFG-NAVX5**). So there won't be any effects at the 2nd weeknumber roll over in 2019.

If the application provides a later valid week number than the one in **UBX-CFG-NAVX5** the 20 years start from this later week number.