sparkfun/sparkfun_rht03_arduino_library

A simple library for RHT03 temperature and humidity sensor, which communicates over a 1-wire digital interface.

RHT03

A simple library for RHT03 temperature and humidity sensor, which communicates over a 1-wire digital interface.

SparkFun RHT03 Arduino Library

SparkFun Humidity and Temperature Sensor - RHT03

The RHT03 (also known by DHT-22) is a low cost humidity and temperature sensor with a single wire digital interface. The sensor is calibrated and doesn’t require extra components so you can get right to measuring relative humidity and temperature.

Repository Contents

• /examples - Example sketches for the library. Run these from the Arduino IDE.
• /src - Source files for the library
• keywords.txt - Keywords from this library that will be highlighted in the Arduino IDE

Documentation

• Installing an Arduino Library Guide - Basic information on how to install an Arduino library.
• RHT03 Datasheet - Technical details

Products that use this Library

• SparkFun Humidity and Temperature Sensor - RHT03 - SEN-10167- Low cost humidity and temperature sensor.

Version History

• 1.0.0 - Initial release of the RHT03 Arduino Library.

License Information

This product is open source!

Please review the LICENSE.md file for license information.

If you have any questions or concerns on licensing, please contact [email protected].

Distributed as-is; no warranty is given.

• Your friends at SparkFun.

sparkfun_rht03_arduino_library's Issues

Using delay() with noInterrupts()

In function RHT03::update(), the delay() function is used on lines 55 and 59 after noInterrupts() is set.

I have only tested this code on an Arduino MKR WAN 1300 and the delay() function does not work if interrupts are disabled. If it is replaced with delayMicroseconds(), it seems to work. The delay() function gives a constant delay of 800 us, no matter what value is passed to it, if interrupts are disabled. The function micros() is working with disabled interrupts on this board which is essential for decoding correctly.

Since the sensor, according to the specification, requires a low signal >1 ms to start the measurement, a low signal for just 800 us sometimes causes errors. I have seen many comments in different forums that a lot of checksum errors should be expected from this sensor. I don't think it's the sensor, it is this coding mistake in this routine.

I have not tested other boards, they may behave differently.