The Modem library contains the GNSS interface, which is used to interface with the GNSS receiver on the nRF91 Series SiP.

Operation modes

The GNSS supports three different operation modes, which are configured by setting the fix interval and fix retry period.

• Single-fix: GNSS receiver is on until it has produced a valid PVT estimate, then it is switched off
• Continuous navigation (default): GNSS receiver is continuously on and producing PVT estimates per second
• Periodic navigation: GNSS receiver tries to produce a valid fix every fix interval. It is turned off after each valid fix (or if the fix retry period has elapsed), and turned back on after the fix interval has passed.

GNSS and LTE

Due to the limited resources in the nRF91 Series modem, the GNSS receiver is time multiplexed with the LTE modem, with LTE events having priority.

GNSS will run whenever it has the chance, most likely when the modem is in RRC Idle mode, either monitoring paging during the <Active-Timer> or in power saving mode.

When the modem is monitoring paging, the GNSS usually does not have a large enough window to generate a valid fix. This is because the LTE has priority over GNSS, and every time the modem performs the paging event, the GNSS events are blocked. In this case, enabling eDRX, i.e extending the time between the paging events, is a useful technique. We will take a closer look at how this works in Exercise 2.

Configuring and starting GNSS

Adding GNSS to your application is quite straight forward.

To configure GNSS in your application, you have to:

• Configure the modem to enable GPS mode (CONFIG_LTE_NETWORK_MODE_LTE_M_NBIOT_GPS).
• Include the header file for the GNSS interface (#include <nrf_modem_gnss.h>)
• Set the GNSS fix interval (default value 1) using nrf_modem_gnss_fix_interval_set().
• Set the GNSS fix retry period (default value 60 seconds) using nrf_modem_gnss_fix_retry_set().
• Register the GNSS event handler using nrf_modem_gnss_event_handler_set().
• Start GNSS using nrf_modem_gnss_start().

GNSS event handler

The GNSS interface has multiple event types that trigger the handler function.

PVT event

We will focus on the PVT event, NRF_MODEM_GNSS_EVT_PVT. This event is sent once a second, with the PVT payload, of type nrf_modem_gnss_pvt_data_frame.

When this occurs, we read the PVT data from the modem and check if this is a valid fix.

struct nrf_modem_gnss_pvt_data_frame, has the following signature (we are only displaying the members used in the exercises).

The flags field of the PVT data is particularly interesting as it will tell us whether the PVT estimate is a valid fix.

• PVT_FLAG_FIX_VALID: This flag tells us that the PVT estimate is a valid fix.

In addition, these two flags will tell us whether the GNSS operations are being blocked by LTE activity.

• PVT_FLAG_DEADLINE_MISSED: This flag tells us that the GNSS has not received a time window since the last PVT notification due to LTE activity.
• PVT_FLAG_NOT_ENOUGH_WINDOW_TIME: This flag tells us that the current average time window length is too short (less than 10 s) and might affect GNSS functionality.

Fix event

There is also the event NRF_MODEM_GNSS_EVT_FIX, which is triggered upon a valid fix event. This event is intended for use cases where you only want to get notified when the PVT estimate is a valid fix.

While EVT_PVT sends a PVT event every second and uses the flags field to indicate if it’s a valid fix or not, EVT_FIX is only triggered when the PVT estimate is a valid fix.

Using both events in an application is redundant, so in the exercise section we will not be using this event.

Other events

We will use some of the other events in Exercise 2, in order to log the operations of the GNSS receiver. The event handler will not perform any actions in these events other than logging to console that they have occurred.

• EVT_PERIODIC_WAKEUP: The GNSS is turned on to start acquiring the next fix.
• EVT_SLEEP_AFTER_FIX: The GNSS starts sleeping after achieving a valid fix.