AssistNow Service specifications

GNSS Systems and signals

AssistNow supports the GNSS and signals listed in the following table.  

Data Size

The table below shows  the typical A-GNSS data volumes for a receiver using the AssistNow service.

The values reported  refers to the payload field of the UBX message plus the 8 bytes for headers and checksum:

• 2 bytes for the Header

• 2 bytes for message class and message ID

• 2 bytes for the Length field

• 2 bytes for the Checksum

Live Orbits 

Notes:

• the UBX-MGA-INI_TIME_UTC is always provided as the first message of the service response and shall be always injected as first message into the receiver

• the total data size might change over the time because of  temporary unavailability of satellites or new satellites, or filtering applied service side if data quality is insufficient. Although we we plan to update the table when needed, your are invited to take in consideration that the data downloaded from the service might change over the time.  The Host Software guide provides additional guidance about the best practice to adopt.

Predictive Orbits 

The table below reports the data size for 1 day  and for each single constellation and for the Almanac. To calculate the total data size when downloading data for multiple GNSS and for periods longer than 1 day, simply do the corresponding maths.

Example: you need to download the Orbit predictions data for 3 days for GPS and GLONASS.

• in the API request select the data type uporb_3

•  the total amount of data sent by the service  are 12.852 bytes

  • GPS: 31 msgs * 84 bytes * 3 days = 7.812bytes

  • GLONASS:  20 msgs *  84bytes * 3 days = 5.040 bytes

When downloading also the Almanac you need sum the  the corresponding size.

Note: It's worth noting that the service might filter in advance data with not sufficient quality, therefore we discourage to write the device firmware to check exactly the the expected data size

Data types and validity

AssistNow service can provide multiple type of data:

• Almanac: this data set contains coarse orbital and status information about all satellites in the constellation. It helps the  receivers to quickly determine which satellites are available for positioning . It's worth noting that almanac information are broadcasted also by the satellites themselves according to the table below.  This implies that to obtain the full Almanac from the satellite instead of using AssistNow, the receiver should stay switched on for a long period, without any interruption,  that is not an option for battery operated devices and in several other use cases. The Almanac broadcast period in the table indicates the time a GNSS receiver would take to obtain the Almanac for all satellites in an ideal environment directly from GNSS satellites.

The table reports also the validity for each constellation. 

• Orbit prediction: this data set contains an approximation of the satellite orbits, required to estimate the GNSS receiver position. While Almanac is used to find faster the visible satellites and lock the signal, the orbit prediction are essential essential for positioning and navigation whenever ephemeris (see next data type) data is unavailable. AssistNow Predictive Orbits provides the satellite orbit predictions from 1 to 14 days at a resolution of 1 day. 

It's important to highlight that the accuracy of satellite orbit prediction degrades over time, impacting the accuracy of the initial estimated position.

The following table reports, for each  GNSS, the available options for the prediction length.

• Ephemeris: this is the set of parameters that describe the precise orbital position and velocity of a satellite at a given time and are used by the GNSS receiver to compute the position accurately. This data is broadcast by each satellite but in nominal signal condition the download of ephemeris for a sufficient number of satellites takes in average 30 seconds. In weak signal conditions this time can increase significantly and even result in a NO-fix condition. This is the reason because getting ephemeris data using a data network from AsssitNow Live Orbits service, can significantly minimize the position fix time and maximize the probability to get to a fix in typical IoT environments.

Because ephemeris represent the precise orbits of the satellite, the validity of the data is limited to few hours and needs to be refreshed, requesting to the service the new data. The following table shows the validity period, in normal satellite operating conditions, for the supported GNSS and signals. The receiver automatically detects if the injected ephemeris data are valid or not and discards the invalid data. The reported validity period assumes that SV operate in standard mode.

• Klobuchar Ionospheric corrections: the Klobuchar model is a simplified ionospheric correction algorithm used in GPS to mitigate ionospheric delay, which is one of the largest sources of error in GNSS positioning. The ionosphere causes a delay in the propagation of GNSS signals, primarily affecting the L1 frequency (1575.42 MHz) used by GPS. 

  • The model estimates total electron content (TEC) in the ionosphere based on a simple cosine function that varies with local time, assuming a single-layer ionosphere.

  • Satellites broadcast eight coefficients (four for the amplitude and four for the period of the delay variation) in the navigation message.

  • GNSS receivers use these parameters to compute the ionospheric delay correction at a given location and time.

  • It is optimized for mid-latitude regions but is less accurate near the equator and polar regions, where ionospheric activity is more complex. 

The Klobuchar Ionospheric corrections are not designed to be used in high precision applications, but mainly in standard precision use cases using single frequency GNSS receivers. AssistNow Live Orbits includes these type of corrections for GPS and Beidou (that uses a version optimized for Beidou).

Note:  For more information on these parameters, see the ICD-GPS-200 documentation. 

• Satellite Health status. Satellites might become unhealthy because of maintenance or other reasons. That is why it's important to let the GNSS receiver know the status so that it can decide if consider or not the satellite for position estimation. The health status is broadcasted by satellite, but also delivered by AssistNow Live Orbits service.

• Time: if the receiver has been completely power-off before a new startup, then it will greatly improve the Time-To-First-Fix if time, position and almanac can be supplied to the GNSS receiver. If the receiver has a working RTC, it should be able to keep its own sense of time, but where no RTC is available or power is completely turned off, providing a time estimate via the UBX-MGA-INI-TIME_UTC message will be very beneficial to lower the Time-To-First-Fix. Time data is always returned with each AssistNow Live Orbits service 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 value set in the message 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 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.

• Position. 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. The position information is not provided by the AssistNow service.

In the Service Integration guide, you can find the list of which UBX messages corresponds to each type of data. For the description of each single UBX message payload, please refer to the Interface Specification document of your GNSS receiver.

A-GNSS data refresh frequency

In order to provide the most accurate data, AssistNow service backend continuously generate new fresh A-GNSS data, so that the device can always download up-to date assistance for the GNSS receiver.