Sleep Detection
Sleep detection happen offline, on the watch. This is great for privacy! If you decide to export your data over email, a separate analysis is done on the server - and, if you export to a different service, they may do their own analysis! Like csv data, I do not store the analysis on the server.
Using a well-published wrist actigraphy algorithm:
Di = P(W-4*Ai-4 + W-3*Ai-3 + ... + W0*Ai + ... + W2*Ai+2)
Where An is the activity measurement for that minute (maximum accelerometer value in that minute, in the default case for Smart Alarm), Wn is a weight for that activity measurement, P is an overall scale factor, and Dn is a discriminant value for the nth minute. Dn >= 1 is taken as wakefulness in that minute, and Dn < 1 is sleep.
The factors used, at the time of writing, were taken from this study on wrist-based actigraphs and are:
| Factor | P | W-4 | W-3 | W-2 | W-1 | W0 | W1 | W2 |
|---|---|---|---|---|---|---|---|---|
| Value | 0.001 | 106 | 54 | 58 | 76 | 230 | 74 | 67 |
In addition, at the time of writing, accelerometer values are 'clipped' to 300, such that any value over 300 is put in to the equation as 300. This helps reduce the skew from overly large values, and is also done in the linked study.
These values work from visual inspection of my data from my watch. I'd like to make them configurable but this may take time.
Currently, this is only done in email analysis. This is an algorithm I developed myself, based on the well-published idea that heart-rate variability (NB: not heart rate) is a strong differentiating factor. Since, at the time of writing, the only data available is heart rate in bpm, I apply this process:
- Filter heart-rate data through a low-pass filter, smoothing out any rapid changes. This provides a baseline for comparison in the next steps
- compute the difference between the filtered heart rate and the original heart rate for each datapoint
- within each wakeful period (detected from the previous section), classify as REM if the maximum difference in that period is greater than a threshold value. At the time of writing, this value is 18bpm (tuned from my own data).
This is not perfect, but seems to provide acceptable results.
Some of the labels given to information in the summaries are not the most informative (yet!). Here is a description of what they're saying:
- Tracking Started: The minute in which tracking was started, either automatically or manually.
- First Detected Sleep Time: The first time that the above algorithm detected deep sleep. If tracking was started after you were asleep, this should be the same time as "Tracking Started"
- Sleep Efficiency (Tracking Start->End): The % time not spent in light sleep / wake, from the moment tracking started until tracking finished
- Sleep Efficiency (First Sleep->Last Wake): As above, but taken between first sleep time and last wake time
- Time in REM sleep: The % time spent in REM sleep, from tracking start to finish.
- Time in light sleep: The % time spent in light sleep, from tracking start to finish. Time in light sleep + Sleep Efficiency (tracking start->end) = 100%.
- Last Detected Wake Time: The last time the above algorithm above detected a wake period.
- Tracking Ended: The minute in which tracking ended. If you used the smart alarm, this will also be approximately the time the alarm went off.
Using the Heart Rate monitor, even if simply applying a single threshold value above which HR is classified as wakeful, has worked great on manually tuned values on my data. However, this will take more work to integrate fully. Perhaps, a smart algorithm could train itself over time, adjusting either HR thresholds or accel W factors.
In addition, an option to only enable heart rate tracking at critical points, and to a heart-rate variability check at those points, could improve tracking and battery performance.
If you have a better source of these weights, or would like to voluntarily submit your data for testing (assuming you have truthful sleep values to compare against), I would love you to get in contact