Optimizing Z-Wave IoT Devices to Achieve 10+ Year Battery Life
This is an abbreviated version of the full blog on the Z-Wave Alliance website.
Introduction
Wireless IoT devices are typically powered with batteries. Thus, a key design criterion is: how long will the batteries last? Z-Wave developers must balance battery lifetime, battery type and functionality. Simple Z-Wave sensors can run on a single coin cell for as many as ten years. Door locks need four AA batteries to mechanically throw the locking bolt, but the electronics contribute significantly to battery life. Most devices need at least a two-year battery life otherwise customers feel they are constantly changing batteries resulting in a one-star review.
There are three components of battery life calculation:
- Average current while sleeping
- Average current while awake
- Awake duration
Battery lifetime calculation: Blifetime = Bcapacity/((Iawake * Tawake * Nwakeups) + Isleep)
For example: A device with 3 AAA batteries has a capacity of 1000mAhr, an average awake current (Iawake) of 12mA for 0.2 seconds (Tawake) with 6 wakeups per hour (Nwakeups) and an average sleep current (Isleep) of 0.030mA, you get 1000/(12*(0.2/3600)*6+0.03=29,000 hours or 3.3 years. Thus, the key for long battery life is to minimize the average sleep current and limit the number of times the device wakes up. Obviously matching the size of battery to the task at hand is crucial. Too small of a battery and the user is annoyed with replacing it too often, too large of a battery increases the physical size of the product and the cost.
Troubleshooting
The classic problem when debugging a battery powered device is isolating a high current draw. When debugging a new design, the typical problem is that the board is drawing hundreds of microamps (or even many milliamps!) when it should be under a few tens of microamps. The obvious first thing to check is if the CPU is sleeping. Load the firmware into a devkit so it is the only device drawing power. This isolates all the other sensors or circuits on the board so at least you know the CPU is asleep. Here’s a brief checklist for high current debug:
- Is the CPU in Sleep mode?
- Is the high-speed oscillator off?
- Are GPIOs floating? Unused inputs might oscillate which can draw a lot of power
- Are GPIOs fighting pullups/pulldowns? Try disabling pullups/pulldowns in the debugger
- Are other circuits drawing power?
- Cut power traces, lift power pins, lift circuit pins, remove circuits from the board
- Debug GPIOs causing phantom power draw?
- Disconnect ALL debug connections – SWD/JTAG and even ground
The big problem comes when customers start returning the product because of short battery life. You may have optimized the battery life in the lab, but did you test it in the real world? One thermostat I worked on would constantly send a humidity report because the humidity reading would bounce back and forth by one percent with each reading. Never saw this in the lab but it became quite common in the field. This was easily solved by adding hysteresis to the readings and requiring the humidity to change in one direction by more than three percent before sending a report. Fortunately, we were able to OTA the firmware and solve the problem before it became widespread.
A serious problem with early FLiRS (now called LSEN) door locks didn’t become a problem until many locks on many Z-Wave networks were installed in a single building. The original WakeUp beam only had the NodeID of the door lock to wake up. The problem was that with many Z-Wave networks in close proximity, every door lock having NodeID 02 (which was the case on all of the networks in the building) when the controller woke up their door lock, all the door locks on all the adjacent networks would wake up because they were all NodeID 02. Battery life in many cases was only a few months due to the gateway polling each door lock every night which meant every door lock woke up hundreds of times every night. This was solved years ago by adding a hash of the HomeID to the WakeUp beam which pretty much assures only the desired node will wake up.
A particularly difficult battery life problem happened with a door/window sensor that in rare cases would remain awake. We had to set up a dozen units and watch the power on them all individually and when one stayed awake for more than 60 seconds then we captured data and stopped the test so we could debug the problem. Turned out the stack was overflowing, causing impossible conditions as I mentioned in Part 5 of the Developers Journey. Often the device continued to function, but it just didn’t sleep causing the battery to die in a few days. Turned out the cause was a complex interaction of interrupts and the Z-Wave mesh rerouting at the same time which is why we didn’t see it in lab testing. Masking all interrupts while servicing the sensor and some careful adjustments to the stack sizes solved the problem which was OTAed to all units in the field.
Remember that each radio transmission uses a significant amount of power. Keep all communication to a minimum especially when powered with coin cells. Ensure that all possible values of configuration parameters can’t accidentally cause rapid transmissions.
Tools For Measuring Power Consumption
Every Z-Wave firmware developer needs access to power measurement tools. These tools can range from Silicon Labs AEM which is part of the development kit to expensive laboratory tools. Measuring the current draw versus time and a few GPIOs is critical for rapidly optimizing battery life. Bill Hewlett, co-founder of Hewlett Packard, has a popular quote: “You cannot manage what you cannot measure… and what gets measured gets done.” The list below provides some tools I’ve used for optimizing battery life – let me know what you’ve had success with!
5-1/2 digit Digital Multi-Meter (DMM) or Bench Power Supply
DMMs with at least 5-1/2 digits have enough dynamic range to measure milliamps to nanoamps. Modern DMMs come with USB and can be remotely controlled and record waveforms for voltage and current but typically lack additional channels for GPIOs or UARTs. DMMs are super accurate for very low currents which is why I typically use one to precisely measure deep sleep current. A good DMM costs $250+ but there are multi-channel power supplies that have similar capabilities for about the same cost. I often use a cheap DRoK power supply with an OLED display to know when the device is sleeping or not, when I don’t need nanoAmp accuracy.
TinyCurrent
The TinyCurrent is a cute and cheap device to convert current into voltage which you then connect to your scope. This is a simple opamp across three switch selectable shunt resistors to select the range. The switch is the main limitation of this device as the dynamic range isn’t enough to cover the milliamp awake mode to the sub microamp sleep mode transition. Since it’s a simple analog conversion of current to voltage, it is easy to connect to a scope along with several GPIOs. Measuring the deep sleep current must be done with a DMM or other device but this works fine to quickly see when the device is in deep sleep or active modes.
Nordic PPK
The Nordic Power Profiler Kit II (PPK2) is a cost efficient and capable power measurement tool. The nRF Connect windows app displays the current graphically along with up to 8 digital GPIOs. PPK2 measures between 200nA and 1A at 100ksps. The PPK can supply up to 1A of 3.3VDC but I found the supply isn’t clean enough to measure small currents accurately. Instead, I use a battery (usually 3 AAA in series) and pass that through the PPK to get a clean power supply. As a side benefit of using real batteries, the voltage sags during high current draw since the power source is an actual battery. The high dynamic range is achieved by switching between 3 shunt resistors which take several samples to switch. Unfortunately, this is often exactly the behavior that is of interest. Overall, this is a capable tool for an affordable price.
Silicon Labs AEM
Silicon Labs Advanced Energy Monitor (AEM) is the primary power measurement tool for Z-Wave developers. A WSTK (BRD4002) developer’s kit is required to run the AEM which you can now purchase by itself instead of part of a more expensive kit. The AEM supplies 1.8-3.6v up to 500mA with a 100kHz sample rate and a resolution just under 1uA. There are four digital logic inputs as well as the VCOM UART. The Energy Profiler is a tool within Simplicity Studio that provides a graphical interface for the AEM. The energy profiler tool suffers from stability problems but is capable if you are working with Silicon Labs Z-Wave chips.
JouleScope
Joulescope is currently the industry standard for IoT development. While pricey, it is the perfect tool for the job. Full disclosure: Joulescope provided me with a JS220 for a previous project which I now use for every project. Wide voltage range of +/- 15V, 3A to 0.5nA resolution, 300kHz bandwidth and a reliable multiplatform software application make the Joulescope indispensable. The JS220 has 4 digital inputs and 2 outputs which help correlate current draw with the firmware being executed. The newer JS320 version is now available with even more dynamic range. The screenshot shows the dynamic range from microamps to over 400 milliamps and two digital logic signals indicating the state of the CPU.
Oscilloscope Current Probe
Traditionally, an oscilloscope current probe was used for measuring current and simultaneously sampling several analog or digital channels. The problem with most of these probes is they were designed for high current (60A or more) and relatively low bandwidth and are very expensive, costing around a thousand dollars just for the probe without the scope. They do not have the dynamic range to go from nanoamps to milliamps and generally don’t have the resolution below milliamps. Maybe there’s one in a drawer somewhere you can use but I wouldn’t buy one of these for debugging IoT devices.
Next Steps
Part 8 of the Z-Wave Developer’s Journey discusses sub-GHz antennas which can make or break a Z-Wave product. The distance a Z-Wave product can be from the hub is determined by the efficiency of the antenna. I’ll discuss a few key factors in low-cost antenna design from my experience of having deployed many different types of antennas. As we continue along the Z-Wave Developer’s Journey, I welcome your comments and questions. Please feel free to reach out to me directly via email.
HomeSeer has several platforms so the precise method might be slightly different than shown here. From the web interface home page select the menu Plug-Ins->Z-Wave->Controller Management then select the Action “Fully Optimize a Network”. The network wide heal will take some time depending on the size of the network.
SmartThings user interface is thru their app which makes finding the network heal a bit of a challenge. Start from the dashboard and click on the three lines in the upper left corner. Your Hub should be the first choice in the menu that slides out, click on your hub. A new menu comes up, click on the last choice “Z-Wave Utilities”. The last choice on the next menu that slides in is “Repair Z-Wave Network” so click on it and then click on “Start Z-Wave Network Repair”. The repair will take from minutes to over an hour depending on the size of your network.
Vera has several versions of their UI but each of them has a similar menu structure so these instructions should work on any version. The Vera version shown here is UI7. Use a PC to log into GetVera.com and select your hub. From the Dashboard, select Settings->Z-Wave Settings and then click on the advanced tab. At the bottom of the advanced tab is the GO button to run the “Update Node Neighbors”. Depending on the size of the Z-Wave network this process will take several minutes to over an hour.
Or you may have inadvertently included the device but the inclusion process failed somehow and the hub is confused. Excluding the node should reset it to the factory fresh state. Newer Z-Wave Plus devices (which have this logo on them) are required to have a way to reset them to factory defaults using just the device itself. Every device is different so you’ll have to refer to the device manual to perform a factory reset but if all else fails this should make the device ready to pair. Naturally having the hub physically close to the device being paired will also help though most devices can be paired from a distance.
