A lot of wrong checksum on DUE

[niesteszeck]

reported here

[niesteszeck]

I don't have a DUE to try it out, can someone please reproduce the issue described here and if pull #3 fix it.

Do you have other dht11 sensor? can you confirm that it happens with other units?

Regarding the result with other units, on this datasheet (page 4) is specified:

Parity bit data definition
“8bit` humidity integer data + 8bit humidity decimal data +8 bit temperature integer data + 8bit
temperature fractional data” 8bit checksum is equal to the results of the last eight.

[romancardenas]

I will try with other sensor as soon as possible and report here the results

[romancardenas]

I have tried the code with another three different DHT11, and the same issue happened: around 80% of the measures reported a checksum error.

[niesteszeck]

Hi, thanks for trying another sensor unit.
I was reading about de DUE, and his IO are 3.3 V, the DHT11 is 3.5-5.5V, how are you connecting it to avoid DUE pins burn out and the sensor working?

[daniel-123]

Hello,

I've also ran into exactly this bug while using DHT11 with Uno R3. Upon examining the fourth byte it turns out to actually be the fractional temperature data - accuracy aside it does consistently rise and fall with changing conditions like you'd expect. Using patch from #3 fixes the checksum, but I think that since DHT11 is reporting that fractional value it should be also passed to the resulting temperature.

Also my DHT11 has 3.3-5.5V range printed right on it. Browsing a bit I have encountered two variants of DHT11 with temperature ranges of 0-50 and -20-60°C (same as DHT12, which also does advertise 0.1°C resolution...). I have latter one - maybe it is only the -20-60°C variant that is affected.

[niesteszeck]

Hi @daniel-123, thanks for reporting, sharing your experience and findings. Thinking about the base of this lib, it was based on DHT11Lib, same logic, no interrupt driven. So, can you try to replicate the error using that lib? If the error also exists, it'll be the sensor that is reporting some bits on bytes 1 and 3. If no error with that lib, I can think that this issue is related to timing, or other thing. Better approach to evaluate the data stream of the sensor will be to use a oscilloscope, so we can confirm that actually the sensor is sending more data bits, the timing between bits, etc.

Also, the DHT11-22 version of the lib has received a excellent rewriting proposed by @kcsoft that makes it really a lib more than a gist. Unfortunately the rewriting broke the backward compatibility, so is a little different (actually is easier). I recommend to use that lib instead of this one, as an extra, if your project needs more accuracy over his own evolution, switching to one sensor to other will be easy.

[daniel-123]

@niesteszeck: I also reproduced it with DHT11Lib. I've also looked directly at bytes 1 and 3 - as I mentioned 3rd byte contains a value that behaves exactly like you'd expect tenth faction of temperature to behave. Byte 1 was always all zeros.

Sadly I don't really have anything other than my UNO to physically look at sensor signal.

For what it is worth I took a photo of my DHT11: https://i.imgur.com/felvJPR.jpg.

[niesteszeck]

@daniel-123 you said that the 3rd byte has decimal temperature data? So your sensor has more accuracy than the normal (original/oldest/etc) DHT11 sensor. Actually I found a page where is specified that your model has 0.1°C accuracy.

If this is the case, you are right, the decimal part should be part of the temperature data, other way you'll loose accuracy.

The DHT11 and DHT22 sensors are almos equivalents, except in the accuracy, so different in byte 1 and 3. Your DHT11 has data on byte 3, so can you try the idDHTLib and set up it configuring a DHT22 sensor connected?

I starting to suspect that this is a third kind of DHT sensor, a DHT11b sensor or a DHT12 sensor. So maybe it will be a better idea to add the support for this special case on the idDHTLib rater that modifying this lib.

Looking forward for your results
Best regards
Nicolas