It is ages since I updated everyone on where we are with a replacement for Pebble Watches (Note that Pebble watches are still available, and are the lowest cost device I have found to use as a seizure detector, so I’d get one while they are available!)
A brief update on each of the trials we have been doing over the last year below. Note that Ben’s work means that Android Wear is well in the lead at the moment!
I got as far as a proof-of-concept for using an accelerometer chip with a small wifi enabled microcontroller (ESP8226). (See Custom Hardware Seizure Detector) But I struggled to get the power consumption down enough to get the battery life I needed. I also realised that realistically, for most people to use it, I’d have to manufacture it and sell it, which is a bit much of an undertaking for me, so that is on hold for now.
Garmin IQ Watches
This is a possibility, but I have been a bit disappointed with the reliability and memory leaks – I could definitely get it working though with a few evenings work on it. They are quite expensive compared to Pebbles though (£180 from amazon)….But Benjamin can tell it is not a Pebble and refuses to wear it, so I am using it for running at the moment!
I started on a proof-of-concept but didn’t get it properly connected up (I had some maths issues in the fourier transform library for android, which was not giving the same numbers as the one I use on pebble).
Ben Geisler has made great progress in getting the seizure detection working on Android Wear watches, and integrating it with the OpenSeizureDetector Alarm System. He has also got heart rate monitoring working too. His source code is on Github: https://github.com/mechanodroid/AndroidWear_SD/
So Ben’s work means that of all the alternatives I have looked at, Android Wear is looking like the closest to something we can release – over the next few weeks I will aim to incorporate Ben’s work into the main OpenSeizureDetector app and release it for testing.
We recently noticed that the battery life of our original Pebble was reducing, and it was becoming borderline if it would make it through the night (we need it to run from about 19:00 to 08:00 the next day – 13 hours).
I was surprised to find that increasing the “Data Transfer Period” from 20 seconds that I was using to 30 seconds made a huge difference to battery consumption – it easily lasts over night now with significant margin.
I think this must be because the gap between bluetooth transmissions is now long enough to allow bluetooth to go to sleep in between, which it was not doing previously, but I don’t know enough about bluetooth to know if that is true or not.
So, if you are having trouble with battery life, change Data Transfer Period (in pebble settings) to 30 seconds.
I would only do this once you are happy that the system is working properly, because it means that the data on the phone display will only update every 30 seconds, which is a long time to wait if you are testing it. It also means that initial start-up will take longer, because the system waits on the start-up screen until it receives a routine data update.
Changing the Data Transfer Period does not affect the alarm response though – if the watch detects a warning or alarm condition it sends data immediately, irrespective of the Data Transfer Period setting.
I have just released a beta test version of V2.5.5 of OpenSeizureDetector on Google Play Store.
The only change in this version is improvements to logging of network connections to help with de-bugging issues with the Network Data Source function, that allows you to monitor OpenSeizureDetector remotely via wifi.
This has been produced because we are having issues with fault warning pips sounding every now and then, and are not sure why. By running this version on both the main phone and the device running with the network data source, we will be able to tell which one is disconnecting from the network.
I have just made the current Beta test version of OpenSeizureDetector (V2.5.4) the main release – this adds an option to use MP3 alarm sounds rather than computer generated ones, as some users have reported problems with the tone generated ones not working on some phones.
You should not notice any change unless you enable MP3 alarm sounds – please let me know if you do! (firstname.lastname@example.org)
We use a Samsung Tab A that we use in ‘network datasource’ mode to raise alarms from Benjamin’s watch using wifi (it connects to the phone in his bedroom that is connected to the pebble watch).
When we first started to use it the ‘power saving’ feature used to shut down the OpenSeizureDetector background process that caused it to fail silently, but Sandie found the option to disable this.
There was a software update yesterday that upgraded it to Android 7.1.1, which broke it again. If the device is running on battery and the screen is switched off, OpenSeizureDetector starts to give fault warning pips after 6-8 minutes. I am pretty sure it is the wifi going to sleep, because as soon as you put the screen on, OpenSeizureDetector changes to OK and the fault pips stop.
The Wifi Advanced settings are set to always on, so it should have been ok, but it turns out there is now a more specific setting….
In Settings–>Apps–>[Three dots]–>Special Access–>Optimise Battery Usage. You can then select “All apps” and OpenSeizureDetector. This prevents OpenSeizureDetector being ‘optimised’ for battery usage (from https://forum.vodafone.co.uk/t5/Android/S8-wifi-disconnects-on-sleep/td-p/2562811).
This ‘optimisation’ is a pain if you want something to just keep running!
This comes with a new version (V2.6) of the Pebble app that will improve alarm annunciation reliability by avoiding the system resetting back to ‘OK’ straight away if, for example the user falls over during a seizure.
Please upgrade to this version, and also use the option on in the app to install the new watch App.
When Benjamin had his seizure a couple of weeks ago I was surprised that OpenSeizureDetector re-set for a while after alarming – I had expected it to stay in alarm continuously until the shaking movements stopped. I think that this was because he fell backwards and the algorithm saw that as a lot of movement outside of the shaking frequency range, so said it was ok. This is not what I want to happen……
I have adjusted the algorithm slightly so that the system is in an ‘ALARM’ state in one analysis period, but the alarm thresholds are not met in the next one, it goes back to ‘WARNING’ rather than ‘OK’. This means that if the next analysis period satisfies the alarm thresholds again it will go back to full ALARM.
In practice this means that the system will make beeping noises throughout rather than going quiet for 10 seconds or so.
We recently set up a Samsung Galaxy Tab A (Running Android V6.0.1) to run as a Network Data Source to act as a remote alarm annunciator for Benjamin’s seizure detector, connected using WiFi. We have been using this system for a couple of years – we were just using a different tablet computer.
Since we set it up it has go into an odd state twice – where it appears like it should be in a Fault condition, issuing fault ‘pips’, but it is not, and the status is shown as OK, with the data time shown as 00:00 – see screenshot below.
This is a significant failure of OpenSeizureDetector, because I designed it to do self checking to warn the user if something was not right, and it is not doing it.
Has anyone else seen this and not reported it? It may be limited to the ‘Network Data Source’ mode of operation, and I don’t think many people are using that, but please let me know if you have seen it, as I haven’t spotted the cause of it yet.