Location Services features¶

This page provides an overview of each method available through nRF Cloud Location Services, along with their associated features.

nRF Cloud Location Services offers location assistance using GNSS, cells, and Wi-Fi networks.

GNSS location and assistance¶

The following figure shows the standard, unassisted process for GNSS coordinate acquisition.

Standard GNSS coordinate acquisition

Standard implementation using a GNSS receiver¶

The standard, unassisted way for devices to obtain a location is using an onboard GNSS receiver, such as the nRF9160 GNSS receiver.

The receiver performs the following actions:

Searches for satellites overhead.
Locks on to satellite signals.
Decodes and downloads the data.
Computes the location using the device's distance to each satellite and the exact location of each satellite in space.

While this standard method can result in an accurate fix, there are limitations:

Obtaining navigation data can take time. This depends upon the device's current time-to-first-fix (TTFF): the GNSS receiver downloads data at 50 bits per second (bps), slower than an LTE modem using location assistance.
The GNSS receiver consumes significant power.
Unassisted GNSS works best outdoors. A-GNSS can improve GNSS performance for indoor devices by making it easier for the device to find satellites.

Cloud-assisted implementation using A-GNSS and P-GNSS¶

To overcome the disadvantages of using a GNSS receiver, nRF Cloud offers two types of cloud assistance: A-GNSS and P-GNSS. In both cases, a fix is obtained more quickly by sending the required data to the device through the cloud instead of the satellite, and over an LTE modem with a much higher transfer rate. This allows a faster TTFF while minimizing use of the resource-intensive GNSS receiver.

How GNSS assistance works

Assistance data consists of the following:

Date and time.
Rough location on Earth (position).
Accurate satellite orbits (ephemerides):
- Usable for maximum four hours.
- Must be updated in GNSS unit on time.
- Required for a GNSS fix.
Approximate satellite orbits (almanac):
- Usable for a month or more.
- Not accurate enough to compute a fix.
- Not required if ephemerides are available.
Other information, such as ionospheric correction or integrity data.

A-GNSS provides the latest current (not predicted) satellite positioning data to devices to help them find a satellite more quickly. This data is for all satellites, regardless of the device's position, and is typically reliable for four hours. A-GNSS also includes an SCELL request as part of its operations. This SCELL request results in an additional data point in the location history.

P-GNSS is similar to A-GNSS, but it allows devices to download up to two weeks of predicted satellite location data. Your device can then use this data to more quickly determine satellite location without needing an active network connection. Predicted data can also provide offline navigation when the device is out of range of a cell.

P-GNSS is especially suited for applications where LTE connection availability is sporadic, whereas A-GNSS requires frequent use of an LTE connection to update assistance information (typically every 2 hours).

With both types of assistance, reduction in TTFF depends on whether the GNSS receiver is fed the device's approximate location, or a previous fix is hot enough to be reliably reused.

The main advantage to cloud assistance is that the data does not need to be downloaded from satellites over a slower GNSS receiver. Even without telling the GNSS receiver the device's approximate location, TTFF is improved.

Comparing unassisted GNSS, P-GNSS, and A-GNSS¶

The following table compares the different assistance methods available through nRF Cloud.

Assistance type	Cloud access	Memory requirement	Power consumption	Time to first fix (TTFF)
Unassisted	Not required	No flash memory required	Unrestricted	Unrestricted
A-GNSS	Frequent	No flash memory required	Restricted	Faster than unassisted and P-GNSS
P-GNSS	Infrequent	Requires predictions to be stored on flash	Restricted	Faster than unassisted GNSS but slower than A-GNSS

Time-to-first-fix¶

The documentation for the nRF9160 GNSS receiver describes receiver performance in different startup scenarios such as cold start and hot start. These are industry-standard terms for whether a GNSS receiver has gotten a prior fix since it was last powered on:

Cold start: The device is starting without previous knowledge of location, date, time, internal clock oscillator frequency, or navigation data, after a reset or power cycle.
Warm start: The device has an approximate position, date and time, internal clock oscillator frequency, and almanac, but not ephemeris. If the GNSS unit needs to decode the current orbital data for each satellite it is tracking, warm start TTFF can be around 30 seconds.
Hot start: The device has recently obtained a fix and remembers its last position, accurate time, internal clock oscillator frequency, almanac, and ephemeris. This information enables the device to lock onto the same satellites and calculate the fix very quickly.

P-GNSS and A-GNSS operations are between hot start and warm start regarding TTFF, since orbital data is known.

Location based on cells¶

Cell location is based on cells near the device. Cell-based location is calculated by the cloud service and sent to the device. GNSS is not involved at all.

How cell location works

Cell-based location assistance (CELL_POS, whether SCELL or MCELL varieties) requires less power and memory because the device does not need to use the GNSS receiver, though the resulting fix is less accurate than GNSS-based location or Wi-Fi. The device is provided a coarse location by submitting a request containing data about the nearest and neighboring cells, if nmr is included in the request. Use of multiple cells (MCELL), if available, can result in a more accurate location.

SCELL and MCELL

Cell-based location is most suitable for constrained or indoor devices.

Location based on Wi-Fi networks¶

Using Wi-Fi location assistance, a device can query nRF Cloud for its location using the MAC addresses of Wi-Fi networks in its area. The device performs an SSID scan of Wi-Fi access points in its surrounding area and sends this data to nRF Cloud. nRF Cloud calculates the location based on the data according to a third-party database, and responds with latitude, longitude and uncertainty.

Wi-Fi location

Wi-Fi location is suitable for indoor devices, or to cover areas where GNSS or cellular networks are not always available. Wi-Fi can be more accurate than GNSS and cellular location for indoor devices, since the signal range of access points indoors is typically much smaller than the range for cells or satellites.

The current implementation of this feature in samples and applications uses a cellular connection for data transfer and connectivity to nRF Cloud, so a valid SIM is also needed.

The GetLocationFromWifiNetworks endpoint supports Wi-Fi location assistance through the nRF Cloud REST API.

Ground fix¶

Ground fix combines cell and Wi-Fi queries into a single operation. See the cell and Wi-Fi guides for examples, as well as the nRF Cloud multi-service sample for an example integration.

See GetLocationFromCellsOrWifiNetworks for the full endpoint documentation.

Wi-Fi anchors¶

An anchor is a known Wi-Fi access point (AP) for which you can assign a custom location and name. When a device scans the AP's MAC address and reports the address to nRF Cloud, the server returns the custom location and name in the response.

Anchors can help track customer assets across the map with increased accuracy.

See CreateAnchor for the full endpoint documentation.

Guides¶

See the list of guides for instructions by method.