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 see a problem doing that. According to Mesh spec this is requried: 

If a node in Normal Operation receives a Secure Network beacon with an IV index less than the last known IV Index or greater than the last known IV Index + 42, the Secure Network beacon shall be ignored.
Note: This above requirement allows a node to be away from the network for 48 weeks. A node that is away from a network for longer than 48 weeks must be reprovisioned.

 

But 48 weeks sleeping is not something we talking about here.

The only limitation I can think of is that when the node is sleeping, you can't send command to the node. And it won't aware of the missing packets. 

Also it won't be able to act as a relay node. You will need a group of backbone nodes to handle the relay task and never sleep.

 

But if you just need a node to wake up occasionally and send some data then sleep again, I think it should work. 

[gordie]

Thanks for the reply! Yes, so what I have set up at the moment is some sensor nodes ("servers") and one client. The sensor nodes have the mesh enabled on power up. They then wait for a command from the client to say "start transmitting with x sleep interval". Ideally I would like them to then transmit, data and as soon as that is done -> call nrf_mesh_disable... then some time passes and I call nrf_mesh_enable again -> then transmit -> disable mesh. The issues arise when disabling the mesh and then restarting it. Am I missing something here? Maybe I am doing the call to disable the mesh too early?

[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?

[gordie]

Hi Nakul,

As far as I know, nrf_mesh_process() is used when running in thread priority and using the app scheduler.