ZED-F9R-Integration manual
When the receiver first starts, it has no information about how these clock ticks relate to other time
systems; it can only count time in 1 millisecond steps. However, as the receiver derives information
from the satellites it is tracking or from aiding messages, it estimates the time that each 1-kHz
clock tick takes in the time base of the chosen GNSS system. This estimate of GNSS time based on
the local 1-kHz clock is called receiver local time.
As receiver local time is a mapping of the local 1-kHz reference onto a GNSS time base, it
may experience occasional discontinuities, especially when the receiver first starts up and the
information it has about the time base is changing. Indeed, after a cold start, the receiver local
time will initially indicate the length of time that the receiver has been running. However, when the
receiver obtains some credible timing information from a satellite or an aiding message, it will jump
to an estimate of GNSS time.
3.10.2 Navigation epochs
Each navigation solution is triggered by the tick of the 1-kHz clock nearest to the desired navigation
solution time. This tick is referred to as a navigation epoch. If the navigation solution attempt is
successful, one of the results is an accurate measurement of time in the time base of the chosen
GNSS system, called GNSS system time. The difference between the calculated GNSS system time
and receiver local time is called clock bias (and 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. This means that 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 as
GLONASS time is closely linked to UTC, conversion to UTC is easier.
When insufficient information is available for the receiver to perform any of these time base
conversions precisely, predefined 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 use UBX messages
UBX-20039643 - R06
3 Receiver functionality Page 66 of 119
C1-Public
To Next Page
Loading...
Need help?
General
