Month: August 2022

V4.0.7 of the Android Phone App should be released for testing shortly (subject to Google approving the release…). The changes relate to improving the user interface for marking events as either real seizures or false alarms in the Data Sharing system. The specific changes are:

V4.0.7 - Improvements to Data Sharing data log manager screen
    - Removed automatic refresh of shared data events list (Issue #62)
    - Added option to include warnings in shared data events list (Issue #64)
    - Added catch of NullPointerException in LogManager in case of network disruption (Issue #61)
    - Added 'demo mode' on main screen when phone data source selected and highighted it in warning colour (Issue #56)
    - Changed default local data retention time to 7 days (from 28) - works around #63

Anyone registered as a beta tester should be invited to upgrade to this version over the next day or so – please let me know if you have any issues.

Graham (graham@openseizuredetetor.org.uk)

We are finding that users are uploading a lot of events to the database (either genuine alarms/warnings or false alarms), but we have a lot which have not been marked to show if they are real seizures or false alarms – and we can not use the data without that. I am going to implement some improvements in a new version of the app. The ones I intend to do are:

• Allow the events list to be filtered to only show alarm events and not warnings (because it is much more important to mark the alarms as seizure or false alarm than it is the warnings). (https://github.com/OpenSeizureDetector/Android_Pebble_SD/issues/64)
• Switch off the automatic updating of the events list, because this makes it difficult to scroll down the list without it jumping back to the top when it refreshes (https://github.com/OpenSeizureDetector/Android_Pebble_SD/issues/62)
• Fix issue with the data log manager screen getting very slow after a while (make the local database access happen in the background, and change the default data retention period to 7 days rather than 28) – https://github.com/OpenSeizureDetector/Android_Pebble_SD/issues/63
• Make the ‘Unvalidated Events’ notification clear if there are no longer unvalidated events – this will make the notification appearing have more significance for the user than if it stands constantly – https://github.com/OpenSeizureDetector/Android_Pebble_SD/issues/58

Please let me know if there are any other data sharing related issues that you would like to see addressed in this update (graham@openseizuredetector.org.uk)

Thanks, Graham.

It has been a while since we released Version 4.x of OpenSeizureDetector, which includes the ‘Data Sharing‘ feature. This feature allows users to contribute to the development of OpenSeizureDetector by sharing data recorded during seizures or false alarms anonymously with researchers and developers to help improve the detection algorithms.

Since we went live with the feature, over 100 users have signed up and the database now contains over 10000 individual ‘events’. An event is an instance where OpenSeizureDetector goes into a warning or alarm state, or the user reports a seizure manually. We then upload data points covering a 5 minute period either side of the event – so we are generating a good amount of ‘real world’ data which will be really useful for testing new seizure detection algorithms.

A key part of the Data Sharing system is the ability for users to categorise the events to say if they are real seizures or false alarms – doing this is really, really important to us, because without that we do not know what to do with the data – do we develop the algorithm to make it more likely to detect events like the uploaded one or less likely to detect it?

Now an activity which generates a warning or alarm condition may well generate several warnings or alarms over a short period, so we have been working on a way of condensing all the contributed data down into a more manageable set of ‘unique events’ which covers a period of activity that generated one or more alarms. Based on the current version of the data condensing code, we have the following numbers of unique alarm events in the database*:

• 24 Tonic-Clonic Seizues
• 62 Seizures in total (of various types)
• 121 classified false alarms (that is the user has confirmed the false alarm and said what caused it).
• 167 events marked as unknown
• 589 unclassified events.

(* Note that this still needs some more checking so the numbers are likely to change – the numbers are lower than you might expect, but this is because unless the event is marked by the user as a seizure, we have ignored events that only produced a warning state, not a full alarm at the moment)

I have a test system that I can use to determine the detection reliability and false alarm rate based on this contributed data – I will report those results in the next week or so once I have checked it some more (the results I have at the moment look a bit too good to be true, so I am looking for a mistake!).

It is clear from the data above that we are building a very useful database of both real seizures and false alarms generated from users’ normal activities. The ‘unclassified events’ list is by far the largest though. Jamie Pordoy, who is using this data to support his PhD research reports that there are quite a few events in the ‘unclassified’ list that look very like real seizures to him – so if you have been contributing data and have had a seizure that you have not reported, please will you get in touch so we can try to identify it in the database?

Note that real seizure data is vitally important to developing better algorithms, so if you know anyone who does have regular seizures, please will you encourage them to use OpenSeizureDetector and contribute data, even if they are not particularly interested in the alarm function for themselves.

I know that marking the events as real seizures or false alarms can be difficult, especially once you have a lot in the list, so please get in touch with any suggestions that you think would make it easier for you to do. The things I have thought of as options so far are:

• Filter the events to list only ALARM conditions (as these are the ones we are most keen on you marking.
• Provide a web page based list of your events that you can scroll through more easily on a bigger screen.
• Provide a feedback function where researchers can ask you explicitly about an event that looks ‘interesting’ and ask you to describe it in more detail – either through a notification in the app, or an email?

Other ideas and feedback would be appreciated!

Thanks for all your efforts in contributing data – keep it up!

Graham (graham@openseizuredetector.org.uk)