|
|
|
|
# Return to Ritherdon: Photosensitive Epilepsy
|
|
|
|
|
|
|
|
|
|
This document is part of the health and safety risk assessment for the
|
|
|
|
|
'unnamed' artwork in the Return to Ritherdon exhibition.
|
|
|
|
|
|
|
|
|
|
## Summary of Assessment
|
|
|
|
|
|
|
|
|
|
The rate of flashes the lighting system produces is not of a higher
|
|
|
|
|
enough rate to cause a photosensitive epileptic seizure -- according
|
|
|
|
|
to the referenced sources below. Based on the **live test** data, the
|
|
|
|
|
system produce a flash rate of **1 Hertz** through out the course of
|
|
|
|
|
one day between **06:57 and 16:00** (9 hours), on the
|
|
|
|
|
**23/04/2021**. This falls outside the **3-30 Hertz** claimed by
|
|
|
|
|
Epilepsy Society (link below).
|
|
|
|
|
|
|
|
|
|
## Information About Photosensitive Epilepsy
|
|
|
|
|
|
|
|
|
|
According to [Epilepsy
|
|
|
|
|
Society](https://epilepsysociety.org.uk/photosensitive-epilepsy), a
|
|
|
|
|
flashing/flicker light between 3-30 hertz can trigger a seizure.
|
|
|
|
|
|
|
|
|
|
> Between 3-30 hertz (flashes per second) are the common rates to
|
|
|
|
|
trigger seizures but this varies from person to person. While some
|
|
|
|
|
people are sensitive at frequencies up to 60 hertz, sensitivity under
|
|
|
|
|
3 hertz is not common.
|
|
|
|
|
|
|
|
|
|
More information can be found at:
|
|
|
|
|
|
|
|
|
|
- [Epilepsy Society](https://epilepsysociety.org.uk/) (home page)
|
|
|
|
|
- [Epilepsy
|
|
|
|
|
Action](https://www.epilepsy.org.uk/info/photosensitive-epilepsy)
|
|
|
|
|
- [National Health Service](https://www.nhs.uk/conditions/epilepsy/)
|
|
|
|
|
(NHS)
|
|
|
|
|
|
|
|
|
|
## How This Relates to the Return to Ritherdon Project
|
|
|
|
|
|
|
|
|
|
The project (unnamed at time of writing) this document refers to is
|
|
|
|
|
one artwork in a much bigger project (called Return to
|
|
|
|
|
Ritherdon). Within **'unnamed project'**, is flashing lights. Because
|
|
|
|
|
of that, the rate of flashing/flickering the artwork produces needs
|
|
|
|
|
reviewing as part of the health and safety risk assessment.
|
|
|
|
|
|
|
|
|
|
## Overview of How the System Works
|
|
|
|
|
|
|
|
|
|
This is not a complete overview of how the system works. That is
|
|
|
|
|
outside the scope of this document. Instead, this is a simplified
|
|
|
|
|
version for the sake of brevity. For a more thorough overview, please
|
|
|
|
|
use the following (documentaton) links:
|
|
|
|
|
|
|
|
|
|
- [Light Meter](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/light-meter)
|
|
|
|
|
- [Relay](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/light-meter)
|
|
|
|
|
- [Midpoint](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/midpoint)
|
|
|
|
|
|
|
|
|
|
The system consists of five devices but only the server (Midpoint)
|
|
|
|
|
interacts with all its counterparts. There are two 'Light Meters'
|
|
|
|
|
which reside in Ritherdon (factory) and two 'Gallery Lights' which
|
|
|
|
|
communicate with each others opposite via the server. 'Each others
|
|
|
|
|
opposite' refers to the two pairings between the light meters and
|
|
|
|
|
gallery lights. Below is a diagram to help explain.
|
|
|
|
|
|
|
|
|
|
![System Overview](media/system-overview.png)
|
|
|
|
|
|
|
|
|
|
The diagram shows the two pairings which consists of one 'Light Meter'
|
|
|
|
|
and one 'Gallery Light'. The 'Gallery Light' is usually referred to as
|
|
|
|
|
'Relay' but I've changed it here to highlight the *factory-gallery*
|
|
|
|
|
relationship.
|
|
|
|
|
|
|
|
|
|
**The important thing to note here is the lights in the gallery only
|
|
|
|
|
turn on when welding is occuring in any of the welding booths in the
|
|
|
|
|
factory.** If no one is welding, the lights remain off.
|
|
|
|
|
|
|
|
|
|
### Why the Readings-per-Second Rate is Fluxtuates
|
|
|
|
|
|
|
|
|
|
As you work your way through this assessment, you will notice the
|
|
|
|
|
system produces inconsistent amounts of light readings per second. The
|
|
|
|
|
reason it fluxtuates throughout the day is because of how the system
|
|
|
|
|
measures the light. The quick version is the light meter is timing how
|
|
|
|
|
long the light sensor (within the light meter) takes to charge, based
|
|
|
|
|
on the amount of light hitting it. The more light hitting the sensor,
|
|
|
|
|
the quicker it charges and reaches its limit. If there is no or little
|
|
|
|
|
light hitting the sensor, it will take longer to charge which means it
|
|
|
|
|
can determine what the current light level is. The amount of light in
|
|
|
|
|
Ritherdon (factory) changes throughout the course of the day hence the
|
|
|
|
|
inconsistent readings-per-second rates. For more information on how
|
|
|
|
|
the light meters measure the light levels, head to:
|
|
|
|
|
|
|
|
|
|
- [Light
|
|
|
|
|
Meter](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/light-meter)
|
|
|
|
|
|
|
|
|
|
## Accessing the Data
|
|
|
|
|
|
|
|
|
|
This document will only provide a summarised view of the data because
|
|
|
|
|
of the size of the raw files and databases are rather large and
|
|
|
|
|
cumbersome. If you would like to review the data used in this
|
|
|
|
|
assessment please head to:
|
|
|
|
|
|
|
|
|
|
- [data](data)
|
|
|
|
|
|
|
|
|
|
Otherwise, the more complete set of test data is available at:
|
|
|
|
|
|
|
|
|
|
- the
|
|
|
|
|
[Flicker](https://git.abbether.net/return-to-ritherdon/flicker/src/branch/stable/src/data)
|
|
|
|
|
project (takes you to the 'data' part of the repository)
|
|
|
|
|
|
|
|
|
|
How I've broken down the data files/directory is as follows:
|
|
|
|
|
|
|
|
|
|
```console
|
|
|
|
|
data
|
|
|
|
|
├── results
|
|
|
|
|
│ ├── filtered_flicker_entries.csv
|
|
|
|
|
│ ├── flicker_list.csv
|
|
|
|
|
│ ├── readings_above_threshold.csv
|
|
|
|
|
│ └── readings-per-sec.csv
|
|
|
|
|
├── test-data.csv
|
|
|
|
|
└── test-data-lite.csv
|
|
|
|
|
|
|
|
|
|
1 directory, 6 files
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
As you can see, the `test-data.csv` and `test-data-lite.csv` reside in
|
|
|
|
|
the top most directory. And, these are the files which I passed
|
|
|
|
|
through
|
|
|
|
|
[Flicker](https://git.abbether.net/return-to-ritherdon/flicker) in
|
|
|
|
|
order to get the files in `results`. Technically, I used only
|
|
|
|
|
`test-data.csv` but `test-data-lite.csv` is a subsection of its larger
|
|
|
|
|
counter part. If your computer is stuggling to open the full-sized
|
|
|
|
|
`test-data.csv` file, I recommend falling back onto
|
|
|
|
|
`test-data-lite.csv` -- where you can see what the data at least looks
|
|
|
|
|
like.
|
|
|
|
|
|
|
|
|
|
I've omitted all databases used throughtout the project in the `data`
|
|
|
|
|
directory because of their unweildy size and niche use (outside
|
|
|
|
|
specialised environments/industries). Access to the SQLite databases
|
|
|
|
|
are available if needed.
|
|
|
|
|
|
|
|
|
|
## Reading the Data
|
|
|
|
|
|
|
|
|
|
If you would like to see the data in situ, click on the following:
|
|
|
|
|
|
|
|
|
|
- [test-data-lite.csv](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/unstable/health-and-safety/data/test-data-lite.csv)
|
|
|
|
|
|
|
|
|
|
The data consists of three columns:
|
|
|
|
|
|
|
|
|
|
1. `Id`
|
|
|
|
|
2. `Time Stamp`
|
|
|
|
|
3. `Reading`
|
|
|
|
|
|
|
|
|
|
*Sampe of readings taken from `test-data.csv`*
|
|
|
|
|
|
|
|
|
|
| Id | Time-Stamp | Reading |
|
|
|
|
|
|---------|----------------------------|--------:|
|
|
|
|
|
| 7780379 | 2021-04-23 07:00:20.000000 | 5 |
|
|
|
|
|
| 7780380 | 2021-04-23 07:00:21.000000 | 11 |
|
|
|
|
|
| 7780381 | 2021-04-23 07:00:22.000000 | 11 |
|
|
|
|
|
| 7780382 | 2021-04-23 07:00:24.000000 | 11 |
|
|
|
|
|
| 7780383 | 2021-04-23 07:00:25.000000 | 11 |
|
|
|
|
|
| 7780384 | 2021-04-23 07:00:26.000000 | 11 |
|
|
|
|
|
| 7780385 | 2021-04-23 07:00:27.000000 | 11 |
|
|
|
|
|
| 7780386 | 2021-04-23 07:00:29.000000 | 11 |
|
|
|
|
|
| 7780387 | 2021-04-23 07:00:30.000000 | 12 |
|
|
|
|
|
| 7780388 | 2021-04-23 07:00:31.000000 | 12 |
|
|
|
|
|
| 7780389 | 2021-04-23 07:00:32.000000 | 12 |
|
|
|
|
|
|
|
|
|
|
For this assessment, you can ignore the `Id` column. I've kept it to
|
|
|
|
|
help preserve the nature of the data in its raw form -- after
|
|
|
|
|
converting it to a comma-seperated-value (CSV or .csv) file. I
|
|
|
|
|
converted the data because of the specialised nature of databases (in
|
|
|
|
|
this case a SQLite database). Essentially, the `Id` column refers to
|
|
|
|
|
the 'row Id' for a particular reading. It makes it easier to refer to
|
|
|
|
|
a reading via its `Id` that its `Reading` value and/or `Time-Stamp`.
|
|
|
|
|
|
|
|
|
|
The `Time-Stamp` and `Reading` columns refer to the level of light
|
|
|
|
|
recorded at that speficied time. For example, at `2021-04-23
|
|
|
|
|
07:00:26.000000` (row `7780384`), the amount of light recorded was
|
|
|
|
|
`11`. I should point out here, the time-stamp format is as follows:
|
|
|
|
|
|
|
|
|
|
- `YYYY-MM-DD Hr:Min:Sec:MicroSec` (`Hr` is 24-hour)
|
|
|
|
|
|
|
|
|
|
On top of that, every time-stamp has their `MicroSec` values set to
|
|
|
|
|
`.000000`. The code used to generate this data is responsible for
|
|
|
|
|
this. It just doesn't record it and is not a data conversion
|
|
|
|
|
issue. I've kept the data as close to its raw form as I can and the
|
|
|
|
|
`.000000` is a consequence of that. The [Light
|
|
|
|
|
Meter](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/light-meter/rtr-light-meter.md)
|
|
|
|
|
project is responsible for generating the data.
|
|
|
|
|
|
|
|
|
|
How the values stored in `Reading` are out of scope for this
|
|
|
|
|
assessment (see [Light
|
|
|
|
|
Meter](https://git.abbether.net/return-to-ritherdon/rtr-docs/src/branch/master/light-meter/rtr-light-meter.md)
|
|
|
|
|
for more information) but the main take-away is the more light in the
|
|
|
|
|
welding booth, the higher the number. There are two welding booths in
|
|
|
|
|
the factory which this system monitors ('Light Meter 1' and 'Light
|
|
|
|
|
Meter 2' in the diagram above) and each one has their own threshold to
|
|
|
|
|
indicate when welding is occuring. For example, when the light level
|
|
|
|
|
for 'Light Meter 1' goes above `39` (at time of writing), this
|
|
|
|
|
indicates a staff member in the 'first' welding booth is welding which
|
|
|
|
|
triggers the light to turn on in the gallery ('Gallery Light
|
|
|
|
|
1'). Throughout the course of the day (factory operating hours are
|
|
|
|
|
07:00-16:00), the system repeats this process and documents every
|
|
|
|
|
reading and the time it recorded it.
|
|
|
|
|
|
|
|
|
|
## How the Data was Processed/Reviewed
|
|
|
|
|
|
|
|
|
|
The data was analysed using the code in the
|
|
|
|
|
[Flicker](https://git.abbether.net/return-to-ritherdon/flicker)
|
|
|
|
|
repository. Please review the code/repository there for more
|
|
|
|
|
information on how the code works -- it is outside the scope of this
|
|
|
|
|
document.
|
|
|
|
|
|
|
|
|
|
## Breakdown of Data Analysis
|
|
|
|
|
|
|
|
|
|
The sample of data reviewed for this assessment was taken from the
|
|
|
|
|
Light Meter readings produced by `factory1` running the software
|
|
|
|
|
provided by
|
|
|
|
|
[Light-Meter](https://git.abbether.net/return-to-ritherdon/light-meter),
|
|
|
|
|
on the **23/04/2021**. Overall, there was **84,294** light readings
|
|
|
|
|
taken over the course of **between 8 to 9 hours**. Also, this was a
|
|
|
|
|
**live test** with readings taken from the **intended environment**,
|
|
|
|
|
under **real-world conditions**. Of those readings, the number of
|
|
|
|
|
readings taken is as follows,
|
|
|
|
|
|
|
|
|
|
*Note: Minutes and Hours are approximate values.*
|
|
|
|
|
|
|
|
|
|
| Readings-per-Second | Seconds | Minutes | Hours |
|
|
|
|
|
|---------------------|---------|---------|-------|
|
|
|
|
|
| 1 | 5,344 | 89 | 1.5 |
|
|
|
|
|
| 2 | 2,955 | 49 | 0.8 |
|
|
|
|
|
| 3 | 13,284 | 221 | 3.5 |
|
|
|
|
|
| 4 | 8,297 | 138.28 | 2 |
|
|
|
|
|
|---------------------|---------|---------|-------|
|
|
|
|
|
| Total | 29,880 | 498 | 8.3 |
|
|
|
|
|
|
|
|
|
|
Let's say you have the following readings (sample taken from
|
|
|
|
|
`test-data.csv` stored in [raw-data](raw-data),
|
|
|
|
|
|
|
|
|
|
**Note: The '.000000' is a artefact from the code's formatting of the
|
|
|
|
|
data.** You can ignore it. I've only kept it in to keep the data here
|
|
|
|
|
aligned as close as possible with the raw and computed data
|
|
|
|
|
[data](data).
|
|
|
|
|
|
|
|
|
|
| Time-Stamp (YYYY-MM-DD Hr:Min:Sec:MicroSec) | Reading | Readings/sec |
|
|
|
|
|
|---------------------------------------------|---------|--------------|
|
|
|
|
|
| 2021-04-23 07:02:50.000000 | 17 | 1 |
|
|
|
|
|
| 2021-04-23 07:02:51.000000 | 17 | ----------- |
|
|
|
|
|
| 2021-04-23 07:02:51.000000 | 17 | 2 |
|
|
|
|
|
| 2021-04-23 07:02:52.000000 | 17 | 1 |
|
|
|
|
|
| 2021-04-23 07:02:53.000000 | 17 | 1 |
|
|
|
|
|
| 2021-04-23 07:02:54.000000 | 17 | 1 |
|
|
|
|
|
| 2021-04-23 07:02:55.000000 | 17 | 1 |
|
|
|
|
|
| 2021-04-23 07:02:55.000000 | 17 | 1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**Note: I've omitted the `Id` column from the example above because is
|
|
|
|
|
not relevant for this assessment.** If you review the raw data, you
|
|
|
|
|
will come across that column. More often than not, you can ignore it
|
|
|
|
|
if you're not looking to review/work with the code written for main
|
|
|
|
|
the system.
|
|
|
|
|
|
|
|
|
|
If you look at the time-stamp `2021-04-23 07:02:51.000000`, you will
|
|
|
|
|
see there are two readings recorded. This sample is very small but you
|
|
|
|
|
can see the remaining time-stamps have only one reading per each
|
|
|
|
|
second intervals. With this in mind, please note there are eight
|
|
|
|
|
reading spread across a five-second time-span. That is why the /first/
|
|
|
|
|
table above is broken down into time and not just hard frequency
|
|
|
|
|
totals. For 5,344 seconds on 23/04/2021, the system took a light meter
|
|
|
|
|
reading at one reading-per-second.
|
|
|
|
|
|
|
|
|
|
According to the sources listed above, 'between 3-30 hertz (flashes
|
|
|
|
|
per second) are the common rates to trigger seizures'. This means the
|
|
|
|
|
number of readings to review can be reduced to those operating at four
|
|
|
|
|
readings-per-second. This is because the lights in this system need to
|
|
|
|
|
go from an off-state (1) to an on-state (2) and back to an off-state
|
|
|
|
|
(3). The extra (fourth reading) is needed because there needs to be a
|
|
|
|
|
starting state (a zero if you will). Below is a sample of a moment
|
|
|
|
|
when four readings were taken in a one second period,
|
|
|
|
|
|
|
|
|
|
| Time-Stamp (YYYY-MM-DD Hr:Min:Sec:MicroSec) | Reading | State |
|
|
|
|
|
|---------------------------------------------|---------|-------|
|
|
|
|
|
| 2021-04-23 09:04:07.000000 | 41 | On |
|
|
|
|
|
| 2021-04-23 09:04:07.000000 | 37 | Off |
|
|
|
|
|
| 2021-04-23 09:04:07.000000 | 36 | Off |
|
|
|
|
|
| 2021-04-23 09:04:07.000000 | 36 | Off |
|
|
|
|
|
|
|
|
|
|
**Note: The light paired with `factory1` is set to turn on (in the
|
|
|
|
|
gallery `gallery1`) when the reading is above 39.**
|
|
|
|
|
|
|
|
|
|
In the table above, you will see the light changes state (on to off)
|
|
|
|
|
once. For it to reach the noted rate of 'between 3-30 hertz', the
|
|
|
|
|
third reading in the table will need to have been above `39` to
|
|
|
|
|
trigger the light back on. This would have made the light change from
|
|
|
|
|
on to off three times, taking into account the need for a 'starting'
|
|
|
|
|
state.
|
|
|
|
|
|
|
|
|
|
Referring back to the table listing the various rates of
|
|
|
|
|
readings-per-second (the first table), there are only **8,297**
|
|
|
|
|
readings (technically it's seconds but 'readings' is easier to
|
|
|
|
|
process) instead of **84,294**. This can be filtered down even more,
|
|
|
|
|
though. This is because not all four readings-per-second occurrences
|
|
|
|
|
cause the light to change its current state (I.E. it doesn't go from
|
|
|
|
|
off to on). With this in mind, the number of entries to review drops
|
|
|
|
|
to **8** when you list just the times when the light changes its
|
|
|
|
|
state. They are,
|
|
|
|
|
|
|
|
|
|
| Time-Stamp | Readings | States | Hertz |
|
|
|
|
|
|----------------------------|----------------|------------------|-------|
|
|
|
|
|
| 2021-04-23 09:04:07.000000 | 41, 37, 36, 36 | on, on, off, off | 1 |
|
|
|
|
|
| 2021-04-23 09:04:11.000000 | 36, 38, 40, 37 | off, on, on, off | 1 |
|
|
|
|
|
| 2021-04-23 10:54:05.000000 | 39, 39, 40, 40 | on, on, on, on | 0 |
|
|
|
|
|
| 2021-04-23 10:54:07.000000 | 39, 39, 39, 40 | on, on, on, on | 0 |
|
|
|
|
|
| 2021-04-23 10:56:46.000000 | 40, 40, 39, 39 | on, on, on, on | 0 |
|
|
|
|
|
| 2021-04-23 10:57:13.000000 | 40, 41, 40, 39 | on, on, on, off | 1 |
|
|
|
|
|
| 2021-04-23 10:58:13.000000 | 39, 46, 44, 39 | off, on, on, off | 1 |
|
|
|
|
|
| 2021-04-23 11:00:11.000000 | 39, 42, 46, 39 | off, on, on, off | 1 |
|
|
|
|
|
|
|
|
|
|
This tables shows the limitations of the system to trigger a
|
|
|
|
|
photosensitive epileptic seizure. The system produced **at most** a
|
|
|
|
|
flash rate of **1 Hertz** over the course of **approximately 8 to 9
|
|
|
|
|
hours** of activity.This is below the '3 to 60 Hertz' claimed by
|
|
|
|
|
[Epilepsy
|
|
|
|
|
Society](https://epilepsysociety.org.uk/photosensitive-epilepsy) (more
|
|
|
|
|
references/links at the top of this file).
|