Smartphone‑based indoor positioning research demands high‑quality, time‑synchronized sensor streams under diverse environmental and hardware conditions, yet many researchers face challenges in their data collection campaigns owing to device heterogeneity, sampling inconsistency, consent management, and privacy compliance. We introduce Studies, a fully managed, end‑to‑end Software as a Service (SaaS) framework built on top of the popular Sensor Logger app (iOS, Android, WatchOS, WearOS). Studies formalizes roles for investigators and participants, automates sensor configuration distribution across platforms, orchestrates data capture, and integrates built‑in consent and customizable questionnaires. Sensor Logger and Studies have already supported numerous research eforts presented at previous IPIN conferences, including pedestrian trajectory reconstruction via bidirectional Kalman filtering [ 1] and magnetometer calibration during SLAM [2]. In this paper, we present the system architecture, cross-platform implementation, managed workflows, and real-world case studies, demonstrating how Studies enables researchers to collect the right data at the right time-while ensuring participant privacy and data consistency.
Indoor positioning research relies on rich, multi‑sensor datasets to achieve high accuracy in complex
environments. However, researchers frequently encounter challenges including device heterogeneity
and sampling variation [
In Section 2, we first outline the key challenges researchers face in data collection campaigns. In Section 3, we review some existing solutions for data logging in research context. Section 4 introduces the Sensor Logger app, and from there we dive into the Studies architecture in Section 5 to demonstrate how it helps reduce friction for researchers. Finally, in Section 6, we showcase how Studies have been used in practice across academia already.
Collecting reliable, large‐scale smartphone sensor data involves overcoming numerous technical,
logistical, and ethical hurdles. Prior tools lack scalable, integrated workflows for crowd-sourced sensor
data collection with privacy control [
Smartphones difer widely in sensor quality, sampling APIs, and coordinates / units definitions, leading
to non‐uniform data that undermines reproducibility and comparability, especially in large-scale studies
[
Many data collection campaigns involve custom sensing logic – whether it is geo-fencing or rules based on time of day or day of week. Incorporating custom sensing logic often necessitates bespoke application development, increasing the technical burden on research teams.
Crowd-sourced studies often rely on ad-hoc uploads to Google Drive folders or Dropbox links,
burdening participants with manual steps [
Smartphone sensor streams (GPS, microphone, Bluetooth) can reveal sensitive personal behaviors,
creating high privacy risks [
While raw sensor data (e.g., accelerometer, magnetometer, GPS) captures physical phenomena, it often
lacks essential contextual information such as user intent, environmental conditions, or semantic labels.
These are often critical to researchers. To address this, many frequently supplement sensor streams with
participant-reported data via additional surveys, daily diaries, or momentary assessments. However,
most resort to separate tools like Google Forms or Qualtrics to administer surveys [
A number of mobile sensing platforms have been developed to facilitate research using smartphone and wearable data. We briefly review representative examples and highlighting potential shortfalls with respect to challenges outlined in the previous section.
The AWARE Framework [
RADAR-base [
The Beiwe Research Platform [
Other toolkits such as SensingKit [
GetSensorData is an Android-based sensor acquisition tool used in the IPIN community, particularly
for competition datasets [
Sensor Logger is a free, versatile, cross-platform mobile application designed to simplify sensor logging from smartphones, tablets, and wearables. As shown in Figure 1, it supports a comprehensive array of on-device sensors—including accelerometers, gyroscopes, magnetometers, barometers, GPS, audio, and camera streams—as well as device metadata such as battery level, network state, and screen brightness. Of note to the IPIN community is support for WiFi and Bluetooth beacons.
The Studies sub-system is designed to tackle the challenges of running data collection campaigns as outlined in Section 2. Figure 2 shows the outline of the Studies system, which will be explained below.
The corner stone of Studies is the participant-investigator model. In this context, researchers play the role of an Investigator, and Participants contribute data to the research. All parties use the same Sensor Logger app on their respective smartphone throughout the life-cycle of a Study.
As shown in step (A) of figure 2, investigators begin by defining a Study directly within the Sensor Logger app, controlling exactly how and what data should be collected. Each Study configuration includes the following: • Defined Sensor Suite: Accelerometer, gyroscope, magnetometer, barometer, GPS, audio, camera, microphone, Bluetooth beacons, Wi‑Fi and any custom sensor decoder plugins. • Defined Sampling Rules: sampling frequencies, time based or geo-fence/location based conditional recording, sensor based triggers. Investigators can test out these rules on their own device and iterate until satisfaction. • Export Formats: JSON, CSV, Excel, KML, SQLite etc that suits the researcher’s downstream analysis scripts. • Metadata & Privacy: privacy statements, approved consent text, contact details. To help investigators, templates are provided as part of the creation workflow. • Contextual Questionnaire: Study-specific questionnaire templates (text, numeric, multiple-choice, signature fields), which can be shown on joining a study and on the ending of each recording session. See figure ?? in the appendix.
The investigator submits this Study configuration to a remote server, also known as Sensor Logger Cloud, as shown in step (B) of figure 2. A backend then validates the Study configuration to ensure integrity and compliance. Thereafter, a single source of truth defining what and how data should be collected exists in the cloud.
Once a Study is created, a simple QR code (or link) is generated, shown as step (C) and (D) of figure 2. This QR code points to the aforementioned created Study. Participants can then enroll seamlessly by simply scanning with their own phones. To ensure privacy compliance, all participants can first preview exactly what they will be collecting on behalf of the Study investigator before joining. Depending on the Study configuration, participants will be asked to complete a consent form before joining. Once joined, shown as step (E) of figure 2, each participant automatically receives the exact configuration as defined in the previous section, regardless of platform. They can also join, pause, or switch studies in-app, filter recordings by study, and remain anonymous by design. It is also noted that once joined, the participant’s devices do not require further internet connection until they are ready to share their recordings back with the investigator – this is important for participants with limited cellular data.
Since participants may use a variety of recording devices, the raw data collected can difer in units and
coordinate systems. For example, as shown in Figure 3, Android’s SensorManager and iOS’s Core Motion
define coordinate systems for acceleration data in opposite directions. In particular, note that iOS does
not follow the standard right-handed coordinate system due to legacy reasons. Additionally, Android
and iOS apply diferent strategies for location fusion, each making distinct trade-ofs between
networkbased and GNSS-based positioning. Studies employs a unified standardization mechanism to resolve
these inconsistencies. This standardization process (Step F in Figure 2) is performed automatically in
the background and requires no configuration or understanding from participants. Standardization
includes:
• Unit Normalization: Converts all measurements to SI units (m, m/s2, rad/s, T, hPa); GPS
coordinates in decimal degrees.
• Coordinate System Alignment: Unified definition of x, y and z coordinate systems for all
vector-valued sensor readings.
• Absolute Reference Frames: All GPS and fused location data are aligned to the WGS84 geodetic
reference system.
• Timestamp Synchronization: To resolve misalignment across sensors (e.g., gyroscope vs. GPS)
caused by internal platform scheduling jitter or bufer diferences, Studies interpolates or aligns
samples to the nearest common sampling grid as defined by the investigator. All timestamps are
referenced to UNIX epoch in milliseconds and are corrected for known device clock skew where
possible.
• Metadata Standards: For traceability and reproducibility, all exported data is bundled with
device identifiers (model, manufacturer, OS version), sensor vendor details, and platform-specific
lfags (e.g., fused vs. raw GNSS, estimated accuracy).
• BLE Decoding: A core component of Sensor Logger is its open-source initiative to provide a
unified interface for Bluetooth Low Energy (BLE) data acquisition and decoding. BLE plays a
crucial role in indoor positioning due to its widespread availability and fine-grained proximity
sensing capabilities. However, BLE data collection varies significantly between platforms, with
diferences in scanning APIs, advertisement formats, and signal reporting. Studies fully leverages
this unified BLE interface to ensure consistent decoding [
For reproducibility, all transformations performed as part of the Standardization are documented in
detail in [
With a single tap, participants can upload their recordings securely to Sensor Logger Cloud, via an encrypted connection (Step (G) of figure 2). The backend infrastructure is hosted on industry-grade providers such as Cloudflare and Backblaze, ofering distributed object storage with configurable redundancy, automatic deduplication, and secure TLS channels for data in transit and at rest. Data is stored in the cloud as per a configured data retention policy. During this period, the investigator can download all contributed recordings securely from a web portal or via an API as shown in step (H) of figure 2. Throughout the Study life cycle, the investigator can monitor the progress of the Study through the app (Step (G) of figure 2) – such as how many participants have enrolled and how many recordings have been uploaded.
While the current implementation emphasizes asynchronous, privacy-first uploads to preserve participant control and minimize cellular data usage, Studies has been designed with real-time streaming capabilities in mind. Preliminary internal testing supports low-latency MQTT-based data relay for scenarios requiring continuous monitoring (e.g., infrastructure-aware SLAM, live mobility tracking).
To facilitate downstream data analysis, Studies exports sensor data in widely-used formats including
JSON, CSV, Excel, KML, and SQLite. Recognizing the importance of easy data ingestion for researchers,
we provide open-source parsing libraries and example scripts compatible with popular scientific
computing environments. For Python users, a repository is available on GitHub [
The principle of Studies is Software as a Service (SaaS). In this paradigm, researchers don’t configure and
manage storage, data transfer and communication infrastructure with participants. Researchers simply
declare a study, and pay for the resources (such as storage) they consume [
Studies has been adopted by leading institutions (MIT Media Lab, ETH Zurich Robotics Systems Lab,
KU Leuven, University of Duisburg‑Essen, University of Cambridge) for applications including:
• Pedestrian trajectory reconstruction with bidirectional Kalman filters [
• Agricultural incident detection via multi-sensor wearables [
We present Studies as a comprehensive, privacy‑first service that automates end‑to‑end sensor data collection for indoor positioning research. The benefits of Studies compared to typical manual workflow for researchers are summarized in table 7. By formalizing roles, standardizing configurations, and ofering dynamic scalability, Studies accelerates reproducible experiments. Future work includes extending Studies to real-time streaming contributions, and even more throughout cross-platform harmonization, such as unified sensor fusion algorithms. Anyone can try Studies for free in the Sensor Logger app. Learn more at https://www.tszheichoi.com/studies. Typical Manual Workflow Studies Workflow Researcher writes custom scripts or apps per de- Investigator declares study parameters in single vice/OS. app.
Create separate consent forms on external plat- In-app consent flows and questionnaires embedded forms (e.g., Google Forms, Qualtrics). in the study configuration.
Participants install and configure manually. One-tap enrollment via QR code or short link applies exact configuration.
Participants record data manually; start/stop re- Automated background recording with smart rules minders require manual follow-up. (time, geofence, motion) and on-device reminders. Participants upload files via email, Google Drive, One-tap, encrypted uploads to cloud; automated or custom S3 scripts. retry and reminder logic.
Researcher merges, cleans, and standardizes het- Data delivered in normalized, SI-unit JSON/CSV; erogeneous exports ofline. metadata and transformations documented automatically.
Maintain custom server infrastructure or ad-hoc Fully managed SaaS backend with dynamic scaling, storage buckets. SLAs, and REST/MQTT APIs.
The author has not employed any Generative AI tools.