Forth-eV Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{pfw:full-banner.png?500 }}

====== The DHT22 Document ======


[[https://wiki.forth-ev.de/lib/exe/fetch.php/pfw:am2302-en-aosong.pdf|am2302-en-aosong.pdf]] Although this information is factually correct, I found some of it difficult to understand due to the cumbersome translation into English. **Page 5** provides an example of how to handle the data.
//Example 1// first shows the interpretation of temperatures above 0 °C and then, as a "special case" the representation of temperatures below 0 °C.((Looks like Sign and Magnitude: The most significant bit (MSB) is used to represent the sign of the number (0 for positive, 1 for negative). The remaining bits indicate the magnitude of the number.))
 Check it out there.

====== The Reality ======
But then I was confused because the sensor I was using delivered something different. 

===== A Strange DHT22 Module =====

Near the freezing point of water, a value of around 4095 decimal was output. 

<code>
chk  409,5 °C   99 %rel 
chk  409,5 °C   99 %rel 
chk    0,0 °C   99 %rel 
chk    0,0 °C   99 %rel 
chk  409,5 °C   99 %rel 
chk  409,5 °C   99 %rel 
chk  409,5 °C   99 %rel 
chk  409,5 °C   99 %rel
... 
</code>

So, one-tenth of a degree below zero was represented as $FFF. And at lower temperatures, the result was something like 32626 °C, which is $7F72. In binary terms:
  
  \              7654321076543210
  dm 32626 bn u.  111111101110010  OK.1
  
You can see that the MSB in the upper byte is 0, but all other bits are set.
If you only take the lower byte, it's $72, which is &114. So, -11.4°C should be displayed here. However, this format didn't correspond to the specification in the datasheet. Instead, it resembled some 12-bit format.

Using the logic analyzer, it was possible to verify that this was not a read error during the SDA bitbang, but that the read routine was actually working correctly.

{{:en:pfw:dht22-0-unternull.png|Example of data output of the bad module below zero degrees}}

There have been numerous questions online about the problem of a DHT22 module malfunctioning in sub-zero temperatures. But ultimately, there was no conclusive explanation as to what exactly is going wrong. I don't know what has to happen in the module itself for this error to occur. But it seems to me that you can program around it. However, that would mean rewriting the driver from a library. But now that we see what's causing it, it could also be done in C, right? Such a routine could also check whether this strange 12-bit representation is present and then display the temperature accordingly. These modules are supposed to be calibrated. Let's see...
:) 


===== The Good Modules =====

After purchasing additional DHT22 modules (am2302), it became clear that only one sensor was delivering these strange temperature values. Three others behaved as specified in the datasheet.


  chk  -3267,4 °C   56 %rel

The corresponding 40 bits read with PulsView were:
  00000010 00100000 10000000 10101010 01001100

And this is then interpreted as follows:
<code>
\                7654321076543210
0000001000100000 1000000010101010 01001100
0000001000100000                          \ hum --> bn 0000001000100000 dm . 544  ok
                 1000000010101010         \ tmp --> bn 1000000010101010 dm . -32598  OK.1
</code>

So, what is meant is this:
<code>
                      bn 10101010 dm . 170  OK.1
</code>
In the source code, the Forth word ''.tmp'' prepares the temperature measurement value.\\
When printed formatted, it shows -17.0 °C.

{{:en:pfw:dht22-2-frost1.png|Example of data output of a good module in the freezer}}

[[https://wiki.forth-ev.de/doku.php/en:pfw:dht22#numerical_representation_of_the_measured_values|Back]]