(high-priority) Don't store PPMs for sensors that are maxxed out.

[JSegrave-IBM]

Significant issue for the risk log...

The Issue

• The current NO2 sensor has a range of 10ppm. Ideally, Prometeo firefighters want the limit to be set at 20ppm, but since 20ppm isn’t possible with this sensor, a 10ppm limit has been proposed. Unfortunately, that can't be done safely.
• An example to illustrate:
  • A firefighter experiences [30mins at 1ppm. Then 30mins at 25ppm]
  • One hour into the fire, this firefighter has experienced an average of 13ppm per hour, well over the 10ppm limit - their status should be ‘Red’.
  • The command center would see their status as Green (not Red or Yellow) with a 5.5ppm per hour average - seemingly well under the limit, because the sensor provides [30mins at 1ppm. Then 30mins at 10ppm] (averages to 5.5ppm)
• For time-weighted average math to give reliable results, the sensor must have a much larger range than the limits. If the limit is set at or near the sensor range, a firefighter's status would essentially never go red, even if they were well over the limit. Not a viable solution.

Options

1. Use sensor with a bigger range - this is in motion, but won't be available for a while.
2. While waiting for Create Main.ino #1, have a way to indicate when sensors are maxxed out and store that rather than a ppm reading. Also make the analytics engine stop generating TWA results for any time-windows affected by maxxed-out sensor readings.
3. It's not yet known if there there will be time to implemnent Recruit IBM Service Corps team for roles #2 before the first events, a safe fallback is needed. That fallback is to record the NO2 values during these events, but not to generate analytics for them on the dashboard. This is a one-line configuration change to prometeo_config.json - to remove nitrogen dioxide from the 'supported gases' configuration property. Once a 'maxxed out detection' is implemented, this NO2 configuration can be switched back on.

This github issue (#117) is to track option #2. Option #3 has been implemented and is pending merge (pull request #9).

[JSegrave-IBM]

Here's the plan (summarising today's call):

1. We’ll get maxed out handling in for the October test burns. When the firmware detects PPMs above 95% of the sensor max specification, it will send -1 instead of a PPM and log the issue to the SD Card. Since -1 is a float, the existing mobile characteristics will be OK with it. maxed out is temporary, so once the firmware detects PPMs fall back down below the 95%, it will send normal PPMs again. For the MICS-4514 sensor, the 95% means ppm > 950 for CO and ppm > 9.5 for NO2.

2. corrupted handling will come afterwards. Sensor corruption is permanent. When the firmware detects a corrupt sensor, it will log it to the SDCard and stop sending data for that sensor (avoid other components handling corrupt data). It will also send a magic number to the mobile (-2? TBC), so the mobile app can tell the user to repair or replace the device. The mechanism for detecting a corrupted sensor is to-be-worked-out during the calibration - possibly something along the lines of ‘the standard deviation of 10 sensor readings is fixed and not changing’

[JSegrave-IBM]

The analytics side of this is ready for review/merging. Based on the sensors sending a signal value of '-1' to indicate when they've exceeded their range.... This change makes sure the analytics handle that signal value correctly and updates the test data to reflect what the sensors are expected to send.