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]

Hmm, calling timeslot_stop() straight after nrf_mesh_disable() seems to achieve what I want (entering low power state much faster). I can then call nrf_mesh_enable() and everything works as normal again. Is it safe-ish to use timeslot_stop() in this manner?

[Hung Bui]

Hi Gordie, 

Sorry for late response, I was checking with our expert. The proper sequence to disable mesh (immediately) is: 

uint32_t retval = proxy_stop();

            if (retval == NRF_SUCCESS)

            {

                scanner_disable();

                retval = nrf_mesh_disable();

            }

     __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Disabling mesh: status: %d\n", retval);

And to enable: 

            scanner_enable();

            uint32_t retval = proxy_enable();

            if (retval == NRF_SUCCESS)

            {

                retval = proxy_start();

            }

 

            if (retval == NRF_SUCCESS)

            {

                retval = nrf_mesh_enable();

            }

 

            __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Enabling  mesh: status: %d\n", retval);

[gordie]

Hi,

Thanks for the reply. I tried this, but when I try and disable the mesh in this fashion, I get an assert in timer_scheduler.c, line 205:

void timer_sch_abort(timer_event_t* p_timer_evt)
{
    NRF_MESH_ASSERT_DEBUG(bearer_event_in_correct_irq_priority()); //assert here
    NRF_MESH_ASSERT(p_timer_evt != NULL);
    remove_evt(p_timer_evt);
    p_timer_evt->p_next = NULL;
    setup_timeout(timer_now());
}

I've come across this assert in the past before, and the only way of fixing it was to call the function causing it from a different context (not ie:main). Is this more or less correct? Is it safe to call from a timer handler?

[Hung Bui]

It's pretty strange you received this issue. Could you try to reproduce it with one of our example, for example the lightswitch server ? 

[gordie]

Okay, I will try that and then post the code here.

Regards,

[Justin]

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?