Hi!
We'd like to include a battery-powered remote control in our Bluetooth mesh network, i.e. we'll have a need for low power consumption.
In our mesh, devices may opt in and out over time.
I see the following alternatives:
1. A custom, parallel GAP/GATT solution.
2. A "forced" BT mesh solution
3. Wait for the implementation of the official Low power & Friend features of the BT mesh specification.
# 1
At
devzone.nordicsemi.com/.../124282
David writes:
"You should be able to implement a connection oriented low power node using the GATT proxy. This will use a GAP/GATT connection to the Mesh proxy. This will enable you to just use the Mesh proxy and get to the low power state for the node."
1 a) If a custom BLE solution is implemented, possibly through GATT proxy, won't GATT be too slow for a remote control scenario? We can't be sure of what devices exist or are in reach, so when the user presses a remote control button, if there is no established connection, the remote control would have to scan(?) and connect to a device, before sending a command.
1 b) If a custom GAP is used instead, what are the possibilities for a mesh node to pick up on advertisements coming from the remote control? From what I understand BT mesh is also using GAP as the bearer, so a node would have to interleave listening to GAP for BT mesh and this custom GAP(?)
# 2
The Mesh profile specification (2.2.5) reads:
"This specification does not require devices to coordinate transmissions, make connections, or restart security on every connection; thus facilitating low power operation."
2 a) Is there a possibility to simply turn off the radio, or avoid some operations to cut down on power consumption?
But I suppose there would be problems with the IV index update, and a recovery is taking too long for us (5s) and also seems impossible to do multiple times (once within 192 hours). From the Mesh profile specification (3.10.6):
"Given that nodes collectively transmit a Secure Network beacon once every 10 seconds, a low duty cycle node will have to listen for an average of 5 seconds to recover the current IV Index before transmitting and receiving mesh messages. If a Low Power node has insufficient power to listen for 5 seconds, then it must stay up to date with the current IV Index by polling its Friend node at least once every 96 hours.
The node shall not execute more than one IV Index Recovery within a period of 192 hours."
2 b) If a node only acts as a client that only sends unacknowledged messages, would this cut down on power consumption considerably? or does simply being a node of the mesh network imply high battery draw?
# 3
When it comes to the low power and friend feature, I wonder about the friend connection.
The Mesh profile specification (3.6.6.3.2) states:
"Note: The above requirement implies that a Low Power node should collect all stored messages at least once every 96 hours, otherwise the Friend node may discard the stored messages before the Low Power node can receive them."
3 a) What happens when the friend is not available, i.e. how fast can a lower power device notice the lost connection and find and establish a connection to another friend node?
3 b) Do you have any updates on the release of this feature? How likely is it to be part of the next release? This blog post "cautiously" says Q3, 2018:
devzone.nordicsemi.com/.../131951
# 4
4 a) Are there other options?
Thank you!
