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]

Modem team;

nrf_modem_gnss_start() should not fail unless there’s something wrong with the configuration.

After GNSS has been successfully started in single fix mode, there should be either a PVT event with NRF_MODEM_GNSS_PVT_FLAG_FIX_VALID set or an NRF_MODEM_GNSS_EVT_SLEEP_AFTER_TIMEOUT event when the timeout happens. Is the customer calling nrf_modem_gnss_stop() before trying to start GNSS again?

A missing nrf_modem_gnss_stop() call could explain the behavior they are seeing.

[Mike Granby]

Thanks for this. Yes, the _stop call is always made after either of events is received. It's not made from within the event function itself, but in a function triggered by a work item. The device works for weeks with both valid fixes obtained and with GNSS timeouts, depending on the location. But on one or two occasions, it has seemed to get stuck between the _start call and the reception of the success or failure events. Is there anything else that might cause the GNSS engine to fail to report success or failure in a timely manner? What if it needs updated almanac or ephemeris data? Right now, I'm going to add a backup timer to detect failure to report within the timeout window (plus a little slop) but I don't like having to do so without understanding what I'm seeing. Any other ideas as to how to gather further diagnostic data?

[Hakon]

Modem team;

"After calling nrf_modem_gnss_start(), do they get NRF_MODEM_GNSS_EVT_PVT events from the GNSS API? When GNSS is running, there should be a PVT event once a second. This would tell us whether GNSS fails to start or whether it times out, and the NRF_MODEM_GNSS_EVT_SLEEP_AFTER_TIMEOUT event is not sent after the timeout.

There are no known issues which would explain the behavior they are seeing. I suggest they implement the workaround, with that we should be able to see if the application and GNSS are still working after the timeout event has been missed. It is possible that there is some corner case where GNSS does not send the timeout event, but it’s also possible that there’s something more fundamentally wrong on the application or modem side (for example a memory leak causing the system to eventually run out of memory)."

[Mike Granby]

Thanks for this. I thought about a memory leak, etc., but the application does no dynamic allocation, and in any case, we set a flag on restart or reset, and we're not seeing that. After the long pause, the system appears to carry on after it eventually (after many hours) got a report from the GNSS.

Re the once per second PVT events, the code is only looking for the ones with the fix flag, so I am unsure as to whether those were occurring. I can add a timeout on those, too, to look for failures more quickly, but since repro is intermittent, I cannot report back immediately.

To further understand the behavior, can you explain about how the GNSS will go about getting updated almanac or ephemeris data? We provide it with minimal assistance via a factory almanac plus time and location injection, but apart from that, we're just powering it on until it gets a fix or times out, and then sleeping it until the next fix is required. Since the timeout is 45 seconds and since as I understand it, almanac or ephemeris data is transmitted on a much longer cycle, how are updates obtained?

[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.