nRF9160 GNSS assistance

RE: nRF9160 GNSS assistance

Hakon — Thu, 28 Aug 2025 13:15:11 GMT

[quote user="Vincent44"]I can see from the GNSS sample that in order to not re-write the almanac, a setting (NVM) in used. The example doesn't perform XFACTORYRESET so it's not an issue. However, in my code, it may occur. So I would like to know if this is something to take care of.[/quote]

If it is stored in NVM, then there is a chance that it is erased with XFACTORYRESET. So yes, this is something to be concerned with.

RE: nRF9160 GNSS assistance

Vincent44 — Thu, 28 Aug 2025 09:20:11 GMT

Thanks for the quick and clear response.

Concerning the almanac, does it get erased when a XFACTORYRESET (0 or 1) is performed ?

I can see from the GNSS sample that in order to not re-write the almanac, a setting (NVM) in used. The example doesn't perform XFACTORYRESET so it's not an issue. However, in my code, it may occur. So I would like to know if this is something to take care of.

An easy way to check would be to read back the almanac using XFILEREAD, but it seems that there is no such command.

RE: nRF9160 GNSS assistance

Hakon — Thu, 28 Aug 2025 07:43:54 GMT

[quote user="Vincent44"]
I am not familliar with the datials of how the alamac works.
But what you are saying, I can hard-code latest factory almanac (currently, from SDK 3.1.0), and would still be valid for several years. An generally speaking, even after several months, it's still better than not having any almanac. Is this correct ?[/quote]

Yes.

[quote user="Vincent44"]Any details on how this table has been constructed ?[/quote]

I couldn't find any information about this. Perhaps it is handled internally in modem lib.

[quote user="Vincent44"]

Side question: when should nrf_modem_gnss_agnss_write() be called to inject time and approximate location ? Before turning on GNSS ? When modem is OFF ?

[/quote]

nrf_modem_gnss_agnss_write() Should be called after GNSS has been started and the NRF_MODEM_GNSS_EVT_AGNSS_REQ event has been received.

[quote user="Vincent44"]Any news on the factory almanac delivery ?[/quote]

No news yet.

RE: nRF9160 GNSS assistance

Vincent44 — Wed, 27 Aug 2025 13:30:59 GMT

Hello Hakon.
Thanks for the detailled answer.

Any news on the factory almanac delivery ?

I am not familliar with the datials of how the alamac works.
But what you are saying, I can hard-code latest factory almanac (currently, from SDK 3.1.0), and would still be valid for several years. An generally speaking, even after several months, it's still better than not having any almanac. Is this correct ?

Thanks for the idea of injecting the previous GNSS fix. This would make a lot of sense for my devices, since they genrally don't move once installed.
I actually assumed that it be stored in GNSS internal memory, but there is indeed no mention of this.

In the GNSS Sample, I had a look at the mcc_location_table.c, which is used to provide rough location.
Any details on how this table has been constructed ?
I had a look for France, which is where I am, and the corresponding Lat/Long are pointing to North Spain. We are look at rought location, so it's note 100% bad, but still ...

Side question: when should nrf_modem_gnss_agnss_write() be called to inject time and approximate location ? Before turning on GNSS ? When modem is OFF ?

Thanks

RE: nRF9160 GNSS assistance

Hakon — Tue, 22 Jul 2025 13:25:13 GMT

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.

RE: nRF9160 GNSS assistance

Hakon — Mon, 14 Jul 2025 16:14:06 GMT

Hello,

I have forwarded your questions to the modem team.