nrf_mesh_disable() function changed since SDK for Mesh V3.1.0?

[gordie]

Hi,

I was wanting to know if this function has been changed since mesh SDK v2.2.1? It appears to not behave quite the same. When I call it, I think the mesh does not entirely get disabled as there is still something like ~8mA of current draw, when before it used to put the system in a state where it drew something like 600uA.

I had a poke into the nrf_mesh_disable() function and saw that scanner_disable() was no longer called. Is this the reason? I tried adding this call back into nrf_mesh_disable() and it caused an assert.

Any help would be greatly appreciated.

[Hung Bui]

Hi Gordie, 

As far as I can tell, the scanner will be automatically disabled after the timeslot has been ended (that what the nrf_mesh_disable() does) . So when testing here I can see that after I call nrf_mesh_disable() the device stayed in high current draw for a little while (about 10s before dropping the current down to the range of uA. This matches with the timeslot being stopped. 

[gordie]

Is there anyway to end the timeslot earlier than 10s? Its just that in mesh sdk 2.2.0, the nrf_mesh_disable() function caused the device to enter the lower power state much faster (less than one second)?

[gordie]

The code posted above does not work for me either, the way I do it is (psuedo code):

// Entering "Sleep" mode

//stop all active app timers here (if used)
timeslot_stop(); // Stop the current timeslot (Work around to enter the low power state much faster).
while(!nrf_mesh_disable());


// Exiting "Sleep" mode

// start app timers here (if used)
timeslot_restart(TIMESLOT_PRIORITY_LOW);
while(!nrf_mesh_enable());

Another thing to check is the SAADC, if you use it. Make sure you are disabling/sleeping it correctly. This can have a large effect on current draw.

[gordie]

This is how I do it in Mesh SDK v 3.1, and it works reliably for me. I have not received confirmation from Nordic if this is how it is supposed to be done.

[Justin]

what is your current draw when "sleeping"?
even with your example code implemented, i'm still seeing ~450uA.  there must be some other module keeping part of the mesh awake.

[Hung Bui]

Hi guys, 
Strange that calling       scanner_disable() didn't help for you. 

We have a new patch that solves the issue more thoroughly that you can try.  

Apply this patch for bearer_handler.c:

--- a/mesh/bearer/src/bearer_handler.c
+++ b/mesh/bearer/src/bearer_handler.c
@@ -319,10 +319,14 @@ uint32_t bearer_handler_stop(bearer_handler_stopped_cb_t cb)
         /* Will stop the timeslot when the current action ends. */
         m_stopped_callback = cb;
         m_stopped = true;
-        if (timeslot_session_is_active())
+        if (timeslot_is_in_ts())
         {
             timeslot_trigger();
         }
+        else if (timeslot_session_is_active())
+        {
+            timeslot_stop();
+        }
         else
         {
             notify_stop();

And in bearer_handler_timer_irq_handler() replace action_switch(); with 

 if (m_stopped)
        {
            timeslot_stop();
        }
        else
        {
            action_switch();
        }

Calling timeslot_stop(); is not suggested as it may cause an assertion if the bearer has not been stopped before that. So it's the other way around.  

(This should not be combined with scanner_disable()workaround )

[Justin]

thanks, i will give this a try and report back!