Thingy:52 mesh demo poor battery life

[RollandMichael7]

Hello all,

I've been modifying the thingy:52 mesh demo (https://github.com/NordicPlayground/Nordic-Thingy52-mesh-demo) to support more sensors but I've noticed a severe drain in battery life even when the sensors aren't activated. I've observed a loss of 25% for the bridge and 50% for the nodes over the course of a weekend. I feel that this is a software issue due to the incredible battery life that the thingy:52 has with its default firmware. With that said, what can I do to improve the battery life for the thingys with this firmware? Is the overhead of Bluetooth mesh really so severe that better battery life is unattainable?

Thanks,

Michael

[Bjørn Kvaale]

Hi Michael,

That could be about right. When we run the Thingy:52 mesh demo at trade shows for 8 hours, we make sure to charge the Thingy's at the end of the day. Not sure how long they would last otherwise. The issue with all mesh networks we support (Bluetooth Mesh, Thread, Zigbee) is that the radio must be on most of the time to listen for incoming messages. Therefore, these are not low power optimized networks. What you are noticing is a SW issue, as the Thingy:52 normal FW battery lasts a long time before it is fully discharged. BLE, in contrast to Bluetooth Mesh, only keeps the radio on a fraction of the time to listen for incoming messages. Therefore, the device can sleep a lot longer (assuming you have a long connection interval) than in Bluetooth Mesh.

What is your current usecase? Would it make sense to run a scatternet instead of a mesh network? Essentially, use the multilink functionality of our Bluetooth stack to create a central to peripheral topology (i.e. star network). We do also have a low power node implementation in the mesh stack? Would this be more useful?

[RollandMichael7]

Hi Bjorn,

Thank you for the prompt and helpful response! I am attempting to develop a network of thingys for monitoring the environment of an area (eg. temperature, humidity, light) for extended periods of time. I had thought this was not feasible with BLE due to its one-to-one nature. It seems like your proposed solutions may be helpful, I'd love to check them out.

Thanks again!

[Bjørn Kvaale]

We have a multilink example here, which may be useful to look at.