fix - getting max values (1023) (or invalid) when using analogRead/DHT/US/etc sensor

[RobertLucian]

It seems like when using the analogRead function or when using the DHT sensor, sometimes outlier values are returned (i.e. value 1023). This can be a hardware issue or even possibly a firmware issue.

https://forum.dexterindustries.com/t/piezo-sensor-i2c-error/4396
https://forum.dexterindustries.com/t/solved-dht-sensor-occasionally-returning-spurious-values/2939

[RobertLucian]

The bug seems to be caused by the HW bug with the I2C interface on the Raspberry Pi, where the clock stretching functionality doesn't seem to work well. Apparently, the Pi recognizes a clock stretch if the signal line is kept low and when it rises again it doesn't take into consideration the clock stretch that happened and thus the positive pulse gets to be too narrow (say less than the regular 7.6 uS).

Here's how it looks like when the stretching is done badly:

More can be read here: raspberrypi/linux#254

Anyway, lowering or speeding up the I2C rate is rather cumbersome (and prone to changes with each new release) on the Pi and that's something that we shouldn't do.
Using software serial on the Pi could be a good idea but again, we would need a library that's solid and well tested by the community.
Using delays in the firmware would have been a good idea, but the default implementation hides away the actual process when the data is sent back to the master. Currently the data is loaded in an ISR-triggerred function by using Wire.write s which actually don't send anything until the function ends - this basically takes away the ability to add delays when doing the actual transmission.

My best bet was to identify each transmission by an ID and thus not accept any transfer that comes in. So far it works, but it's not the perfect solution because it doesn't fully solve it - bad values still get through but at a lower rate, which I'd say it's a success.

The best thing we could do is use SPI instead, but unfortunately we are bound by our hardware.