RCB-F9T - Integration manual
Leap second information can be polled from the u-blox receiver with the message UBX-NAV-TIMELS.
3.7.8 Real time clock
u-blox receivers contain circuitry to support a real time clock, which (if correctly fitted and powered)
keeps time while the receiver is otherwise powered off. When the receiver powers up, it attempts to
use the real time clock to initialize receiver local time and in most cases this leads to appreciably
faster first fixes.
3.7.9 Date
All GNSS frequently transmit information about the current time within their data message. In most
cases, this is a time of week (often abbreviated to TOW), which indicates the elapsed number of
seconds since the start of the week (midnight Saturday/Sunday). In order to map this to a full date,
it is necessary to know the week and so the GNSS also transmit a week number, typically every 30
seconds. Unfortunately the GPS L1C/A data message was designed in a way that only allows the
bottom 10 bits of the week number to be transmitted. This is 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, GPS L1 receivers cannot tell the difference between,
for example, 1980, 1999 or 2019 etc.
Fortunately, although BeiDou and Galileo have similar representations of time, they 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 has a different
structure, based on a time of day, but again transmits sufficient information to avoid any ambiguity
during the expected lifetime of the system (the first ambiguous date will be in 2124). Therefore, u-
blox 9 receivers using Protocol Version 24 and above regard the date information transmitted by
GLONASS, BeiDou and Galileo to be unambiguous and, where necessary, use this to resolve any
ambiguity in the GPS date.
Customers attaching u-blox receivers to simulators should 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.
3.7.9.1 GPS-only date resolution
In circumstances where only GPS L1C/A signals are available and for receivers with earlier firmware
versions, the receiver establishes the date 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
at compile time and is normally set a few weeks before the software is completed, but it can be
overridden by CFG-NAVSPG-WKNROLLOVER configuration item 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 of 500 ... 1023, these will be interpreted as week numbers
1524 ... 2047 (calendar year 2009 ... 2019), whereas transmissions with week numbers from 0 to
499 are interpreted as week numbers 2048 ... 2547 (calendar year 2019 ... 2028).
It is important to set the reference rollover week number appropriately when supplying u-
blox receivers with simulated signals, especially when the scenarios are in the past.
UBX-19003747 - R04
3 Receiver functionality
Page 29 of 54
Early production information
