ZED-F9T - Integration Manual
It is however important to note that the first six fields are the result of rounding to the nearest
hundredth of a second. Consequently the nano value can range from -5000000 (i.e. -5 ms) to
+994999999 (i.e. nearly 995 ms).
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 will need to 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.
UTC time is derived directly from the GNSS time scale, which in turn is realized by the
receiver's navigation solution. The derivation of the UTC time includes various parameters
that are having their own errors which are then added on top of receiver's navigation solution
error. Because of that, UTC time is not recommended to be used in high accuracy timing
applications. The best timing accuracy and stability is achieved when receiver outputs GNSS
time scale rather than UTC.
3.5.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 and 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.5.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.5.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 which 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
UBX-19005590 - R01
3 Receiver functionality
Page 40 of 80
Advance Information
