nRF9160 GNSS assistance

[Vincent44]

Hello,

I have a product based on nRF9160 that uses GNSS. The device is a meter, not an asset tracker, so GNSS is not the TOP 1 feature we need.

When the device is installed, its location is not meant to change for a long time. The application will trigger the GNSS only once a week to ensure the device has not moved.

I recently discovered the "minimal assistance" feature in the GNSS sample, which consists in loading the almanac in the modem.

After some research, I found some 1~2 years old posts on devZone indicating that there was plan to provide an updated almanac periodically. Has this been made already ? I couldn't find any recent info on this.

So far, the only way to get a recent almanac seems to be looking in the latest SDK releases.

Is there a document indicating how this almanac is generated ?

Depending on results I get with this assistance, I am also considering testing the A-GPS.

To ensure that I understood the principle, could you please confirm whether the following explanation is correct or not :

the A-GPS feature consist in loading an almanac (an other data ?) in the modem. This almanac is retreived from nRFCloud, and provides more accurate data that the "factory almanac method", because it is generated specifically for the device, based on it's raw location (determined by the cell ID and/or MNO).

The drawback is that this accurate assistance is only valid for a short period of time. 

Thanks for you help !

Vincent

[Hakon]

Modem team commented;

“So far, the only way to get a recent almanac seems to be looking in the latest SDK releases.“ ← unfortunately this is still the case. Making the factory almanac readily available has not been forgotten. An IT ticket about this has been opened recently to figure out where to host this data.

We have not documented how the factory almanac is generated because our eventual goal is to make it easily available for our customers.

However, in the meantime, you can modify your application so that you only inject GPS time and coarse location to the GNSS module. Having the almanac available only helps the device to determine the rough position of satellites and thus makes startup slightly faster and more sensitive compared to cold start. The device will have an almanac in the memory (hence the name factory almanac) which remains usable for years for this purpose as long as the time and coarse location of the device is known.

Actually your application is well suited for the minimal assistance kind of operation because you can just save and inject the last position from one week ago instead of using nRFCloud to resolve the coarse location based on neighbouring LTE base stations. If the device had indeed moved, the GNSS fix would converge to a correct new position regardless of the inaccurate assistance position - it might just take a bit more time to output the fix in this case.

So up to this point you can do all this without resorting to A-GPS. Now if you are interested in saving power by shortening the time to first fix or increasing the accuracy of the position fix, I recommend using A-GPS. A-GPS data from nRFCloud contains all the required navigation data - not only almanacs. It is mostly the injection of ephemerides that makes A-GPS so good compared to unassisted GNSS. A-GPS ephemerides are valid for roughly two hours, as you mentioned. So to get one GNSS fix per week, you need to download A-GPS every time before attempting the fix. Nevertheless, we’ve found that it uses less power that doing 1 cold start per week.