ZED-F9P-Integration Manual
UBX-18010802 - R02
4 Receiver description Page 43 of 114
Advance Information
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.5s). 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.
4.6.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 will run at least two instances of the AssistNow Online Service on
independent machines. Customers will have a free 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 fall-back mechanism
to use another server instead.
4.7 Broadcast navigation data
This section describes the data reported via UBX-RXM-SFRBX.
The UBX-RXM-SFRBX reports the broadcast navigation data message collected by the receiver
from each tracked signal. When enabled, a separate message is generated every time the receiver
decodes a complete subframe of data from a tracked signal. The data bits are reported, as received,
including preambles and error checking bits as appropriate. However because there is considerable
variation in the data structure of the different GNSS signals, the form of the reported data also
varies. Indeed, although this document uses the term "subframe" generically, it is not strictly the
correct term for all GNSS (e.g. GLONASS has "strings" and Galileo has "pages").
4.7.1 Parsing navigation data subframes
Each UBX-RXM-SFRBX message contains a subframe of data bits appropriate for the relevant
GNSS, delivered in a number of 32 bit words, as indicated by numWords field.
Due to the variation in data structure between different GNSS, the most important step in parsing
a UBX-RXMSFRBX message is to identify the form of the data. This should be done by reading
the gnssId field, which indicates which GNSS the data was decoded from. In almost all cases, this
is sufficient to indicate the structure and the following sections are organized by GNSS for that
reason. However, in some cases the identity of the GNSS is not sufficient, and this is described,
where appropriate, in the following sections.
In most cases, the data does not map perfectly into a number of 32 bit words and, consequently,
some of the words reported in UBX-RXM-SFRBX messages contain fields marked as "Pad". These
fields should be ignored and no assumption should be made about their contents.
UBX-RXM-SFRBX messages are only generated when complete subframes are detected by the
receiver and all appropriate parity checks have passed.
To Next Page
Loading...
Need help?
General
