MIA-M10Q - Integration manual
drive many of the receiver's processes. In particular, the measurement of satellite signals is arranged
to be synchronized with the "ticking" of this 1-kHz clock signal.
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.
2.8.2 GNSS time bases
GNSS receivers must handle a variety of different time bases as each GNSS has its own reference
system time. What is more, although each GNSS provides a model for converting their system time
into UTC, they all support a slightly different variant of UTC. So, for example, GPS supports a variant
of UTC as defined by the US National Observatory, while BeiDou uses UTC from the National Time
Service Center, China (NTSC). While the different UTC variants are normally closely aligned, they
can differ by as much as a few hundreds of nanoseconds.
Although u-blox receivers can combine a variety of different GNSS times internally, the user must
choose a single type of GNSS time and, separately, a single type of UTC for input (on EXTINT pins)
and output (via the TIMEPULSE pin) and the parameters reported in corresponding messages.
The CFG-TP-TIMEGRID_TP* configuration item allows the user to choose between any of the
supported GNSS (GPS, GLONASS, BeiDou, etc.) time bases and UTC. Also, the CFG-NAVSPG-
UTCSTANDARD configuration item allows the user to select which variant of UTC the receiver
should use. This includes an "automatic" option which causes the receiver to select an appropriate
UTC version itself, based on the GNSS configuration, using, in order of preference, USNO if GPS is
enabled, SU if GLONASS is enabled, NTSC if BeiDou is enabled and, finally, European if Galileo is
enabled.
The receiver will assume that an input time pulse uses the same GNSS time base as specified for the
time pulse output. So if the user selects GLONASS time for time pulse output, any time pulse input
must also be aligned to GLONASS time (or to the separately chosen variant of UTC). Where UTC is
selected for time pulse output, any GNSS time pulse input will be assumed to be aligned to GPS time.
The receiver allows users to independently choose GNSS signals used in the receiver (using
CFG-SIGNAL-*) and the input/output time base (usingCFG-TP-*). For example it is possible
to instruct the receiver to use GPS and GLONASS satellite signals to generate BeiDou time.
This practice will compromise time pulse accuracy if the receiver cannot measure the timing
difference between the constellations directly and is therefore not recommended.
The information that allows GNSS times to be converted to the associated UTC times is
only transmitted by the GNSS at relatively infrequent periods. For example GPS transmits
UTC(USNO) information only once every 12.5 minutes. Therefore, if a time pulse is
configured to use a variant of UTC time, after a cold start, substantial delays before the
receiver has sufficient information to start outputting the time pulse can be expected.
Each GNSS has its own time reference for which detailed and reliable information is provided in the
messages listed in the table below.
UBX-21028173 - R01
2 Receiver functionality
Page 42 of 89
C1-Public
