rtr-docs/health-and-safety/photosensitive_epilepsy.md

# Return to Ritherdon: Photosensitive Epilepsy

This document is part of the health and safety risk assessment for the
artworks *Personal Flash in Real Time (Andy)* and *Personal Flash in
Real Time (Tony)* which are part of the Return to Ritherdon
exhibition. If you would like to know more about how the artwork and
the exhibition, head to [Return to Ritherdon
Doc's](https://git.abbether.net/return-to-ritherdon/rtr-docs).

This assessment was produced by [Craig
Oates](https://git.abbether.net/craig.oates).

## Summary of Assessment 

The amount of flashes the artworks ('*Personal Flash in Real Time
(Andy)*' and '*Personal Flash in Real Time (Tony)*') produce are not
of a high enough rate to cause a photosensitive epileptic seizure --
according to the referenced sources below ('between 3-30 hertz').

The two main reasons why the artworks don't produce a high enough
flicker/flash rate are as follows:

1. The devices controlling the lights in the gallery cannot receive
   enough new readings-per-second to reach the hertz required to cause
   a seizure (according the reference sources below); And,
2. The welders in the factory do not alter the light levels (in their
   welding booths) at a high enough rate to trigger a seizure.

The majority of this assessment will focus on the second point. The
reason why is because I can refer you to the link below to address the
first point:

- [Relay](https://git.abbether.net/return-to-ritherdon/relay/src/branch/unstable/relay.py#L51)
(the software controlling the lights in the gallery)

The highlighted line (on the linked page) indicates the gallery lights
must wait 0.3 seconds until it receives the latest light reading
(I.E. process three readings-per-second). This means **the lights (in
the gallery) can change states (I.E. off to on) at a rate of two
hertz, at most**.

To expand on the second point, I have analysed and reviewed a
days-worth of **live test** data, collected on the
**23/04/2021**. *Personal Flash in Real Time (Andy)* (the light meter
part of the artwork) took the light readings from **06:57 to 16:00**
(approx. 9 hours). Also, the test was conducted under the intended
environment and under real-world conditions.

The overall assessment of the data is the light meter took readings at
a rate of four readings-per-second for approximately two
(non-consecutive) hours. Within that time, the light meter produced
*readings* which generated a flash rate of two hertz, at most. And, it
reached this 'peak' for a total of three non-consecutive seconds
throughout the nine hours. With the light meter demonstrating it has
*the potential* to generate enough new readings-per-second, the
gallery lights have a hard limit of three readings-per-second encoded
into their systems (via their software).

## 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 available 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 Risk Assessment Relates to the Return to Ritherdon Project

The artworks *Personal Flash in Real Time (Andy)* and *Personal Flash
in Real Time (Tony)* this document refers to are two artworks which
are, in effect, one system and part of a much bigger project (called
Return to Ritherdon). Within these two artworks are flashing
lights. Because of that, the rate of flashing/flickering the artworks
produce 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 above shows the two pairings which consists of one 'Light
Meter' and one 'Gallery Light'.

**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 Fluctuates

As you work your way through this assessment, you will notice the
system produces inconsistent amounts of (light)
readings-per-second. The reason it fluctuates 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 before it discharges. If there is no or little light hitting the
sensor, it will take longer to charge which means it will take longer
to calculate 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](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 calculates and 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 (Andy) 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

I 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

Within the [data](data) directory, the [results](data/results)
directory contains four files. These files are the result of the data
analysis.

```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
```

These four files are the results of the analysis conducted for this
assessment. And, each file will have its own subsection below.

### readings-per-sec.csv

- [readings-per-sec.csv](data/results/readings-per-sec.csv)

Overall, the test data recorded **84,294** readings over the course of
about nine hours. With that said, the readings-per-second rates
fluctuated throughout those nine hours. To help explain, please review
the table below,

(*data taken from `test-data.csv`*)

| 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            |

**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).

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 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 **seven reading
spread across a five-second time-span**.

When you calculate the amount of readings-per-second rates for all the
readings in `test-data.csv`, you will get the following results,

*(Minutes and Hours rounded to nearest .5)*

| Readings-per-Second | Seconds | Minutes | Hours |
|---------------------|---------|---------|-------|
| 1                   | 5,344   | 89      | 1.5   |
| 2                   | 2,955   | 49      | 1.0   |
| 3                   | 13,284  | 221     | 3.5   |
| 4                   | 8,297   | 138     | 2     |
|---------------------|---------|---------|-------|
| Total               | 29,880  | 498     | 8.0   |

The way to read to table is as follows:

- for 5,344 seconds, the system operated at a rate of one
  reading-per-second
- for 2,955 seconds, the system operated at a rate of two
  readings-per-second
- for 13,284 seconds, the system operated at a rate of three
  readings-per-second
- for 8,297 seconds, the system operated at a rate of four
  readings-per-second

According to the sources listed above, 'between 3-30 hertz (flashes
per second) are the common rates to trigger seizures'. To reach this
rate, the system needs to have a readings-per-second rate of four or
more. In this instance, the data shows the system can reach a rate of
four-readings-per-second. This means the light meters can
(technically) take enough readings-per-second to could trigger a
seizure. I nullified this, though, by limiting the number of new
readings the gallery lights can receive in a one second time period.

The reason why the rate needs to be four readings-per-second or higher
-- and not three -- is because of the need for a 'starting state'. For
example, let's say the first reading is 'off' and the second reading
is 'on'. There is only one change in state but two readings. If you
continue the process, you will require four readings to reach the
minimum threshold of three changes in state (I.E. off to on) per
second before you reach the quoted hertz limit to trigger a seizure:

1. off (starting state -- no change)
2. on (first state change)
3. off (second state change)
4. on (third state change)

What the data in `readings-per-sec.csv` shows is the system can
technically record enough readings-per-second to potentially trigger a
seizure. Although, it cannot do it at a constant rate. This result
meant I needed to expand my analysis of the data
(`test-data.csv`). But, I could limit the scope to the 8297 seconds of
recordings and not all of it.

### readings_above_threshold.csv

- [readings_above_threshold.csv](data/results/readings_above_threshold.csv)

To review the time periods were the light meter was recording above
three hertz, I needed to know there timestamps. This file is a list of
those times. If you would like to manually review each time period
where the light meter recorded at three hertz, you can cross-reference
the times in `readings_above_threshold.csv` with `test-data.csv`. This
file is an artefact of the filtering process and needed to generate
`flicker_list.csv`. **For the most part, you can ignore this file**.

### flicker_list.csv

-  [flicker_list.csv](data/results/flicker_list.csv)

This file lists all the moments the light meter recorded at four
readings-per-second and the light levels at those times. I should note
here the gallery light paired with this light meter only **turns on**
if the light level is **above 39**. Upon reading this list, it is
apparent the gallery light does not always change its state (I.E. on
to off) for every time frame. This meant I could reduce the list even
more.

To help explain how to interpret the data, please consider the follow
sample from `flicker_list.csv`,

*Note: The '.000000' is a artefact from the software's formatting of
the data.*

| Timestamp                  | Readings                 |
|----------------------------|--------------------------|
| 2021-04-23 09:04:07.000000 | ['41', '37', '36', '36'] |
| 2021-04-23 09:04:11.000000 | ['36', '38', '40', '37'] |
| 2021-04-23 09:04:14.000000 | ['36', '36', '37', '36'] |
| 2021-04-23 09:04:18.000000 | ['36', '36', '36', '36'] |
| 2021-04-23 09:04:22.000000 | ['36', '36', '36', '36'] |
| 2021-04-23 09:04:26.000000 | ['37', '37', '37', '37'] |

What it shows is the light level recordings taken at the specified
moment in time. For example, for the one second period at `2021-04-23
09:04:11.000000`, the amount of light recorded in the welding booth
(in the factory) was `36`, `38`, `40` and `37`. What's important to
note here is the light changed state only once during this time frame
(when above `39`).

To expand on the point about noting the change in state, please
consider the following table (an expansion of the `2021-04-23
09:04:07.000000` timestamp),

| 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   |

It shows, for the one-second period at `2021-04-23 09:04:07.000000`,
the gallery light changed its state (from on to off) once. It does this
when the light level is above `39`. This, in effect, demonstrates the
system flash rate was one hertz for that second.

### filtered_flicker_entries.csv

-  [filtered_flicker_entries.csv](data/results/filtered_flicker_entries.csv)

The data in this file filters the data in `flicker_list.csv` down to
eight time periods. These are the times the light recorded at four
readings-per-second and cause the gallery light to change state at
least once. The format in this table is the same as
`flicker_list.csv`, so refer to that section for information on how to
read the data in `flicker_list.csv`.

The three main points to take away from this file are:

1. The system never managed to reach the three hertz threshold;
2. The system couldn't sustain the rate to *potentially* reach the
   three hertz threshold beyond one second; And,
3. The system reached the readings-per-second rate to *potentially*
   reach the three hertz threshold for eight seconds over an
   *approximate* nine hours period.
   
What's important to note about the last point is eight seconds over
nine hours is **less than one second-per-hour**. That's even if the
system manage to cause the gallery light to flash at three hertz. To
help explain the above, please see the table below,

*Note: This is an expansion of
`filtered_flicker_entries.csv`. 'States' and 'Hertz' and not included
in the .csv file.*

| 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 | 2     |
| 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 | 2     |
| 2021-04-23 11:00:11.000000 | 39, 42, 46, 39 | off, on, on, off | 2     |

### The Human Element in The System

A point I haven't touched on yet is the involvement of the two members
of staff, in Ritherdon (factory), operating the welders. Overall, it
is the welders who trigger the gallery lights on and off. This means
they would need to cause their welders to flicker/flash above three
hertz which does not align with the types of jobs they are tasked
with. Granted, this is a point without any *immediate and explicit*
data recorded data to demonstrate this as fact. I can only imply it
through the data analysis above. This section/point is more about
providing extra context to the assessment.