0

We are trying to use a Camera Module v1 to record video using gstreamer whilst also reading from DHT11 every 4s. I observed that, when the camera is not running, DHT11 takes 1.5s to output the temeprature and humidity values for the first time and it takes 0.5s for each consecutive read. I am using the Adafruit Python_DHT package (found here: https://github.com/adafruit/Adafruit_Python_DHT)

When running a gstreamer pipeline to record while and tryin to get readings from DHT11, I observed that DHT11 takes a long time to return values sometimes (ranging anywhere between 3-70s) and sometimes, the values returned are not accurate (got very high values). When I stopped the gstreamer pipeline, I was getting proper readings in 0.5s from DHT11.

We hooked up an oscilloscope to the DHT11 to observe the pulses. It looks like the data being returned from DHT11 is failing checksum test and rpi keeps on querying for data until it gets a correct reading and sometimes, it times out and we don't get a reading at all.

I even added the dtoverlay for DHT11 on the correct gpiopin and yet we are still facing the same issue. Has anyone else run into this issue?

5
  • "It looks like the data being returned from DHT11 is failing checksum test" - does it mean an incorrect data correctly fails the checksum test, or a correct data incorrectly failing the checksum test? Sep 7 '18 at 12:34
  • @DmitryGrigoryev to be honest, I'm not sure.. Sep 7 '18 at 12:52
  • Well, if you got a sensor which outputs incorrect data, you'll never find out what the problem is unless you either check the data manually or test your system with a sensor which you know works fine. Sep 7 '18 at 13:17
  • could it possibly be a power/voltage issue - i.e. flakey voltage to DHT11 whilst the camera is in operation? just a thought from left field Sep 8 '18 at 2:43
  • use the oscilloscope when the gstreamer pipeline is stopped ....see if the problem actually disappears, or if it only decreases
    – jsotola
    Sep 8 '18 at 18:36
1

It's hard to time the relatively short pulses (circa 30µs) accurately in Linux.

Try DHTXXD for one reliable method (requires the pigpio daemon to be running sudo pigpiod)

10
  • Just tried DHTXXD and looks like I'm getting a lot of bad data and timeouts from the DHT11. Its only succeeding to get a good value probably 10% of the time Sep 7 '18 at 11:40
  • Is that with or without gstreamer?
    – joan
    Sep 7 '18 at 11:44
  • same observation with or without gstreamer pipeline running Sep 7 '18 at 11:51
  • Here's some sample data read every 3s glot.io/snippets/f4kw8snfoz Sep 7 '18 at 11:54
  • That is odd. I suspect a wiring problem or a faulty device.
    – joan
    Sep 7 '18 at 11:59
0

This is not a faulty device but I think CPU problem. If my CPU is too busy the frequency of messages below come up. I'm using the dht11 dtoverlay with Debian Stretch.

dmesg output (kernel messages)

dht11 dht11@0: Only 0 signal edges detected
dht11 dht11@0: Only 1 signal edges detected
dht11 dht11@0: Only 81 signal edges detected
dht11 dht11@0: Don't know how to decode data: 156 128 12 0

All of these lines are written in red by the kernel

This is not a faulty device at all, but I think something related to the kernel module and the RPI resource usage.

I got a daily log attached to the values read by DHT11 ( I read it every 10 minutes) and when the output works, NO lines like these are printed in dmesg...

4
  • I don't see any such messages in the dmesg output. I'm also using the dht11 overlay with Debian Stretch Sep 7 '18 at 12:27
  • so dmesg | grep dht11 give no output?
    – MadPapo
    Sep 7 '18 at 12:35
  • yes. no mention of dht11 anywhere in dmesg Sep 7 '18 at 12:51
  • ok, but it seems similar to pigpio but the number of bits seems incorrect. I don't know if it a kernel bug, so for the moment, it seems another problem
    – MadPapo
    Sep 7 '18 at 19:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.