RCB-F9T - Integration manual
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.
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
UBX-22004121 - R01
3 Receiver functionality
Page 32 of 64
C1-Public
Early production information
