We have had a couple of issues over the last few months where Benjamin’s watch has come off his wrist while he has been asleep, so although OpenSeizureDetector was running properly, it would not have detected a seizure.
If we used the heart rate alarm function of OpenSeizureDetector the watch coming off would have shown up as a fault so we would have been alerted. But Benjamin has delicate skin so wears his watch over his clothes, so the heart rate reading is unreliable, so we do not use it.
For this reason I have been looking at an alternative way of confirming that the watch is attached to the wrist. The method I am trialling is detecting small movements while the wearer is asleep (“Fidgets”), and generating a fault condition if the time since the last detected fidget is more than a given threshold. The idea is that if the watch is not attached, it will not detect fidgets, so this is a way of telling of the watch is attached or not.
The algorithm for fidget detection is simple:
- Every time a new 5 second batch of data arrives from the watch, we calculate the standard deviation of the acceleration vector magnitude (as a percentage). If the standard deviation is above a threshold, we consider this period to contain a fidget.
- If a fidget is detected, we record the time of the fidget.
- If the data does not represent a fidget, we check the time since the last detected fidget. If it is more than the specified threshold, we generate a fault condition to alert the users to a problem.
The issue is trying to decide where to set the thresholds – if we set the time threshold very long, we will get very few false alarms, but it will take that long time to warn us that the watch has come off. If we set the standard deviation threshold too low, random noise will be detected as fidgets, and it will fail to warn us if the watch comes off.
My first guess of the settings for this were to use a 5% acceleration standard deviation as the definition of a fidget – this is quite a lot of movement. I then raised a fault condition of there were more than 20 minutes since the last fidget….This woke me up three times in one night, so was not a good result!
To try to be a bit more scientific we collected data for an entire night and analysed it by calculating the acceleration magnitude standard deviation for each 5 second period during the night, and using several different thresholds to determine which 5 second periods represent fidets. We then analysed the maximum time between fidgets using the threshold to see if it looked useful or not. The results are shown below:
The above graph shows that if we set the fidget threshold above about 0.6 %, the maximum time between fidgets of this size is quite large (> 10 minutes). Once the threshold is 0.8% the maximum time between fidgets reaches around 1 hour, which is too long a period to be useful for us.
To give an idea of the fidget time distribution, the histogram for 0.6% fidget threshold detection is shown below (Note that the y axis is truncated at frequency of 10, so that the lower frequency bins are visible):
So it looks like fidget detection threshold of about 0.6% and a time gap of 20 minutes should not produce too many false alarms – so I will try this out.
The remaining uncertainty is how well this will detect the watch coming off. If it falls off completely and lands on the floor, I am confident it will work. If the watch is resting on the mattress though, it might still detect the fidgets – I will have to think of a way of testing this and updating this post.
If anyone has a better idea or suggestions, please let me know!
Graham (graham@openseizuredetector.org.uk).