MAX-M10S - Integration manual
Note that iTOW values may not be valid (i.e. they may have been generated with insufficient
conversion data) and therefore it is not recommended to use the iTOW field for any other purpose.
The original designers of GPS chose to express time/date as an integer week number
(starting with the first full week in January 1980) and a time of week (often abbreviated
to TOW) expressed in seconds. Manipulating time/date in this form is far easier for digital
systems than the more conventional year/month/day, hour/minute/second representation.
Consequently, most GNSS receivers use this representation internally, only converting to a
more conventional form at external interfaces. The iTOW field is the most obvious externally
visible consequence of this internal representation.
If reliable absolute time information is required, it is recommended to use the UBX-NAV-PVT
navigation solution message which also contains additional fields that indicate the validity (and
accuracy in UBX-NAV-PVT) of the calculated times (see also the GNSS times section below for
further messages containing time information).
2.8.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 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.
2.8.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
UBX-20053088 - R03
2 Receiver functionality
Page 43 of 89
C1-Public
