Achieve extremely long battery life in wireless sensor nodes


With the expansion of the Internet of Things (IoT), the need for wireless sensor nodes is growing. Many different sensor types are being integrated into IoT networks: temperature, humidity, pressure and ambient light, just to name a few. As the desire to add sensing abilities to IoT networks increases, so does the importance of a sensor node’s battery life.

For example, if a commercial building is retrofitted with wireless sensor nodes to turn it into a smart building, it is conceivable that several thousand wireless sensor nodes may be installed to link various devices, such as thermostats, smoke and fire detectors and the like. Since it is impractical to run power cabling to every single node, batteries are a necessary power source. However, there is a significant labor cost when several thousand batteries need to be changed in all of those wireless sensor nodes.

To reduce cost and inconvenience associated with battery maintenance, it makes sense to ensure that every wireless sensor node has as long a battery life as possible. Most typical wireless sensor nodes employ a duty-cycled approach to extend battery life. This is a scheme whereby the node powers up, records a measurement from the sensor, transmits that data wirelessly to a central hub or gateway and then turns itself off, either by using a low-power mode or load switch. The main factors that affect overall system battery life are the on-state duration, on-state average current, off-state duration and off-state average current.

A TI Design reference design for humidity and temperature sensor nodes (TIDA-00374) demonstrates an optimized method to duty-cycle a wireless sensor node. A nano-power system timer and ultra-low leakage load switch are used in lieu of an internal wireless microcontroller (MCU) system timer to control when the wireless MCU and sensor receive power. A humidity sensor with an integrated temperature sensor is read by a wireless MCU to gather environmental data. Once the environmental data has been transmitted, the wireless MCU signals the nano-power system timer to remove power from the wireless MCU and humidity sensor. The system block diagram for this TI Design is shown in Figure 1.

Humidity and temperature sensor node

Figure 1. Humidity and temperature sensor node for star networks enable 10+ year coin-cell battery life 

This reference design optimizes overall system battery life, since the nano-power system timer and ultra-low leakage load switch reduce the off-state average current to tens of nanoamps, which is lower than most typical MCU shutdown modes. In addition, the wireless MCU and humidity sensor used in this reference design are extremely low power, which reduces the on-state average current to less than 5mA. Since the sensor measurement and wireless data transmission only take approximately 30ms to complete, the overall estimated system battery life is 10.5 years, when measuring once per minute.

This duty-cycled architecture using a nano-power system timer makes wireless sensor nodes a practical reality as IoT networks become more widespread. With system battery life longer than the typical shelf life of the batteries themselves, this TI Design reference design shows how practical wireless sensor nodes could be for a variety of new applications. 

Additional resources:

  • Hi Evan,

    Are there any firmware application or guide for TIDA-00374 firmware project?

    Could you suggest a matched stack project for TIDA-00374 firmware project?

    Best Regards,

    Jim

  • Hi Jim,

    The firmware can be found on the TIDA-00374 (www.ti.com/.../TIDA-00374).  The firmware sends the data as a non-connectable undirected advertising BLE packet and does not use any BLE profiles.  The reason we did not use any BLE profiles was to minimize the ON time to achieve long battery life.  With non-connectable undirected advertising, the design can broadcast the data without having to waste time connecting or pairing with another device.  The design will operate only as a transmitter.

    Since we are not using any BLE profiles in the firmware, there is no corresponding stack project.  

    Regards,

    Christina

  • Hi Christina,

    Thanks for your reply.

    Is that why I can't scan the demo board by using an Android 'BLE debug tool' app just because you guys don't use any BLE profiles?

    Regards,

    Jim

  • Jim,

    Yes, that is correct.  Since it is not using a BLE profile, you will not be able to view the packets with the Android tool.  The only way to view the packet is with the CC2540EMK-USB.

    Regards,

    Christina

  • Is the complexity of the external timer and switch really worth it, or even a good solution? It looks like the CC2650 can sleep w/ clock at 1uA. Even if the core was powered directly from Vbatt, that would still be 20+ years of sleep time. The lifespan will be dominated by the radio and CPU on-time.

    This solution also limits you to non-time-sync networks, so no 802.15.4e, no TSCH.

  • Hi Christina,

           Could you tell me that how many sensor nodes can work well at most in the designe?Is there a limit?

           Best Regards,

           Lei

  • Lei,

    This design is only for the sensor end node.  It does not showcase the controller.  It will be up to the controller implementation to determine the number of sensor end nodes that it can work with.

    --Christina

  • Sorry I have a very stupid question. It's possibile to use the TPL5110 without using a uC?

    I would lilke to use this low power timer in order to open the switch only 200 ms every 2 seconds or similar but I don't what to use a micro to control the lengh of the DRV pulse, it is possibile to do that?

    Thanks in advance for you help.

    Best Regards,

    Filippo

  • Filippo,

    Generically, it is possible to use the TPL5110 without a microcontroller.  The pulse generated at DRV (which is connected to the switch) is equal to the selected time interval period, minus 50ms.  For example, if you configure TPL5110 for 2 seconds, the DRV will be on for 1.95 seconds and off for 50ms. This TPL5110 characteristic is fixed and cannot be changed.  For more information, see the TPL5110 datasheet.

    However for your specific requirement, where you want to control the exact length of the DRV pulse, you will need to use a microcontroller.

    Regards,

    Christina