SAM-M10Q - Integration manual
validDate
means that the receiver has knowledge of the current date. However, it must
be noted that this date might be wrong for various reasons. Only when the
confirmedDate
flag is set, the probability of the incorrect date information drops significantly.
validTime
means that the receiver has knowledge of the current time. However, it must
be noted that this time might be wrong for various reasons. Only when the
confirmedTime
flag is set, the probability of incorrect time information drops significantly.
fullyResolved
means that the UTC time is known without full seconds ambiguity. When
deriving UTC time from GNSS time the number of leap seconds must be known, with the
exception of GLONASS. It might take several minutes to obtain such information from the
GNSS payload. When the one second ambiguity has not been resolved, the time accuracy is
usually in the range of ~20s.
2.7.6 UTC representation
UTC time is used in many NMEA and UBX messages. In NMEA messages it is always reported
rounded to the nearest hundredth of a second. Consequently, it is normally reported with
two decimal places (e.g. 124923.52). Although compatibility mode (selected using CFG-NMEA-
COMPAT) requires three decimal places, rounding to the nearest hundredth of a second remains, so
the extra digit is always 0.
UTC time is also reported within some UBX messages, such as UBX-NAV-TIMEUTC and UBX-NAV-
PVT. In these messages date and time are separated into seven distinct integer fields. Six of these
(year, month, day, hour, min. and sec.) have fairly obvious meanings and are all guaranteed to
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.7.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
UBX-22020019 - R01
2 Receiver functionality
Page 35 of 72
C1-Public
