ZED-F9T - Integration Manual
and receiver local time is called the clock bias (and the clock drift is the rate at which this bias is
changing).
In practice the receiver's local oscillator will not be as stable as the atomic clocks to which GNSS
systems are referenced and consequently clock bias will tend to accumulate. However, when
selecting the next navigation epoch, the receiver will always try to use the 1 kHz clock tick which it
estimates to be closest to the desired fix period as measured in GNSS system time. Consequently
the number of 1 kHz clock ticks between fixes will occasionally vary (so when producing one fix per
second, there will normally be 1000 clock ticks between fixes, but sometimes, to correct drift away
from GNSS system time, there will be 999 or 1001).
The GNSS system time calculated in the navigation solution is always converted to a time in both
the GPS and UTC time-bases for output.
Clearly when the receiver has chosen to use the GPS time-base for its GNSS system time, conversion
to GPS time requires no work at all, but conversion to UTC requires knowledge of the number of
leap seconds since GPS time started (and other minor correction terms). The relevant GPS to UTC
conversion parameters are transmitted periodically (every 12.5 minutes) by GPS satellites, but can
also be supplied to the receiver via the UBX-MGA-GPS-UTC aiding message. By contrast when the
receiver has chosen to use the GLONASS time-base as its GNSS system time, conversion to GPS
time is more difficult as it requires knowledge of the difference between the two time-bases, but
conversion to UTC is easier (as GLONASS time is closely linked to UTC).
Where insufficient information is available for the receiver to perform any of these time-base
conversions precisely, pre-defined default offsets are used. Consequently plausible times are nearly
always generated, but they may be wrong by a few seconds (especially shortly after receiver start).
Depending on the configuration of the receiver, such "invalid" times may well be output, but with
flags indicating their state (e.g. the "valid" flags in UBX-NAV-PVT).
u-blox receivers employ multiple GNSS system times and/or receiver local times (in order to
support multiple GNSS systems concurrently), so users should not rely on UBX messages
that report GNSS system time or receiver local time being supported in future. It is therefore
recommended to give preference to those messages that report UTC time.
3.5.3 iTOW timestamps
All the main UBX-NAV messages (and some other messages) contain an iTOW field which indicates
the GPS time at which the navigation epoch occurred. Messages with the same iTOW value can be
assumed to have come from the same navigation solution.
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, users are 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).
3.5.4 GNSS times
Each GNSS has its own time reference for which detailed and reliable information is provided in the
messages listed in the table below.
UBX-19005590 - R01
3 Receiver functionality
Page 38 of 80
Advance Information
