Field verification of GNSS on the nRF91 Series

Introduction

The intention of this guide is to clarify and describe the main aspects relevant to the GNSS receiver functionality on the nRF9160 as well as build configurations, tool recommendations and how to get started with the field measurements. All the measurements discussed in this guide are focused on the usage and output of the GNSS sample available in the nRF Connect SDK.

Overview

 The nRF9160 has three operating modes for GNSS: 

• GNSS-only 
• LTE-M & GNSS 
• NB-IoT & GNSS 

GNSS-only mode is the simplest to start with as there is no need to consider the interaction between cellular and GNSS operations. We recommend GNSS-only mode when measuring GNSS performance initially in the field. Operating GNSS alongside LTE-M or NB-IoT does not necessarily differ very much between the two cellular modes, but several cellular network functions and parameters can affect GNSS performance. 

The largest contributing factor to overall GNSS performance, regardless of the operation mode, is the antenna and RF design of the device. Pay close attention to the application use case, cellular radio usage, and configuration. We also highly recommended always having a reference device, such as the latest nRF9160 Development Kit (DK) for comparison. 

The main concept to understand when running the nRF9160 in LTE-M or NB-IoT mode with GNSS is the time multiplexing between cellular and GNSS operations, always keeping in mind that cellular operations override GNSS operations by default (however, exceptions are possible). 

Cellular operations and features are strongly related to GNSS operations. Note the tight coupling with cellular radio state as follows:

Connected Mode	GNSS operations prohibited
Idle Mode	Idle DRX (Discontinuous Reception): GNSS operations allowed but assistance required Idle eDRX (extended DRX): GNSS operations allowed, but assistance required if Idle eDRX period is shorter than 20 seconds.
Power Saving mode (PSM)	GNSS operations allowed

To interact with the GNSS receiver, we will use the GNSS interface in the nRF Connect SDK Modem library. Before using GNSS, the modem must be set into the correct system and functional mode: 

// Enable LTE-M and GNSS system modes
AT%XSYSTEMMODE=1,0,1,0 Enables LTE-M and GNSS system modes 
// Activate the modem
AT+CFUN=1

There are currently four GNSS-related samples and applications in the nRF Connect SDK (version 2.0 onwards):

• GNSS - Demonstrates how to use the GNSS interface
  • Simplest to start with
  • GNSS-only mode by default
• Location - Demonstrates retrieving the devices' location
  • Covers multiple positioning methods, GNSS, cellular, and Wi-Fi 
• Modem Shell - Enables testing of wide variety of nRF9160 modem features, such as GNSS
  • Cellular and positioning test tool 
  • Shell-based end-user control for a wide range of nRF9160 functionalities
• Asset Tracker v2 - Low-power, configurable asset tracking application
  • Full support for GNSS asset tracking use case 
  • nRF Cloud MQTT by default 
  • Support for multiple cloud backends

Samples in the nRF Connect SDK either handle the system and operational mode automatically or require end-user interaction, as explained in the following table:

	GNSS	Location	Modem Shell	Asset Tracker v2
API(s) used	GNSS API	Location API	GNSS API and Location API	GNSS API
Automatic System and Operation mode	Yes	Yes	No, manual interaction needed using Shell	Yes
Assistance nRF Cloud (A-GPS)	Yes	Yes	Yes	Yes
Predicted Ephemerides nRF Cloud (P-GPS)	Yes	Yes	Yes	Yes
Cold start TTFF measurements	Yes	No	Partial - requires user interaction	No
Assisted TTFF measurements	Yes	No	Partial - requires user interaction	No
NMEA output	Yes	No	Yes (user can configure during runtime)	No

Tools

Serial Terminal

You will need a serial terminal software, like Teraterm or PuTTY, for viewing and capturing the application COM port output. The default baud rate is 115200 bps.

VisualGPSView

We recommend installing VisualGPSView for displaying the DUT NMEA data graphically. Capture and playback is also supported. See the link for further information. 

Google Earth

Use Google Earth for viewing the live capture. Instructions for how to do this can be found here:Import data from GPS devices - Google Earth Help.

Google Earth also has playback capability based on the NMEA $GPRMC output. We recommend storing any application output in a .log file.

One drawback of using Google Earth is that the UART baud rate must be set to 4800 bps. In this case, the application should not output much more than just the NMEA $GPRMC data to save UART bandwidth. To modify the baud rate in the application, you need to add an overlay file that sets the current-speed property in the device tree, see below:

&uart0 {
    status = "okay";
    current-speed = <4800>;
};

NMEA output

 Below is a list of NMEA information that is supported by the nRF9160. This includes an example output and different colors highlighting and explaining what the information means.

1. $GPGSV: Satellites in view

$GPGSV,2,1,5,31,43,256,36,2,31,055,42,25,44,143,36,29,00,000,34,1*6D 

$GPGSV,2,2,5,5,23,094,37,1*5C 

•    Total number of GSV sentences and current sentence number (two in this example). Maximum of four sentences possible, up to 16 satellites total 
•    Total number of satellites visible
•    Satellite PRN number, elevation, azimuth and C/N0 signal level in dB-Hz, for each tracked satellite. Elevation and azimuth of the satellites are not indicated until the ephemeris of each satellite has been successfully downloaded from the satellite or through GPS assistance and only the tracked satellites have C/N0 level indication
• C/N0 levels: 25-30 dB-Hz (poor), 30-35 (fair), 35-40 (moderate), 40-45 (good), >45 (excellent). NOTE: The measured C/N0 level is manufacturer dependent

2. $GPGSA: GNSS DOP and active satellites

$GPGSA,A,3,02,05,25,31,,,,,,,,,7.05,2.02,6.75,1*1B 

•    Automatic mode only  
•    1 = No fix or 3 = 3D fix  
•    Satellites PRNs used in fix calculation  
•    Position DOP,    Horizontal DOP,    Vertical DOP 
  • HDOP and VDOP indicate isolated components of the horizontal and vertical dilution of precision
  • When combined, the three-dimensional dilution of precision is given by PDOP 
  • DOP < 1 (ideal), 1-2 (excellent), 2-5 (good), 5-10 (moderate), 10-20 (fair) and >20 (poor) (Wikipedia) 

 3. $GPGGA: Global positioning system fix data

$GPGGA,092751.62,6127.95117,N,02343.85159,E,1,05,2.02,100.62,M,0,,*20 

•    UTC time  
•    Latitude: 2 fixed digits of degrees, 2 fixed digits of minutes and 5 fixed digits for a decimal fraction of minutes. The precision is 1.85 cm 
     North or South  
•    Longitude: 3 fixed digits of degrees, 2 fixed digits of minutes and 5 fixed digits for a decimal fraction of minutes. The precision is 1.85 cm 
     East or West 
•    Quality indicator type: “0 = No fix” or “1 = Fix”  
•    Number of Satellites used in fix (see $GPGSA and $GPGSV for more details) 
•    Horizontal Dilution of Precision 
•    Elevation above sea level (meters)

  4. $GPRMC: Recommended minimum specific GNSS data

$GPRMC,184141.63,A,6123.93190,N,02410.76883,E,0.20,0.00,150222,,,A,V*2D 

•    UTC time  
•    Status: V – Navigation receiver warning, A – Data valid, autonomous 
•    Latitude: 2 fixed digits of degrees, 2 fixed digits of minutes and 5 fixed digits for a decimal fraction of minutes. The precision is 1.85 cm 
     North or South  
•    Longitude: 3 fixed digits of degrees, 2 fixed digits of minutes and 5 fixed digits for a decimal fraction of minutes. The precision is 1.85 cm 
     East or West 
•    Speed over ground [0..1166.31] in knots, corresponds to [0..600] m/s 
•    Course over ground [0..360] degrees 
•    Date 
•    Mode indicator: A – Autonomous, N – No fix 

 5. $GPGLL: Geographic position

$GPGLL,6123.93190,N,02410.76883,E,184141.63,A,A*64 

•    Latitude: 2 fixed digits of degrees, 2 fixed digits of minutes and 5 fixed digits for a decimal fraction of minutes. The precision is 1.85 cm 
     North or South  
•    Longitude: 3 fixed digits of degrees, 2 fixed digits of minutes and 5 fixed digits for a decimal fraction of minutes. The precision is 1.85 cm 
     East or West 
•    UTC Time
•    Mode indicator: A – Autonomous, N – No fix 

Performance measurements and aspects for consideration

We recommend starting field measurements under open sky conditions (wide open space without any tall buildings and obstructions around the device) and the GNSS Sample.

The nRF9160 in GNSS normal accuracy mode requires a minimum of 4 satellites to calculate a 3D fix. 

Initial GNSS cold start time-to-first-fix (TTFF) should be less than 60 seconds in the aforementioned conditions, preferably within 25 to 40 seconds. Measurement should be repeated several times.  

GNSS cold start with assistance data should shorten the TTFF in the same conditions. Note that GNSS cannot operate while LTE is in Connected Mode. The GNSS sample will calculate the time GNSS was blocked by LTE activity. 

The received C/N0 signal level and the number of the acquired and tracked satellites is an extremely important indicator of the device performance, impacting the TTFF directly. The NMEA string(s) $GPGSV contains the information for monitoring the satellite C/N0 signal level, elevation, and azimuth. 

Device orientation and surrounding area impacts greatly on the GNSS performance, but it is especially important to keep in mind that any other radio transmitter (Wi-Fi, Bluetooth® Low Energy (LE) and so on), peripheral (LEDs and sensors) or data bus (UART, SPI and TWI) activity during the GNSS operation can negatively impact satellite signal reception. Great care should be taken when designing the end user application behaviour and use cases. We recommend avoiding any overlapping activity during the GNSS satellite reception to achieve the best possible performance. 

Radiated lab and field measurements should be performed frequently throughout the development cycle. Any device hardware related modification can impact the GNSS receiver performance. 

It is also possible to operate the GNSS in Low Accuracy mode, enabling the usage of 3 satellites for fix calculation, but this operation mode requires certain pre-requisites to be met prior to TTFF measurements. NMEA string $GPGSA indicates the number of satellites used for the fix and 3D fix is always indicated even if it has been performed with 3 satellites. 

Assisted GPS (A-GPS)

Assisted GPS enables faster TTFF but requires an LTE-M or NB-IoT connection to download the required assistance information. LTE-M is recommended due to higher bandwidth and lower latency in data transfer. The assistance data consists of ephemerides, almanac, integrity, GPS time, UTC, reference location, and Ionospheric correction. The most important data for obtaining a short TTFF are satellite ephemerides, time, and the reference location. 

By default, the GNSS receiver performs the assistance data downloads autonomously, mostly triggered by ephemeris expiration every ~2 hours. The download size of the assistance data is roughly 24 kB per day. 

Assisted GPS can be enabled in the GNSS sample by enabling CONFIG_NRF_CLOUD_AGPS.

nRF Connect SDK and nRF Cloud also support the filtering of assistance data using CONFIG_NRF_CLOUD_AGPS_FILTERED which enables further savings on data transfer and power consumption. We recommend using filtering when the fix interval is 2 hours or more. 

Predicted GPS (P-GPS)

Predicted GPS provides predicted satellite ephemerides. In this case, the GNSS receiver does not need to download the latest ephemerides information from the satellite or request them through assistance, but the receiver can utilize the predicted ephemerides to calculate a position. Position accuracy deteriorates over time.  

A P-GPS package is requested by the device from nRF Cloud. Download size of the package depends on the duration of the predictions requested. The default is one week, and the package download size is roughly 84 kB. LTE-M is the recommended technology for downloading the P-GPS package. Use CONFIG_NRF_CLOUD_PGPS_NUM_PREDICTIONS=42 for one week default, 84 is the maximum value indicating two weeks. 

P-GPS can be considered for example when the cellular connectivity can be challenging at times for assistance data downloading, and emphasis is on the power consumption and reliability of the position fix.  

Predicted ephemerides data will not be available for all satellites if the requested prediction length is more than ~10 days, due to satellite clock inaccuracies. This means that after ~10 days the GNSS receiver needs to download the missing ephemeris data for those satellites which do no longer have any predicted ephemerides available in the downloaded package. 

Predicted GPS can be enabled in the GNSS sample by enabling CONFIG_NRF_CLOUD_PGPS. We highly recommended enabling A-GPS together with P-GPS. This enables a configuration where assistance data is the most recent at the time of download and ephemerides are based on predictions. 

GNSS debug output and modem tracing

Debugging and tracing can be divided into two categories:

• Application debug output
• Modem tracing for more detailed information on both LTE and GNSS operations.  

Application debug output is end user configurable and provides particularly good visibility to the device behaviour. In general, it is recommended to get familiar with Zephyr RTOS logging, and the concept of log levels. 

GNSS sample related debug output can be enabled using CONFIG_GNSS_SAMPLE_LOG_LEVEL_DBG and NMEA string output provides comprehensive information for most GNSS tests and measurements. 

Modem tracing, on the other hand, is content-wise predefined by Nordic Semiconductor. Certain LTE-M and NB-IoT traces are exposed to the end-user and can be accessed and viewed in real-time, or as playback with the nRF Connect for Desktop Trace Collector V2 application. Modem tracing is disabled by default in all samples and applications and can be enabled using CONFIG_NRF_MODEM_LIB_TRACE_ENABLED.  

We highly recommend enabling both application debug output and modem tracing. However, note that for any power measurement scenarios, application debugging and modem tracing should be disabled, for example, by using CONFIG_GNSS_SAMPLE_LOG_LEVEL_OFF.

Unassisted and assisted TTFF, GNSS-only

This section describes the most common Kconfig configurations to enable for example unassisted and assisted cold start, warm start, and hot start TTFF measurements. LTE-M or NB-IoT mode is either always disabled, or enabled and disabled on-demand only. 

Please note that the very first fix after device start-up is a rather different measurement than any of the following consecutive fixes. Time To First Fix (TTFF) is the amount of time in seconds spent in producing a position fix and seems to be a de-facto term in the industry indicating time-to-fix regardless of the GNSS receiver state prior to starting the test sequence.  

GNSS unassisted and assisted cold start cases describe the TTFF measurements where the receiver does not have any prior knowledge of the required satellite information at the start of each test interval, i.e., as close as possible to a situation where device is booted up for the first time. 

GNSS sample calculates the TTFF times automatically. The output is visible in the application log after each test interval for postprocessing. 

When using an onboard or external antenna (only relevant for the nRF9160 DK), enable CONFIG_MODEM_ANTENNA_GNSS_EXTERNAL.

TTFF measurements, GNSS unassisted cold start case. Cold start repeated every 2 minutes automatically

CONFIG_GNSS_SAMPLE_MODE_TTFF_TEST=y
CONFIG_GNSS_SAMPLE_MODE_TTFF_TEST_COLD_START=y
CONFIG_GNSS_SAMPLE_MODE_TTFF_TEST_INTERVAL=120

TTFF measurement, GNSS assisted cold start case. Cold start repeated every 2 minutes automatically

CONFIG_GNSS_SAMPLE_MODE_TTFF_TEST=y
CONFIG_GNSS_SAMPLE_MODE_TTFF_TEST_COLD_START=y
CONFIG_GNSS_SAMPLE_MODE_TTFF_TEST_INTERVAL=120
CONFIG_GNSS_SAMPLE_ASSISTANCE_NRF_CLOUD=y
#LTE-M or NB-IoT is enabled and disabled automatically as needed
CONFIG_GNSS_SAMPLE_LTE_ON_DEMAND=y

Consecutive TTFF measurements, non-assisted or assisted warm start case

CONFIG_GNSS_SAMPLE_MODE_TTFF_TEST=y
CONFIG_GNSS_SAMPLE_MODE_TTFF_TEST_INTERVAL=2400
#If assistance is used
CONFIG_GNSS_SAMPLE_ASSISTANCE_NRF_CLOUD=y
#LTE-M or NB-IoT is enabled and disabled automatically as needed
CONFIG_GNSS_SAMPLE_LTE_ON_DEMAND=y

Consecutive TTFF measurements, non-assisted or assisted hot start case

CONFIG_GNSS_SAMPLE_MODE_TTFF_TEST=y
CONFIG_GNSS_SAMPLE_MODE_TTFF_TEST_INTERVAL=120
#If assistance is used
CONFIG_GNSS_SAMPLE_ASSISTANCE_NRF_CLOUD=y
#LTE-M or NB-IoT is enabled and disabled automatically as needed
CONFIG_GNSS_SAMPLE_LTE_ON_DEMAND=y

Low accuracy mode (CONFIG_GNSS_SAMPLE_LOW_ACCURACY) and 3 satellite usage can also be enabled. Defining the reference altitude also enables 3 satellite usage for the initial fix. Otherwise, 3 satellite usage is only active when any previous fix has been achieved with 5 satellites or more. 

CONFIG_GNSS_SAMPLE_ASSISTANCE_REFERENCE_ALT sets the reference altitude in meters to WGS-84 ellipsoid surface. Range is -32767 to 32767, and the number should be within +- 10 meters of the actual altitude. The reference altitude is valid for 24 hours. 

Unassisted and assisted TTFF, LTE enabled

This section describes the most common Kconfig configurations to enable both LTE and GNSS for TTFF measurements. Keep in mind that the GNSS receiver can only operate while LTE is in Idle DRX/eDRX mode or Power Save Mode. Using Idle eDRX and PSM requires support from the carrier network.

We recommend configuring >40 seconds Idle eDRX intervals in general and this configuration can act as a fallback in case fetching assistance fails or assistance is not planned to be used. This allows a long enough time window for GNSS to download the needed information from the acquired and tracked satellites. A shorter Idle DRX/eDRX interval is possible but then assistance must be enabled. The same rule applies if the carrier network does not support Idle eDRX and PSM. 

If the device is not expected to receive downlink traffic, the PSM Active timer T3324 can be set to 0 seconds. No need to wait for the paging occasions for downlink traffic. Otherwise, we recommend setting the Active timer T3324 to at least to 20 seconds, giving the possibility to receive paging for any downlink data traffic before entering PSM. 

The fix interval should be several (tens of) minutes, as waking up from PSM is a power consuming procedure if triggered too frequently. If shorter fix intervals are required, it is recommended to keep the device in Idle eDRX/DRX mode instead to avoid unnecessary carrier network signaling load.

The AT commands for eDRX and PSM are documented in Network service related commands - Infocenter.

TTFF measurements with both LTE and GNSS enabled

#LTE-M or NB-IoT is kept active during the TTFF measurement
CONFIG_GNSS_SAMPLE_LTE_ON_DEMAND=n
CONFIG_LTE_PSM_REQ_RPTAU="00101000" #PSM T3412ext Timer
CONFIG_LTE_PSM_REQ_RAT="00000011" #PSM T3324 Active Timer
CONFIG_LTE_EDRX_REQ=y
CONFIG_LTE_EDRX_REQ_VALUE_LTE_M="1001" #LTE-M specific Idle eDRX timer
CONFIG_LTE_EDRX_REQ_VALUE_NBIOT="1001" #NB-IoT specific Idle eDRX timer

Checking and debugging of the eDRX and PSM conditions can be complicated at times, because the carrier network can allocate different values than what the end user has requested. However, checking the network allocated timer values is quite straightforward with the AT command AT%XMONITOR.  

eDRX can become much more complicated as the carrier network controls the usage on two levels: the core network level where the network allocated eDRX timer value can be checked with AT%XMONITOR, and the radio network level with eDRX Enable/Disable indication, which is not visible to the end user with an AT command. 

If the Radio level does not support eDRX, the timer value provided by the Core network level is meaningless. nRF Connect Trace Collector v2 provides Peer Message decoding capability if CONFIG_NRF_MODEM_LIB_TRACE_ENABLED=y is enabled.

Here is an example of the Peer Message capture with Trace Collector v2 and Wireshark, with the carrier network supporting eDRX on the radio level:

GNSS fix accuracy measurements

It is also possible to measure the accuracy of the position fix during the TTFF measurements with the GNSS sample. To do this, you must know the ground truth position where any measurement takes place with at least 1-meter accuracy.

To set the reference latitude and longitude, use the following configurations. 

CONFIG_GNSS_SAMPLE_REFERENCE_LATITUDE="61.500000"
CONFIG_GNSS_SAMPLE_REFERENCE_LONGITUDE="23.800000"

The values must be given in the format decimal degrees. The difference between defined ground truth and the GNSS fix is provided in meters. 

Final remarks

We have covered some of the aspects and functionalities related to GNSS positioning of the nRF9160, with the focus being on the GNSS sample for basic GNSS measurements in live open sky conditions. 

We are improving and developing the nRF Connect SDK applications and samples continuously and any feedback and improvement ideas are very welcome through the Nordic Semiconductor DevZone and GitHub repositories.