The idea is that it will run through the winter, display current temp on a 3-digit 7-segment display, keep track of max, min and average temp (& humidity) and if it gets too cold it will kick in a heater on a relay.
I'm just using a bootloaded '168 on a breadboard at the moment but it's all hooked up and the code works - it measures the temp, averages it, displays current temp and responds to a button-press to display other measurements (max, min etc). It will run fine for several hours.
However, if I leave it running overnight, by the time I get up in the morning the sensor will be giving a read-error. It doesn't respond to a reset of the '168 but if I kill all the power and start again, it reads fine again.
It's quite hard to track this fault down because it takes several hours each time to test a new configuration! I am currently using a 10K between power and data on the DHT22 and I thought about trying a 4.7K (LadyAda seems to suggest that either is fine) but I can't see what difference it will make.
Ultimately, if I can't make it stable, I may have to power the DHT22 from a pin on the micro-controller, so that I can turn it off and on again every few hours but that's not very satisfactory. Anyone have any experience of this issue or any thoughts on what I can do to stabilise it?
I haven't had the same issue. However, I use 1K resistors per one of the spec sheets.
I assume that you're not trying to get more than one reading every couple of seconds, right? That's one thing that the DHT22 is very slow on, leading to bus errors. Also, I would double-check the power going into the device, i.e. make sure you have 3-5V on pin 1 (IRRC).
Timing is clearly important - I tried this running at 8MHz on the internal oscillator and it wouldn't read reliably. I guess that was because the timing wasn't accurate enough. However, it takes hundreds of readings with no errors with the same '168 on a 16 MHz crystal. Then it suddenly stops.
I'll try a lower value pull-up. General voltage on the board was 5.08V, which is 5V to the accuracy of my meter so should be OK. I will check at the sensor in case I've done anything stupid.
I have de same problem.
I hace a arduino UNO reading two DHT11, one 1m and other 70m distance. There are error only in the fare sensor. The nearly work always correct.
¿why? I don´t now. I modificated the library because with the original library, if there is a error reading the sensor, the program go in a while loop and never go down.
pacojarcia:
I have de same problem.
I hace a arduino UNO reading two DHT11, one 1m and other 70m distance. There are error only in the fare sensor. The nearly work always correct.
¿why? I don´t now. I modificated the library because with the original library, if there is a error reading the sensor, the program go in a while loop and never go down.
I think perhaps I was using a different library to read the sensor, but that suggests a dodgy sensor rather than a coding issue.
Have you tired swapping the sensors to see if it's down to the wire length or the sensor itself? My sensor is on less than half a meter and gets this occasional error issue.
I have taken to powering the DHT22 from a pin on the '168 and if I get several error readings in a row then I power it down for a few seconds and it resets.
pacojarcia:
I had thought the same:power the senson by a arduino pin and shut down when there is a problem.
thants
I have done this powering of the sensor from the Ardu' and it seems to be stable, although a further subsequent coding modification has helped a lot too:
It seems that sometimes, after an error reading, the sensor takes a while to settle and if you query it again too soon (i.e. at the normal 2-second rate) you just get into a cycle of repeating errors. I have now coded a simple 5s "delay" after any error reading and I have not seen the multiple consecutive errors issue since.