MIA-M10Q - Integration manual
match the corresponding values in NMEA messages generated by the same navigation epoch. This
facilitates simple synchronization between associated UBX and NMEA messages.
The seventh field is called nano and it contains the number of nanoseconds by which the rest of
the time and date fields need to be corrected to get the precise time. So, for example, the UTC time
12:49:23.521 would be reported as: hour: 12, min: 49, sec: 23, nano: 521000000.
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 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 the CFG-NAVSPG-UTCSTANDARD
configuration item. The UTC time variant configured must correspond to a GNSS that is currently
enabled. Otherwise the reported UTC time will be inaccurate.
2.8.7 Leap seconds
Due to the slightly uneven spin rate of the Earth, UTC time gradually moves out of alignment with
the mean solar time (that is, the sun no longer appears directly overhead at 0 longitude at midday).
Occasionally, a "leap second" is announced to bring UTC back into close alignment with the mean
solar time. Usually this means adding an extra second to the last minute of the year, but this 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 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.8.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
UBX-21028173 - R01
2 Receiver functionality
Page 45 of 89
C1-Public
