Non-blocking interrupt driven DHT22 library

I finally got the idDHT22 library for Spark working. It is an interrupt driven, non-blocking version of the DHT22 library. The library can be found on my github :smile:

7 Likes

Very cool, thanks for sharing! I’ve got 2 RHT03 sensors that I’m testing with, they both seem to be providing some strange values - temperature is around -40C, humidity at 43.9%. I also seem to be hitting checksum errors nearly every second request. Have you experienced any issues like this?

emc2, I’ve found that not all DHT22/RHT03 sensors are happy at 3.3V. I use the raw 3.3V line on the Spark and not the filtered line because the voltage is below 3.3V and my DHT22s don’t work. Make sure you have a pull-up resistor and that you don’t draw too much current from the 3.3V regulator on the Spark.

Good tip, thanks. 10k pullup already there, moved power to raw rail… sensor is responding much better!

1 Like

I’m having trouble with this.
I have this working with the blocking firmware no problem.
When I run this firmware it hangs at “Read sensor:”.

It’s definitely blocked because I have to reset the core to flash firmware.

I don’t have a pullup resistor in place but this same circuit works perfectly with the blocking firmware. Is this more sensitive somehow?

Edit: With a couple of extra debug lines, I can see it’s stuck in the acquiring while loop forever.

kareem613, my experience with DHT22s has shown me that not all are created equal! I use a 4.7K pull-up but it is not always necessary. Nonetheless, I suggest you use one because the non-blocking code is sensitive to the DHT22 data output rise time and the resistor helps. Another thing is the voltage used for the DHT22. I do not suggest powering off the 3.3*v line since it is lower that 3.3V and I have found a lot of DHT22s that will not work at anything even slightly lower than 3.3V.

Try the pull-up and let me know how it goes.

I got passed that infinite loop without the pullup. I got mixed up when switching pins.
FYI. If you’ve got the wrong data pin set, it results in an infinite loop.
I now get checksum errors.

To confirm. Pullup goes between Data and 3.3v right?

Yes, that is correct.

Ok. I tried both a 9k and 5k pull up. Still checksum errors.

Bah. Back to infinite loop. When I test 3.3V and 3.3*V I get a 3.25V reading for both.

You can try a 2.2K resistor. Timing is everything in the non-blocking version and I found that sometimes it does not work with all DHT22s. The timing in the code is based on the datasheets and a bit of experience but may not work in all cases. The blocking version may be your only option. Besides, you don’t really need to sample that sensor very often do you?

True. This isn’t necessary I guess. Tried a lower resister. Still no luck. I guess I’ll just revert back to the blocking one.

Thanks for the help!

I have no idea how I missed this topic. I’m back to the DHT22, so I’m going to give this a whirl!

@peekay123, you should have kicked me and let me know. :wink: I forked your repo, changed the files and directories to line up with the proposed Spark library format, and submitted a pull request. It validates, too! Hopefully you won’t mind much.

2 Likes

@wgbartley, it’s all good dude. We’re all on the same team :wink:

2 Likes

@peekay123, Hi I just tried the example as well and even when i power the :spark: with 5V and I hook up my DHT22 to the 5V with a pull up of 5K ( 2 10K’s in parrallel) I get a reading of 70% humidity, which is exat the same as my livingroom says. The only strange thing I also see is that the temperatures are negative values of -39.00 for C and -38.20 for F. Any suggestion ?

@rudyvan, I’ll setup a DHT22 and do some tests and get back to you. :smile:

Thanks @peekay123, i’ll cross check tonight the sensor on an adafruit library on Arduino as well to make sure the sensor is not the issue here, I’ll be back.

@peekay123, Hi, When I use the DHT22 sensor on an Arduino like in https://learn.adafruit.com/dht/using-a-dhtxx-sensor then I get normal temperatures, not negative. So are you sure it is not something in the library ?
KR,
Rudy

@rudyvan, it was a problem with the library! I tweaked the timing a bit and now it seems to read correctly at both 5V and 3.3V supplying the DHT22. I posted v0.0.2 of the IDDHT22 library on the web IDE. Give it a shot! :smile:

Working great for me :slight_smile:

1 Like

If I’m understanding this, the asynchronous data read of 40 bits from the sensor takes a max of 80 * 40 us = 3.2ms. But there’s a 10ms blocking delay in the call to acquire() - so the bulk of the time is spend blocking.

It might be a good idea to make the 10ms delay asynchronous also, so the call to acquire() returns almost immediately.