The DHT22 is a low cost, single wire sensor which measures temperature and relative humidity.
I started out just playing around with this thing, just wiring it to a Pi to see it working.
But I got sucked in much deeper into thinking about how it worked and assessing its limitations.
Output Data Stream
The DHT22 produces a serial stream of data. In other words the sensor has just one “wire” over which it sends data and receives commands.
It does this by simply raising and lowering the voltage level, and varying the amount of time that the wire is either “high” or “low”. In my circuit “high” is approximately 3.3 Volts, while low is approximately 0 Volts.
The data output consists of a series of low-to-high-to-low sequences where each sequence represents either a logical 0 or a 1.
A logical 1 waveform looks like this:-
There should be 40 of these zeros and ones in a complete data set, and this data stream may start out looking something like this:-
00000010 00110101 0000…
The first 2 bytes contain the rh (relative humidity) value. In this example:-
02hex & 34hex = 234hex = 564
As data values are 10 x actual readings, 564 is an rh of 56.4%.
Likewise, the third and forth bytes represent 10 x the temperature reading.
The Checksum
In order to validate the integrity of the sensors transmitted data, the unit generates a simple checksum, which occupies that last byte of the 40 bit data stream.
This sensor calculates the checksum by adding the 4 data bytes together, and using only the lower 8 bits of the result as the 1 byte checksum.
Here is an example where the rh is 60.2% and temperature is 23.1'C:-
60.2%: 602 = 025Ahex, so byte 1 = 02hex and byte 2 = 5Ahex
23.1: 231 = E7hex, so byte 3 = 00hex and byte 4 = E7hex
02h + 5Ah + 00h + E7h = 143h
So the high byte is disgarded, and the checksum becomes 43hex.
When our system [software] reads this data it simply repeats the process and checks the result against the checksum. If there was a data transmission or reception error, our calculated checksum will not match the checksum transmitted from the sensor, so we can ignore this bad data.
There are of course a couple of exceptions. If the data error is in the 1st or 3rd bytes, this error will not be detected by the checksum, because we only use the lower 8 bits of the result. Also, it is possible that 2 or more errors may cancel one another out (e.g. a -1 error in rh and a -1 error in received checksum).
However, in the first case, an error in the 1st or 3rd bytes will make a very large difference to either the rh or temperature. For example, 01hex in the first byte is 256. This would be a change of 25.6% rh (or 25.6'C for the 3rd byte).
In the second case? Well, someone with good maths abilities could probably tell me the likelyhood of canceling errors.
For more detail: DHT22 Temperature/RH Sensor on the RaspberryPi
