ZED-F9T-Integration Manual
Time reference Message
GPS time UBX-NAV-TIMEGPS
BeiDou time UBX-NAV-TIMEBDS
GLONASS time UBX-NAV-TIMEGLO
Galileo time UBX-NAV-TIMEGAL
UTC time UBX-NAV-TIMEUTC
Table 19: GNSS times
3.5.5 Time validity
Information about the validity of the time solution is given in the following form:
•
Time validity: Information about time validity is provided in the valid flags (e.g. validDate
and validTime flags in the UBX-NAV-PVT message). If these flags are set, the time is known
and considered as valid for being used. These flags can be found in the GNSS times table in the
GNSS times section 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 could 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.5.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). What is more, 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.
UBX-19005590 - R01
3 Receiver functionality Page 39 of 80
Advance Information
To Next Page
Loading...
Need help?
General
