I’ve been struggling for thinking and tinkering time this week due to a bad cold that has totally wiped me out but I did have some more thoughts on further reducing the power usage of the TempTX V2. The first one is quite simple and will only have a minor effect but only needs a minor code change – it turns out that it is possible to reduce the time the DS18B20 temperature sensor takes to get a reading by reducing its resolution as shown in the table below. It is currently using a 12 bit resolution but even reducing it to the lowest setting of 9 bit, an effective resolution of 0.5°C at a time would be acceptable for most applications I think.
| Resolution | 9 bit | 10 bit | 11 bit | 12 bit |
|---|---|---|---|---|
| Conversion Time (ms) | 93.75 | 187.5 | 375 | 750 |
| LSB (°C) | 0.5 | 0.25 | 0.125 | 0.0625 |
Milliseconds might only seem like a small difference but that is as much as an 8 fold difference and as I said in the last post, every little counts.
Secondly, a completely unrelated discussion on Twitter at the weekend lead to a likely explanation for the total drop out when the battery voltage reaches 2.7V, namely that the default BOD (Brown Out Detection) fuse setting for the ATmega328 when using the default Arduino bootloader is 2.7V (sound familiar?), when the voltage drops below this level the mcu is put into a reset loop until it rises again. That explains the sudden cut off at 2.7V.
With some fiddling and reflashing of the bootloader this BOD setting can be changed to 1.8V or even disabled completely and some brief research shows that the ATmega328 can run from as little as 1.8V (although it would be out of spec running at 16MHz at that low of a voltage) and that the RFM12B module should run OK down to 2.2V so there is plenty of room there. Surprisingly the DS18B20 temperature sensor is not so tolerant, the datasheet says it needs a minimum of 3.0V, however, I’ve already proved that it runs ok at 2.7V (at current average temperatures anyway) and a little research found some reports that it works down to around 2.6V before it starts to give errors and the addition of an electrolytic capacitor should be sufficient for it to get a reliable reading at even lower voltages, especially at the lower resolutions where it needs to be powered for a shorter amount of time. I might try some more voltage tests with the BOD disabled to see how low I can get the whole thing will go before it starts to become unreliable.
Another, maybe more sensible option might be to look at some different temperature sensors that are rated to work at lower voltages, there are several cheaper analogue alternatives to the DS18B20 that might make more sense, they would need to be calibrated though and it would mean only one sensor per input (not really a factor with the way I’ve been using these boards so far) but would have a secondary advantage in that the 1-wire and Dallas Temperature libraries wouldn’t be required which might mean that the code can be reduced to fit into one of the smaller ATmega microcontrollers thus reducing cost again.
Please feel free to post in the comments if you can think of any other suggestions or improvements.
Glyn at OpenEnergyMonitor.org is now running an experiment on their emontx board using the reduced BOD value, see the progress along with a nice emoncms graph here: http://openenergymonitor.org/emon/node/342
I’ve done some testing with the BOD set to 1.8V now and it seems to work ok down to 2.3V before the DS18B20 starts to return random temperature readings. That’s a lot lower than I expected it would go. The RFM12B carries on working down to around 2.02V but does seem to get a bit unreliable once it drops below 2.1V (probably the tx power dropping) so a bit more might be gained by using a different sensor but I’m happy with 2.3V for now.