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