RCB-F9T - Integration manual
applications. The best timing accuracy and stability is achieved when receiver outputs GNSS
time scale rather than UTC.
3.9.7 Leap seconds
Occasionally it is decided (by one of the international time keeping bodies) that, due to the slightly
uneven spin rate of the Earth, UTC has moved sufficiently out of alignment with mean solar time (i.e.
the Sun no longer appears directly overhead at 0 longitude at midday). A "leap second" is therefore
announced to bring UTC back into close alignment. This normally involves adding an extra second
to the last minute of the year, but it can also 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 theoretically 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 users
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 u-blox receiver with the message UBX-NAV-TIMELS.
3.9.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.9.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.
UBX-22004121 - R01
3 Receiver functionality
Page 33 of 64
C1-Public
Early production information
