GNSS Events After nrf_modem_gnss_start

[Mike Granby]

Toolchain v2.70, SDK v2.7.0, Modem 1.3.6, VS Code, Windows

nrf_modem_gnss_fix_retry_set(45)

nrf_modem_gnss_fix_interval_set(0)

Starting one-shot location acquisition with nrf_modem_gnss_start.

First question:

Can nrf_modem_gnss_start fail once modem and GNSS is correctly initialized?

Or are the various error codes only reflective of bad setup?

Second question:

Once nrf_modem_gnss_start has been successfully called, is it always true that either:

NRF_MODEM_GNSS_EVT_PVT will be received with bit 0 of the flags set; or

NRF_MODEM_GNSS_EVT_SLEEP_AFTER_TIMEOUT will be received after 45 seconds.

I'm seeing a situation where I'm starting the location acquisition, but it seems like I'm getting neither a valid fix, nor a failure indication in the expected window. This stalls my state machine, and data reporting grinds to a halt. I'm in particular wondering about interplay between the cellular radio and the GNSS, and whether there is any cellular state that might result in either a failure to start the GNSS acquisition, or in a failure to report a timely success or failure.

[Hakon]

In single fix mode, GNSS only runs when started by calling nrf_modem_gnss_start() and it stops as soon as it gets the first usable fix, or the timeout (in this case 45 seconds) is reached. Without A-GNSS, GNSS can only get new data from satellite broadcast when GNSS is running. With this kind of configuration, it is unlikely that GNSS ever has time to decode new almanacs from the broadcast. Ephemerides take a shorter time to decode, but 45 seconds is still probably too short timeout to be used without assistance in less than optimal conditions. Without assistance, something like 90-120 seconds would be much better.

When GNSS is used in periodic mode, it automatically downloads fresh ephemerides (with fix interval set to 30 minutes or less) and almanacs when needed unless this functionality is explicitly disabled.

[Mike Granby]

Thank for this. So, to be clear, if the GNSS timeout is N seconds and it is operating in one-shot mode, will it hold off providing a fix notification until it has updated its ephemerides? Or will it provide a fix as quickly as it can, only to have the app turn it off before the ephemerides can update? If the latter is the case, is there any way for the app to know that the ephemerides is needed and thus to hold power on for longer? I am concerned that a system operating with on-demand fixes that powers the GNSS off as soon as a fix is obtained (often less than five seconds in my experience) will never get chance to update its ephemerides. I understand that in periodic mode, this will be handled automatically, but we ideally want the fix to be in sync with the other data we're recording.

[Hakon]

In single fix mode GNSS always stops as quickly as possible, i.e. when it has been able to provide a good enough fix. If GNSS has enough valid ephemerides when it starts, it does not wait that new ephemerides can be downloaded. If GNSS does not have enough valid ephemerides, it can not provide a fix before necessary ephemerides have been downloaded.

GNSS API provides a method to check how long GNSS data is valid, nrf_modem_gnss_agnss_expiry_get(). If desired, the application can check ephemeris validity and let GNSS sometimes run for longer than needed for the first fix. This would also mean, that GNSS has to be in continuous tracking mode. But that said, this kind of pre-emptive update is not that straight forward to implement. For example, device movement and sky visibility affect the behavior. Let’s say GNSS runs longer, so that it can download new ephemerides for the satellites it sees at that particular moment. When GNSS is started for the next fix, the device may have moved and some of those satellites are no longer visible, so there might no longer be enough satellites with valid ephemerides for a fix. This is because unlike almanacs, each satellite broadcasts only it’s own ephemeris.

The easiest solution is to make the timeout longer, so that GNSS has time to download new ephemerides whenever needed for a fix.