A key feature of battery-powered devices is an optimized battery life cycle. The battery life cycle affects all aspects of the design process: size, weight, communication standard, sensor type, MCU selection, low-power software solutions, types of batteries and so on — all based on the client’s requirements and the intended operating environment. It’s a complex optimization process which involves a lot of decision-making. We’ll focus on the basic possibilities for extending battery life and let you know a little bit about tests on our devices. Let’s dive into power management magic!

Introduction

A key feature of battery-powered devices is an optimized battery life cycle. The battery life cycle affects all aspects of the design process: size, weight, communication standard, sensor type, MCU selection, low-power software solutions, types of batteries and so on — all based on the client’s requirements and the intended operating environment. It’s a complex optimization process which involves a lot of decision-making. We’ll focus on the basic possibilities for extending battery life and let you know a little bit about tests on our devices. Let’s dive into power management magic!

Basic possibilities for battery life improvement

First, let’s see how we can improve battery life through software changes. The major possibilities are in the device’s main processing unit. Depending on what kind of microcontroller is used, we can choose between different power saving modes. Our devices can work in several operating modes:

• active — the default setting; all peripherals and external components (sensors, radio) are turned on,
• sleep — some microcontroller peripherals (depending on the microcontroller type) and external components are stopped by firmware (not turned off), enabling us to proceed quickly to the measurements,
• deep sleep — microcontroller peripherals work with low-speed clocks and are turned off when not in use; external components are turned off by hardware; SRAM and registers still hold data; the microcontroller can be woken by RTC, watchdog or external events,
• shutdown — only the essential microcontroller peripherals work with low-speed clock, e.g. RTC; SRAM and register content is lost; microcontroller can be woken by RTC or external events such as reset.

When preparing the data frame and sending it to the gateway node, the device operates in active mode — it communicates with external sensors and uses radio to send data frames. That means high energy consumption and quick battery discharge if we use a low data-sending interval (see figure 1 for differences in current and voltage between the active and deep-sleep states). The opposite is shutdown mode, where the energy consumption is lowest, but at a high price: we have limited possibilities to wake the device up and, if it takes a long time to do so, all data in SRAM and the registers are lost, so the device will need to be re-initialized. Therefore, this operating mode is rarely used. For saving energy, we instead keep the device in deep-sleep mode as much as possible.

Figure 1. Influence of device operating modes on current and voltage.

Apart from the MCU, there are a lot of components which can be chosen or set for better energy efficiency — sensors, memory and communication modules. The goal is to choose those which consume the least energy in active mode, and whose power-up time is quite short. Table 1 shows one of the sensors used in our device with power management modes.

Impact of Spreading Factor on battery life

After selecting hardware and software tools, the next step is to select a communication standard. We can choose from a wide variety of wireless possibilities, but some of them are much better for long range and power efficiency (see figure 2). We’ve chosen LoRaWAN, which combines cheap communication modules, no need for a license, long range, and low energy consumption.

Figure 2. Comparison LoRa and other communication standards. https://www.semtech.com/lora

To set up LoRaWAN communication, we must choose a Spreading Factor parameter (SF7–SF12). The Spreading Factor affects the device’s crucial parameters: range, bit rate and time on air (radio on-state time). These three variables are inter-related — by selecting the Spreading Factor, we set bit rate which, combined with frame length, defines the maximum time on air (see table 2 and figure 3). To reduce the time needed for sending frames, the LoRaWAN standard uses the Adaptive Data Rate (ADR) algorithm which allows dynamic changes to the sending time by monitoring the connection parameters and changing the Spreading Factor if needed. Increasing the Spreading Factor level can be required to maintain the node’s connection to the LoRaWAN gateway, and also to improve the system’s range. The ADR algorithm can reduce energy consumption when the nodes are close to the LoRaWAN gateway, reducing also the transmission time (time on air), and increasing the bit rate. On the other hand, when we reduce bit rate, time on air will increase which increases energy consumption. ADR is commonly used to improve battery life in LoRaWAN devices.

Table 2. LoRaWAN Spreading Factors in relation to Bit Rate, Range and Time on air.
https://lora-developers.semtech.com/library/tech-papers-and-guides/lora-and-lorawan/
¹ For UL at 125 kHz.
² Depends on terrain.
³ For an 11-byte payload.

Figure 3. LoRaWAN Spreading Factors in relation to Bitrate, Range and Data Rate.
https://www.digikey.pl/pl/articles/lorawan-part-1-15-km-wireless-10-year-battery-life-iot

Typical batteries for wireless devices

The most popular way to power LoRaWAN nodes is to use a 3–3,6 V battery. Depending on requirements, devices may need one or several batteries, chosen for their rechargeability, dimensions, capacity, and price. Rechargeable batteries are very rarely used due to their price, size and the difficulty of charging them. Table 3 lists the most popular batteries currently used in IoT LoRaWAN devices.

Table 3. Comparison of the advantages and disadvantages of popular IoT batteries.

Energy consumption in our LoRaWAN devices

To show the influence of the prospective solutions, we conducted a few tests with our devices (figure 4). As representatives of different approaches we’ve selected the YO Temp (larger enclosure, designed for low and high-varying signals) and the ultra-low-power YO 360 (very small enclosure and long battery life cycle). To compare not only the power management solutions but also battery impact, we’ve prepared 2 test cases with different battery capacities. A Joulescope DC Energy Analyzer was used to measure the energy consumption (figure 5).

Figure 4. Tested devices: (A) YO Temp, (B) YO 360 with SX1261, (C) YO 360 with RFM95, (D) YO LoRadio based on SX1261, (E) communication module RFM95.

Figure 5. Energy consumption metering system for tests.

YO 360 powered by CR2450/77 batteries

The device was connected to the analyzer and operated for the full 24 h. After this time, we analyzed the collected data and determined the average energy consumption of the device in various operating modes (table 4).

Test parameters:

• duration: 24 h,
• device: YO 360 with radio based on SX1261 and RFM95,
• LoRa frame sending interval (active mode): 30 min, 1 h, 2 h, 4 h and 8 h,
• Bluetooth advertising interval: 1 s and 6 s,
• battery: CR2450 (700 mAh) and CR2477 (1000 mAh),
• LoRaWAN mode: ABP and OTAA,
• ADR: on,
• LoRa region: EU868.

Table 4. Average energy consumption by the device in various operating modes, assuming that the device wakes up every 30 minutes to send the LoRa frame.
¹ The device takes measurement and LoRa send frame.
² Only Bluetooth advertising.

As we can see from table 4, decreasing the Bluetooth advertisement interval (from 6 s to 1 s) increased the power consumption by almost 4 times in deep sleep mode, and the total energy consumption more than doubled. The RFM95 communication module is based on the SX1276 chip, so it is difficult to compare it to our radio (based on the SX1261).

When calculating the battery’s life, we assumed that we can only use 70% of its total capacity. This is a very important issue because it allows for the battery’s voltage drop as it discharges. When the voltage drops below the permissible minimum supply value, the device will reset or shut down, resulting in unstable operation.

Figure 6 shows the battery voltage in a device operating for over a year. As we can see, the battery voltage is slowly dropping.

Figure 6. Slow battery voltage drop measured by the device from 2020.02 to 2021.04.

Based on these measurements, we have determined the maximum number of frames that the device can send and how many days it will work. The results are summarized in table 5.

Table 5. Test results for YO 360.

By looking at the values in table 5, we can see that the method of activating LoRaWAN (ABP or OTAA) does not significantly alter the energy savings. Changing the Bluetooth advertising interval from 1 s to 6 s, on the other hand, can at least double the battery life. The data also confirm that the device should be kept in deep-sleep mode as much as possible. The more we wake it up for measurements and to send LoRa frames, the more we draw down the battery. In the case of non-critical measurements and slowly varying signals, we can adjust the sampling frequency to keep the device in deep sleep mode longer, as a strategy for reducing energy consumption. As our results show, reduced consumption makes it practicable to use even use small batteries such as CR2450 or CR2477.

YO Temp powered by lithium-thionyl and alkaline batteries

We repeated the tests for another device (YO Temp) that can run on different types of batteries.

Test parameters are now:

• duration: 1 h,
• device: YO Temp with RFM95,
• LoRa frame sending interval (active mode): 2 min,
• Bluetooth advertising interval: 1 s,
• used battery: lithium-thionyl 3,6 V size D (19 Ah - 19000 mAh) and alkaline 1,5 V size LR6/AA (2500-2000 mAh),
• LoRaWAN mode: ABP,
• ADR: on,
• LoRa region: EU868.

Table 6. Average energy consumption by the device in various operating modes, assuming that the device wakes up every 2 minutes to send the LoRa frame.
¹ The device takes measurement and LoRa send frame.
² Only Bluetooth advertising.

Table 7. Test results for YO Temp with different types of batteries and approximate lifetime of the device, assuming that the device wakes up every 2 minutes to send the LoRa frame.

As we can see in table 7 (calculations based on results in table 6) a device with 3xRL6 (AA) size alkaline batteries will last up to 3-4 months. Thanks to the larger size D lithium-thionyl batteries we can extend the life of the device from several months to several years (table 7). When measuring critical values and rapidly changing signals, the use of larger batteries is necessary in order to ensure frequent measurements and a long service life of the device.

Conclusion

Extending the life of battery-powered devices can be achieved in two ways - through software and hardware changes. Since we create firmware for hardware it is also very important to properly select energy efficient components. Putting a bigger battery is not always the best solution – it has a negative effect on the final product which becomes bigger (less aesthetic) and more expensive. On the other hand that action reduces the cost of maintaining the device (battery replacement) which might be crucial when there is a difficult access to a battery powered node.

Measurement time interval has a great impact on battery life and must be chosen wisely. We must thoroughly analyze the characteristics of the signal to obtain the proper amount of information. We cannot always afford the low sampling frequency – In some cases, the measured signal may change abruptly or very quickly. Then it is reasonable to perform measurements often, and thus it becomes necessary to use larger batteries with a greater capacity.

Thanks to the tests we have performed you should have a better idea of how certain parameters affect devices energy consumption and what kind of battery estimations we can expect from LoRaWAN devices.