|
|
|
@ -1,8 +1,7 @@
|
|
|
|
|
|
|
|
|
|
# Return to Ritherdon: Photosensitive Epilepsy |
|
|
|
|
|
|
|
|
|
This document is to be used as part of the health and safety risk |
|
|
|
|
assessment for the Return to Ritherdon exhibition. |
|
|
|
|
This document is part of the health and safety risk assessment for the |
|
|
|
|
'unnamed' artwork in the Return to Ritherdon exhibition. |
|
|
|
|
|
|
|
|
|
## Summary of Assessment |
|
|
|
|
|
|
|
|
@ -10,9 +9,9 @@ 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 with *approximately* 8 to 9 hours on usage, on the |
|
|
|
|
23/04/2021. This falls outside the **3-30 Hertz** claimed by Epilepsy |
|
|
|
|
Society (link below). |
|
|
|
|
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 |
|
|
|
|
|
|
|
|
@ -20,9 +19,7 @@ According to [Epilepsy
|
|
|
|
|
Society](https://epilepsysociety.org.uk/photosensitive-epilepsy), a |
|
|
|
|
flashing/flicker light between 3-30 hertz can trigger a seizure. |
|
|
|
|
|
|
|
|
|
> What rate of flashing light can trigger seizures? |
|
|
|
|
|
|
|
|
|
> > Between 3-30 hertz (flashes per second) are the common rates to |
|
|
|
|
> 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. |
|
|
|
@ -39,19 +36,168 @@ More information can be found at:
|
|
|
|
|
|
|
|
|
|
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 to |
|
|
|
|
be reviewed as part of the health and safety risk assessment. |
|
|
|
|
|
|
|
|
|
## Viewing the Raw Data |
|
|
|
|
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 it. If you would like to review the raw data please |
|
|
|
|
head to: |
|
|
|
|
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) |
|
|
|
|
- [raw-data/results](data/results) (for the data after it's been |
|
|
|
|
processed and used for this risk assessment) |
|
|
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
|
@ -92,16 +238,17 @@ 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 | |
|
|
|
|
|---------------------------------------------|---------| |
|
|
|
|
| 2021-04-23 07:02:50.000000 | 17 | |
|
|
|
|
| 2021-04-23 07:02:51.000000 | 17 | |
|
|
|
|
| 2021-04-23 07:02:51.000000 | 17 | |
|
|
|
|
| 2021-04-23 07:02:52.000000 | 17 | |
|
|
|
|
| 2021-04-23 07:02:53.000000 | 17 | |
|
|
|
|
| 2021-04-23 07:02:54.000000 | 17 | |
|
|
|
|
| 2021-04-23 07:02:55.000000 | 17 | |
|
|
|
|
| 2021-04-23 07:02:55.000000 | 17 | |
|
|
|
|
| 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 |
|
|
|
@ -170,5 +317,5 @@ 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 |
|
|
|
|
Society](https://epilepsysociety.org.uk/photosensitive-epilepsy) (more |
|
|
|
|
references/links at the top of this file). |
|
|
|
|