Archived Forum

The claimed accuracy is ± 0.5 °C. I have wondered whether self-heating takes place, but I can find no mention of that in the data sheet. I suspect you could temporarily reprogram the low power module to run continuously to see whether the difference narrows.

Robert,

I may give that a try just to see if it does affect the readings. Will post results when I have some.

Keith

I've done a fairly informal test, and I've concluded that a rough-and-ready figure for self-heating is about 0.2 °C in moving air and about 0.5 °C in still air.

I set up an emonGLCD upside down (so that the  DS18B20 was at the bottom) with a mercury thermometer (1 °C being about 1.8 mm scale length!) about 10 mm from and level with the sensor, and allowed the whole lot to stabilise. The GLCD is displaying to 1 decimal place.

I powered the GLCD and immediately read the temperature on the GLCD and the mercury thermometer; then let it warm up for 5 mins and checked the temperatures again. I fanned the sensor for 2 mins with a piece of card, then allowed it to warm up for 5 mins again. Then I left the GLCD off for about 15 mins before repeating everything.

Run 1
From cold: 21.1 °C (mercury just over 21 °C)
after 5 mins: 21.5 °C.
fanned: 21.3 °C
after 5 mins: 21.5 °C.

Run 2
From Cold 21.2 °C (mercury just below 21½  °C)
after 5 mins: 21.7 °C.
fanned: 21.4 °C
after 5 mins: 21.8 °C.

Run 3
From Cold 21.2 °C (mercury just below 21½  °C)
after 5 mins: 21.6 °C.
fanned: 21.3 °C
after 5 mins: 21.8 °C.

Interesting results. This is quite topical at the moment. I'm currently working on a little unit called the emonTH. Its a remote temperature and humidity monitoring node with an option for DS18B20 (temperature) or DHT22 for humidity & temperature. External DS18B20's can also be connected. The unit will be wall mountable and battery powered, maybe 6 months + battery life, I hope we might be able to get a year or so battery life with optimization and taking readings every min or so  

I'm currently testing prototype #1. 

To keep power consumption down the sensors are powered from a digital output and are turned off in between readings. This should stop any self heating effects. I'll do some testing and report back. 

Glyn, I've had a PM from someone about inaccuracy in the DHT22 RH sensor. Apparently, there's an error in one of the libraries. This thread http://jeelabs.net/boards/7/topics/1469 has the details. There is also a method using concentrated salt solution to obtain an absolute calibration at a spot value - details at http://en.wikipedia.org/wiki/Hygrometer#Saturated_salt_calibration and yet more details at the reference cited there: Salt Calibration of Hygrometers

Does anyone have a bit more experience with the DHT22/AM2302 and/or DS18B20? They seem to be specified for 3.3V and 3.0V minimum supply voltage. How is accuracy or function in general affected by lower supply voltages (two AAs or AAAs)? Or is the new emonTh equipped with a boost converter?

I see Martin Harizanov has picked up my post above here: http://harizanov.com/2013/06/dht22-accuracy-test-part-1/?utm_source=rss&...

Martin's experiments a little while ago with a boost converter certainly seem to suggest that its inclusion would be a good idea. End of life for a single cell is generally reckoned to be 0.8 V, so 1.6 V for two in series - I don't think it is reasonable to expect a 5 V (min 3.3 V) device - the DHT22 - or a 3.0 V min device (DS18B20) to work at all at a voltage as low as that. And sorry, but I haven't tested the DS18B20 for accuracy at anything other than the normal voltage, and I haven't got a DHT22 to test. All I can say is if the manufacturer specifies a minimum voltage, that's what they mean - no guarantees below that. You might get one sample or one batch that's ok at a particular voltage, the next might not be.

All I can say is if the manufacturer specifies a minimum voltage, that's what they mean - no guarantees below that.

And the same is true for the ATmega328 which is also not guaranteed to work with 16MHz clock at these low voltages (AFAIK the RFu328 has a 16MHz resonator mounted).

> I'm currently working on a little unit called the emonTH

Great. Is there more info on this yet ?

Did you consider LiPo batteries ?

Power down mode with watchdog wake-up ?

Use a low res on the temp sensor ?

I reported my experience here http://openenergymonitor.org/emon/node/2331 concerning accuracy and battery voltage.

and from my experience so far a can definitely recommend using a step-up regulator.

What's wrong with installing the 3.3V regulator and using a higher voltage battery and letting it run all the way down to about 3.5V?

The regulator only draws 2 microamps so the extra usable battery capacity should easily cover that.

What's wrong with installing the 3.3V regulator and using a higher voltage battery

I don't know if there is anything wrong with it.  I did indeed look at using three or four AA cells, but I concluded it was cheaper / easier to use two AA alkaline cells and the step-up regulator.  They will last approx two years for me at one measurement each minute.

see here

I haven't any experience, and I haven't done the sums, but if you're using a linear step-down regulator, it is dissipating power, and hence energy, to ambient. If you're using a switched-mode step-down, or a single cell and a switched-mode step-up, regulator, then I wouldn't like to bet which is the more efficient, but I would bet that both are more efficient than the linear one.

So I'd say that in terms of running cost, using a linear regulator and higher battery voltage than necessary will cost more.

-"The unit will be wall mountable and battery powered, maybe 6 months + battery life, I hope we might be able to get a year or so battery life with optimization and taking readings every min or so "

Start to ignore all duplicate sensor readings, i.e. if the new value is almost equal the last value then there is no point to send it.

I have been playing with this idea in another project, but it could help your battery problem.

More or less.

1. Read the value every minute.

2. If value is within +-0.5 deg from last send value, then ignore it (and keep the radio powered off), but if the change is bigger than the +-0.5deg then send the value directly.

3. To know that the sensor is still alive, send a value every 30-60min even if it is the same as before.

This will save battery and still tell you when there is change in readings, since the change is the interesting.

Please note that in my project I have the device powered with PoE so I don't care about powersave, I only care about getting the relevant data, and with the above idea I can poll my sensors every second and safely ignore 95% :)

My little test project (with unit tests) can be found here:

https://github.com/jsiei97/FunTechHouse_RoomTemperature/blob/master/FunT...

https://github.com/jsiei97/FunTechHouse_RoomTemperature/blob/master/test...

/Johan

Unfortunately we're going way off topic, from calibrating to battery life.

Working on a similar design (currently napkin/brain stage) there should be much better ways to handle this.

Looking at the size of the device, wouldn't it be far far more interesting to use some cheap lipo and a small solar panel? You hang it somewhere at the wall, even if the lightsource is weak, it should charge a little bit. If you do all the conserving things mentioned above, the battery (charged) could last a few months, so if it charges, even only 10% per day, it should be fine. Things like this come to mind:

http://www.ebay.com/itm/Portable-Mini-Solar-Power-Panel-3-LED-Flashlight...

It has a battery and a small solar panel and most importantly, costs next to nothing, 1.20 USD shipped world wide at retail priceing. Better alternatives can be thought of for sure. That's almost cheaper then those batteries.

Obviously for situations where there's no (sun)light at all to charge it, batteries will remain to be required. Also having it in direct sunlight has the side effect that the temperature isn't measured properly anymore, but if the device is cheap enough (< $10) you can have a few around the house!

That sounds vaguely familiar - search the forums and I think you'll find someone has done it - or similar. But surely you should have started a new topic for this.

I have been trying that saturated salt test over the past few months and got some pretty interesting results. I took six sensors and sealed them all in a test cell with a variety of different saturated salts to try and get a 12 point calibration curve over the whole range 0 - 100%. I do not claim to be an expert or that this experiment is flawless, but if anyone is interested my write up is at
     http://www.kandrsmith.org/RJS/Misc/calib_dht22.html
These are just the results I got for my devices. At the level of errors I am seeing, the fault could just as likely be in my experiment as in the devices themselves.

I still do not really believe the datasheet's 2% absolute accuracy claim from 0-100%, but they are amazingly good for the price and come surprisingly close to that. The maximum errors I have measured are about 6% RH, with typical errors of 2-3% RH. I see quite a strong temperature dependence of at least 2% RH over the temperature range I have tested so far but am still working on that. I have not done any long term tests, but on timescales of a few weeks I find repeatability in the range 0.5-1% RH.

More importantly though, it's been fun.

That's a very interesting, well written and informative document Robert. I learned a lot from that while drinking my morning tea - thanks for posting.