ZED-F9T - Integration Manual
seconds in order to account for network latency and any time between the client receiving the data
and it being provided to the receiver.
If both the network latency and the client latency can safely be assumed to be very low (or are
known), the client can choose to set the accuracy of the time message (tacc) to a much smaller
value (e.g. 0.5 s). This will result in a faster TTFF. The latency can also be adjusted as appropriate.
However, these fields should be used with caution: if the time accuracy is not correct when the time
data reaches the receiver, the receiver may experience prolonged or even failed start-ups.
For optimal results, the client should establish an accurate sense of time itself (e.g. by calibrating
its system clock using a local NTP service) and then modify the time data received from the service
as appropriate.
3.4.7 Multiple servers
u-blox has designed and implemented the AssistNow Online Service in a way that should provide
very high reliability. Nonetheless, there will be rare occasions when a server is not available (e.g. due
to failure or some form of maintenance activity). In order to protect customers against the impact
of such outages, u-blox runs at least two instances of the AssistNow Online Service on independent
machines. Customers have a choice of requesting assistance data from any of these servers, as all
will provide the same information. However, should one fail for whatever reason, it is highly unlikely
that the other server(s) will also be unavailable. Therefore customers requiring the best possible
availability are recommended to implement a scheme where they direct their requests to a chosen
server, but, if that server fails to respond, have a fallback mechanism to use another server instead.
3.5 Clocks and time
This section introduces and explains the concepts of receiver clocks and time bases.
3.5.1 Receiver local time
The receiver is dependent on a local oscillator for both the operation of its radio parts and also for
timing within its signal processing. No matter what nominal frequency the local oscillator has, u-blox
receivers subdivide the oscillator signal to provide a 1 kHz reference clock signal, which is used to
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 relevant GNSS system. In previous generations of u-blox receivers
this was always the GPS time-base, but for this generation it could be GPS, GLONASS, Galileo, or
BeiDou. 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 aiding message, it will jump to
an estimate of GNSS time.
3.5.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
UBX-19005590 - R01
3 Receiver functionality
Page 37 of 80
Advance Information
