Developing Host software

Data injection and storage

This section describes how  to design the device firmware to store and inject the data received by the AssistNow service.

Predictive Orbits

According to the type of receiver used (with or without flash) there are two options to store and inject data in the receiver:

• Flash based

• Host based

The downloaded A-GNSS data is encoded in a sequence of UBX-MGA-ANO messages, one for every SV for every day of the period covered. 

For u-blox receivers that have flash storage, all the data can be directly transferred to the flash until it is needed. These receivers automatically select the most appropriate data to use at any time. 

Receivers without flash storage or with insufficient spare flash memory can also use AssistNow Predictive Orbits. In this case, the device firmware must store the Predictive Orbits data until the receiver needs it and then transfer only the data needed for immediate use.

Flash-based AssistNow Predictive Orbits

Flash-based Predictive Orbits functionality means that A-GNSS data is stored in the flash memory connected to the chip.

The user's host system downloads the data from the AssistNow service when an internet connection is available, and then delivers the data to the GNSS receiver. As the total amount of data to be transferred is large (typically around 100 kilobytes) and writing to flash memory is slow, the transfer must be done in blocks of up to 512 bytes, one at a time. The UBX-MGA-FLASH-DATA message is used to transmit each block to the receiver.

Predictive Orbits data stored in flash memory is not affected by any reset of the receiver. To clear the data, completely erase the whole flash memory or overwrite it with a new set of Predictive Orbits data. Transferring a dummy block of data (e.g. all zeros) also has the effect of deleting the data, although this uses a small amount of flash storage.

Flash-based storage procedure

The following steps are a typical sequence for transferring Predictive Orbits data into the receiver's flash memory:

• The host downloads a copy of a latest data from the service using the HTTPS request and stores data locally.

• It sends the first 512 bytes of that data using the UBX-MGA-FLASH-DATA message.

• It awaits a UBX-MGA-FLASH-ACK message in reply.

• Based on the contents of the UBX-MGA-FLASH-ACK message, the host sends the next block, resends the last block or aborts the whole process.

• The above three steps are repeated until all the rest of the data has been successfully transferred (or the process has been aborted).

• The host sends an UBX-MGA-FLASH-STOP message to indicate completion of the transfer.

• The host awaits the final UBX-MGA-FLASH-ACK message in reply. Background processing in the receiver prepares the transferred data for use at this stage. Particularly if the receiver is currently busy, this may take many seconds, so the host must be prepared for a delay before the UBX-MGA-FLASH-ACK is seen.

Note that the final block may be smaller than 512 bytes (where the total data size is not perfectly divisible by 512). Also, the UBX-MGA-FLASH-ACK messages are distinct from the UBX-MGA-ACK messages used for other AssistNow functions.

Any existing data will be deleted as soon as the first block of new data arrives, so no useful data will be available until the completion of the data transfer. Each block of data has a sequence number, starting at zero for the first block. In order to guard against invalid partial data downloads, the receiver will not accept blocks that are out of sequence.

Host-based AssistNow Predictive Orbits

If the u-blox receiver has no embedded Flash, the host based approach can be used. The device firmware in the Host system downloads the data from the AssistNow service when an internet connection is available. The Host stores the A-GNSS data so that it is available when the u-blox receiver needs it.

When the receiver needs the data, the Host transfers just the relevant portion of the data to the receiver, so that the receiver can start using it. This is achieved by reading the date of each message and selecting only those UBX-MGA-ANO messages with a date-stamp nearest the current time. As each message is a complete UBX message, it can be sent directly to the receiver with no extra packaging.

When parsing the data obtained from the AssistNow service, the following points should be noted:

• The data is made up of a sequence of UBX-MGA-ANO messages.

• the messages does not have all the same sized but the Host firmware should read their length from the UBX header to work out where the message ends (and where the next begins).

• Each message indicates the SV for which it is applicable through the svId and gnssId fields.

• Each message contains a date-stamp within the year, month and day fields.

• The messages will be ordered chronologically, earliest first.

• Messages with same date-stamp will be ordered by ascending gnssId and then ascending svId.

Host-based procedure

The following steps are a typical sequence for host-based firmware:

• The host downloads a copy of a latest data from the AssistNow service and stores it locally.

• It is recommended to also download a current set of almanac data from AssistNow service

• the Host waits until the GNSS receiver should be used

• the host transfers  position estimate (UBX-MGA-INI-POS) and/or time estimate (UBX-MGA-INI-TIME) and/or any almanac (e.g. UBX-MGA-GPS-ALM for GPS) to the receiver.

  • position and time estimate re very important information  to assist the receiver. The format of the corresponding message can be found in the Interface Specification document of every u-blox GNSS receiver. You can find this document by visiting the Products and Services webpage in the u-blox website

• the Host scans through A-GNSS data looking for entries with a date-stamp that most closely matches the current (UTC) time/date.

• the host sends each such UBX-MGA-ANO message to the receiver.

Live Orbits

As u-blox receivers do not connect directly with the internet, to use the AssistNow Live Orbits data the the host shall connect to the internet, download the data from the AssistNow service and inject A-GNSS data into the receiver. 

The simplest case is to fetch the AssistNow Live Orbits data (by means of a single HTTPS GET request), and send the resulting data to the receiver immediately. The data returned by the AssistNow Online Service is a sequence of UBX-MGA messages, starting with an estimate of the current time in the form of a UBX-MGA-INI-TIME_UTC message.

Note: It is very important that the receiver has started up fully before sending it any assistance data. The first assistance message provides the receiver with a sense of time. If this message is not received for any reason, the receiver will not use the rest of the assistance data.

A typical sequence of use of the AssistNow Online Service comprises the following steps:

• Power-up the u-blox receiver

• Request the AssistNow Live Orbits data

• Send UBX-MGA-INI-TIME_UTC followed by hardware time synchronization pulse if hardware time synchronization is required.

• Send the UBX messages obtained from the AssistNow service to the receiver.

Preserving data during Power-off

The performance of u-blox receivers immediately after they are turned on is enhanced by providing them with as much useful A-GNSS data as possible. All the types of data delivered by assistance can be retained while the receiver is powered down for use when power is restored. Obviously the value of this data will diminish as time passes, but in many cases it remains very useful and can significantly improve time to first fix.

The are several ways in which a u-blox receiver can retain ephemeris, Ionospheric corrections data and health state while it is powered down, including:

• Battery Backed RAM: The receiver can be supplied with sufficient power to maintain a small portion of internal storage, while it is otherwise turned off. 

• Save on Shutdown: The receiver can be instructed to dump its current state to the attached flash memory (where fitted) as part of the shutdown procedure; this data is then automatically retrieved when the receiver is restarted. 

• Database Dump: The receiver can be asked to dump the state of its internal database in the form of a sequence of UBX messages reported to the host; these messages can be stored by the host and then sent back to the receiver when it has been restarted. 

For further information about each option, please refer to the Integration guide of the GNSS receiver

Best practices

Predictive Orbits

Request frequency

The Orbit predictions are updated very frequently (see. Service specification guide), nevertheless there is no need to query the data continuously because the retrieved information are valid for one or more days (according to the period selected). Remind also that except when using a Developer plan, each device can request the data up to 2 times/day.

Almanac Data and GLONASS

The receiver needs a valid set of GLONASS almanac data in order to use the GLONASS Predictive Orbits data. 

GPS does not need an almanac but using one is highly recommended since it improves the performance significantly.

Time, Position and Almanac

While AssistNow Predictive Orbits can be used on its own, it is expected that the user will provide estimates of the receiver's current position and the current time, and ensure that a reasonably up-to-date almanac is available.

In most cases, this information is likely to be available without the user needing to do anything.

For example, where the receiver is connected to a battery backup power supply and has a functioning real time clock (RTC), the receiver will keep its own sense of time and will retain the last known position and any almanac.

However, should the receiver be completely unpowered before start-up, then it will greatly improve TTFF if time (UBX-MGA-INI-TIME_UTC), position (UBX-MGA-INI-POS__*) and the almanac (UBX-MGA-***-ALM) can be supplied in some form.

Almanac data has a validity period of several weeks and can be downloaded from the AssistNow service. It can then be stored in the host for uploading on receiver startup, or it can be transferred to the receiver straight away and preserved there (provided suitable non-volatile storage is available). Obviously, where a receiver has a functioning RTC, it should be able to keep its own sense of time, but where no RTC is fitted (or power is completely turned off), providing a time estimate via the UBX-MGA-INI-TIME_UTC message will be beneficial.

Similarly, where a receiver has effective non-volatile storage, the last known position will be recalled, but if this is not the case, then it will help TTFF to provide a position estimate via one of the UBX-MGA-INI-POS_XYZ or UBX-MGA-INI-POS_LLH messages.

Note: Where circumstances prevent the provision of all three of these pieces of data, providing some of them is likely to be better than none at all.

Live Orbits

Request frequency

A device is only expected to request assistance data at GNSS receivers startup. Therefore, there is no need to request assistance data when the receiver is already in tracking mode because the receiver will keep itself updated directly from the satellites thereafter.  Remind also that except when using a Developer plan, each device can request the data up to 10 times/day but in most of the use cases 3-5 request per day are sufficient.

Initial position 

For better performance the host should submit the position information in the GNSS receiver according to the message format UBX-MGA-INI-POS_LLH or UBX-MGA-INI-POS_XYZ (see The GNSS Interface specification ).  According to the position accuracy provided in the position information message the GNSS can decide the best strategy to minimize the Time-To-First-Fix. For example, if the position is accurate to 100 km or better, the u-blox receiver chooses to go for a more optimistic startup strategy. This results in quicker startup time. If the submitted user position is less accurate than what is specified with the “pacc” parameter, then the user experiences prolonged or even failed start-ups. 

Time parameters (tacc and latency)

Time data is always returned with each  AssistNow Live Orbits 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 parameter is set to +/-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), then the client can choose to set the accuracy of the time message (tacc) to a much smaller value (e.g. 0.5 s). This results in a faster TTFF. The latency value can also be adjusted as appropriate. However, these parameters 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 (by maintaining local RTC via a backup supply or using a u-blox cellular modem and “RTC sharing” functionality) and then modify the time data received from the service as appropriate.

Flow control

u-blox GNSS receivers aim to process incoming messages as quickly as possible, but there will always be a small delay in processing each message. Transferring assistance data to the receiver can involve sending as many as one hundred individual messages to the receiver, one after the other. If the communication link is fast, and/or the receiver is busy (trying to acquire new signals), it is possible that the internal buffers will overflow and some messages will be lost.

To avoid this, u-blox receivers support an optional flow control mechanism for assistance and it's highly recommended to implement it in the device firmware.

For u-blox generation 9 and 10 receivers, this can be activated by setting the CFG-NAVSPG-ACKAIDING configuration item in the UBX-CFG-VALSET message. 

As a result, the receiver will issue an acknowledgement message (UBX-MGA-ACK) for each assistance message it successfully receives. The host software can examine these acknowledgements to establish whether there were any problems with the data sent to the receiver and deduce (by the lack of acknowledgement) if any messages have been lost. It may then be appropriate to resend some of the assistance messages.

There are two possible strategies

• The simplest way to implement flow control would be to send one UBX-MGA assistance message at a time, waiting for the acknowledgement, before sending the next. However, such a strategy is likely to introduce significant delays into the whole assistance process. 

• A smarter strategy is to send all assistance messages and then analyze the resulting acknowledgements to see whether there have been significant losses. Adding small delays during the transmission may be a simple but effective way to avoid substantial loss of data.

Note: It's also worth noting that the GNSS receiver always validate the received messages and automatically discards the invalid ones, if any.

Next readings

• Service integration

• Service specifications

• Service API specification