Prioritize sending data when trying to get a fix with GNSS

RE: Prioritize sending data when trying to get a fix with GNSS

Samruddhi Jadhav — Fri, 30 Jan 2026 12:33:33 GMT

Hi,

Unfortunately, there isn't a way mentioned in our docs to "pause" GNSS and later resume without restarting it. The GNSS API only has start and stop. To minimize the impact of stopping, you can use A-GNSS or P-GNSS in order to ensure faster restarts. To make sure that GNSS is not running more than needed between your send windows, you can select an operation mode (fix interval/ retry) which matches your pattern.

Best Regards,

Samruddhi

RE: Prioritize sending data when trying to get a fix with GNSS

mackz — Thu, 29 Jan 2026 14:16:49 GMT

I have managed to send the data much faster by calling:

nrf_modem_gnss_stop();

before publishing the data, and then after waiting for 2 seconds i call:

nrf_modem_gnss_start();

Which restarts the searching for fix.

But perhaps there is a better way to do it without having to stop and restart the seach from scratch?

RE: Prioritize sending data when trying to get a fix with GNSS

Samruddhi Jadhav — Thu, 29 Jan 2026 11:52:53 GMT

Hi,

By default, LTE already has priority over GNSS. You can't specifically switch to always prioritize LTE over GNSS, but I can provide some suggestions to minimize the delay, while keeping LTE prioritized.

1) Before you planned sensor upload window, make sure GNSS is stopped/paused. Restart after the LTE transaction is completed and modem is back to idle.

2) During high-activity periods or where you expect frequent sensor transmissions, avoid using PSM/eDRX. When expecting frequent sends, use short or no PSM/eDRX. When tracking with GNSS and rarely sending, save power by using PSM/eDRX.

Some general practices:

3) If your deployment area is controlled, in order to reduce search time, use band lock.

4) During deployment, try to avoid frequent hard resets without proper shutdown.

To minimize average delay, you can try to avoid unnecessary reconnects and Nordic suggests sending data in batches instead of small packets.

Best Regards,

Samruddhi