RCB-F9T - Integration manual
• If the datatype "pos" is requested, the server will return the position and accuracy in the
response data. When this data is supplied to the u-blox receiver, depending on the accuracy
of the provided data, the receiver can then choose to select a better startup strategy. For
example, if the position is accurate to 100 km or better, the u-blox receiver will choose to go
for a more optimistic startup strategy. This will result in quicker startup time. The receiver will
decide which strategy to choose, depending on the "pacc" parameter. If the submitted user
position is less accurate than what is being specified with the "pacc" parameter, then the user
will experience prolonged or even failed startups.
3.6.4.4.2 Time parameters (tacc and latency)
Time data is always returned with each request. The time data refers to the time at which the
response leaves the server, corrected by an optional latency value. This time data provided by the
service is accurate to approximately 10 ms but by default the time accuracy is indicated to be +/-10
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 needed. 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 startups.
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.7 Clocks and time
This section introduces and explains the concepts of receiver clocks and time bases.
3.7.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 one of the GNSS systems in a multi-GNSS receiver. In previous
generations of u-blox receivers this was always the GPS time-base, but for the current 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
UBX-19003747 - R04
3 Receiver functionality
Page 25 of 54
Early production information
