Towards Smarter Positioning through Analyzing Raw GNSS and Multi-Sensor Data from Android Devices: A Dataset and an Open-Source Application

Abstract

The state-of-the-art Android environment, available on a major market share of smartphones, provides an open playground for sensor data gathering. Moreover, the rise in new types of devices (e.g., wearables/smartwatches) is further extending the market opportunities with a variety of new sensor types. The existing implementations of biometric/medical sensors can allow the general public to directly access their health measurements, such as Electrocardiogram (ECG) or Oxygen Saturation (SpO2). This access greatly increases the possible applications of these devices with the combination of all the onboard sensors that are broadly in use nowadays. In this study, we look beyond the current state of the art into the positioning capacities of Android smart devices and wearables, with a focus on raw Global Navigation Satellite Systems (GNSS) measurements that are still mostly lacking in the research world. We develop a novel open-source Android application working in both smartphone and smartwatch environments for multi-sensor measurement data logging that also includes GNSS, an Inertial Navigation System (INS) magnetometer, and a barometer. Four smartphones and one smartwatch are used to perform surveys in different scenarios. The extraction of GNSS raw data from a wearable device has not been reported yet in the literature and no open-source app has existed so far for extracting GNSS data from wearables. Not only the developed app but also the results of these measurement surveys are provided as an open-access dataset. We start by defining our methodology and the acquisition protocol, and we dive into the structure of the dataset files. We also propose a first analysis of the data logged and evaluate the data according to several performance metrics. A discussion reviewing the capacities of smart devices for advanced positioning is proposed, as well as the current open challenges.

1. Introduction

Interest in using smartphones for sensor logging has been part of the research community for the last decade. Smartphones provide a very interesting environment for data gathering, as they include a variety of sensors (e.g., accelerometers, gyroscopes, camera, Wireless Fidelity (WiFi), Bluetooth Low Energy (BLE)) embedded inside a low-cost platform. The Application Programming Interface (API) centralizes access to all the sensor measurements for Android devices, greatly simplifying the developments. Moreover, synchronization of all data is ensured by a common platform, making it useful for sensor fusion studies [1,2].

More recently, the development of “wearables” provides similar but new data-gathering platforms. On top of providing ultra-compact designs for the same sensors available on smartphones, smartwatches propose new kinds of sensors more related to health monitoring, such as ECG, photoplethysmogram (PPG), Galvanic Sensor Response (GSR), and/or SpO2. The different sensors in Android smart devices are displayed in Figure 1, showing the potential of smartwatches. While some manufacturers still propose their ecosystem (e.g., “ConnectIQ” for Garmin [3], Fitbit OS for Fitbit [4]), many manufacturers (e.g., Samsung, Google) are aligning on a common Android-based operating system with the possibility of common development of Android application on both the wearable and the smartphone platforms. This research will refer to them under the terms “smart devices”.

In the context of satellite positioning, all smart devices today include a GNSS receiver, yet the collection of measurements used to be limited to the device coordinates only. In 2016, Google enabled access to the “raw GNSS measurements” directly through the Android API. By “raw GNSS measurements”, we understand the measurements made by a receiver to compute a position, such as pseudoranges, carrier phases, Doppler shifts and Signal-to-Noise Ratio (SNR). Since the raw GNSS measurements were made available for smartphone manufacturers, the GNSS research community has been highly interested in the potential of enabling advanced high-precision positioning techniques on such devices, and many research works have been published to assess the receivers’ quality for positioning (see Section 2). We note that, as of today, Apple still needs to open access to the raw GNSS measurements in their OS, preventing similar comparisons on Apple devices. Thus, in this paper, we focus only on Android devices.

In the early years of Android GNSS measurements, only a certain number of Android models would provide access to raw data. Since Android 10 (API 29), Google made it mandatory for any Android device to support access to raw GNSS measurements. Discrepancies between device measurements are still present, but access to raw measurements is now open to potentially any Android devices and not only smartphones, including smartwatches.

The main contributions of this paper are as follows:

• Developing a novel open-source sensor logging app called “Mimir”, designed for both smartphone and smartwatch environments;
• Providing an open-source multi-sensor dataset acquired on various Android smart devices (four smartphones and one smartwatch), along with a geodesic-grade reference receiver;
• Comparing the data quality and positioning accuracy of the Android smart devices in the context of positioning applications.

To the best of the authors’ knowledge, raw GNSS measurements acquisition comparison for smartwatch devices is conducted for the first time in the literature.

This research is performed in the context of the EU-funded projects APROPOS [5] and LEDSOL [6] that aim, among others, to also review low-power/low-cost devices, such as Android smart devices, for navigation purposes. The data acquired consist of four surveys, one static and three pedestrian/dynamic cases, and it was acquired in open-sky and urban areas. The complete dataset is released as an open source under a Creative Commons license CC-BY-4.0 on a Zenodo repository [7].

2. Related Research

2.1. Usage of Android GNSS Measurements

The development of Android GNSS measurements was highly impacted by the release in 2018 of the Xiaomi Mi8, the first device to embed a dual-frequency GNSS chip from Broadcom (BCM4775) [8]. Reception of multiple GNSS frequencies, such as L1 and L5, can enable advanced positioning techniques [9]. Consequently, many publications over the last five years have demonstrated diverse application topics for the usage of Android GNSS measurements: measurement quality [10,11,12,13], high-precision positioning [10,14,15,16], atmospheric error estimation [17,18], sustainable water access through standalone positioning aiding [19,20], spoofing/jamming mitigation [21,22], etc.

While the use of the Android GNSS measurements appears very fruitful and has high potential, acquiring the raw data is not trivial and requires specific apps and access to the device’s developer options. In [11], a comprehensive review of the available Android apps for GNSS data acquisition is performed. The paper analyzes the raw measurements available in Android devices and mentions some of the problems associated with the processing. One of the issues pointed out is the measurement quality and unknown hardware characteristics, which prevent more precise positioning as of today. Similarly, as the receiver is greatly influenced by its environment, a lack of details about the acquisition protocol and lack of dataset diversity (e.g., harsh environments) are also highlighted as a limitation with currently available open data.

2.2. Access to Public Datasets

Today, a few public datasets provide access to Android GNSS measurements. The review from [11] was based on a dataset published by Google, in the context of the Google Smartphone Decimeter Challenge (GSDC) that happened in both 2021 and 2022. The data used for the competition is still accessible online and can be downloaded upon acceptance of the competition rules [23,24]. The data from 2021 are composed of dynamic tracks acquired in a car scenario and performed with different Android device models. Additional details can be found in [25].

Other interesting datasets were published by the EUSPA (former GSA) as part of the “GNSS Raw Measurements Task Force” [26]. The data are accessible through a Google Doc, summarizing the campaigns. As of today, two campaigns are accessible through the document. One campaign from 2020 focuses on different wearables devices but provides access only to positions and not to raw GNSS measurements. Another campaign from 2021 contains data acquired in different scenarios (i.e., static, dynamic pedestrian/bike/car) and environments (i.e., open-sky, forest, suburban, urban, highway) from six Android devices. The accessibility and diversity of the data make the EUSPA dataset very interesting for research purposes. However, we did not use this dataset in this research, as we wanted to focus on a newer generation of Android devices including smartwatches, and assess the potential improvements in the GNSS measurement quality.

To summarise, access to raw GNSS measurements in open datasets is still scarce and limited to a few providers. Indeed, all the studies mentioned before that compared several devices have shown the large discrepancies that can exist in terms of measurement quality. Thus, to mitigate the impact of the data over the proposed methods, it is necessary to compare it on a variety of datasets and devices. Given the amount of new Android devices released every year, keeping up with new datasets for every device might seem vain. Yet, crowd-sourcing and publication of the datasets used in studies could enable more device comparison without the need for each research team to purchase a specific device.

2.3. Wearables and Next GNSS Chip Generation

Wearables have the potential to expand the usage of data gathered in smart devices, bringing the health-related sensor dimension. Android smartwatches are based on a slightly different operating system (OS) than smartphones, called WearOS (formerly Android Wear). This OS is based on the same Android API levels, which allows for the common development of Android applications in both smartphones and smartwatches. WearOS 3.0 (Android 11) is the first version based on a higher version than Android 9, which should provide access to raw GNSS measurements. However, to the best of the authors’ knowledge, no paper until today has yet investigated the GNSS measurement quality of any Android smartwatch. Nevertheless, medical-oriented studies have shown the potential of wearables for medical research [27,28], as well as Android devices for contact tracing [29]. More specifically, in [30], the usage of indoor/outdoor positioning to retrieve the mobility patterns showed interesting results in recovering mental health assessment for patients. Thus, more accurate positioning and motion estimation could enable further medical research, especially if combined with the health sensors of smartwatches.

In 2019, Broadcom announced the chipset’s second generation (BCM4776), a follow-up chipset to the previously mentioned BCM4775 included in the Xiaomi Mi8. According to Broadcom, the new chipset comes with potentially 60% additional L5 signals with the reception of BeiDou-L5 signals [31]. Since 2021, new Android devices have integrated this chipset into their design, such as the Google Pixel 6 and 7, and even the recently released Google Pixel Watch. The release of the new Broadcom chipset could potentially mark the beginning of the second generation of GNSS measurements in Android smart devices.

2.4. Paper Structure

We start by presenting the methodology used for the creation of the dataset. In Section 3, we review the motivation for the device selection, the developed software, and the survey (or measurement) protocol. In Section 4, we provide a deep review of the dataset contents, including the type of sensor logged, the list of the performed surveys, and a description of the scenario and environments. In Section 6, we propose a first analysis of the data, with a comparison of the capacities between the devices. Finally, Section 7 concludes the paper with future development plans for our logging app and perspective research using this dataset.

3. Methodology

In this section, we present the methodology for filtering the different Android devices, in order to select only a subset fitting our research. We proceed with detailing the different software used and developed to acquire and analyze the data, and we finish by presenting our survey protocol.

First, we recall some terminology used in this paper:

• By “survey”, we mean the act of surveying and gathering data using a measurement device, as defined in land surveying topics.
• In Differential GNSS (DGNSS), the “base” refer to the static receiver and “rover” refer to the moving receiver.
• In GNSS, an “epoch” is defined a measure of time when a new GNSS measurement is received. A 1 Hz sampling rate would be equivalent to 1 epoch per second.

3.1. Device Selection

Research in Android GNSS measurements have shown that the measurement’s quality is not equal among all devices, even under identical measurement scenarios, as the manufacturers can embed different GNSS receivers in each new model [12]. Even access to specific GNSS observables (e.g., carrier phase, navigation message) cannot be ensured for each device. While the impact of these discrepancies can be minimal or unseen by the general user, it can prevent some of the research potential. Therefore, we performed the surveys over multiple Android devices for better assessment of their capacities in this study.

As the number of existing Android smartphones is enormous, the selection of the best devices can prove challenging. Thanks to the research community, a comprehensive list of Android devices with their GNSS capacities has been created through crowdsourcing and it is available online [32]. While it may contain multiple entries and some contradictory information, it still offers a first filter to select the devices with the required GNSS capacities. We note, however, that no smartwatch has been reported in this list so far.

To maximize the potential of each evaluated device and the quality of the dataset, we have decided to select devices under four constraints: (1) support of dual-frequency reception; (2) available carrier-phase measurements; (3) available navigation message; (4) GNSS chipset diversity. Point (3) was the most constraining, as many devices do not retrieve the satellite’s ephemeris from the navigation message anymore. Using the aforementioned list, we came down to only 22 devices checking all four requirements. More than half of them used a Broadcom BCM4775 or BCM4776 chip. The BCM4775 has been extensively reviewed in research before given that it was implemented in the Xiaomi Mi8 [10,14,17]; we have decided to focus on evaluating only the new generation BCM4776 instead. The rest of the receivers were chosen based on prices and in order to maximize GNSS chipset and manufacturer diversity. As one smartphone (Samsung A52) was already present in our lab for previous research purposes, we decided to also include it in these surveys for comparison purposes, even though it did not fit the requirements mentioned before. In total, four smartphones were selected and are summarized in

Table 1. Selected Android devices included in the dataset.

Acronym	Device Name	Type	Release	Android (API)	GNSS Chip	Frequencies	Phase	Navigation Message
GP7	Google Pixel 7	Phone	October 2022	Android 13 (API 33)	Broadcom BCM4776	L1, L5	✓	✓
GPW	Google Pixel Watch	Watch	October 2022	WearOS 3.5 (API 30)	Broadcom BCM4776	L1	✓	✓
ON2	OnePlus Nord 2 5G	Phone	July 2021	Android 12 (API 31)	Unknown	L1, L5	✓	✓
A52	Samsung A52 5G	Phone	March 2021	Android 13 (API 33)	Qualcomm SD 720G	L1	✗	✗
X11	Xiaomi 11T	Phone	September 2021	Android 12 (API 31)	Unknown	L1, L5	✓	✗

. Note that while the Xiaomi 11T was said to have the navigation message enabled in the online list, we did not receive any during our experiments, and reported it accordingly in the table.

As no previous studies have looked into GNSS measurements in smartwatches, we decided to review the recently released Google Pixel Watch (October 2022) [33]. The watch also embeds a BCM4776 GNSS chip, similar to the one in the Pixel 7, enabling the measurement comparisons between both platforms. For example, while the BCM4776 is supposed to be dual-frequency-enabled, only L1 frequencies were received during the survey. The most logical hypothesis is that the dual-frequency reception was disabled in order to save energy, as it was proven to have a large impact on the energy budget of Android devices [34]. This shows that even when the GNSS chipset model is similar in two devices, large differences in the measurements can still be present.

In the following sections, devices will be referred to by the acronym listed in Table 1 for simplicity.

3.2. Logging Application Developments

In order to log the measurements inside the Android device, an app is used to interact with the Android API. Several apps exist today to log GNSS or sensor data, as reviewed in [11]. The most common one is GNSS logger [35], maintained by Google. It can log GNSS data in multiple formats (e.g., CSV, RINEX, NMEA). Logging other motion sensors is also possible, such as accelerometers, gyroscopes and magnetometers. However, several limitations of the existing applications were found during the first stages of our research. Firstly, only a partial version of the GNSSLogger source code is available on GitHub (old versions of the app), which prevents easy forking to the current version. Secondly, the logging is limited to GNSS and motion sensors logging only (no barometer data), with no possibility of controlling the sampling frequency. Thirdly, GNSSLogger does not exist for smartwatches, and, to the best of the authors’ knowledge, there is currently no app available for logging GNSS data from smartwatches.

Consequently, we decided to develop our own Android app called “Mimir”, a name based on the God of Knowledge in Nordic mythology (see https://www.britannica.com/topic/Mimir (accessed on 21 November 2023)). Mimir was developed with the goal of enabling the logging of any sensors present in an Android device. The code is released as open-source, under the Apache 2.0 license and is available on Github [36]. As mentioned earlier, while the Android smartwatch implements different flavors of the WearOS, they are based on a common Android API. Thus, the development of smartwatch apps is similar to smartphones, except for the UI design of the app. It allows the development of a common Android library for sensor logging, implemented in two different apps, for smartphones and smartwatches, respectively. Currently, the app allows logging of GNSS, motion and environment sensors, as defined in the Android developer documentation. The raw data are logged in a Comma Separated Value (CSV) format, similar to GNSSLogger logging format. For compatibility with the former processing software, all measurements related to GNSS have kept the same columns as in GNSSLogger. Other sensors are logged using our own defined format (see Appendix A). Furthermore, the app also allows the logging of health data on the smartwatch version. However, the recording of health data has been tested with the Google Pixel Watch only and is not recorded in the dataset provided for ethical reasons. Future developments planned are discussed in Section 7.

Note that similarly to GNSSLogger, no processing of the sensor is performed in the app. It is only used for sensor data gathering, logging the measurements exactly as provided by the Android API. Any post-processing is left to the computer processing software.

3.3. Analysis Software Developments

Once the data have been logged, it needs to be processed in order to analyze and use the sensor’s measurements for specific target applications; in our case, the target applications are based on accurate and/or robust positioning. The aforementioned GNSSLogger app is widely used by the research community because of its companion processing software called “GNSS Analysis App” [35], allowing plotting of the logged data. It is developed in Matlab and the source code can be found on GitHub. During the processing of the data, multiple unknown errors arose that prevented its usage for our analysis goals. Thus, similarly to how we developed the Mimir app [36], we have decided to build our own software to process the measurements.

For processing the data, we developed a Python library called “MimirAnalyzer”, with its code also available in open source on Github [37]. The library allows parsing of the CSV data into a Pandas DataFrame format, to be later analyzed. For a quick review of the measurement quality, we also created a local web dashboard. It allows visualization of the trajectory, comparison with a reference and review of the measurements logged into the file. For a deeper analysis, we have created also some Jupyter Notebook templates that allow for visuals and statistical analysis. More details about the performance metrics are provided in Section 5.

3.4. Survey Protocol

Based on the sections above, we can derive the survey protocol used for the acquisition and analysis of the devices, which is summarized in Figure 2.

For a proper comparison of the devices’ capacities, we define our reference/baseline to compare the measurements. During the process of evaluating the positioning capacities of the receivers, the most obvious benchmarking method is to find the reference coordinates of the surveyed locations. For static surveys, this can be easily defined after or before the survey by surveying the static location with a high-grade GNSS receiver. To minimize device disturbances, we used a tripod as represented in Figure 3a. For dynamic surveys, we used a backpack with an antenna mount on top as represented in Figure 3b. The used receiver was a Novatel PwrPak7 receiver connected to a Novatel GNSS-850 antenna. For the trajectory computations, we opted for Differential GNSS (DGNSS) computations, using the backpack a rover and our local GNSS station located on the university rooftop (Novatel GPS-703-GGG antenna, Septentrio PolaRx5 receiver) as a base. The total baseline between the devices ranges from a few hundred meters to a few kilometres, depending on the scenario. The DGNSS computations were performed using the open-source software RTKLib [38]; as these computations were needed only for the reference dynamic tracks, the DGNSS algorithms are not a part of our MimirAnalyzer software at present.

4. Dataset Description

In this section, we provide details on the dataset. We refer to it as a single “dataset” since it is provided at a single Zenodo link [7] but it is to be remembered that it contains several scenarios, both under static and dynamic conditions, and several Android devices. We start by detailing the logged sensors, then the survey scenarios will be presented and we provide a list of the performed surveys. Finally, we review the file structure of the dataset.

4.1. Scenarios and Environments

For our research purposes, we focused on pedestrian scenarios that are highly relevant in a variety of location-based applications such as studying mobility and migration patterns of workers or accessing various fundamental resources such as potable water (see LEDSOL project [6,19]), helping city planners to offer optimized services based on user location, or promoting more sustainable ways of transportation through optimized access to bikes, green lanes, or parks [39].

The university campus area and Hervanta center (a district in Tampere, Finland) offer an interesting and diverse environment for challenging positioning (i.e., open-sky, light forest, lake, suburban). While there are not many high buildings that could represent very harsh urban canyoning conditions, it is possible to recreate a partial blockage within the campus due to campus buildings (having between 3 and 10 floors). We have divided the surveys into three scenarios, all pedestrians with the conditions summarized in

Table 2. Summary of the scenarios.

	Motion	Environment	Duration	Device Carrying Mode
S1	Static	Open-sky	45 min	Placed on tripod
S2	Pedestrian	Urban canyoning	10 min	In right-hand, texting *
S3	Pedestrian	Suburban area	30 min	In backpack, pocket *
S4	Pedestrian	Forest & lake	30 min	In backpack, pocket *

* Smartwatch placed on left wrist, texting mode.

.

Defining the way the device is held or carried is also part of the scenario definition and crucial for future post-processing. Several studies [40,41] have shown how these carry modes determine the positioning models to use [40]. In [41], several carrying modes were assessed (e.g., texting, swinging, jacket pocket) and their effect on the inertial measurements, and consequently on the positioning solution, were reviewed.

In our study, two carry modes were reviewed in the dataset: (1) texting, where the device was held face up in front of the user; (2) backpack pocket, where the device was put in a stood-up orientation. These modes were chosen for their practical aspects, but also to understand how positioning might be affected by partial body blockage, as highlighted in [42]. Note that the smartwatch was placed on the left wrist (except S1). A representation of the scenario’s trajectories is displayed in Figure 4.

4.1.1. Static Scenario (S1)

The first scenario is a long static acquisition (45 min), performed in a near-perfect open-sky environment. We took a small light post as a visible landmark to perform the acquisition with each device separately. The devices were placed on a stable tripod as represented in Figure 3a, allowing long acquisition with minimal disturbances. The tripod landmark was surveyed using our reference receiver to obtain its precise location. While the light post is relatively wide, this setup was assessed to be suitable for the purpose of the survey, given the positioning accuracy of the devices. Moreover, the positioning of the antenna phase centre is unknown for all Android devices, so a highly precise benchmark is not required.

The receiver taken as reference for the visibility analysis in this scenario is a base station located on top of the nearest building, about 100 m northeast. Figures and statistics of the survey are provided in Appendix B.

4.1.2. Short Dynamic Scenario with Urban-Canyoning (S2)

The second scenario is a short dynamic pedestrian acquisition (10 min), performed in heavy urban canyoning. The scenario starts and ends with a short (30 s) static acquisition over the landmark previously described in S1. This was performed to allow the convergence of the position and to ensure that every available signal was correctly tracked before the dynamic part started. The trajectory went from south to north. The southern part has relatively good visibility, with only some overpass bridges between the buildings. The northern part presents a very narrow alley between the buildings, with only a quazi-zenital sky view. The data were acquired separately, device by device, and the device was always placed in the right hand of the surveyor. The GPW was placed on the left wrist and acquired at the same time as the GP7, for comparison over the same GNSS chipset model. We used the backpack setup described in Section 3 as a reference receiver for each survey. Figures and statistics of the S2 survey are provided in Appendix C.

4.1.3. Dynamic Scenario in Urban Area (S3)

The third scenario is a dynamic pedestrian acquisition (45 min), performed in a light urban area. Similarly to S2, the S3 scenario starts and ends with a short static acquisition for the usual landmark. The southern part has good open-sky conditions, contrary to the northern part, which has tall buildings around it. Strong noise can be seen in the trajectory due to a tall building with an outside ceiling, which as expected leads to noisier measurements. Finally, the part located on the road shows a small underground tunnel with possible GNSS cutoffs. The data from all the devices were acquired at the same time; all devices were placed in separate side pockets of the backpack. This allows comparison of the devices over the exact same-scenario conditions. Figures and statistics of the S3 survey are provided in Appendix D.

4.1.4. Dynamic Scenario in Forest/Lake Area (S4)

The final scenario is a dynamic pedestrian acquisition (30 min), performed in a light forest area around a lake. Similarly to S2 and S3, the S4 scenario starts and ends with a short static acquisition. The scenario was chosen to evaluate the impact of vegetation and the lake on the measurement quality. Similarly to S3, the data from all the devices were acquired at the same time and all devices were carried along in the backpack. Figures and statistics of the S4 survey are provided in Appendix E.

4.2. List of the Surveys Performed

In total, twelve surveys were performed to acquire the dataset with the devices over all four scenarios. The surveys happened on different days throughout the year, and a summary is available in

Table 3. Summary of the surveys performed and sensors logged.

Scenario	Date	Device	GNSS	INS	Magnetometer	Barometer
S1	17.02.2023	GP7	✓	✓	✓	✗
	03.03.2023	ON2	✓	✓	✓	✗
	03.03.2023	X11	✓	✓	✓	✗
	17.03.2023	A52	✓	✓	✓	✗
	14.08.2023	GPW	✓	✓	✓	✓
S2	01.08.2023	GP7	✓	✓	✓	✓
	01.08.2023	GPW	✓	✓	✓	✓
	01.08.2023	X11	✓	✓	✓	✓
	11.08.2023	A52	✓	✓	✓	✓
	11.08.2023	ON2	✓	✓	✓	✓
S3		GP7	✓	✓	✓	✓
		ON2	✓	✓	✓	✓
	11.08.2023	X11	✓	✓	✓	✓
		A52	✓	✓	✓	✓
		GPW	✓	✗	✗	✗
S4		GP7	✓	✓	✓	✓
		ON2	✓	✓	✓	✓
	11.08.2023	X11	✓	✓	✓	✓
		A52	✓	✓	✓	✓
		GPW	✓	✓	✓	✓

. Note that S1 surveys were acquired before the completion of the Mimir app. The measurements were acquired using the GNSSLogger app for smartphones, which explains the lack of barometer data. For S1 and S2, a separate survey was performed for each device, as the device was held in the right hand of the surveyor, thus allowing for only one device per survey. For S3 and S4, all devices were acquired at the same time in different pockets located on the side of the backpack.

4.3. File Structure

Multiple types of files are present inside the dataset. For the reference data, we provide the observation data in Novatel proprietary log file format, and the RINEX files extracted using Novatel Application Suite software. The observations from the base station are provided in RINEX files.

For Android devices, the raw logs are produced in a simple CSV format. This format was chosen to allow compatibility with the GNSSLogger app (presented in Section 3.3). Each line of the CSV file represents the data from a sensor at a specific timestamp. While multiple clocks might be defined inside the device (e.g., GNSS clock, system clock), all entries provide two timestamps: a UTC time in Unix format based on the global system clock, and a time counter since the last time the smart device was booted. The former is used for temporal indication but it might not be very accurate, as explained in Android documentation [43], and it is recommended to use the latter for more accurate time intervals.

We note that, while it is possible to request a specific sampling frequency through the Android API, our empirical experiments have shown that the accuracy of the sampling clock can be poor. Requesting for a too high or too slow sampling interval might lead to truncated sampling, based on the physical limitation of the sensor. It is recommended to interpolate the values of a log to the wanted sampling frequency before any processing is performed. The time information discussed above should be sufficient for accurate clock alignment between the sensors and with the GNSS clock.

4.4. Sensors Summary

Multiple sensor types were logged during the surveys and are listed below:

• GNSS measurements that can be associated with multiple line entries in the log file: (1) location measurements (latitude, longitude, altitude) provided by the phone, from different providers; (2) raw GNSS measurements, as described in [11,44]; (3) navigation messages, as provided by the Android API and decoded by the GNSS receiver (i.e., not from another network channel).
• INS measurements, composed of two type of sensors: accelerometers, providing linear acceleration measurements, and gyroscopes, providing rotational acceleration measurements. In total, we have on each mobile device three accelerometers and three gyroscopes, placed on the three orthogonal axes (X, Y, Z), allowing re-composition of a relative motion in three dimensions.
  Additionally, an INS often include magnetometers, which measures the magnetic field (similar to a magnetic compass). The magnetometer enables the absolute orientation and estimation of the INS drifts [45]. Similarly to the INS measurements, three magnetometers allow the measurement of the magnetic field in three dimensions. All this information can be put together to form a low-grade INS system to be combined with GNSS measurements [1,2,45]. In the Android documentation, these sensors are regrouped under the term “motion sensors”.
• Barometer measurements, related to the atmospheric pressure can be converted into altitude. As GNSS is known to have low precision in the up/vertical direction due to the geometry of a GNSS system, a fusion of GNSS/Barometer measurements is often seen in positioning applications [46].

All sensor entries are located in the same file, the first column containing the tag identifying the measurement type. The entry order follows the timeline of the sensor event reception. As different sensors provide different data, a header at the beginning of the files recalls the CSV columns for each sensor type. Motion sensors can also be retrieved “uncalibrated”, with their biases provided but not applied. In total, there are 10 different possible tags in the file.

Table A1. Mimir log entries related to GNSS sensors.

Tag	Measurement	Description	Unit
Fix	provider	Origin of the location provided (e.g., GPS, NLP, FLP)
	latitude	Geodetic latitude (WGS84)	[Dec. Deg.]
	longitude	Geodetic longitude (WGS84)	[Dec. Deg.]
	altitude	Geodetic altitude (WGS84)	[m]
	speed	User velocity	[m/s]
	accuracy	Horizontal uncertainty (1-σ)	[m]
	bearing	Horizontal direction	[Deg.]
	time	UTC time in UNIX	[ms]
	speedAccuracyMetersPerSecond	User velocity uncertainty (1-σ)	[m/s]
	bearingAccuracyDegrees	Horizontal direction velocity (1-σ)	[Deg.]
	elapsedRealtimeNanos	Time since system boot	[ns]
	verticalAccuracyMeters	Vertical uncertainty (1-σ)	[m]
	elapsedRealtimeUncertaintyNanos	Time since system boot uncertainty (1-σ)	[ns]
Raw	utcTimeMillis	UTC time in UNIX	[ms]
	timeNanos	Internal clock from GNSS hardware receiver	[ns]
	leapSecond	Number of leap seconds w.r.t. provided clock	[s]
	timeUncertaintyNanos	Internal clock uncertainty (1-σ)	[ns]
	fullBiasNanos	Full bias between clock and true GPS time	[ns]
	biasNanos	Partial clock bias	[ns]
	biasUncertaintyNanos	Partial clock bias uncertainty (1-σ)	[ns]
	driftNanosPerSecond	Clock drift	[ns/s]
	driftUncertaintyNanosPerSecond	Clock drift uncertainty (1-σ)	[ns/s]
	hardwareClockDiscontinuityCount	Counts of hardware discontinuities
	svid	Satellite ID
	timeOffsetNanos	Time offset of the measurements	[ns]
	state	Current tracking state of the signal
	receivedSvTimeNanos	Received satellite time at measurement time	[ns]
	receivedSvTimeUncertaintyNanos	Received time uncertainty (1-σ)	[ns]
	cn0DbHz	Carrier-to-Noise ratio	[dB-Hz]
	pseudorangeRateMetersPerSecond	Pseudorange rate, i.e., Doppler shift	[m/s]
	pseudorangeRateUncertaintyMetersPerSecond	Pseudorange rate uncertainty	[m/s]
	accumulatedDeltaRangeState	Carrier tracking state
	accumulatedDeltaRangeMeters	Accumulated pseudorange rate, i.e., carrier phase	[m/s]
	accumulatedDeltaRangeUncertaintyMeters	Accumulated pseudorange rate uncertainty	[m/s]
	carrierFrequencyHz	GNSS carrier frequency	[Hz]
	carrierCycles	Number of carrier phase cycles (deprecated)
	carrierPhase	Carrier phase (deprecated)
	carrierPhaseUncertainty	Carrier phase uncertainty (deprecated)
	multipathIndicator	Multipath flag	[Boolean]
	snrInDb	Signal-to-Noise ratio	[dB-Hz]
	constellationType	Constellation ID
	automaticGainControlLevelDb	Current Automatic Gain Control	[dB]
	basebandCn0DbHz	Baseband Carrier-to-Noise ratio	[dB-Hz]
	fullInterSignalBiasNanos	Full GNSS inter-signal bias	[ns]
	fullInterSignalBiasUncertaintyNanos	Full GNSS inter-signal bias uncertainty (1-σ)	[ns]
	satelliteInterSignalBiasNanos	Partial GNSS inter-signal bias	[ns]
	satelliteInterSignalBiasUncertainty	Partial GNSS inter-signal bias uncertainty (1-σ)	[ns]
	codeType	RINEX code type
	elapsedRealtimeNanos	Time since system boot (1-σ)	[ns]
Nav	utcTimeMillis	UTC time in UNIX	[ms]
	svid	Satellite ID
	type	Navigation message type
	status	Parity check status
	messageId	Message frame ID
	submessageId	Message sub-frame ID
	data	Byte array of navigation message

in Appendix A provides a summary of each logged sensor measurement; additional details can be found directly in the Android developer documentation [43].

5. Performance Metrics

For the analysis of the collected raw data, we have divided our study into three sections for each scenario: (1) positioning, assessing the native capacity of the device; (2) visibility, assessing the constellations/frequencies visible by each device; (3) measurements, assessing the raw GNSS observables’ precision, which is relevant to advanced positioning applications. In this section, we explain the performance metrics chosen to evaluate these aspects in each scenario.

5.1. Positioning

The Android API give access to different location providers, with different degrees of precision: NLP, Network Location Provider, related to the mobile network position (coarse precision); GPS, as provided by the GNSS chipset (standard precision); FSL, Fused Location Provider (best precision); in this paper, we focused on the GPS provider locations only, as provided by the phone. We did not perform any post-processing of the positions, nor computed the positions using advanced positioning techniques (e.g., sensor fusion, DGNSS, PPP). Instead, for positioning quality review, we computed the position errors in the east/north/up (ENU) direction, based on the reference receiver used in each scenario (see Section 3). These errors can be reviewed in two graphs, an overall map and ENU error against time, as well as statistic tables.

5.2. Visibility

Throughout our analysis, we realized that the Android API provides an event at a regular sampling rate (i.e., 1 Hz), while the measurements per satellite are not regular. Gaps of several seconds (1–5 s) can be seen for certain satellites, leading to the idea that the device performs some kind of sequential tracking. The signal stops being tracked by the receiver for a certain amount of time to concentrate on the tracking of another signal. The receiver then comes back to the first signal to converge again, and avoids the signal falling out of the tracking loop. The most probable reason is to limit the energy consumption, and possibly to enable more signal tracking than supported by the number of channels available in hardware. This phenomenon has been seen on every device, even with a different number of total visible signals per epoch.

Today, the GNSS tracking is often limited to the four major constellations (GPS, GLONASS, Galileo, BeiDou), with dual-frequency (L1/L5) for the most advanced ones. Some Android devices do support some other satellite-based systems such as IRNSS and QZSS. However, none of the devices reviewed showed the reception of SBAS satellites. Consequently, while the geodesic-grade receivers used as a reference allowed the coverage of almost all constellations and frequency bands, we limited our comparative analysis only to the signal available in the Android devices, for a fairer comparison.

Constellations in the results are named based on their RINEX code, as defined in [47]: G (GPS), R (GLONASS), E (Galileo), C (BeiDou), I (IRNSS) and J (QZSS). Similarly, frequencies and signals are simplified to L1 (∼1575.42 MHz) and L5 (∼1176.45 MHz). For comparison with the reference receiver, we extracted the following signals based on RINEX definition: L1 ⇒ (L1C, L1L), L5 ⇒ (L5Q, L2I, L5P, L5A).

To best assess the satellite’s visibility of the devices, we provide two types of graphs: the number of signals seen at each epoch w.r.t time, and bar graphs with the total amount of unique signals seen during the whole scenario. For the latter, we also add the total amount of signals seen by the reference receiver (the left bar) to compare against each device (the right bar). The bar graphs come in two variants: one per constellation and one per frequency. We also provide a summary table comparing the percentage of visible signals compared to the reference receiver.

5.3. Measurements

Four observations are used in GNSS positioning: pseudorange, carrier phase, Doppler shift, and SNR. The last two are provided straightforwardly in the GNSS event of the Android API; however, the pseudoranges and the carrier-phase data require some post-processing to be usable in a typical GNSS algorithm.

As described in [44], the pseudorange needs to be constructed based on the received and transmitted times given in the event. Several checks of the tracking state should be performed for each constellation to ensure correct measurements. In our analysis, we used the instructions provided by [44], but we only checked for adequate code lock and Time of Week (TOW) decoded. The carrier phases in Android devices are provided as “Accumulated Delta Ranges”, which correspond to the regular carrier-phase measurements multiplied by the wavelength of the GNSS signal, thus in meter units and not in cycle units.

For both the pseudoranges and the carrier phases, we performed a double time difference on the measurements, similarly to [10]. The double time difference allows for discarding the residual drift induced by the velocity changes, leaving only the acceleration changes which are assumed too small for both satellites and users in our study cases. It also reduces or cancels out some errors present in the GNSS measurements, such as atmospheric error or satellite orbit/clock error, as two consecutive measurements at a regular small rate (here 1 Hz) should be tainted by similar errors. Consequently, the error left can be assumed to be related mostly to the receiver tracking noise. While other papers have used different error estimations for measurements, such as the Code–Minus–Carrier combination [11,12], the double time difference method showed adequate results for a preliminary analysis. For Doppler measurements, only one time difference is needed as the measurement is already a velocity/rate estimation. For C/N0, it is more interesting to study its value range; thus, there is no difference in performance.

The results are provided as logged, with minimum filtering of the data for a more realistic analysis. However, to minimize the number of outliers and end up with biased statistics, we filtered some of the measurements based on a threshold, as a basic navigation filter would do. The threshold values were chosen empirically, based on the standard deviation and expected precision of each type of data. Consequently, the thresholds were set as follows: pseudorange ⇒ 300 m, Doppler ⇒ 30 m and phase ⇒ 30 m.

For each scenario, a statistic table for each GNSS measurement is provided, along with the percentage of measurements included/removed from the filter. For pseudoranges, Doppler and phase errors, we used box plot graphs to represent the different statistics. For Carrier-to-Noise ratio (C/N0), we choose to represent the data in “violin plots”, which are mostly similar to box plots but provide additional information on the data distribution. It is specifically interesting to study the L1/L5 differences and the range of CN0 values.

6. Results

In this section, we review each scenario and provide a first analysis of the data. We do not review in detail the content of each figure/table provided in the appendices, as they can be redundant for many scenarios. Instead, we summarize the observations from all scenarios in three sections related to positioning, visibility and measurement analysis, and only show the relevant figures within this section. A comprehensive summary of the performance metrics is available for each scenario in Appendix B (S1), Appendix C (S2), Appendix D (S3) and Appendix E (S4). For more details on the data, the results presented in this study are accessible in the Jupyter Notebook file available on MimirAnalyzer’s Github.

6.1. Positioning Analysis

All the devices showed signs of heavy filtering (e.g., Kalman Filter) inside their proprietary navigation algorithms. The locations provided by the GNSS chipset inside each Android device followed a stringent user dynamic, which allowed a very smooth trajectory. This heavy filtering is even more apparent during the static survey (S1). In Figure 5 and Figure 6, the GP7 and GPW seem to be converging around the static position, with a looser prediction model. However, other devices such as the ON2 and X11 report a constant position throughout the whole survey, which explains the very small standard deviation. This can probably be explained by a more highly constrained motion model based on user dynamic assessment performed by the receiver internally.

During the dynamic surveys, all the devices provided consistently good positioning with relatively small divergence from the ground truth and within each other. Certain discrepancies can, however, be found with the A52 device during S3 (Figure 7) and S4 (Figure 8), leading to wrong positioning before quickly re-converging to the actual user position. Yet, this was not seen during S2, with a much more challenging signal environment, making it hard to assess the actual cause for such drift in positioning.

6.2. Visibility Analysis

Overall, dual-frequency devices showed great visibility performances, capturing most of the signals compared to the receiver. In certain cases, some devices have even reported more satellites than the reference receiver. In these cases, the satellites were actually flagged as unhealthy and were not included by the reference receiver, contrary to the devices that included any measurement received in the log file. As the positioning solution presented here is computed by the device itself, not all the visible satellites in the raw data are likely to be used by the devices and this is a topic of future investigation; in any case, the effect on navigation should be minimal if not in a highly constrained environment.

The visibility analysis would benefit from additional comparisons that should be performed to compare the C/N0 levels against satellites’ elevation w.r.t. the reference receiver. Mono-frequency devices showed very good results in capturing the L1 frequency. Yet, given that all the major constellations today transmit L5 signals, it significantly reduces the amount the total amount of signals seen by the device. An interesting case is the GPW smartwatch, as it should integrate the same GNSS chipset as the GP7 smartphone, but did not show any dual-frequency measurements contrary to GP7. Nevertheless, comparing positioning results between GPW and GP7 showed similar results in all scenario cases.

The most remarkable result seen in smart devices is the capacity to alternate ON/OFF tracking of signals. It allows more signals to be tracked concurrently and optimizes power consumption. Concurrent tracking is not a new concept, as it was used in the very first GNSS receiver with limited hardware channel, and probably is still used today in other receivers. Yet, the effects are directly visible here in the measurements.

The downside of concurrent tracking is it results in many gaps in the measurements. To overcome this issue, one could perform interpolation of the measurements to have a regular rate, as the gaps are relatively short. In our processing, we did not perform any interpolation as it was not needed for our presented analysis. Advanced processing techniques, such as PPP, might indeed require adaptation to their algorithms to account for such measurement discrepancies and should be reviewed for future research.

6.3. Measurements Analysis

All measurement errors were found to be very consistent throughout all the scenarios, with higher noise during dynamic scenarios compared to the static ones. As mentioned before, measurements were filtered to avoid biases in statistics due to outliers. Yet, a more thorough analysis of these outliers would be interesting to better understand the resilience of devices in different environments. Moreover, Android provides a certain amount of flags on code and phase tracking quality, as well as multipath flags, directly within the API. These flags have not been used in this analysis but should be checked for more advanced positioning computations, as assessed in previous studies [48,49].

Pseudoranges errors from certain devices (i.e., ON2 and X11) appeared to have a much smaller dispersion. A possible explanation could be pseudorange smoothing using Doppler or phase measurements, as this technique is often used to reduce pseudorange noise [9].

Regarding Doppler measurements, a relatively small standard deviation was observed for GP7 and GPW, compared to the other devices. Both Doppler and phase measurements showed a tendency for a small positive, regardless of the devices. While the exact reason is not clear, it is believed to be due to the time-differencing operations performed to obtain the error measurements, as described in Section 5.3. Future research should review the effects on measurements, possibly using other techniques such as the Code–Minus–Carrier combination (see Section 5.3).

C/N0 comparison showed a distinct drop in their values between L1 and L5 tracking in all devices. Yet, L5 signals are designed with a higher minimum received power [50], which shows that smart device hardware is not optimized yet for the reception of this additional frequency. Further comparison between frequencies should be performed to further assess the impact on the measurement quality.

7. Discussion and Future Work

7.1. A Suitable Reference Definition

During the processing of dynamic surveys, we realized that the reference trajectory actually looked noisier than the one from the devices. The reference trajectory was computed in DGNSS baser/rover setup, as described in Section 3 and DGNSS computations were performed using the open-source software RTKlib. Even with DGNSS, the errors of the reference rise significantly in challenging environments, due to the limited number of satellites visible and multipath errors. Consequently, the statistics tables of position errors presented in the appendices need to be reviewed with this consideration in mind.

Nevertheless, we do not attribute such error to the receiver, but to the processing itself. As navigation algorithms inside Android devices are proprietary, it is difficult to assess the filtering algorithms and parameters. Consequently, simple DGNSS processing as performed in RTKlib is not sufficient and more advanced processing should probably be performed on the reference data to better assess the positioning capacities of each device. In our next research developments, we are planning to integrate the positioning processing (i.e., Kalman Filter) within the MimirAnalyser software to improve the reference trajectory processing.

Moreover, the dataset would benefit from an INS coupled with the reference receiver setup. It would enable better processing for the reference trajectory, and the INS measurements could be compared against the INS recordings from the smart devices. However, INS methods require alignments of the different devices’ frames, which could prove challenging. It is the main reason why using a combined GNSS/INS solution for the reference trajectories was left out of this analysis. Future work should look into the feasibility of enhancing the reference trajectories with INS measurements.

7.2. The Android Platform for Research

Sensor logging and measurement quality assessment on Android come with a set of challenges. During our research, we discovered that while there are numerous apps existing today for sensor logging, there were none suitable to log every sensor available on smartphones/smartwatches. Apps related to GNSS logging (e.g., GNSSlogger) only concentrate on motion-related sensors and do not allow customization on the sensor parameters. Therefore, we had to develop a new application to fit our research needs, which required a certain knowledge of Android development. As this app is open-source, it can be re-used and enhanced by the research community to be used in new applications. Alternatively, the dataset produced through this research can be used as also provided under open-source license.

While the Android platform is not easy to access, it does allow common and easy access to raw measurements from sensors, which would require heavier hardware developments otherwise. Power management inside the device can prove challenging, as the system itself might perform automatic duty-cycling strategies which can impact sensor logging, which can be even trickier on smartwatches. An easy workaround for Mimir was to prevent screen lock and keep the app awake to avoid duty-cycling by the system. Yet, the assessment of power consumption is part of the future work for this research to review the impact of advanced positioning techniques on the battery life of a device.

Regarding the smartwatch, developments have proven to be quite similar to the smartphone case. The common API made the development of a common Android library possible, avoiding the need for redundant code developments specific to each platform. Data extraction was, however, a bit more challenging, as the smartwatch did not have any USB port. Consequently, the data had to be extracted through WiFi and with the help of the Android development software. Future developments on the Mimir app will try to improve the interactivity between smartphone and smartwatch so that the data can be uploaded through a companion phone first before being extracted by USB.

While the smartwatch offers a new playground for health-related sensors, they have not been reviewed here as outside the scope of this study. It has to be noted, however, that extraction of these sensor data is implemented in the Mimir app, and future research will also focus on reviewing their quality. As smartwatches can be very interesting for long-term study of patients, focus will be given on enhancing the energy-consumption of the app for extending the battery-life of the device.

7.3. Android Devices and Scenario Impact

Analysis of a different scenario showed a clear impact on the measurements and positioning quality. S2 was expected to give the largest errors, given the challenging nature of the dense urban canyoning. Yet, the scenario that registered the highest errors is S3. While it also contained challenging sections, the highest error values could be due to the longer survey time, which increases the probability of erroneous measurements in the dataset. Despite the increase in measurement noises, the positioning results stayed consistent for all devices throughout all scenarios and regardless of the device platform (i.e., smartphone/smartwatch). This supports our hypothesis of using smartwatches for research applications in positioning, and possibly other topics (e.g., health applications).

Devices have shown clear positioning abilities to maintain a suitable positioning solution throughout the scenarios, yet with challenges for some devices (see Section 7.4). These discrepancies can partially be explained due to the environment and possible unaccounted multipath, yet would require a deeper analysis to better understand their exact origin. While we focus mainly on the outdoors for this study due to GNSS positioning, the additional indoor scenarios would be interesting to review in a future analysis. More specifically, the transition from outdoor to indoor and/or light indoor environment (e.g., glass ceiling) would be beneficial to assess the sensitivity of the antenna/receiver embedded in smart devices.

Similarly, future research should provide deeper attention to the carry mode effects on the device measurements. While we only performed acquisition texting and pocket mode, new modes like swinging should be considered, especially for the smartwatch review.

7.4. Positioning with Smart Devices

In the results presented, we have seen that all smart devices showed reliability in providing a precise positioning regardless of the environment. While an increase in measurement noise could be seen in more challenging environments, such as S2, the devices maintained a suitable positioning accuracy. This is also the case for C/N0 values, which remained at a similar level throughout the surveys and do not seem to be a real determining factor in this case for positioning precision.

Yet, a comparison of the raw measurement errors between the devices showed large differences from one device to another. With more advanced positioning techniques, this needs to be taken into account, as not all devices might be capable of performing similarly. The most evident discrepancies in measurements seen in our analyses were access to dual-frequency measurements, retrieval of carrier-phase measurements and pseudorange smoothing. Moreover, GP7 and PGW provided interesting comparison points as they had the same GNSS chipset model embedded, which showed that the platform has an impact on the measurements as well. The clearest example is the absence of L5 signals on the GPW.

Another limiting factor in Android devices remains the missing characterizations of the hardware, such as the antenna used for reception of GNSS signal, as already pointed out in [11]. While access to antenna information has been added in the Android API, the information provided by the manufacturer is slim or non-existent. For advanced positioning processing, one has to rely on self-characterization of the hardware.

A similar conclusion can be drawn for INS-related sensors, such as accelerometers and gyroscopes. They have not been reviewed in the analysis even though they are present in the dataset, as we preferred to focus on GNSS capacities, but will be part of the future analysis.

8. Conclusions

In this paper, we presented a new open-source dataset for research on advanced positioning using Android smart devices, with a first review of and the first app for GNSS raw data on a smartwatch platform. We detailed our methodology for creating the dataset by describing the logging software development, the protocol definition and file structure in detail. We also provided a first analysis of the results by comparing five devices (four Android smartphones and a smartwatch) in terms of several performance metrics. It is to be reminded that the paper’s focus and main novelty has been to introduce the methodology of the acquisition protocol and the new open-access app and datasets. The results are just examples of what can be achieved with the developed open-access tools, but they do not provide a comprehensive selection of performance metrics; for example, algorithms for user positioning starting from the acquired raw data are still to be implemented and the multi-system multi-frequency GNSS analysis is still a topic for future research. Nevertheless, our results have shown that GNSS raw data collected from mass-market devices is of good quality, with similar results between the smartwatch and smartphones. This strengthens the possibility of using smartwatch sensor data for broader research topics. It can enable significant research in the area, provided that suitable acquisition and processing tools are made available to the research community, such as our developed software “Mimir”. Last but not least, we have also reviewed the current challenges associated with Android data processing and highlighted the potential research opportunities for the continuity of this work.