Readings unstable with rpi, DHT11 and mjpg_streamer about adafruit_python_dht HOT 2 CLOSED

Yep the DHT code is sensitive to other tasks taking too much CPU. It's bit-banging the GPIO on the Pi as fast as it can (and actually tries to increase the process' priority so the kernel gives it as much time as possible) so that it doesn't miss any of the relatively short pulses from DHT sensor (~50-80 microseconds long each). If something CPU intensive runs at the same time it will throw off the timing and give bad results that don't pass the checksum.

Yeah interesting idea to use SPI hardware to read the signal. It's a trade off though in that you could only use one DHT sensor at a time with SPI. I'm not super familiar with the Pi DMA support but perhaps there's a way to read GPIO very quickly and dump it to memory with a DMA timer too. That might make things more flexible, but could be a lot of work.

A third thing to look at too is that in the more recent Linux kernels (since ~3.18 IIRC) they actually added a native DHT sensor module to the kernel. I think there's a little more info in this thread: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=98543 Since it's being read by the kernel it might be a little more resilient to processor intensive tasks happening at the same time, but I wouldn't be surprised if by using the module you find mjpg streamer starts stuttering. :)

For now I think we like the simplicity and flexibility of bit-banging GPIO in the current implementation. If you have some hard real time tasks you need to do in addition to CPU intensive stuff on the Pi you might look at adding a small Arduino to talk to the sensor and then send data back to the Pi over a serial link.

from adafruit_python_dht.

Tony, Thanks for detailed answer. I found it extremely useful.

For now I stick with measuring with multiple retires after I will jump to proposed Arduino solution.

from adafruit_python_dht.