The fact that 802.15.4/ZigBee applications involve networks of as manyas 65,000 “nodes”, each of which has a radio and a controller, can havea significant impact on the power requirements not only on the networkas a whole, but on each node as well.
This is because the type of node – controller, full function (FFD),and reduced function (RFD) – and the number used can have significantimpact on the power consumption of each node and its ability to lastthe required two years the specification requires.
Controller and full function nodes, such as those in gateway serversor electrical equipment, are usually hard wired to a power source.Reduced function nodes, connected to sensors and switches, are usuallybattery powered. All battery-operated nodes should have a very longbattery life ” if possible longer than the life of the end product.
The ZigBee standard actually mandates a 2-year battery life forbattery-powered nodes. However, where battery life is concerned, longeris always better. Imagine how annoying (not to mention expensive) itwould be to replace all the light switches in a building or house everyfew years.
Several factors affect power consumption: the supply voltages of theradio and microcontroller, the active current drawn by the radio andmicrocontroller, the clock frequency at which the controller operates,the sleep mode power consumption of the radio and controller, thenumber of external components required in the system (particularlypower amplifiers), and the code size, in as much as it affects the MCUclock frequency.
A good rule of thumb
When designing battery-powered nodes, the rule of thumb should be touse a radio with the highest transmit power and the highest receivesensitivity to minimize or eliminate power-hungry power amplifiers. Thecontroller should be supported with a MAC that executes in the minimumnumber of clock cycles. Both radio and controller should supportmultiple supply voltages with the low-end being no higher than1.8-volts, with true 1.8-volt operation.
Since most battery operated 802.15.4/ZigBee nodes (think thermostator light switches) will be in sleep mode 99.9% of the time, waking upperiodically for a few milliseconds to check a sensor or poll the otherradios, total power consumption of the node will approach sleep modepower consumption.
This is important because engineers and vendors tend to emphasizeactive power consumption. However, in a system that is off most of thetime, active power drain can be less important than sleep mode powerconsumption. To illustrate this point take the hypothetical example ofan end node that wakes up once a minute to perform a task that takes 12milliseconds with equal amounts of time spent on transmission andreception. The rest of the time the node is asleep.
As the Table 3 below shows,the total power consumed by just the controller and radio is 0.0062 mA,with sleep mode power representing over one-third of the total. This iswhy close attention should be paid to sleep mode power as well asactive power.
In a real-life temperature sensor node application, themicrocontroller has active current of 8 mA and sleep current of 1.5 uAwith watchdog timer on, while the radio has transmit and receivecurrents of 17 mA and 15 mA and sleep current of 0.7 uA. The actualpower consumed by this application for wakeup, sense, ADC conversion,transmit data, receive acknowledgement, and transition back to sleepmode is 0.0011 mAh, including external components and sensors for eachtransmission cycle.
At a rate of one transmission per minute, this node would consume0.0706 mA per hour of operation. At this rate, two AA 2700mahlithium-ion batteries last about 5.2 years. Increasing the sleep modecurrent on both the microcontroller and the radio by 1uA each reducesthe battery life to 4.8 years ” about 10% less.
In addition to paying close attention to sleep mode powerconsumption of both the radio and the controller, engineers should alsocheck the controller data sheet to verify true 1.8-volt operating rangewhen designing battery-powered nodes. Some microcontrollers that claim1.8V operation in their marketing literature actually require more than2.0V to operate properly. The 0.2-volt difference can cut practicalbattery life by up to 30%. This information may be buried in afootnote, so it is a good idea to contact the vendor directly to verifythe supply voltage.
Avoiding Power Saving Pitfalls
A controller operating below its minimum voltage could execute codeincorrectly, causing code runaway and the corruption of non-volatilememory – an event that can irrevocably damage the application so itnever works again. As a result, brownout detectors (BODs) arefrequently used to monitor the supply voltage and shut the system downbefore it falls below a certain threshold.
Unfortunately, BODs can make a substantial contribution to sleepmode power consumption. A common solution to this problem is to use azero-power brownout detector that consumes as little as a few nanoamps.Although this approach keeps power consumption to a minimum, too littlecurrent may compromise the BOD's accuracy and speed so that the systemfails before the brownout is noticed or a reset executed.
A BOD requires at least 20 uA to achieve sufficient accuracy andspeed to protect the system. One way to achieve this accuracy withoutincreasing sleep mode power drain is to turn the BOD off as soon as thecontroller goes to sleep and wake the BOD up before the controller isallowed to execute any code. This approach provides better brownoutprotection without compromising sleep mode power consumption.
ZigBee and 802.15.4 end nodes frequently need to keep track of thetime, waking up periodically to poll a sensor or check in with acontroller node. In these systems, an accurate real time clock must berunning in both active and sleep modes while consuming a minimal amountof power.
Either a real-time crystal oscillator or a very low power oscillator(VLO) can be used to effect timed wake from deep sleep mode. If timingaccuracy in not important, a VLO can be a good choice. However, ifthere is even a hint that the timing must be accurate, verify that themicrocontroller has a very accurate 32 kHz oscillator.
Keeping Costs Down
Radios frequently require external components, such as filters, poweramplifiers, baluns, coils and inductors, to meet standards for range orsensitivity. External components should be minimized because they costmoney, increase board real estate, and increase power consumption.
Although engineers don't have to become radio architecture experts,they should definitely find out how many of what kind of externalcomponents are required. If two radios meet power consumption andsensitivity constraints and offer a non-intrusive MAC, the best choiceis the one that requires the fewest external components.
Some 802.15.4/ZigBee vendors offer reference designs and developmentkits. In these kits the basic 802.15.4 application is already done andonly needs to be integrated into the target application. It's a goodidea to take advantage of the vendor's engineering expertise in RFapplications. As with everything else, the quality and completeness ofreference designs varies greatly between vendors.
Some vendors provide a simple board with radio, controller and notmuch else, while other vendors provide modular kits with all the piecesneeded to create a working 802.15.4 application right out of the box.The higher-end reference designs include a board with a radio andcontroller, fully featured 802.15.4 MAC, plus an industry standard MCUdesign environment. This type of kit can also include additionalplug-in modules for ceramic and PCB antenna, as well UFL and SMAconnector modules.
The right application framework
If the application does not require a “mesh” networking capability anddoes not need interoperability with equipment from other vendors, someOEMs may prefer to develop 802.15.4 applications using proprietaryapplication frameworks and profiles.
This approach will allow them to establish a position in themarketplace right away, rather than waiting until the final standard isratified. If interoperability is a key feature of the end product, theapplication can be migrated to the ZigBee standard and certified afterit has been ratified,
The variety and quality of application framework and profilesavailable to support each vendor's product should also be considered. Acautionary note about vendor-developed application software: No siliconvendor has the resources to become an expert in every aspect of thehundreds of ZigBee and 802.15.4 applications that are likely to evolvein coming years. It's probably a better idea to use third parties whoreally are experts in the target application. Just be sure that theyhave a close partnership with the silicon vendor to ensure a seamlesstransition from hardware to software for the applications.
Some closing caveats
802.15.4/ZigBee applications are going to proliferate in coming years,but engineers don't need to panic about learning RF standards. Thereare plenty of good vendors of both radios and controllers that offergood solutions for a variety of target applications.
When evaluating 802.15.4/ZigBee system solutions, pay particularattention to the robustness of the architecture and size of the mediaaccess controller, diversity and flexibility of the microcontrollerssupported by the radio vendor, and the receive sensitivity of theradio.
For applications that will have battery-powered end nodesparticularly close attention should be paid to the sleep mode powerconsumption and the voltage operating range of both the radio andcontroller.
To read Part 1 in this twopart series, go to MatchingZigbeeprotocols to the application
Chris Bauman is Director of Atmel'sBiCMOS Products business unit. Prior to joining the company, heheld positions at Texas Instruments and Honeywell where he managedseveral Product Engineering groups supporting non-volatile memories,ASICs and analog products.