With the introduction of the nRF7000 Wi-Fi companion IC, we now offer a complete silicon-to-cloud locationing solution with Wi-Fi, cellular IoT, and GNSS. The nRF7000 is optimized for Wi-Fi network scanning, and together with the nRF91 Series cellular IoT SiP, it enables SSID-based Wi-Fi locationing. Nordic’s SSID-based Wi-Fi locationing enables the acquisition of accurate location fixes in an extremely power-efficient manner both indoors and outdoors, in urban and suburban areas. This is a valuable complement to GNSS, especially in buildings and dense urban areas where GNSS can fail due to signal fading and interruptions.
This blog post will give an introduction to how our SSID-based Wi-Fi locationing solution works and how to get started testing it. Then, we will perform and present actual power consumption and accuracy measurements using the nRF9160 DK, nRF7002 EK, and PPK2 to compare the performance of the different location services available in nRF Cloud.
Table of Contents
Background Knowledge
Wi-Fi locationing service
Wi-Fi is a well-known wireless networking technology used for local area networking of devices and Internet access. Wi-Fi provides convenient wireless Internet access service through Wi-Fi networks in environments like homes, offices, and schools.
Wi-Fi locationing is a geolocation functionality that allows Wi-Fi-enabled devices to determine their approximate location using data from nearby Wi-Fi networks. It works by retrieving Wi-Fi network information like SSID, BSSID, and signal strength of nearby networks and comparing this information to a database of Wi-Fi networks with known locations.
A Wi-Fi locationing system contains the following key components:
-
Wi-Fi radio in the user's device to detect nearby networks.
-
Database that maps Wi-Fi network information like MAC addresses to locations. This database is maintained by location service providers.
-
Algorithm to estimate location by looking for pattern matches in the database and calculating signal strengths.
When a device queries the location service, it provides data on all the Wi-Fi networks it can see. The service looks up the networks in its database, finds the associated locations, and estimates a location for the device based on similarities and signal strengths.
nRF Cloud Wi-Fi location service
The nRF Cloud offers location services that provide fast and power-efficient location capabilities tailored for Nordic silicon chips. They can help devices and applications that need location data without high power draw. Multiple location technologies are offered, including Assisted-GPS, Predictive-GPS, Single-Cell, Multi-Cell, and Wi-Fi locations. By leveraging nRF Cloud's optimized location algorithms, products built on Nordic SoCs and SiPs can achieve high performance with ultra-low power consumption for location use cases. For Wi-Fi location requests, nRF Cloud can calculate the device position with the help of a Wi-Fi database, which has coordinates of different Wi-Fi networks. The device position is then sent from the nRF Cloud to either the customer cloud or back to the device.
nRF70 Series
Nordic Semiconductor released our Wi-Fi product series, the nRF70 Series, early this year. The first chip launched in this series is the nRF7002, which is an ultra-low-power dual-band wireless companion IC that adds low-power Wi-Fi® 6 capabilities to another host chip. In addition, we recently introduced the nRF7000, dedicated to this use case. It is a dual-band Wi-Fi companion IC that does not send data but can do active and passive scanning purely for Wi-Fi locationing purposes. In conjunction with our nRF9160 cellular IoT SiPs and nRF Cloud services, the nRF7000 enables Wi-Fi-based location service by sniffing the SSID of local Wi-Fi access points.
Wi-Fi Location Service Process
The Cellular: Location sample in the nRF Connect SDK demonstrates how to use the different location services offered by nRF Cloud.
Let's test how the nRF Cloud Wi-Fi locationing service works in an indoor environment.
- Hardware: nRF9160 DK, nRF7002 EK, PPK2.
- Software: nRF Connect SDK v2.4.2, MFW v1.3.5, Power Profiler application in nRF Connect for Desktop.
The hardware connection is set up according to the picture below. In the Power Profiler application, configure the PPK2 source meter mode to power the nRF9160 SiP on the DK and record its current consumption change.
The original location_wifi_get() function in the Cellular: Location sample can be used to request Wi-Fi location service. Additional log configurations are enabled to help to understand the request process.
# Add the following lines to the end of prj.conf CONFIG_LOCATION_LOG_LEVEL_DBG=y CONFIG_NRF_CLOUD_REST_LOG_LEVEL_DBG=y CONFIG_REST_CLIENT_LOG_LEVEL_DBG=y CONFIG_NRF_CLOUD_LOG_LOG_LEVEL_DBG=y CONFIG_NRF_CLOUD_LOG_LEVEL_DBG=y
Let's go through the process of how to use location_wifi_get() to request the Wi-Fi locationing service. We have split the process into three steps to explain the Wi-Fi locationing service request process.
Step 1: Scan Wi-Fi APs information
In this step, the Wi-Fi locationing service is configured, and the device starts scanning for nearby Wi-Fi access points. The result shows that the device found 14 Wi-Fi APs near or in the Nordic Semiconductor Oslo office building.
Requesting Wi-Fi location with GNSS and cellular fallback... [00:01:19.903,594] <dbg> location: location_core_config_log: Location configuration: [00:01:19.911,682] <dbg> location: location_core_config_log: Methods count: 1 [00:01:19.919,342] <dbg> location: location_core_config_log: Interval: 0 [00:01:19.926,605] <dbg> location: location_core_config_log: Timeout: 300000ms [00:01:19.934,356] <dbg> location: location_core_config_log: Mode: 0 [00:01:19.941,223] <dbg> location: location_core_config_log: List of methods: [00:01:19.948,913] <dbg> location: location_core_config_log: Method #0 [00:01:19.956,146] <dbg> location: location_core_config_log: Method type: Wi-Fi (3) [00:01:19.964,660] <dbg> location: location_core_config_log: Timeout: 30000ms [00:01:19.972,686] <dbg> location: location_core_config_log: Service: Any (0) [00:01:20.044,921] <dbg> location: location_request_info_create: Wi-Fi and cellular methods are not one after the other in method list so they are not combined [00:01:20.059,448] <dbg> location: location_core_location_get_pos: Requesting location with 'Wi-Fi' method [00:01:20.069,458] <dbg> location: location_core_location_get_pos: Starting request timer with timeout=300000 [00:01:20.079,711] <dbg> location: location_core_timer_start: Starting timer with timeout=30000 [00:01:20.088,745] <dbg> location: scan_wifi_start: Triggering start of Wi-Fi scanning [00:01:24.832,458] <dbg> location: scan_wifi_result_handle: scan result #1 stored: ssid XXXX, channel 108, mac 24:36:da:16:xx:xx [00:01:24.845,184] <dbg> location: scan_wifi_result_handle: scan result #2 stored: ssid XXXX, channel 108, mac 24:36:da:16:xx:xx [00:01:24.858,093] <dbg> location: scan_wifi_result_handle: scan result #3 stored: ssid XXXX, channel 11, mac 24:36:da:16:xx:xx [00:01:24.870,910] <dbg> location: scan_wifi_result_handle: scan result #4 stored: ssid XXXX, channel 11, mac 24:36:da:16:xx:xx [00:01:24.883,483] <dbg> location: scan_wifi_result_handle: scan result #5 stored: ssid XXXX, channel 1, mac 24:36:da:11:xx:xx [00:01:24.896,209] <dbg> location: scan_wifi_result_handle: scan result #6 stored: ssid XXXX, channel 1, mac 24:36:da:17:xx:xx [00:01:24.908,935] <dbg> location: scan_wifi_result_handle: scan result #7 stored: ssid XXXX, channel 1, mac 24:36:da:17:xx:xx [00:01:24.921,417] <dbg> location: scan_wifi_result_handle: scan result #8 stored: ssid XXXX, channel 64, mac 24:36:da:11:xx:xx [00:01:24.933,990] <dbg> location: scan_wifi_result_handle: scan result #9 stored: ssid XXXX, channel 64, mac 24:36:da:11:xx:xx [00:01:24.946,807] <dbg> location: scan_wifi_result_handle: scan result #10 stored: ssid XXXX, channel 6, mac 8a:5a:85:af:xx:xx [00:01:24.959,442] <dbg> location: scan_wifi_result_handle: scan result #11 stored: ssid XXXX, channel 100, mac 24:36:da:17:xx:xx [00:01:24.972,167] <dbg> location: scan_wifi_result_handle: scan result #12 stored: ssid XXXX, channel 6, mac 34:21:09:48:xx:xx [00:01:24.984,649] <dbg> location: scan_wifi_result_handle: scan result #13 stored: ssid XXXX, channel 132, mac 24:36:da:11:xx:xx [00:01:24.997,619] <dbg> location: scan_wifi_result_handle: scan result #14 stored: ssid XXXX, channel 132, mac 24:36:da:11:xx:xx [00:01:25.010,284] <dbg> location: scan_wifi_done_handle: Scan request done with 14 Wi-Fi APs
Step 2: Request nRF Cloud Wi-Fi locationing
The nRF9160 will encode the Wi-Fi APs information, including MAC address, SSID, signal strength, and channel, into a JSON file. The JSON file is then sent to nRF Cloud, which will use the data to check the Wi-Fi location database and calculate the device location using a specific algorithm. nRF Cloud will send back the result to the device for a successful request. The result contains information like latitude, longitude, accuracy. See the nRF Cloud REST API Documentation for the API request and response formats.
[00:01:25.028,015] <dbg> location: cloud_service_location_get: Cloud service location parameters:
[00:01:25.037,170] <dbg> location: cloud_service_location_get: Service: 0
[00:01:25.044,494] <dbg> location: cloud_service_location_get: Timeout: 25060ms
[00:01:25.052,337] <dbg> location: cloud_service_nrf_pos_get: Sending positioning request (REST)
[00:01:25.160,125] <dbg> nrf_cloud_codec_internal: nrf_cloud_location_req_json_encode: JSON: {"wifi":{"accessPoints":[{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-41,"channel":108},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-41,"channel":108},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-48,"channel":11},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-49,"channel":11},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-63,"channel":1},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-70,"channel":1},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-70,"channel":1},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-72,"channel":64},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-72,"channel":64},{"macAddress":"8a:5a:85:af:xx:xx","ssid":"XXXX","signalStrength":-73,"channel":6},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-75,"channel":100},{"macAddress":"34:21:09:48:xx:xx","ssid":"XXXX","signalStrength":-76,"channel":6},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-85,"channel":132},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-85,"channel":132}]}}
[00:01:25.283,142] <dbg> rest_client: rest_client_request: Requesting destination HOST: api.nrfcloud.com at port 443, URL: /v1/location/ground-fix
[00:01:25.296,966] <dbg> rest_client: rest_client_request: Payload: {"wifi":{"accessPoints":[{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-41,"channel":108},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-41,"channel":108},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-48,"channel":11},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-49,"channel":11},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-63,"channel":1},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-70,"channel":1},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-70,"channel":1},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-72,"channel":64},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-72,"channel":64},{"macAddress":"8a:5a:85:af:xx:xx","ssid":"XXXX","signalStrength":-73,"channel":6},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-75,"channel":100},{"macAddress":"34:21:09:48:xx:xx","ssid":"XXXX","signalStrength":-76,"channel":6},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-85,"channel":132},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-85,"channel":132}]}}[00:01:25.417,358] <dbg> rest_client: rest_client_sckt_connect: Doing getaddrinfo() with connect addr api.nrfcloud.com port 443
[00:01:25.435,699] <dbg> rest_client: rest_client_sckt_connect: getaddrinfo() 52.70.xxx.xxx
[00:01:25.445,892] <dbg> rest_client: rest_client_sckt_connect: Connecting to api.nrfcloud.com port 443
+CSCON: 1
[00:01:26.902,130] <dbg> rest_client: rest_client_http_response_cb: HTTP: All data received (content/total: 79/328), status: 200 OK
[00:01:26.914,245] <dbg> rest_client: rest_client_request: API call response len: http status: 200, 79 bytes
[00:01:26.926,025] <dbg> location: location_core_event_cb_fn: Location acquired successfully:
[00:01:26.934,844] <dbg> location: location_core_event_cb_fn: method: Wi-Fi (3)
[00:01:26.942,901] <dbg> location: location_core_event_cb_fn: latitude: 59.920980
[00:01:26.950,988] <dbg> location: location_core_event_cb_fn: longitude: 10.689317
[00:01:26.959,136] <dbg> location: location_core_event_cb_fn: accuracy: 15.0 m
[00:01:26.966,857] <dbg> location: location_core_event_cb_fn: date: 2023-08-31
[00:01:26.974,609] <dbg> location: location_core_event_cb_fn: time: 13:49:40.035 UTC
[00:01:26.982,879] <dbg> location: location_core_event_cb_fn: Google maps URL: https://maps.google.com/?q=59.920980,10.689317
Got location:
method: Wi-Fi
latitude: 59.920980
longitude: 10.689317
accuracy: 15.0 m
date: 2023-08-31
time: 13:49:40.035 UTC
Google maps URL: https://maps.google.com/?q=59.920980,10.689317
Step 3: Device goes to sleep
When the RRC Inactivity Timer expires, the nRF9160 will enter RRC Idle state. I have set the active timer (T3324) to 0 (CONFIG_LTE_PSM_REQ_RAT="00000000") to help the device enter PSM immediately to save power once the device enters the RRC Idle state. The RRC Inactivity Timer is configured by MNOs (here it is 5 seconds for Telenor Norway). If the fast release feature (AS-RAI) is supported by the MNO, the device can enter RRC Idle immediately by sending RAI to inform the base station to release the radio connection between them. This will further reduce the total power consumption. You can learn more about RAI from the blog Maximizing battery lifetime in cellular IoT: An analysis of eDRX, PSM, and AS-RAI.
Comparing the location services in practice
The location services available in nRF Cloud have different performance when it comes to position accuracy and power consumption, and it is up to you to select the one best suited for your application needs.
| Wi-Fi | GNSS | Single-cell | Multi-cell | |
| Accuracy (optimal) | 5-15m | 5-10m | 1000m | 200-300m |
| Latency | Seconds | Seconds | <1s | <1s |
| Power consumption | Moderate | Very high | Low | Low+ |
| Read distance | 150m | Anywhere | 35km | 35km |
| Use-case | Which room | Very accurate outdoor | Very rough outdoor | Which building |
The chart has a table listing the optimal accuracy of different location services; the actual accuracy will vary in practice. For example, GNSS location service accuracy in a city surrounded by tall buildings can get poorer accuracy than Wi-Fi because of reflections and buildings that can interfere with the GNSS signal. It is important to choose the correct location service methods according to application needs and evaluate the actual position accuracy and power consumption with measurements.
To help you understand how to do this evaluation in practice, we have taken power consumption measurements when using different locationing methods. The measurements are still based on the nRF Connect SDK sample Cellular: Location. The test is on the roof of the Nordic Semiconductor Oslo office building.
Cellular-based location service
The following new function location_cellular_get() is defined to test the cellular location service.
/**
* @brief Retrieve location with cellular location service.
*/
static void location_cellular_get(void)
{
int err;
struct location_config config;
enum location_method methods[] = {LOCATION_METHOD_CELLULAR};
location_config_defaults_set(&config, ARRAY_SIZE(methods), methods);
printk("Requesting cellular location...\n");
err = location_request(&config);
if (err) {
printk("Requesting location failed, error: %d\n", err);
return;
}
location_event_wait();
}
The power consumption results of cellular-based location services look quite similar to a Wi-Fi location service. The following picture shows the PPK2 measurement of a cellular location service.
Here is the log output from the test. The total power consumption of this cellular location service request was 122.48 mC, and the accuracy was 1708.0 m.
Requesting cellular location...
Got location:
method: Cellular
latitude: 59.920624
longitude: 10.689719
accuracy: 1708.0 m
date: 2023-09-04
time: 12:47:23.399 UTC
Google maps URL: https://maps.google.com/?q=59.920624,10.689719
Wi-Fi-based location service
The following captures use the location_wifi_get function to request Wi-Fi location service. The total power consumption for this event was 125.85mC, and the log showed 30.0m accuracy.
Got location: method: Wi-Fi latitude: 59.919015 longitude: 10.688577 accuracy: 30.0 m date: 2023-09-04 time: 12:47:51.753 UTC Google maps URL: https://maps.google.com/?q=59.919015,10.688577
GNSS-based location service using A-GPS
The original function location_gnss_low_accuracy_get() in the sample is used for the GNSS location service request, and A-GPS assistance is enabled. Low accuracy mode lets GNSS demonstrate a looser acceptance criterion for a fix to conserve power consumption. There are three accuracy mode for GNSS location service: low, normal, and high. The higher accuracy, the more power the device will consume, but we know from experience that all of them will consume more power than Wi-Fi and cellular location services. In the GNSS location service measurement, we expect even the GNSS low accuracy mode will provide better location accuracy than Wi-Fi and cellular location services, so the low accuracy mode is used in this measurement and we can see the "closest" power consumption difference of GNSS with other location services."We expect even the GNSS low accuracy mode will provide better location accuracy than other methods, but it will consume more power, so the low accuracy mode is used in this measurement. The result did prove this assumption. A-GPS data is only requested one time to speed up TTFF. Note that the A-GPS request is not needed as long as the almanac and ephemeris data in the device are still valid.
The PPK2 measurement shows the total charge for this event is 316.71mC without the A-GPS data request process, and the log shows 16.9m accuracy.
Got location:
method: GNSS
latitude: 59.920928
longitude: 10.689040
accuracy: 16.9 m
date: 2023-09-04
time: 12:48:34.586 UTC
Google maps URL: https://maps.google.com/?q=59.920928,10.689040
Results
Below you can see the results from our power consumption and accuracy measurements, taken from the roof of the Nordic Semiconductor office in Oslo.
|
nRF Cloud location service |
Power consumption (mC) |
Accuracy (m) |
|---|---|---|
|
Cellular |
122.48 |
1708.0 |
|
Wi-Fi |
125.85 |
30.0 |
|
GNSS (low accuracy with A-GPS) |
316.71 (A-GPS data request process is not included) |
16.9 |
As we can see, these measurements properly reflect what was presented in the figure "Position accuracy and power consumption on location services". In general condition, Wi-Fi is a great location service method that captures great accuracy with a low power consumption.
Note that the chart has a table listing the optimal accuracy of different location services; the actual accuracy will vary in practice. For example, GNSS location service accuracy in a city surrounded by tall buildings can get poorer accuracy than Wi-Fi because of reflections and buildings that can interfere with the GNSS signal. It is important to choose the correct location service methods according to application needs and evaluate the actual position accuracy and power consumption with measurements.
Useful references
- Product Page: nRF Cloud Services
- Product Page: Wi-Fi
- nRF Connect SDK sample: Cellular: Location
- Webinar: Unleashing Wi-Fi Locationing: Nordic Chip-to-Cloud Solution
- Webinar: Introduction to low-power Wi-Fi
- DevZone Blog: Target Wake Time on the nRF7002 DK
- DevZone Blog: Implementing MQTT over Wi-Fi on the nRF7002 Development Kit
