1.1 Introduction

In the social sciences (e.g., [6, 5]) and health sciences (e.g., [3, 8]), consumer smartwatches are often used to measure human activity levels or movement. These smartwatches are typically chosen because of their convenience: they are affordable, small, and have a plethora of sensors built-in. The collected wearable sensor data can be used, for example, to design better urban infrastructure [7], to monitor patients [1], or to assess the effect of lifestyle behavior on long-term health outcomes [4].

Recording raw sensor data from smartwatches often poses a problem to researchers though, especially when working with consumer-grade devices. While they are usually cheaper than research devices, consumer-grade devices often offer a more closed environment and record data that is already aggregated or otherwise processed (e.g., by applying some unknown form of activity recognition). Depending on the brand, researchers can opt for paying external providers to aggregate and download data from them or to use a limited set of data points that is made accessible to consumers [3]. In practice, however, researchers usually require complete access to the raw data while cloud services are not an option due to privacy reasons.

To address these needs, we present WEARDA, the open-source WEARable sensor Data Acquisition software package that is primarily aimed at researchers who require transparency, full control, and access to raw sensor data. By running as an app on a smartwatch, WEARDA allows the recording of raw sensor data from a consumer smartwatch bypassing cloud-based or third-party privacy-sensitive services. The software can be used with Samsung smartwatches running the Tizen operating system³ and can record and access raw data from the tri-axis accelerometer, tri-axis gyroscope, barometer, and GPS sensors. While WEARDA was originally developed for real-life data collection, it can also be used to collect data in controlled settings. We chose a Samsung smartwatch⁴ running the Tizen OS because of 1) the required functionalities of the smartwatch software API, e.g., the possibility to read the raw sensor data and write this to local storage; 2) the availability of embedded software development tools and accessible documentation; 3) having the required sensors for human activity monitoring and localization, and 4) requirements on case design for acceptance by the target user group of the project the software was initially developed for, i.e., people with dementia.

Collecting activity data on human subjects—either in real life or in a controlled laboratory environment—is a difficult and error-prone task. Without a thought-out process supported by the software, problems can occur during all three main phases of the data collection, i.e., preparation, the actual measurement, and data logistics. Besides the practical challenges in these three phases, privacy preservation and reproducibility are two additional areas of attention. Table 1 gives an overview of how WEARDA addresses these five practical challenges; this is described in more detail in Section 2.1.

1.2 Data collection using WEARDA

By addressing the practical challenges as shown in Table 1, WEARDA aims to make it as simple as possible to smoothly prepare for data collection, then robustly collect sensor data while preserving privacy, and finally upload the data to an on-site laptop. The workflow of using the software can be summarised as follows.

The first step is to create a configuration file with the desired settings, upload this to all watches that will be used in the study, and check and test all watches (preparation phase). Once on site, the researcher activates each watch using the WEARDA sensor app: remove all previously collected data, enter a person-id, start the measurement, and then let the subject wear the watch on their wrist (measurement phase). Once the data collection is complete, a laptop is used to copy the data from each watch to a folder, first sorted by person-id, and after that by date time (data logistics phase).

The following section describes the implementation and architecture of the WEARDA software. It is followed by a section regarding the quality control of the package, where several tests and techniques are provided to ensure the high quality of the delivered software. In the availability section, details on the WEARDA software system requirements and dependencies are given, as well as information on how to obtain the software. The last section describes the software reuse potential and provides an overview of how to configure and run WEARDA on a Samsung watch.

2.1 The five practical challenges

The first practical challenge is the efficient and errorless preparation and configuration of smartwatches. We, therefore, chose a configuration file that can be prepared beforehand and can easily be uploaded onto the watches while they are charged before the measurements take place.

The second practical challenge is efficient and errorless measurement execution. The WEARDA software collects data in the background, invisible to the subject, and it cannot be stopped to prevent unintended interventions by the subject or researcher. The stored measurements on the watch can be copied to a standalone laptop wireless, and later removed, with Tizen software running on this laptop. We chose the digital spinner wheel widget that shows only possible id’s while swiping (errorless entry) as opposed to a free format data entry.

The third practical challenge of data collection is efficient and errorless logistics. The measurements are linked to a unique identifier of the watch and are accompanied by the (corrected) configuration settings used by that particular watch. The WEARDA software replaces invalid configuration settings by default values: it will not block the start of the measurements, nor produce error messages, if errors are detected in the original configuration settings. With this correction mechanism, the researcher will not be confronted with the absence of measurements later, after intensive data collection efforts on site. We chose this correction error handling because giving notice of warning or errors could confuse subjects and researchers.

The fourth practical challenge is the preservation of privacy. We used the GPS geo-fencing API of Tizen OS by configuring a privacy circle as geofence around the area where the data collection takes place. All data collected outside of this circle are marked in the data file, but still recorded and can easily be removed in a post-processing step. For our use case, data integrity out-weight privacy concerns and we opted for gathering all data. Other use cases might require data to not only be marked but deleted before downloading. This would require additional development of the software.

The fifth practical challenge is to take measures for the reproducibility of the data collection. The configuration file does not only ease the process of setting up watches for data collection; it also helps to make the data collection reproducible for others by making data collection choices transparent and traceable.

The technical descriptions of the ‘Sensor application’ and ‘Sensor service’ components, in the next two subsections, indicate which software functions are included to address the practical challenges. This is indicated between brackets, as [x,P] – preparation, [x,M] – measurement, [x,L] – logistics, [x,Pr] – privacy, and [x,R] – reproducibility, where x represents the software function listed in Table 1.

2.2 Sensor application

The software package contains the Tizen OS widget application “liacs.sensorapplication”, visible in the list of applications with the title “Sensors” and a digital brain as the icon shown in Figure 1.

2.3 Sensor service

The software package contains a Tizen OS widget service, “liacs.sensorservice”, which runs in the background, neither visible in the list of applications nor visible via the display of the watch. This design makes continuous measurements possible since Tizen applications become idle after a brief time to reduce the power consumption of the display, while services only become idle if the battery is (almost) empty [10,M].

Processing messages

The sensor service processes the messages RESTART and CLEAN sent by the sensor application. After switching on the smartwatch, the sensor service is activated and waiting for these messages. After one valid message is received, the service starts the recording of the sensor values and stores it in comma-separated values files. The measurement is based on the contents of the uploaded configuration file. Each RESTART message will reload the configuration file found in its upload folder. This allows the researcher to change the configuration of watches while the measurement is still running [19,M].

Figure 2 shows a state diagram with transitions with the format “event – actions”, as a formal description of the states, and relevant state events between the watch application manager, the sensor application, and the service.

Figure 2 

State diagram of sensor application (green), sensor service (orange), and the Tizen OS (grey).

Acceleration and Gyroscope

We conducted a spinning test — watch rotating on its Gorilla glass, decelerating in rotation speed – to test the main flow of WEARDA producing the expected raw data files following the configured settings, and validate the values of the (linear) acceleration and gyroscope sensors by inspecting the expected values along time, see Figures 3, 4 and 5. The sensors are positioned a bit outside of the center of the watch.

Gyroscope and accelerometer

The gyroscope values showed a decreasing trend on two of its axes, the gravity acceleration axis showed ax = 0, ay = 1.2 m/s², az = 9.81 m/s². The linear acceleration was not valid for high rotation velocities but showed promising values after 32 seconds. The linear acceleration is derived from the gravity acceleration with an algorithm used by Samsung.

Baseline measurements

Zero measurements or baseline measurements showed that the standard deviation of the gravitational acceleration $G=\sqrt{(a{x}^2+a{y}^2+a{z}^2)}$M1 \documentclass[10pt]{article} \usepackage{wasysym} \usepackage[substack]{amsmath} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage[mathscr]{eucal} \usepackage{mathrsfs} \usepackage{pmc} \usepackage[Euler]{upgreek} \pagestyle{empty} \oddsidemargin -1.0in \begin{document} \[G = \sqrt {(a{x^2} + a{y^2} + a{z^2})}\] \end{document} ranges between 0.02 – 0.036 m/s². Its average G ranges between 9.6 – 10.2 m/s². Further, the average gravitational acceleration G was dependent on the spatial orientation or spatial positioning of the watch compared to the direction of the gravitational force or orientation of the surface of the ground as well.

Barometer and GPS

The barometer and GPS were validated by comparing the height differences of a GPS track with the air pressure measured.⁵ An air pressure difference of 1 millibar (hPa) corresponded to 7.75 meters at sea level, temperature 10 degrees Celsius. The accuracy of the barometer is roughly 0.01 millibar (0.075 meters).

Different timestamp bias and irregular sampling rate

We noticed that the Tizen OS API is producing different biased time stamps per sensor type. On top of that, the sampling time appears to be irregular.

We implemented a writing timer that writes all sensor values known at a certain moment, to one or more sensor files, to overcome these two problems. As a consequence, identical values can be written if the write timer interval is shorter than a sensor-specific readout interval. Therefore identical values are not written to the files. One could argue that a sensor value could be identical to its previous value. However, because of noise influences on the values, this probability is very low.

In case the sensor readout interval is shorter than the write timer interval, changing sensor values could be missed. We choose to write only the last available values.

Writer and sensor intervals, and sample density

The best intervals of the writer timer and the sensor readouts are listed in Table 3. The table also contains the realized sample density which is defined as the ratio between recorded samples divided by the expected number of samples. A sample density of 1 is ideal; if it is lower than 1 the effective sample frequency is lower than the configured one; if it is larger than 1 the effective sample frequency is higher than the configured one.

Operating system

Tizen OS developed by Samsung based on Linux OS, version 2.3.1:13

Programming language

C-programming language, Tizen API version 2.3.1:13

Additional system requirements

The software needs some disk space to store the data collected. Typical for 7 days of data collection, 12 hours a day, 50 Hz sample frequency 500 MB will be sufficient.

Dependencies

None

List of contributors

Richard van Dijk, research software engineer of the LIACS Software Lab was the only developer of the software package and wrote most of the paper. The software was tested, refined functionally, and used in practice by Daniela Gawehns. Daniela Gawehns and Matthijs van Leeuwen contributed to the writing of this paper in a number of iterations and made contributions to the interpretation of the collected data for the work.

Software location

Language

The language of repository, documentation, software and supporting files, are all in English.

An example of use

WEARDA was successfully used to collect data at a nursing home in the Netherlands. Researchers wanted to assess how changes in care management affected residents’ daily life and activity levels. The main focus was to find out how the new park surrounding the nursing home was used by residents. Therefore it was necessary to not only measure acceleration but also to record GPS trajectories to see if and how residents used the new park.

Researchers recorded activity (with accelerometers and gyroscope) and displacement (GPS traces) on five consecutive days. During the first two days, all participants were given watches configured to record sensor data as well as GPS data. On the remaining three days, only residents who have left the building during the first two days wore a watch with GPS recording. This reduced the need to switch wearables during lunchtime and recharge them as the continuous GPS recording needed a lot of battery power.