ZED-F9K - Integration manual
and considered valid for use. These flags are shown in table GNSS times in section GNSS times
above as well as in the UBX-NAV-PVT message.
• Time validity confirmation: Information about confirmed validity is provided in the
confirmedDate
and
confirmedTime
flags in the UBX-NAV-PVT message. If these flags are
set, the time validity can be confirmed by using an additional independent source, meaning
that the probability of the time to be correct is very high. Note that information about time
validity confirmation is only available if the
confirmedAvai
bit in the UBX-NAV-PVT message
is set.
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.
3.9.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.
UBX-20046189 - R01
3 Receiver functionality
Page 55 of 105
C1-Public
Early production information
