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]

Hello,

I have forwarded your questions to the modem team.

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