SAM-M10Q - Integration manual
happen on 30th June. When this happens, UTC clocks are expected to go from 23:59:59 to 23:59:60,
and only then on to 00:00:00.
It is also possible to have a negative leap second, in which case there will only be 59 seconds in a
minute and 23:59:58 will be followed by 00:00:00.
u-blox receivers are designed to handle leap seconds in their UTC output and consequently
applications processing UTC times from either NMEA or UBX messages should be prepared to
handle minutes that are either 59 or 61 seconds long.
Leap second information can be polled from the receiver with the message UBX-NAV-TIMELS.
2.7.8 Date ambiguity
Each navigation satellite transmits information about the current date and time in the data
message. The time of week (TOW) indicates the elapsed number of seconds since the start of the
week (midnight Saturday/Sunday). The week number (WN) indicates the elapsed number of weeks
since the particular GNSS system was started. By combining these two values the current date and
time can be known. Modern GPS satellites use a 13-bit value for the week number. As GPS system
was started in 1980, it allows the week number to represent dates up to year 2137. Unfortunately,
at the time when the commonly used GPS L1C/A data message was designed the signal had only
10 bits available for the week number. The top bits of the full week number had to be left out. The
10 bottom bits of the week number are not sufficient to yield a completely unambiguous date as
every 1024 weeks (a bit less than 20 years), the transmitted week number value "rolls over" back to
zero. Consequently, the information in GPS L1 message does not differentiate between, for example,
1980, 1999, or 2019. GPS L1 receivers must thus use additional methods to calculate the full week
number.
Although BeiDou and Galileo have similar representations of time, they still transmit sufficient
bits for the week number to be unambiguous for the foreseeable future (the first ambiguity will
be in 2078 for Galileo, and not until 2163 for BeiDou). GLONASS presents the time and date in
different way and transmits sufficient information to avoid any ambiguity during the expected
lifetime of the system (the first ambiguous date will be in 2124). Therefore, the receiver regards
the date information transmitted by GLONASS, BeiDou, and Galileo to be unambiguous and, where
necessary, uses this information to resolve any ambiguity in the GPS date.
If the receiver is connected to a simulator, be aware that GPS time is referenced to 6th
January 1980, GLONASS to 1st January 1996, Galileo to 22nd August 1999 and BeiDou to
1st January 2006; the receiver cannot be expected to work reliably with signals simulated
before these dates.
2.7.8.1 GPS-only date resolution
If only GPS L1C/A signals are available, the receiver establishes the date by assuming that all week
numbers must be at least as large as the reference rollover week number. The default value for
the reference rollover week number is selected at the compile time of the receiver firmware and is
normally set to a value of a few weeks before the software is completed. The value can be overridden
by CFG-NAVSPG-WKNROLLOVER configuration item.
The following example illustrates how this works:
Assume that the reference rollover week number set in the firmware at compile time is 2148 (which
corresponds to a week in calendar year 2021, but is transmitted by the satellites as 100). In this case,
if the receiver sees transmissions containing week numbers in the range of 100 ... 1023, they are
interpreted as week numbers 2148 ... 3071 (calendar years 2021 ... 2038), whereas transmissions
UBX-22020019 - R01
2 Receiver functionality
Page 36 of 72
C1-Public
