This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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.

Parents
  • 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. 

  • 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)?

  • I am also experiencing this issue.
    I have a device in which mesh is completely disabled to save power.
    It wakes up at a specified interval to transmit data, then goes back to sleep.

    In the old (2.x) mesh SDK, when calling nrf_mesh_disable() to put the device to "sleep", I measured around 15uA.  This is comparable to our BLE code version of the device (same hardware).

    Current draw measures around 450uA with the new (3.1) mesh SDK.
    The code posted above does not reduce the current consumption.

    Are there other modules enabled that need to be turned off?

  • 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.

  • 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.

  • 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.

  • 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 )

Reply
  • 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 )

Children
Related