[Part 1 began with an introduction to wireless sensor networks, and examined factors relating to their organization, size and throughput.]
One of key promises of 802.15.4-based networks is the promise of low power consumption and a multi-year lifetime without a battery change. This promise is made possible by the fact that 802.15.4 standard defines a reduced function device (RFD) which can both participate in the network and sleep for an extended periods of time, giving it an especially low duty cycle and a long battery life as a result.
ZigBee networks differentiate among three device (or node) roles. Not surprisingly, power consumption requirements depend on the device type, i.e. the fundamental restrictions imposed by the ZigBee specification, and the way the device is powered in a particular application, i.e. battery or mains-powered.
There are three types of devices in a ZigBee network:
- Coordinator. This is the "core" node of the entire ZigBee network, responsible for starting the network and managing it to a certain extent. The coordinator is typically mains-powered, because it generates and receives lots of radio traffic and must remain always-on to maintain ongoing operation of the entire network.
- Router. These nodes are responsible for relaying data across multiple hops of the network, extending coverage and network flexibility. Since they also use the radio chip actively, routers are mains-powered in most scenarios.
- End-device. This is the "workhorse" of the network, performing data collection, etc. at regular intervals and/or on demand. These nodes can be (and, in most cases, are) battery-powered and spend most of the time in "sleep" mode, waking either by timer or from external event (interrupt) to receive data from external source (such as sensor, etc.) and send it to the collecting node (usually the coordinator). End devices can also receive control messages queued up at the nearest router, and received during the time interval when the device is awake. Typical scenario for end-device is as follows:
a. Node is in power-saving mode (sleeps) until a wake up event is triggered or external interrupt is received
b. Node goes to full power, optionally re-establishes the connection to the network if it has been lost during sleep, receives the data and then sends it to the parent node over radio (if the network is still available)
c. Node shuts down the radio circuitry and goes back to power-saving mode.
d. Repeat (a)-(c).
The typical stages in the operation of an end device comprise what is commonly known as a duty cycle. When designing a system to have an extended battery life the primary concern is with the end devices as the other nodes in the network are expected to be mains-powered. For end devices, the duty cycle is of utmost importance. It is the parameter that directly affects battery lifetime, and the only parameter that the system engineer can manipulate in the software to achieve longer battery operation. Duty cycle is the proportion of time a device is on out of its total sleep time. For instance, if a device sleeps for 99 seconds, and spends 1 second awake, then the duty cycle of that device is 1%.
The formulas used below do not account for several important parameters, e.g. battery self-discharge and internal leakage, that affect real power consumption and related battery lifetime. Thus the formula should be used solely as a rough guide in estimating appropriate battery capacity in the target application. Also, the formula computes battery lifetime based solely on the power consumed by a network node itself (MeshNetics ZigBit is used as a reference). In actual application, the power consumed by the network node itself is often dwarfed by the connected peripherals, thus any design must account total power consumed by all components in sleep and active states.
The following calculation shows how to compute battery lifetime for a given battery capacity and duty cycle.
Battery capacity: W = 2000 mAh
Because of voltage requirements, actual designs may require more than one battery connected in series. For example, the minimum allowed voltage of 1.8 V will require at least two AA-sized batteries of 1.25 V each. As the batteries drain, their voltage decreases, thus one battery of 1.8 V will last less than two batteries of 1.25 V each.
Total battery lifetime: Twork (seconds)
Time spent in active mode: Tawake (seconds)
Sleep interval: Tsleep (seconds)
Power consumption in active mode (ZigBit module only, without external circuitry or peripherals): Iawake = 19 mA
Power consumption in sleep mode (ZigBit module only, without external circuitry): Isleep = 0.006 mA
Working period (just an example, will vary with every case): Tperiod = 3.6 sec
Now let's find Twork:
(1) Twork = W / Iaverage;
(2) Iaverage = (Isleep * Tsleep + Iawake * Tawake) / Tperiod
(3) Tperiod = Tsleep + Tawake
Here you see that the most important factor is Tawake (length of active cycle, when the power consumption is maximum), since Tsleep is constant in most cases. To illustrate this, we'll calculate the working time for 2 values of Tawake: 20 ms and 200 ms.
For Tawake = 200 ms:
Tsleep = Tperiod - Tawake = 3.6 - 0.2 = 3.4 sec
Twork = 2000 / (0.006 * 3.4 + 19 * 0.2) / 3.6 = 2000 * 3.6 / (0.0204 + 3.8) = 1884 hours (78 days).
For Tawake = 20 ms:
Tsleep = Tperiod - Tawake = 3.6 - 0.02 = 3.58 sec
Twork = 2000 / (0.01 * 3.58 + 20 * 0.02) / 3.6 = 2000 * 3.6 / (0.0358 + 0.4) = 16521 hours (688 days).
Note the drastic difference in the estimated battery lifetime between a 200 ms and 20 ms awake times. Our computation illustrates that the battery lifetime is roughly proportional to the on time. The reason for this is that current drawn in the on state dominates the current drawn in sleep (there are about three orders of magnitude separating the two). Clearly, the system engineer is best served by trying to aggressively optimize the awake time, not trying to make the sleep time longer.