Go Down

Topic: attiny84 at 1 MHz internal@3.3V, DHT22 timeouts (Read 2865 times) previous topic - next topic

sstoyanov

Jan 11, 2015, 09:21 pm Last Edit: Jan 11, 2015, 09:42 pm by sstoyanov
Hello,

at @8Mhz the DHT22 sensor works great, but when I go down to @1Mhz I'm getting >90% timeouts.

I'm using
Code: [Select]

// VERSION: 0.1.18
// PURPOSE: DHT Temperature & Humidity Sensor library for Arduino
//     URL: http://arduino.cc/playground/Main/DHTLib


Is there anything specific which I should tweak in the library in order to get DHT22 work with attiny84@1mhz ?

edit: the board is powered by 3.3v regulated, if that matters.

nickgammon

The constructor has a parameter to tweak for the processor speed:

Code: [Select]

// DHT-22 temperature and humidity sensor
DHT dht (DHTPIN, DHTTYPE, 3);    // 6 for 16 MHz, 3 for 8 Mhz (defines pulse width for zero/one)


You could try making the "3" to be a "1" but even then it might not work.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

nickgammon

Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

robtillaart

@Nick
that is another library from ADAFRUIT


@sstoyanov
I could not get the library reliable at speeds lower than 8MHz. The reason is that for the Arduino's at 1MHz the minimal time or granularity for micros() call is 64 usec, so that is not usable to find differences of about 20 usec. Counting iterations in a loop like done in 0.1.18  worked quite well for 8Mhz and "almost reasonable" for 4 MHz but fails - dramatically - for 2 and 1 Mhz. I have been thinking of using hardware timers to measure the pulse lengths but did not implemented it (yet). Because timers count independently it would improve the accuracy/precision and possibly reach the 1 MHz limit.
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

sstoyanov

#4
Jan 11, 2015, 10:22 pm Last Edit: Jan 11, 2015, 10:24 pm by sstoyanov
@robtillaart: Now I see... Thank you for the great explanation! At 8MHz 0.1.18 works just perfectly for me. >99% success rate.

@Nick: I'll run that board on battery, and was trying to save as much mA as I can. The step down to 1MHz saved me a few mA, but I guess I'll stuck with 8 because of the DHT sensor.


nickgammon

I'm running a temperature and humidity sensor on batteries using a DHT22, and have not had to replace them yet, about 17 months later.

That runs at 8 MHz. I don't think you save a lot by running at a slower speed, because your objective should be to be asleep most of the time, in which case the clock is not running, so the clock speed is irrelevant.

That articles states that I had an average consumption of (around) 42 µA, which is below the self-discharge rate of the batteries anyway.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

sstoyanov

#6
Jan 11, 2015, 11:18 pm Last Edit: Jan 11, 2015, 11:25 pm by sstoyanov
@Nick: I was thinking about measuring the data once a minute or two and send it over nRF24. (Its DHT22 + soil temperature + photo resistor + soil humidity). My point was to change the battery once a year at the best case. Otherwise, while sleeping, the tiny and the nRF module are pulling about 9 µA together.

It was just about how much life time can I get without compromising the transmission times.

edit: You have a great website! I was wondering why your name sounds familiar to me, and figured it out.

jurs

at @8Mhz the DHT22 sensor works great, but when I go down to @1Mhz I'm getting >90% timeouts.
And the 10% readings without timeout produce a checksum error?

You cannot use any of the standard Arduino DHT libraries for that.

Just do some timing calculation:

On a 16 MHz Arduino, a simple "digitalRead()" function call will last about 4µs.

On a 1 MHz Arduino, everything ist 16 times slower, so "digitalRead()" will last 16*4µs = 64µs.

Now look into the DHT22 datasheet:
A 0-bit will last about 27µs and a 1-bit will last about 70µs.

How would it be possible to distinguish a 27µs pulse from a 70µs pulse, if every reading of the signal pin takes 64µs for itself?

No chance, I think!

The solution would be:
Avoid every use of "digitalRead()", and do direct port programming to read in the bits from the DHT sensor!

Do you think you are able to handle that kind of programming with PORTx and PINx registers and bit masking with an effective algorithm?

sstoyanov

@Jurs: After robtillaart's answer I saw the reason why it is failing. I ran the sketch for about 3 minutes, waiting 3 seconds between each read. Only 2 times I received an answer, so it makes it around 95% failure rate for my test case. Unfortunately I'm quite new in this kind of programming, so at the moment I'll just stick to the 8MHz fuses.

jurs

@Jurs: After robtillaart's answer I saw the reason why it is failing. I ran the sketch for about 3 minutes, waiting 3 seconds between each read.
3 seconds is just fine. The minimum wait time is
- 2 seconds after powering the DHT sensor
- 2 seconds waiting time between readings


Only 2 times I received an answer, so it makes it around 95% failure rate for my test case. Unfortunately I'm quite new in this kind of programming, so at the moment I'll just stick to the 8MHz fuses.
If 8 MHz is OK for you, just use that.

Go Up