Minimum one second delay in activating board LED in Zephyr Bluetooth Mesh based on OnOff applic


frv
 

Hi Zephyr community, bluetooth Mesh fans,

I played around with the Zephyr Mesh OnOff applic running on a Nordic nRF52 board.
https://docs.zephyrproject.org/1.13.0/samples/boards/nrf52/mesh/onoff-app/README.html

I made a mesh network with 4 nRF52 boards, 1 running a generic onoff client model as client node, 2 running a generic onoff server model as peripheral node and 1 acting purely as relay node to extend BLE coverage/range.
For setting up the mesh network(provisioning) I rely on the tool meshctl.

All seems to work pretty well, although independent of placing a relay node in between the client and server node, it takes mostly roughly at least 1 second after the button is pressed on the client node to light up one of the green LEDs on the server node (regardless if it close or far (maybe 150 meters) from the client node).

Only on the relay node the relay mode is active, on the other nodes the applic is running with RELAY DISABLED define (as unmodified OnOff . All other nodes is the relay function not enabled. I must say for all the nodes the 4 elements are defined but on each node only one element is bounded and on the client node only the generic onoff client model (thus linked to the primary element) publishes to a group address. On the server nodes only one element (1 to primary element on other node to second element) is subscribed to the group address.

This minimum 1 second delay is this normal after pushing the button on the client node? If not which (time?) parameters can be further tuned, is there a cost?

BTW it is great to have these Mesh examples around in Zephyr to speed up proto typing in a Bluetooth Mesh environment. Thanks! Keep on the good work.

Thanks in advance.

Best regards,
Frank


vikrant8051 <vikrant8051@...>
 

Hi,
It is because of new logging sub-system.
And If you disable CONFIG_BT_DEBUG_LOG to avoid that then provisioned NODE
takes 10+ seconds to initialized the Mesh.

I've already raised issue for that ...

Regards,
vikrant

On Fri, Nov 30, 2018 at 6:42 PM frv <F.Vieren@...> wrote:
Hi Zephyr community, bluetooth Mesh fans,

I played around with the Zephyr Mesh OnOff applic running on a Nordic nRF52 board.
https://docs.zephyrproject.org/1.13.0/samples/boards/nrf52/mesh/onoff-app/README.html

I made a mesh network with 4 nRF52 boards, 1 running a generic onoff client model as client node, 2 running a generic onoff server model as peripheral node and 1 acting purely as relay node to extend BLE coverage/range.
For setting up the mesh network(provisioning) I rely on the tool meshctl.

All seems to work pretty well, although independent of placing a relay node in between the client and server node, it takes mostly roughly at least 1 second after the button is pressed on the client node to light up one of the green LEDs on the server node (regardless if it close or far (maybe 150 meters) from the client node).

Only on the relay node the relay mode is active, on the other nodes the applic is running with RELAY DISABLED define (as unmodified OnOff . All other nodes is the relay function not enabled. I must say for all the nodes the 4 elements are defined but on each node only one element is bounded and on the client node only the generic onoff client model (thus linked to the primary element) publishes to a group address. On the server nodes only one element (1 to primary element on other node to second element) is subscribed to the group address.

This minimum 1 second delay is this normal after pushing the button on the client node? If not which (time?) parameters can be further tuned, is there a cost?

BTW it is great to have these Mesh examples around in Zephyr  to speed up proto typing in a Bluetooth Mesh environment. Thanks! Keep on the good work.

Thanks in advance.

Best regards,
Frank






frv
 
Edited

Hi all, Vikrant,

Thanks for your feedback.

However the issue if you can call it an issue, is that the BL Mesh OnOff sample applic sets by default a minimum 1 second delay before publishing the state of the button press, this makes it possible to distinguish between a single and a double button press either to switch on or either to switch off (linked to one button only).


Best regards,
Frank