ZED-F9P - Integration manual
When the nano field is negative, the number of seconds (and maybe minutes, hours, days, months
or even years) will have been rounded up. Therefore, some or all of them must be adjusted in order
to get the correct time and date. Thus in an extreme example, the UTC time 23:59:59.9993 on 31st
December 2011 would be reported as: year: 2012, month: 1, day: 1, hour: 0, min: 0, sec: 0, nano:
-700000.
Of course, if a resolution of one hundredth of a second is adequate, negative nano values can simply
be rounded up to 0 and effectively ignored.
Which master clock the UTC time is referenced to is output in the message UBX-NAV-TIMEUTC.
The preferred variant of UTC time can be specified using CFG-NAVSPG-UTCSTANDARD
configuration item.
3.10.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.10.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.10.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-
UBX-18010802 - R08
3 Receiver functionality
Page 55 of 110
Early production information
