MAX-M10M - Integration manual
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 without power before
startup, then it will greatly improve TTFF if time, position and almanac can be supplied in some form.
Almanac data has a validity period of several weeks, so it can be downloaded from the AssistNow
Online service at roughly the same time the AssistNow Offline data is obtained. 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).
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 to lower the time to first fix and make use of the AssistNow
Offline data.
Similarly, where a receiver has effective non-volatile storage, the last known position will be recalled,
but if this is not the case, then providing a position estimate via one of the UBX-MGA-INI-POS_XYZ
or UBX-MGA-INI-POS_LLH messages will improve the TTFF (details can be found in the MAX-M10M
interface description [
].
Where circumstances prevent providing all three of these pieces of data, providing some is likely to
be better than none at all, as this helps to lower the TTFF.
3.12.3.3 Host-based AssistNow Offline
Host-based
AssistNow Offline involves AssistNow Offline data being stored until it is needed by the
host system in whatever memory it has available.
The host system must download the data from the AssistNow Offline service when an internet
connection is available, but retain it until the time the u-blox receiver needs it. At this point, the host
must upload just the relevant portion of the data to the receiver, so that the receiver can start using
it. This is achieved by parsing all the data and uploading to the receiver only those UBX-MGA-ANO
messages with a timestamp nearest to the current time. As each item is a complete UBX message,
it can be sent directly to the receiver with no extra packaging. The host can control the message
flow if required, but in most cases this is likely to prove unnecessary.
When parsing the data obtained from the AssistNow Offline service, the following points should be
noted:
• The data is made up of a sequence of UBX-MGA-ANO messages.
• Customers should not rely on the messages all being of fixed size, but should read their length
from the UBX header to work out where the message ends (and where the next begins).
• Each message indicates the satellite for which it is applicable through the svId and gnssId
fields.
• Each message contains a timestamp within the year, month and day fields.
• Midday (UTC) on the day indicated should be considered to be the point at which the data is
most applicable.
• The messages will be ordered chronologically, earliest first.
• Messages with the same timestamp will be ordered by ascending gnssId and then ascending
svId.
3.12.3.3.1 Host-based procedure
The typical sequence for host-based AssistNow Offline is as follows:
UBX-22038241 - R02
3 Receiver functionality
Page 57 of 92
C1-Public
