## 2 Materials and Methods
### Experimental Protocol
#### 2.3.5 Data Curation and Analysis  
Each MetaMotionR+ device streams to the smartphone time-stamped, accelerometry values for the X, Y, and Z axes in gravitational units (1 g = 9.8 m/s\({}^{2}\)); these data are accumulated into a data file throughout each day of data collection. During IRF use, the system also creates a file with time-stamped events indicating when vibrotactile cues are delivered by the MetaMotionR+ devices; no cues are provided during the at-home phase of the study. Data files are stored locally on the smartphone and are also uploaded automatically (without user intervention) to a HIPAA-compliant online storage site at the end of each day of study participation. We used the time-stamped accelerometry data from the two wrist-worn MetaMotionR+ devices to compute two primary outcome variables pertaining to patient compliance with study procedures; these two factors are important determinants of the practical feasibility of using the _Souvenir_ system to encourage therapeutic activity after stroke. We defined system wear time as the overall amount of time each day that the patient wore the two MetaMotionR+ devices while maintaining proximity to the smartphone such that the Bluetooth wireless connections were maintained. Specifically, to compute system wear time, we analyzed the two MetaMotionR+ accelerometer data files for gaps between successive data points greater than or equal to 60 s duration. We reported system wear time as the percentage of the intended 8 h daily wear time without a data gap in either wrist device. We regarded system wear time as a measure of compliance to protocol, with compliance reported as the summation of all instances with less than 60 s of consecutive missing data divided by the total monitoring time (multiplied by 100 to yield a percentage). We computed the activity cue response rate by determining the number of cue indicators eliciting a significant activity response. As described previously [27], several post-processing steps were needed to compute the activity cue response rate. We used the data timestamps to synchronize and resample the two sets of MetaMotionR+ accelerometer data and the system cue event timestamps to yield a synchronous and simultaneously sampled bilateral motion dataset. The resulting accelerometry values along each axis were filtered using a bandpass window of 0.25 Hz to 2.5 Hz (MATLAB function bandpass); this window was chosen to be similar to windows used by [PERSON] et al. 2014 to filter out the static effect of gravity as well as other sources of extraneous motion or noise [44]. Using these filtered data, we calculated the magnitude of acceleration measured at each wrist using the Euclidean norm. Acceleration magnitudes were then summed within each 1 s epoch to yield a time series of each arm's acceleration magnitude for every second of monitoring throughout the day. We then transformed the acceleration magnitude values into an intermediate variable called activity counts using a thresholding approach [27] similar to those described by [PERSON] et al. (2014) [44] and [PERSON] et al. (2013) [45; 46]. We computed activity cue response rate by counting the number of vibrotactile cues immediately followed (within 5 s) by a period of arm activity greater than or equal to 1 s and then dividing that sum by the actual number of cues provided. Data processing of activity monitoring data and compliance calculations was completed using the MATLAB computing environment (version R2021a; the MathWorks, Inc., Natick, MA, USA). Finally, we computed three primary outcome variables pertaining to subjective user experiences using the SUS, IMI, and QUEST surveys. Survey scores were computed using each survey's standard scoring method. Specifically for the SUS, negatively worded items were subtracted from the maximum scale value of 5 before summing all items. The sum of all ten item scores was multiplied by 2.5 to give an overall score ranging from 0 to 100; a value of 68 is considered the cut-off threshold for possible usability [38].