Proper use of the nrf_mesh_disable() & nrf_mesh_enable() functions (nRF5 SDK for Mesh 2.0.1)

[gordie]

Hi there,

I was hoping you guys could point me in the right direction with regards to the use of the nrf_mesh_disable() & nrf_mesh_enable() functions. Since the "friend node" and "low power node" features are not yet implemented in the SDK, I was thinking of a work around to get lower power consumption.

Would this work: I have an app timer constantly running, and use the power manager - I want to disable the mesh when in system-ON "sleep".  Then when a certain amount of time has elapsed, I want to re-enable the mesh, transmit a packet and then disable the mesh again.  I think this is possible because the nodes are able to drop in and out of the mesh (ie when power was cycled etc).

Also, how long do you need to allow after calling nrf_mesh_disable() before calling nrf_mesh_enable() again?

I am using SDK for Mesh 2.0.1, SDK15 and the nrf52840, my software is based on the light switch examples.

Regards,

Gord

[Hung Bui]

Hi Gord, 

I don't think putting nrf_mesh_disable() inside mesh_event_cb() of config_server.c would be a proper way of using it. This basically mean you will disable the mesh stack whenever you have sent anything. 

 

If you want to wait for a particular packet to be sent, you would need to register your own call back by using nrf_mesh_evt_handler_add() and then add a token into your message and check for the token when you receive NRF_MESH_EVT_TX_COMPLETE. 

Could you let me now what exactly the assertion you receive ? What throwing that and which error code ? Note that you should always check for return code after you call a function, for example nrf_mesh_disable().

[gordie]

Hi Hung, see my reply below:

"I don't think putting nrf_mesh_disable() inside mesh_event_cb() of config_server.c would be a proper way of using it. This basically mean you will disable the mesh stack whenever you have sent anything."  

Agreed.

"If you want to wait for a particular packet to be sent, you would need to register your own call back by using nrf_mesh_evt_handler_add() and then add a token into your message and check for the token when you receive NRF_MESH_EVT_TX_COMPLETE. "

I like this idea, that is a much nicer way of doing it!

"Could you let me now what exactly the assertion you receive? What throwing that and which error code?"

I was getting error code 8 on nrf_mesh_enable() (I was running it in a timer). But it seems to work fine if I instead call nrf_mesh_disable() from the NRF_MESH_EVT_TX_COMPLETE case statement.

"Note that you should always check for return code after you call a function, for example nrf_mesh_disable()."

I usually do. It is a good habit, I was just showing where I would call it, that is not my actual code.

[Hung Bui]

You will receive NRF_ERROR_INVALID_STATE from nrf_mesh_enable() if the mesh stack is either not initialized or is already enabled. 
I guess it's the second case, maybe the disable function earlier didn't take effect ? 

[gordie]

Hi Hung, yes it would seem that was the case. Either way, It might be worthwhile waiting until the friend and low power features have been added to the mesh SDK. Thanks for the help!

[Nakul Nair]

Hello gordie,

When should we call nrf_mesh_process() function after re-enabling the mesh or should it there by default?