GNSS interface

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

Note

Although it is a GNSS receiver, the receiver on the nRF9160 SiP currently supports GPS and QZSS, a regional satellite system developed by Japan to enhance GPS over the Asia-Oceania region.

This is why the documentation often uses GNSS and GPS interchangeably.

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

Note

If the eDRX Cycle given by the network is too short, (e.g. 10.24 seconds), it can be difficult to get a valid fix without implementing GPS enhancements such as A-GPS or P-GPS.

For a cold start, the GNSS receiver needs to download all the satellite data between the eDRX intervals, and when everything is downloaded it can begin trying for a valid fix.

Configuring and starting GNSS

Adding GNSS to your application is quite straight forward.

To configure GNSS in your application, you have to:

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.

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.

Note

The GNSS never sets both flags at the same time (DEADLINE_MISSED and NOT_ENOUGH_WINDOW_TIME).

The first one is true when LTE is in RRC Connected mode. When it has been released, GNSS should in theory be getting run time by the time window it gets may be too short, so the GNSS sets this flag to indicate that downloading data from the satellite broadcast may not be possible.

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

Register an account
Already have an account? Log in
(All fields are required unless specified optional)

Forgot your password?
Enter your email address, and we will send a link to reset your password.