Power Consumption

Initial news on the power consumption of a TinySensor just in! A sensor was configured to transmit every 5 seconds until its battery ran down; it managed 1205331 transmissions in just under 70 days on a Duracell AAA Plus. Therefore, if configured to transmit once per minute, it would have lasted for 2 years and 4 months.

This handy page informs us that a long-life AAA Alkaline battery contains about 5kJ of energy, therefore each transmission takes about 4mJ, which equals an average power consumption of 0.8mW. At an average voltage of 3v this requires a current of about 0.26mA. Ignoring consumption by the sensors and boost converter, and estimating current drawn by the radio and processor combined at 25mA, gives a duty-cycle of 1:100, meaning it's awake for 50ms.

Voltage over time looks like this, which seems typical for Alkaline batteries; it jumps around quite a bit at the end, and the interval between transmission times increases considerably.

During normal operation there is a bit of variation between successive readings, I'm not sure whether this is just due to thermal fluctuations or an artifact of the ATtiny's ADC.

The starting battery voltage was logged at an unsurprising 1.51v but the last reading received was an astonishing 0.28v! This shows the amazing ability of the step-up voltage converter to suck every last drop of juice out of a battery. Here we have zoomed in on the end of its life:

Each transmission carries a message-ID which should be monotone increasing, within the limits of its range. The next plot shows that the TinySensor worked perfectly (or at least didn't reboot) for most of its run (and also that the message-ID is 16-bits unsigned):

However, towards the end of the battery's life, this is certainly not the case:

Here we zoom in still further on the system's behaviour at the end of the battery's life:

It is clear that the system halts for increasingly long periods of time while the battery recovers, then it manages a few hundred transmissions before collapsing again. We can look at the time interval between messages on the same time axis as the plot above:

Noticing the change in the slope of the message ID line above, let's zoom in on the corresponding part of the inter-arrival time graph:

Note that this is the time at which the message was written to the database on the Raspberry Pi, so some variation must arise from the behaviour of the Linux kernel on that box, however it's not clear what to make of the rising trend in the graph from about 03:37 onwards. (The processor used its Watchdog timer to sleep; this is clocked using its own 128kHz RC-oscillator so perhaps the falling supply voltage is causing time to dilate!)

Update:

A little experiment with an ATtiny, a blinking LED and an almost-exhausted battery disproves the hypothesis that the watchdog timer is losing time: the blink-rate remained constant until the battery died. Furthermore a voltmeter attached to the battery confirmed that it fluctuated up and down by about 10mV during the sketch's blink cycle.

Update 2:

An important lesson from this kind of experimentation is to keep as many sources of time as possible. We've seen the inter-arrival time above, but what about the transmission time as seen by the sensor? Below is a plot of the inter-transmission time, as recorded by the millisecond timer on the ATtiny:

What is really interesting about this is that all of the noise in the inter-arrival times has vanished! As far as the ATtiny is concerned, there are only 4 distinct intervals between packets: 5s (as intended), 10.45s, 15.9s and 21.4s. My best guess for this is that the radio has only succeeded in transmitting one out of every two, three and four packets respectively. Lastly, the steadily rising inter-arrival time is most likely due to radio-level retransmissions, required due to diminishing transmission signal power.