When developing for cellular, battery life is often part of the equation. There are several areas to consider: the hardware design itself, the firmware on the device, and the communications with the cloud (which I’m going to call software). This post is an overview of each that you should have in mind as you work on product development.
Backstory and Hardware:
The idea for this post came from a recent webinar we did with Jared Wolff, creator of the nRF9160 Feather which has a Nordic nRF9160 SIP on the board for connectivity. The concepts discussed will apply to any nRF9160-based project (and much of it applies to cellular IoT in general). Consider viewing the webinar for more on this topic.
Hardware Design Considerations
Low-power begins with the hardware design. This is not unique to the nRF9160 and obviously applies to all boards that use a battery.
- Be sure to choose the most efficient power regulator that fits your needs and budget. This is especially true for the quiescent current and deep sleep draw. Jared recently redesigned the nrf9160 Feather using a Texas Instruments TPS62840 with an operating quiescent current of 60nA with a shutdown current of 20nA.
- Carefully consider how passives are included in your design. Avoiding use of Schottky diodes, pull-up resistors, and anything else that represent a constant draw. One approach is to use internal pull-ups that can be disabled when the nRF9160 is in sleep mode.
- Design external circuitry that can be disabled by the microcontroller. As with the previous point, this allows the nRF9160 to shut down eternal draws when going into low-power mode.
Firmware Design Considerations
The nRF9160 uses the nRF Connect SDK (NCS) which is based on the Zephyr RTOS.
- Zephyr has a Power Management (PM) API. This controls the low-power and sleep modes of the nRF9160
- The Zephyr PM API also has a device management feature that targets sensors and other other peripherals. Check the Zephyr driver for your specific peripheral to see if the PM API has been implemented.
- Radio “On” time is by far the largest power draw. Optimize your firmware to use the radio as quickly and infrequently as possible. Investigate Extended Discontinuous Reception (EDRX) and Power Saving Mode (PSM) cellular modes which manage the time and frequency at which a device connects to a cell tower.
Software Design Considerations
This is a catch-all category for the “cloud” side of a Cellular connection. As mentioned in the previous section, radio “On” time is a huge current draw for battery-powered applications. Wise device management choices on the cloud side will help reduce packets being sent, saving both battery life and cell bandwidth costs.
- Implement Over-the-Air firmware updates as your first feature. This may not seem like a power saving consideration, but when your application hits a bug in production that prevents a sleep mode, the ability to update the firmware remotely makes OTA an impactful power-management tool.
- Choose your communications protocols for the fewest packets possible. I work at Golioth which is a device management platform. We use the Constrained Application Proctol (CoAP). CoAP is UDP based and in most cases it’s a more efficient transfer protocol in comparison to MQTT (which is TCP based).
- Make every bit you send count. We use the Concise Binary Object Representation (CBOR) to serialize data sent over the network. CBOR is much more efficient than using JSON for data transfers. This kind of savings adds up over the life of the device (and the size of the fleet)
Conclusion
As chip vendors continue to push the limits of low power on chips, it is becoming much easier to design devices that can operate for years without replacing batteries. Go into your product design with power constraints in mind, and utilize the obvious (low-power modes in the silicon), the non-intuitive (cellular modes like EDRX), and the tangential (OTA updates) for truly successful product development.