One of my main objectives for this project has been to make seizure detector systems available at low cost so people on low incomes can afford it if they want it. So it has been a bit disappointing that we have been tied to Garmin watches for so long (Since Fitbit bought and discontinued Pebble watches).
The Garmin watches are very good, but they are expensive, and we are tied to using their software and as we have seen recently they break it sometimes with software updates.
So over Christmas I have been concentrating on getting OpenSeizureDetector to work on lower cost devices – I did a post in December about BangleJS, which costs around £77, so about half the cost of a compatible Garmin watch.
Since then I have been working on PineTime, which costs about £35 delivered to the UK. I have been using the Open Source InfiniTime firmware and developing it to supply the data needed by OpenSeizureDetector. It now seems to be working, but needs some more testing to see if there is any unusual behaviour to be sorted, but it is looking very promising to be a seizure detector for those who can not afford an Embrace or other commercial system.
Please contact graham@openseizuredetector.org.uk with any questions.
A user has reported that a recent firmware update on a VenuSq 2 has resulted in the app not working any more (it stalls during start up waiting for seizure detector data).
*** If you are offered a Garmin Firmware Update, DO NOT ACCEPT IT until we have investigated further ***
If you have had a recent firmware update and things are still working ok, please let me know which watch firmware you have and what version of Garmin Connect you have installed.
We have made some progress towards a lower cost seizure detector by developing support for the BangleJS2 watch.
It is still in the development stage, but the testing I have done has shown that it is very promising – we can get acceleration and heart rate data off the watch, the battery life is good, and I have not had any trouble with it losing the bluetooth connection.
Some details and a place for technical discussion is posted on our Github discussions page here.
It would be good if anyone who enjoys tinkering with devices could help with getting this suitable for end user release by sorting out some of the identified issues, and developing end-user instructions to set it up.
Please get in touch (graham@openseizuredetector.org.uk) if you would like to help out!
Thanks to all of the users who have been contributing data using the Data Sharing system (and most importantly marking events as either real seizures or false alarms!), we have now released Version 1.3 of the Open Seizure Database.
The OpenSeizureDatabase is the anonymised database of seizure and false alarm data that is available to researchers to help improve seizure detection algorithms. The main condition of using the data is that they publish the results so that the OpenSeizureDetector project can benefit from the work.
The database contains 160 seizure events containing acceleration data measured by the OpenSeizureDetector watch app. Many of the events also contain heart rate data and we can see from the data that heart rate does tend to increase significantly during a seizure. You can see a summary of the seizure data that is available here.
Jamie Pordoy has put a lot of effort into the database and has written a very good summary of the data and how it was collected in a paper, which you can see in preprint form here.
If you know someone that is into machine learning, please encourage them to have a look at training a model to detect seizures using the database – contact osdb@openseizuredetector.org.uk for access to the full dataset.
A user has reported an issue where their VenuSQ watch crashes after 1 or 2 hours and disconnects from the phone – the only way of restoring the connection is to re-boot the watch.
It appears to be caused by the communications to send data to the phone taking too long, so multiple requests are being sent, and I think this is crashing the watch (which is a Garmin bug).
I have a new test version of the watch app which I am testing to see if it fixes the issue, but it looks like we still have the low data transfer rate issue which will need to be investigated.
This may have been caused by a Garmin Connect update, so if you are using a VenuSQ and it is working ok, please set play store so it will not update Garmin Connect automatically, and let me know which version of Garmin Connect you are using.
Update 30/09/2023: A number of users have confirmed that this issue is present on the VenuSQ running firmware V4.90. I have reported the bug to Garmin, but so far have only got an ‘Acknowledged’ response. It appears that the VenuSQ V2 is not affected.
V4.1.12 of the OpenSeizureDetector Android App is now live on Play Store for upgrades.
The changes here are:
Targeting Android 13 devices (which is a requirement from Google to list the app on play store)
Fixed the Export Data function which is in the menu of the Data Sharing screen. The Export Data function saves the user’s data to the phone storage (in Downloads) so you can do your own analysis on it if you want to. There was an issue that crashed the phone if you tried to export too much data (2 hours worked, but 12 hours ran out of memory). It takes a while to do a significant export (say 24 hours), but should finish without any errors now.
Introduced a simple Fidget Detector to try to detect if the watch has come off the wrist. A fidget is designed by a 5 second period with at least 0.6% standard deviation variation in the accelerometer readings. If no fidgets are detected for 20 minutes (Default values – user configurable), it generates a fault pip. Most users will not need this if they are using heart rate alarms as a heart rate sensor failure will also occur if the watch comes off, which will generate a fault.
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!
I have a new version (V4.1.11) with Google for review before being released for beta testers (so hopefully tomorrow).
The changes here are:
Targeting Android 13 devices (which is a requirement from Google to list the app on play store)
Fixed an issue that crashed the phone if you tried to export too much data (2 hours worked, but 12 hours ran out of memory). Export is still quite slow so you might see some ‘this app is not responding – do you want to wait’ messages from the Android System.
Introduced a simple Fidget Detector to try to detect if the watch has come off the wrist. A fidget is designed by a 5 second period with at least 5% standard deviation variation in the accelerometer readings. If no fidgets are detected for 20 minutes (Default value – user configurable), it generates a fault pip. Most users will not need this if they are using heart rate alarms as a heart rate sensor failure will also occur if the watch comes off, which will generate a fault.
Assuming I do not get a load of issues generated by the beta testers, I will make this version live towards the end of the week.
Graham (graham@openseizuredetector.org.uk)
Update 22/08/2023: The default settings for the fidget detector will need changing – by default it will go into a fault state if it does not detect movement for 20 minutes – we got an alarm because of this last night so I increased it to 30 minutes…and two hours later it woke me up again with a fault alarm. I have it set to 60 minutes at the moment – I think that will be ok, but means it will take an hour to warn us that the watch has come off, which is longer than I would have liked. I’ll collect data for a couple of days and do some analysis to see if I can optimise the settings before releasing this version.
I have used the Data Sharing (the Open Seizure Database) data to assess the false alarm rate, so new users have an idea what to expect from OpenSeizureDetector. I have analysed one particular user who I know wears the watch every night so it gives us a good idea of the overnight false alarm rate.
I have taken all the false alarms (ie not genuine seizures) and calculated the weekly total for each week in 2023, up to 05 August 2023. The weekly totals are divided by 7 to give us the average daily false alarm rate. The results are shown below:
From the graph above you can see that our false alarm rate is between 1 and 2 per day on average, but it does vary quite a lot. This variation is behaviour related, because the seizure detector settings were constant throughout this period (Alarm Threshold=900, Alarm Ratio Threshold=57). Note also that this user does not use the heart rate alarm functions, only the ‘OSD’ algorithm to analyse movement.
The database does not contain much information on what behaviour caused the false alarms – some of it is repetitive autistic movements, such as pointing or sorting, and quite a lot is just fidgeting when asleep.
While we could reduce this false alarm rate by increasing the Alarm Threshold setting (so the system has to detect more movement before it activates the seizure detection algorithm), or the alarm period (so we need to see seizure-like movement for longer before it alarms), both of these would reduce the seizure detection sensitivity. The carers of this particular user are happy to tolerate the false alarm rate because the system has successfully woken them up in the night for genuine seizures.
Note also that this user only wears the watch when alone in his room, so maybe around 12-14 hours per day, and he does not generally wear it when brushing teeth etc. We know that the following activities would generate false alarm if the user is wearing the watch and does not use the ‘mute’ function on the app screen to inhibit alarms: Brushing Teeth, Brushing Hair, Cooking (e.g. chopping or stirring), cleaning (scrubbing).
The next major development for OpenSeizureDetector will be to develop a Machine Learning (“Artificial Intelligence”) seizure detector algorithm that will distinguish between genuine seizure movements and the common false alarm movements more effectively. We have a promising one that has been trained on the data in the Data Sharing system that I hope to release for testing soon. We are also releasing the Open Seizure Database that we have developed for researchers to use in the hope that they will identify a better way of detecting seizures with fewer false alarms.
So please keep contributing to the Data Sharing system, and most importantly mark genuine seizures that occur when OpenSeizureDetector is in use, so we can use these to train the new systems and test them.
At least three users have confirmed the issue with Garmin VenuSQ devices returning incorrect heart rate readings (after several hours it stops updating heart rate, and returns the same value all the time, even though the accelerometer data is updating correctly and Garmin Connect reports correctly varying heart rate). More details here: https://github.com/OpenSeizureDetector/Garmin_SD/issues/22.
V4.1.10 of the OpenSeizureDetector Android App is now available on play store. This version will enter a fault condition if this heart rate issue occurs while you have heart rate alarms active – so please run this version and let me know if you experience the issue, and which watch you are using.
