Skip to main content

Best Practices for High Accuracy Location with nRF Cloud

Endpoint: POST /v1/location/ground-fix
API Reference: Ground Fix


Overview​

The ground-fix endpoint determines a device's location by correlating Wi-Fi access points and/or cellular measurements against a reference database. The quality of your location result is determined by the quality and quantity of the data you submit. This document describes how to get the most accurate results from both Wi-Fi and cellular inputs.


Wi-Fi Best Practices​

1. Send as many access points as possible​

This is the single most impactful thing you can do. The odds of getting a location response improve significantly when sending more APs, and the accuracy improves dramatically. A minimum of two APs are required (or one AP combined with cell data), but sending 5 or more will often produce the best results. For single AP requests, see Single access point requests and accuracy tradeoffs. Both universally administered and locally administered MAC addresses are accepted. See MAC address: Universal vs. local for more information.

Submit every reading your scan returns, even those with weak signal. Do not pre-filter on the device.

2. Always include signal strength​

The signalStrength field (signal strength in dBm) is used for weighted positioning — APs with stronger signal are given more weight.

{
"macAddress": "AA:BB:CC:DD:EE:FF",
"signalStrength": -62
}

3. Do not pre-filter by signal strength​

It is tempting to drop APs below a threshold before sending. Don't. Even weak-signal APs constrain the position estimate and reduce ambiguity. Let the service decide how to weight them.

4. Do not round or truncate signal strength​

Submit the raw signal strength value from the scan. Rounding to the nearest 5 or 10 dBm degrades the weighted positioning calculation.

Single access point requests and accuracy tradeoffs​

By default, a Wi-Fi request with only one AP is rejected. Setting the fallback query parameter to singleWifi lets the service return a location estimate based on a single AP:

curl -X POST "https://api.nrfcloud.com/v1/organizations/$NRFCLOUD_ORG/projects/$NRFCLOUD_PROJECT/location/ground-fix?fallback=singleWifi" \
-H "Authorization: Bearer $NRFCLOUD_OAT" \
-H "Content-Type: application/json" \
-d '{"wifi":[{"macAddress":"AA:BB:CC:DD:EE:FF","signalStrength":-62}]}'

A single-AP estimate is less accurate than a multi-AP one. The location is intentionally obscured for privacy reasons, and the accuracy could be hundreds of meters.

Requests with fallback=singleWifi provide higher availability, but lower accuracy. Requests that would otherwise fail can return a coarse location instead.

If your app prioritizes stricter accuracy and is okay with fewer results, fallback=singleWifi can be omitted. The request will fall back to cellular data or return a not found (404) if no location can be resolved.

This choice is independent of how many APs your scan returned. nRF Cloud cannot tell in advance whether the APs in a request are usable. For example, if only one of twenty APs is known in our dataset, that request still needs fallback=singleWifi to return a location. Rather than enabling it only when a scan looks sparse, decide whether a coarse location is better than no location for your use case, and set the parameter consistently on all requests accordingly.

Notes:

  • fallback=singleWifi only applies to the ground-fix endpoint and must be requested explicitly.
  • The AP must have a valid MAC address. Duplicate entries for the same MAC address count as one AP.

Cellular Best Practices​

1. Always prefer multi-cell over single-cell​

Single-cell location (lte with one entry) produces a coarse estimate based on the theoretical coverage area of the serving cell — often hundreds of meters to several kilometers of uncertainty, depending on the cell's size.

Multi-cell location uses many cells to produce a higher quality result.

2. Include all available signal metrics​

For LTE and NB-IoT, include rsrp and rsrq for every cell that reports them. These signal quality values are used to weight each cell's contribution to the position estimate, analogous to signal strength in Wi-Fi positioning.

{
"mcc": 310,
"mnc": 410,
"tac": 12345,
"eci": 12345678,
"rsrp": -95,
"rsrq": -12
}

3. Use the full 28-bit ECI (E-UTRAN Cell Identifier)​

The eci field must be the full 28-bit cell identifier, not just the local cell ID. The ECI encodes both the eNB ID (20 bits) and the local cell ID (8 bits). Sending only the local cell ID (0–255) will cause a lookup failure or match the wrong cell.

4. Include TAC (Tracking Area Code)​

tac is required for unambiguous cell lookup. Cell IDs are not globally unique; the combination of MCC + MNC + TAC + ECI uniquely identifies a cell. Always include it.


Combining Wi-Fi and Cellular​

Submitting both Wi-Fi and cellular data in the same request often produces the best result. The service fuses both inputs and can recover gracefully when one source is unreliable. Where possible, collect both and send them together.

{
"wifi": [
{ "macAddress": "AA:BB:CC:DD:EE:FF", "signalStrength": -62 },
{ "macAddress": "11:22:33:44:55:66", "signalStrength": -74 },
{ "macAddress": "AA:11:BB:22:CC:33", "signalStrength": -81 }
],
"lte": [
{
"mcc": 310,
"mnc": 410,
"tac": 12345,
"eci": 12345678,
"rsrp": -95,
"rsrq": -12
},
{
"mcc": 310,
"mnc": 410,
"tac": 12345,
"eci": 12345679,
"rsrp": -103,
"rsrq": -14
}
]
}

Accuracy​

The API returns the resolved location and an uncertainty value indicating result accuracy. Visualize accuracy by drawing a circle with a radius equal to the uncertainty value (in meters) around the latitude and longitude point. The actual location lies within this circle. Wi-Fi location offers higher accuracy than cellular because a Wi-Fi network's coverage area is significantly smaller than a cellular network's. Learn more about accuracy in the nRF Cloud Location Services overview.


Quick Reference Checklist​

Wi-Fi​

  • Submitting 5+ access points per request
  • signalStrength included for every AP
  • Not pre-filtering APs by signal strength
  • Sending universally administered MAC addresses only
  • Not rounding RSSI values

Cellular​

  • rsrp and rsrq included for every cell
  • Using full 28-bit ECI, not local cell ID
  • tac included for every cell

For the full API reference and request schema, see Ground Fix API.