Which is the most efficient way to disable and enable Bluetooth mesh stack in order to extend battery life?

[harid]

Hi,

I am using sensor server model to build our application on top of it. We want to save juice in the battery as much as possible. In order to that, I must disable bluetooth mesh stack and enable the stack on a periodic basis. On enabling, the node should publish data to the destined address (Set through model configuration) and the stack should be disabled immediately and enabled after a specific interval for periodic publishing.  I do not want to use low power node feature as we only want to publish the data and not poll data from a friend node. What would be the efficient way to achieve this? Thanks in advance.

Best Regards,

Hariharan D

[tesc]

Hi,

The mesh_stack_power_down() API call is part of the power-down feature, and it is intended for when you turn the device off. It is both shutting down the mesh stack and storing the full state to flash. It is safe to do once in a while, but it comes with a lot of flash writes, which is time consuming, energy consuming, and leads to flash wear if done too often. Flash is typically rated at 10k to 20k write/erase cycles, depending on the SoC.

Please also note that even if you do not intend to receive messages from the rest of the network, there are some messages that the node must get in order to stay on the network. The node must receive messages for configuration. Not getting messages means you can't reconfigure it. Further, the network key can change, which means the node must get the new key. Also, there is the concept of IV Index, which is periodically changed and that all nodes in the network must follow. The procedures for updating network key and IV Index relies on nodes being able to receive messages. In short, the whole Bluetooth mesh specification is written with the assumption that all nodes will be able to receive messages, and mandates that all nodes should be able to receive messages.

In Bluetooth mesh, Low Power Nodes (LPN) can send messages at any time, just as ordinary nodes. The difference is that an LPN does not listen for mesh packets. Instead, it periodically polls the friend to see if there are any messages waiting, listening only for a short period of time for the answer from the friend. This means the LPN uses significantly less power than other nodes, have the same performance for sending messages, has latency for receiving messages, and some minor overhead for establishing friendships.

If the power consumption of an LPN is too much, then you could consider your device not being a mesh device at all, but rather a broadcaster. You would then need a node in the mesh network that can act as bridge between these broadcasts and the rest of the mesh network. The bridge will listen for BLE advertisements, and the BLE advertisements containing the published data will be converted to a mesh message and sent to the correct recipient. We have one such example in the nRF5 SDK, namely the EnOcean switch translator client example. It listens for advertisements from an EnOcean switch, translating those to Generic OnOff messages on the mesh network.

Note that nRF Connect SDK is the main SDK going forward, with nRF5 SDK now in maintenance mode. See our nRF Connect SDK and nRF5 SDK statement for details.

Regards,
Terje