battery usage / fruity mesh

[cmedianu]

is a BLE mesh application appropriate for usage with a coin cell powered device, or would the application be too power hungry? In particular, I'm trying to figure out how it compares with a fruity mesh application.. I'm trying to choose between the two...

Thanks!

[trond-snekvik]

Both the OpenMesh and the Bluetooth Mesh are quite power intensive, and I wouldn't recommend running them on coin cell batteries. The OpenMesh (with 100% duty cycle) on an nRF51 burns through a coin cell in less than 2 hours at worst, and although you should be able to squeeze a couple of days out of it with reduced duty cycle on an nRF52, it's going to make you change batteries quite often.

I believe Fruity mesh is connection based, which should make it consume less power, but I don't have measurements for it. Perhaps @mariusheil can chime in?

[mariusheil]

Sure, glad to :-) FruityMesh uses Connections and I have some energy measurements on this page:
https://github.com/mwaylabs/fruitymesh/wiki/Battery-Consumption

Per default, FruityMesh uses discovery with 100ms advertising and a scan duty cycle of 15%. Because scheduling in the SoftDevice, the duty cycle is however a lot less depending on the connection count. This provides solid discovery. It is possible to disable discovery after all mesh nodes have been found and turn it back on, if any node is lost. This gets energy consumption down a lot. However, this is currently a duty of our custom MeshGateway and is not implemented in the mesh yet. The mesh would need to know how many devices are enrolled to switch off discovery by itself. Shouldn't be hard to do, but depends on the provisioning process used.