Energy Saving Tips for Constrained IoT Devices

January 06, 2023

Blog

As IoT matures as an industry, it’s becoming clear that most use cases will involve battery-powered devices, which poses a unique set of challenges. As much as 70 percent of IoT projects may fall into this category, and their chance to thrive is going to depend entirely on energy saving strategies to prolong device lifetime.

Energy saving is a puzzle

Energy saving requires many odd pieces that must be carefully tweaked individually, and then orchestrated together to create a whole. It requires an end-to-end approach in planning and developing energy-optimized solutions. From the outset, it’s essential to have a very detailed plan for the use case and develop clear answers for a handful of key questions.

These are the key questions every developer should ask before taking any action:

• What is the use case?
• How long does the device need to last? A week, month, year, decade?
• Can data be lost? Does it need to be retransmitted?
• How often does data need to be transmitted?
• How big is the payload?
• What is the maximum physical size of the battery?
• Can recharging mechanisms (e.g., solar or manual battery exchanging) be leveraged?

Every use case is unique and there are countless permutations that can be tweaked based on answers to the above, but there are several general recommendations that should apply to nearly any IoT project.

Here are the top recommendations:

1. Everything starts with the hardware setup for an IoT project. On the microcontroller (MCU) level, the hardware should meet the requirements of the use case almost exactly. Obviously, underpowered hardware setups won’t work, but overpowered hardware means higher costs, as well as wasted energy. Great is the enemy of good, so don’t overspend or buy hardware because it’s a great deal. A couple of good MCUs to start with might be STM32 or ESP32, but it all depends on the use case.
2. It’s advised to put the CPU / MCU into deep sleep modes whenever possible. Most modern MCUs support deep sleep modes already, but it’s important to double-check whether the chosen component supports it.
3. Also on the hardware front, it’s important for cellular modems using NB-IoT or LTE-M to support Release Assistance Indication (RAI), Power Safe Mode (PSM), and Extended Discontinuous Reception (eDRX). Note that these may not be available in all countries or through all carriers, so it’s important to check into every rollout scenario. NB-IoT is often recommended over other bearers when it comes to energy optimization, but for moving products, LTE-M might be the better choice.
4. Turning to the firmware, particularly the operating system, are there processes or threads running in the background that aren’t needed? Make sure there isn’t anything on that will slowly and surely drain the battery. To find out which processes can be disabled, look at the entire list of processes running and research the purpose of each. If it isn’t required for the use case, turn it off.
5. The business logic of the firmware also needs to be taken into account. It’s important to optimize the data processing by reviewing the sensor values and determining how often it’s necessary to send them. Distinguish between how often sensor values get recorded from the source, and how often these measurements get sent to the cloud system. It’s generally not necessary to record or send them at the same time, so a good tweak is to record them often, buffer locally, and send in batches to reduce radio airtime. Or only the send averages of the values.
6. Try compressing the message payload before sending. Instead of sending a verbose and explicit JSON object over and over again, save energy by compressing the data into a binary format. A good example is Binary Conversion Language (BCL), which uses a template that instructs how to turn JSON into binary, and vice versa. Of course, the cloud endpoint must decompress the data when it receives it to get the original message.
7. There are choices in optimized data transmission protocols that can make a big difference when building energy-optimized products: Protobuf instead of JSON, CoAP instead of MQTT, NB-IoT instead of LTE.
8. During development, it’s essential to measure, then measure again. Create a scientific environment to do tests, ensuring it’s repeatable. Try to set the conditions to be as close to the real scenario as possible. And use the final hardware, if possible, not dev kits.

Clearly, it’s a lot of work to build energy-optimized IoT products, and it takes a certain mindset to keep it from becoming an afterthought. The optimizations must be factored into the project from the very beginning, on every layer, from hardware to firmware to connectivity to the cloud. It can be a pain, but the attention paid to energy optimization is a true make or break decision for IoT projects.