NEO-M9N - Integration manual
The HTTP GET request from the client to the server should contain a standard HTTP querystring in
the request URL. The querystring consists of a set of "key=value" parameters in the following form:
key=value;key=value;key=value;
The following rules apply:
• The order of keys is not important.
• Keys and values are case-sensitive.
• Keys and values must be separated by an equals character ('=').
• Key/value pairs must be separated by semicolons (';').
• If a value contains a list, each item in the list must be separated by a comma (',').
The following table describes the keys that are supported.
Key Name Unit/Range
Optional Description
token
String
Mandatory The authorization token supplied by u-blox when a client registers to use the
service.
gnss
String
Mandatory A comma-separated list of the GNSS for which data should be returned. The
currently supported GNSS are: gps and glo.
period
Numeric
[weeks]
Optional
The number of weeks into the future the data should be valid for. Data can be
requested for up to 5 weeks in to the future. If this value is not provided, the server
assumes a period of 4 weeks.
days
Numeric
[days]
Optional
The number of days into the future the data should be valid for. Can be used instead
of the period parameter when data for less than one week is desired.
resolution
Numeric
[days]
Optional
The resolution of the data: 1=every day, 2=every other day, 3=every third day. If this
value is not provided, the server assumes a resolution of 1 day.
Table 18: AssistNow Offline parameter keys
Thus, as an example, a valid parameter string would be:
token=XXXXXXXXXXXXXXXXXXXXXX;gnss=gps,glo;
3.9.3.2 Time, position and almanac
While AssistNow Offline can be used on its own, it is expected that the user will provide estimates of
the receiver's current position, 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
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 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).
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 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 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 (details can be found in NEO-M9N
Interface description [
].
UBX-19014286 - R07
3 Receiver functionality
Page 35 of 95
C1-Public
