Incorrect readings about adafruit_python_dht HOT 12 CLOSED

I did further investigation. I found about 30% of individual readings are returned with Checksum error. I am doing thousands of readings in a day. It is possible multiple errors are happening during reading the data and checksum bytes and with a small probability still the checksum is correct, so the data is accepted and passed. Better success rate on individual readings would reduce the risk...

from adafruit_python_dht.

In The current example None is returned for the reading if there is a Checksum error, so maybe this issue can be closed.

from adafruit_python_dht.

I see the same behavior. As dmole said, I will try to use the if .. is None statement. But still as you can see, the values aren't None, but are in fact a value (although it's wrong).

from adafruit_python_dht.

I debuged further what is happening. I found high percentage of measurements rejected in the background due to wrong CRC. Most of these are ignored by the driver and the measurements are repeated, however there are some measurements where the bit reading is incorrect but the CRC result is a false positive. There are the ones you see as a bad measure. Since this this is not a kerner level driver, I don't believe this can be avoided especially if your linux is doing many other things like mine.Finally I implemented the am2302 data read on an Arduino pro mini and I am reading the temperarure data from the Arduino via i2c bus on the Pi. I have no false reading since then.Sent from
Yahoo Mail for iPhoneOn 29 Sep 2015 22:28:13, Melroy van den Berg wrote:I got the same issue. Sometimes the readings are not correct. I got a AM2301 sensor, but in the code I'm forced to use 'AM2302' (notice the '2' at the end). Nevertheless, sometimes I see that humidity and temp_1 is really strange and incorrect. temp_1 is the reading from AM2301 sensor. The other temperatures are other sensors and not relevant.

—Reply to this email directly or view it on GitHub.

from adafruit_python_dht.

Hi, I also got a lot of bad values. Maybe in 30-50% I get humidity 3005% and wrong temperature. So I done easy check - if humidity is < 0 || > 100 then don't save values to database. In future I'll try to repeat measuring.

Is there any way, how to check if CRC check has been successful false positive). or CRC is not checked while DHT22 measuring?

Thanks

from adafruit_python_dht.

If you want this to work more reliably;

• nice all other things you have running,
• run this as root (to have access to lower nice values)
• use only the c portion
• return the raw values (not the calculated H, and T)
• use the calibration signal instead of the magic number
• use the linux RT patch.

You can't expect this to work if you are sharing the CPU with other things.

from adafruit_python_dht.

@Dmole
Wait wait, wait a second. You are saying I can't do readings on BeagleBone Black with Debian (they advised to install), and using GPIO pins for 1-wire for AM2301 sensor? 1-wire works perfectly with another waterproof temp. sensor, BS18B20, which also uses 1-wire protocol.

Maybe you are right at some point. But CRC should just work. Again I got correct readings with the other sensor (BS18B20). Which uses the Linux Kernel driver:
http://lxr.free-electrons.com/source/drivers/w1/w1.c

I created a device tree for the BS18B20 sensor.

from adafruit_python_dht.

@Danger89
A Kernel driver has much higher priority than a user space script so you don't need to do much to get it close to real time. Also this is analog (length of a signal), 1-wire protocol is digital(pattern of signals).
Also the Kernel driver is likely not ignoring the calibration signal.

https://en.wikipedia.org/wiki/1-Wire#Example_communication_with_a_device

from adafruit_python_dht.

Ok, so maybe it's an idea to use w1-gpio? And maybe it's also an idea if this Adafruit python library try to use this w1-gpio Linux kernel driver?

from adafruit_python_dht.

@Danger89 This library exists because the package does not conform to the w1 protocol. but yes using a package that does is highly advisable.

from adafruit_python_dht.

@Dmole
Damn. omg that's true .. -,- In that case the only good solution is to create a Adafruit DHT Linux kernel driver for this special 'w1 protocol'.

from adafruit_python_dht.

There's actually a kernel driver for the DHT11/22/etc. sensors now, it's part of the iio subsystem and you can find a little more Pi-specific info here on using it: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=113988 and https://www.raspberrypi.org/forums/viewtopic.php?f=31&t=117938. Yeah it's definitely a good step in the right direction if you're running into checksum and other errors. The python code really just makes a best effort at reading the signal from userspace--if anything else is taking a lot of CPU or resources then it can be problematic to get a good reading. The kernel driver should help a bit since it won't be affected as much by other processes monopolizing the CPU. I haven't used the kernel driver myself yet though so just be aware it might require some device tree configuration and other Linux setup.

from adafruit_python_dht.