Clip sensor reading values to non-negative

[danieltsoukup]

We have seen recently that the sensor can produce invalid (negative) readings under certain extreme conditions (e.g., moisture saturating the mic) See https://dashboard.tracket.info/locations/747559 around January 1st.

The goal of this ticket is to adjust the sensor data processing to automatically clip values to be non-negative before sending to the API.

A related ticket is being worked on to notify sensor owners if the device is recording zeros, which should practically never happen CivicTechTO/tRacket-sensor-manager#1

[tcsullivan]

I made a new branch for this and added a lazy fix of forcing negative decibel values to zero before they are recorded. This made me come to a few realizations though:

1. Decibel measurements are the result of multiple "instantaneous" microphone samples. If one of these samples reads "zero", it is 99.99% likely to be invalid. Many zero samples in a row are what weigh dB values down to zero and below. Since this weighing down ruins accuracy, I wonder if any dB measurement should be zeroed if it contains an invalid sample? This would guarantee that only 100% valid (and accurate) measurements are recorded.

2. Maybe instead of zeroing an entire dB sample, we can just omit invalid mic samples from a dB calculation...

3. Should invalid/negative dB measurements (after being forced to zero) affect min/max/mean statistics? I think probably not, which means my lazy fix isn't enough.