Is this a port of the synchronous/blocking or the asynchronous (interrupt driven) library? If the latter, do the other activities the spark core is carrying out (wifi stuff) interfere with the timing when reading from the sensor?
As far as I can tell after a quick look, it’s almost copy/paste from the adafruit library. Since there is no support yet for libraries the typical way, you have to include everything in one file. So just take the content from your *.h and *.cpp files and combine them at the top of your sketch. You can also remove most of the conditional compiler directives that attempt to test the ARDUINO version, and header guards like:
It’s about 99% copy+paste of the Adafruit library. The only real changes are: #define cli noInterrupts #define sei interrupts #define NAN 999999
The rest is pretty much just cleaning up the tabs and braces to my preferred coding style, and removing the Serial.print stuffs.
@BDub, I partially agree about the bunch of libraries stuff. Once the Spark Team has library support, we’ll just need to break this code back into the .h and .c counterparts again. The hard work of porting the code to compile on the Spark Core architecture is the important part.
Reading the Adafruit library code on github, this library is a synchronous or blocking version. It disables interrupts and uses delay commands. So when your code requests the humidity reading, things are held up for two or three hundred milliseconds while the data is retrieved from the sensor. Any interrupts during this period could be missed. For most applications, this will be fine.
There is also available an asynchronous or non-blocking library available for Arduino. This has the advantages that your code can carry on doing something else while the reading is being taken and retrieved from the sensor, and interrupts are not disabled, so will not be missed.
For the application I have in mind, I am going to need the non-blocking version, because I will have other sensors generating interrupts that I dont want to miss, for example a windspeed sensor.
So when my core finally arrives, I can use your version for testing, but ultimately I will need to work on converting the non-blocking version.
Alternatively, I may use an SHT21 sensor. This has a similar spec to a DHT22 (more accurate than DHT11) but has an i2c interface.
Do you have a link to a non-blocking version off the top of your head (or bookmarks menu)? Since I have my Core in hand already, I can give porting it a try. I’ll change the post topic and label this as the blocking version. Thanks for the clarification!
I’m not 100% sure this “library” is working correctly. It seems to work, but the temperature reading is high. I don’t have a thermometer on-hand here at work to verify, but I know it’s definitely not 79.16F in the office. In fact, my analog thermistor, DS18B20, and DHT22 all read in the 79-80F range. Hrmm…
@zach, I didn’t think it would affect the digital thermometers like the DHT22 and DS18B20. Although, it is strange that all 3 sensors (analog thermistor, DHT22, and DS18B20) all report roughly the same temperature. Hopefully I can get a chance to test all 3 sensors in the same loop to get more accurate anamolies.
Keep in mind, temperature varies wildly in a room depending on where the sensor is. It could be under an air vent, it could be close to the Core itself which will be quite a bit warmer than ambient. If even the digital sensor is reading 79, it might very well be within 5 degrees of that!
Hi @wgbartley, I can confirm your code works fine with DHT11. Thanks again for your work on this so far. Temp & humidity readings match the other sensors I have attached to a nearby Arduino. I’m reading the values over serial. Next learning step for me is to expose the variables to the cloud and see them on a web page.
Yes! It’s a ported version of Adafruit’s library. Unfortunately, I stripped out a bunch of comments since it’s still awkward to work with these “libraries” in the web build IDE. I posted what I’ve used to a Gist at https://gist.github.com/wgbartley/8301123.
@wgbartley Thanks for the port of the library. I have it hooked up to a DHT11. The first reading I get is good, but all subsequent readings produce the same output unless I do a reset. Any thoughts on why? Cheers!
Not off the top of my head, unfortunately. I do know that you need to let a DHT22 sit idle for about 2 seconds before you get another reading. I’ve never tried with a DHT11, but I assume it’s probably similar. Now that I look back at the code, not having at least a delay(2000); inside the loop() is probably a bad idea. Maybe try adding in the delay and see if that helps?