CaReflect, a visualization and management software, was created in re- sponse to the requests in the first study. The developed CaReflect sensor- management software can configure, start, and stop sensors. When a sensor is stopped, recorded data are downloaded automatically and stored in a database. A variety of visualizations facilitate the inspection of the data according to requests from end-users. Figure 6.11 depicts the final system as it was used in the studies that are reported in Section 6.5. The
USB SimpliciTI C1101 Proximity sensors CaReflect
Figure 6.11: CaReflect suitcase with sensors and management laptop suitcase contains all required components to conduct a study. The laptop starts with the CaReflect software that uses the CC1101 USB access point to communicate with the sensors. The system could be used without additional equipment. The used USB access point comes with the Chronos watch. A custom firmware has been installed to communicate with multiple sensors simultaneously using the SimpliciTI protocol [167] that was part of the pre-installed Chronos and access point firmware.
6.4.1 Architecture
The CaReflect manager is a Java-based software that consists of five major components that work together to realize the required functionality. The components and their interaction are depicted in Figure 6.12. TheStudy
GUI is the visible part of the application. It is a full screen application
Sensor Interface Proximity Library
Study GUI
Visualizations
Study Management
Figure 6.12: CaReflect architecture
create accounts, take sensors at the beginning of the shift, and return them after the shift. All activities can be performed with two or three clicks. However, users must sign in to take a sensor and again later to review their data.
The Study Manager monitors which sensors are available and their status (e.g., if they are already assigned to a carer or resident). It is controlled by theStudy GUI and communicates with the sensors using the Sensor Interface to check and change the status of sensors as well as reading proximity data. Data are stored using theProximity Library, with special attention to the arising privacy aspects of working with such sensitive data. Finally, the analysis and visualization component provides the tools to draw charts and browse through the collected data.
6.4.2 Sensor Interface
The Sensor Interface communicates with the sensors by using the Java Native Interface (JNI). The interface to the proximity sensors is based on the CC1101 USB wireless interface. The CC1101 acts as SimpliciTI access point. Sensors request a connection and receive a channel ID to be addressed later on. After sensors are assigned a channel ID, they will start polling for new commands in 500ms intervals. Supported commands are reconfiguration commands or a request to read the current configuration of the sensor. The original firmware supported only one connection to a single sensor at a time. The access point firmware was extended to support
up to 10 sensors at the same time. More sensors and corresponding channel IDs could not be stored because of memory limitations. Sensors still connect in regular intervals, but an independent command queue is maintained for each sensor. The command protocol of the USB interface was analyzed and re-implemented as a new C++ driver to communicate with the access point based on a serial interface. The main difference from the original driver is the possibility to specify the sensor that should receive the send command. The driver was packaged as a dynamic-link library (DLL) and made available to the Java application by using the JNI. The communication between sensor and access points follows strict timing rules. The access point has to react within milliseconds to prevent a timeout. If other sensors attempt to connect at the same time, the connection is reset and a send command is ignored. As stated above, the transmission of commands to the sensors is error prone. A growing number of sensors in the receiving distance of the access point increase the likelihood of a packet collision and a transmission error. Therefore, every command that does not result in an immediate response, such as a reconfiguration command, is wrapped into read commands to ensure that the new values are correctly set. Furthermore, connected sensors were extended with a new sleep command that increases the poll interval to 10 seconds. As a result, sensors in sleep state are slower to react to commands, but collisions can be reduced.
Reading of data does not follow the poll-command pattern described above. The download state is started by a dedicated download command. The sensor starts to send packets in shorts bursts and does not expect a reply. The sensor DLL has to read the receive buffer continuously to prevent data loss. Transmissions of other sensors may lead to lost packages as well. If more than 80 percent of the packets within a burst are missing, the burst is completely restarted. If fewer packets are missing, these packets are requested by requesting only the missing packets. However, these single packets are not transmitted in burst mode.
6.4.3 Data Storage and Visualization
Data storage was implemented in a separate library,Proximity Library, to hide implementation details. The library contains not only functionality to read and write data, but optimized methods for often-used queries. For
example, the question of which users have been in contact with a specified sensor at a specified time can be implemented in a more efficient manner if the specified time and sensor can be used directly to filter the data. Otherwise, a large number of objects has to be created in memory to filter them in code later on. Supported storage formats include MySQL, HSQL, and a file-oriented format based on Unisens [142].
The analysis component shown in Figure 6.13 builds on the supported queries of the Proximity Library to show visualizations that aim at trigger- ing and facilitating reflection. Three types of visualizations are supported: timelines, pie charts, and bar graphs. Timelines aim at reconstructing the work process in chronological order to facilitate recollection of specific timespans. Pie charts were requested by care staff because carers can see how they spent their time at a glance. Bar charts are available for in-depth comparison (e.g., how much attention was overall provided to each resident). Although carers can use the visualization component to create all three kinds of graphs for different kinds of data, the system uses a small subset of the graphs by default. Carers requested that a pie chart
Figure 6.13: CaReflect user interface: visualizations of all care activi- ties during one day
provide a brief overview of their day before any other graphs are shown. Carers can analyze the data in detail by showing a timeline of the day. Bar charts are used only to compare documentation effort or the overall time spent with residents by all carers.