So I have the DHT22, confirmed the chip. I'm using the Adafruit library and test code, and the only difference is I'm using pin 12 as I want to put an LCD on it later. All though I have have used other pins due to my issue.
With a 4k7 resistor, a 10k resistor, and no pullup resistor at all, I get the same values back. Initially I got 1% humidity - categorically wrong, and 32 degrees (seemed wrong).
So I put the whole thing in my fridge. The bottle of water in there has some ice crystals in it, so I'm guessing that the 19.4 degrees the DHT22 is telling me is also categorically wrong. It also still says 1% humidity.
Apologies, I thought the adafruit library and test code where famous and the go-to code to use. Here is my sketch:
// Example testing sketch for various DHT humidity/temperature sensors
// Written by ladyada, public domain
#include "DHT.h"
#define DHTPIN 12 // what pin we're connected to
// Uncomment whatever type you're using!
//#define DHTTYPE DHT11 // DHT 11
#define DHTTYPE DHT22 // DHT 22 (AM2302)
//#define DHTTYPE DHT21 // DHT 21 (AM2301)
// Connect pin 1 (on the left) of the sensor to +5V
// Connect pin 2 of the sensor to whatever your DHTPIN is
// Connect pin 4 (on the right) of the sensor to GROUND
// Connect a 10K resistor from pin 2 (data) to pin 1 (power) of the sensor
DHT dht(DHTPIN, DHTTYPE);
void setup() {
Serial.begin(9600);
Serial.println("DHTxx test!");
dht.begin();
}
void loop() {
// Reading temperature or humidity takes about 250 milliseconds!
// Sensor readings may also be up to 2 seconds 'old' (its a very slow sensor)
float h = dht.readHumidity();
float t = dht.readTemperature();
// check if returns are valid, if they are NaN (not a number) then something went wrong!
if (isnan(t) || isnan(h)) {
Serial.println("Failed to read from DHT");
} else {
Serial.print("Humidity: ");
Serial.print(h);
Serial.print(" %\t");
Serial.print("Temperature: ");
Serial.print(t);
Serial.println(" *C");
}
}
My standard thermometer shows 18 degrees, but the output at the moment is:
The next thing I would do, is edit dht.cpp, and activate some of the comments in there which print outputs about what is going on during the reading process. I'd look at the bytes which are actually received from the device, if they are all numbers like 00 or FF hex, it means your actual line communication is not working.
The temp keeps on rising to about 32 degrees (Which it's not) and Humidity stays at 1%
If I switch off and start again, it continues close to where it was. If I leave it for a couple of hours and start it again, it seems to go back to almost accurate.
Right, So I breathed on the sensor. Humidity ramped up to a calamtous 30% which for breath is way low. Temp got to about 33 degrees. When I stopped, humidity ramped down to 1% again. Temp dropped to about where it was climbing previously and continues to climb... Currently sitting at 31.3 degrees.
The process of converting each of the bytes to a float separately, seems very odd.
I'd put them into the int first, and then make the float. But it should work anyway.
It seems rather dodgy, that the four bytes you print there, are all single-digit hex numbers. Each byte should be two hex digits, at least some of the time.
If your actual temperature is 18 degrees, then your two byte temperature value should be 180 ( decimal ), this is B4 in hex, so your data[2] and data [3] should be 00 and B4 hex respectively, and you seem to be getting 01 and 05 .
nigeljohnson73:
Right, So I breathed on the sensor. Humidity ramped up to a calamtous 30% which for breath is way low. Temp got to about 33 degrees. When I stopped, humidity ramped down to 1% again. Temp dropped to about where it was climbing previously and continues to climb... Currently sitting at 31.3 degrees.
I'm currently thinking I have a dodgy sensor ??
the sensor works by a hydrophilic polymer absorbing moisture and changing its electrical response accordingly. It takes time for it to respond. It shoots up nicely when sudden changes but can take several seconds to get to steady state.
I use this for my DHT22's, and it works: Note the use on the sensor's minimum sampling time. too many readings affect the temperature/humidity.
Your checksum seems OK. This seems to indicate that the communication is working.
So when you are getting your 103 hex temperature, that is 259 decimal which is 25.9 celsius. so that bit works.
If all of the bits were being received one bit out of step, your checksum might be right, most of the time. In other words, you could be receiving bad data and still get a valid checksum. Particularly if the first and last bits in your 40 bit sequence were zero.
So if this happened, your actual hex temperature would be 81. Which is 129 decimal. which is 12.9 celsius. It's hotter than that in your room, right ??
In the second sample of your output that you provided, you'll see the output from reading the sensor, and then you print the temperature and humidity four or five times.
This suggests that your loop function is running around four times than the sensor will actually respond. So, three of the four times, you are printing an old value, not a new one. This seems reasonable enough, sort of. But when I look at the actual code, I am having trouble seeing where this is accomplished, exactly. It seems, you should be getting the NaN's sometimes, but you don't.
The temp in my room at the moment is about 22 degrees according to an LN35 I have wired up on another board. So it makes no sense that the temp from the DHT22 climbs to 30+ degrees. RH is definitely above 1% regardless of how you look at it. I live in England, while we are having a bit of a dry spell, I would still expect 25-50% RH.
@BulldogLowell, I am using the latest version of the Adafruit library that I downloaded again this morning, it doesn't seem to have dht.getMinimumSamplingPeriod() so I am not sure which library you are using.
The data that comes off the board is just printed in HEX for ease I guess, the calc for working out the temp is doing what the data sheet is expecting:
f = data[2] & 0x7F;
f *= 256;
f += data[3];
f /= 10;
if (data[2] & 0x80)
f *= -1;
Given the code is correctly working out the values based on the bytes it reads, and the comms seems to be working because the checksum matches (in running this for an hour, I never get a read fail), the problem must reside with the sensor.
I added the delay(3000) and it reads every time without skipping as per the default Adafruit code, but it still does what it did.
My current 'out-there' theory:
Comms work - checksum is fine for over an hour of operation
Code works - values all match the correct math
RH is very wrong but breathing on it does raise the RH
Temp starts out close if left off for a while, but rises quickly
The RH bit seems like its a bit bust, and it's raising the temperature that the sensor is detecting and correctly reporting.
I think I'm going to stick with the LM35 cuz this is bugging the crap out of me
I recall reading the instructions for one of these sorts of sensors, it was quite complicated, you were supposed to put it in the fridge, then the clothes drier, for three days, some sort of bogus procedure. I don't see anything like that in the instructions for this one.
You said you tried a different version of library code, and got a checksum error. Where did that other code come from ?
nigeljohnson73: @BulldogLowell, I am using the latest version of the Adafruit library that I downloaded again this morning, it doesn't seem to have dht.getMinimumSamplingPeriod() so I am not sure which library you are using.
I think I'm going to stick with the LM35 cuz this is bugging the crap out of me
My Library attached.
I don't remember if I had a problem with VCC at 5V or 3.3V on the DHT22, but I do recall issues there,. I may be wrong.
I think I found the other code you said you tried ( I re-read your first post in this thread... ) , one of the libraries of Rob Tillaart. He's a genius so I am sure he knows what he is doing.
Did you realise, the test program there tries to read a DHT21 and a DHT22 in the same sketch ? It might be, it was reading the DHT22 and getting the error on the DHT21, because you weren't using a DHT21... I'd try it again. If you get the same poor outcome, it would increase the confidence in the conclusion that maybe your device is just defective.
to check if it changes reading as per local weather