Server Publishing messages every minute

[nish]

Good day, 

I am using the ANNA-B112 BLE device from ublox in a custom design. The ANNA-B112 interfaces with a host MCU over UART. The ANNA=B112 is flashed with Soft Device S132 and is set up for mesh networking.

The way my design works, is that Host MCU will wake up from a sleep stage every minute or two, take some data readings from sensors, and then the ANNA B112 (mesh) publishes a packet to the Client node. The system then goes to sleep, and in this state the ANNA-B112 is actually powered off. So every time MCu wakes up, the ANNA-B112 is powered back on again. 

The issue I am experiencing, is that after some time, the server fails to successfully publish and packets. I have verified that it is indeed attempting to publish packets, using access_model_publish(); which is returning with error code NRF_ERROR_FORBIDDEN. Following the function access_model_publish() to identify what exactly is going wrong, I can see that the error code comes from a function in the net_state.c file, particularly in the following function call:

uint32_t net_state_seqnum_alloc(uint32_t * p_seqnum)
{
    if (m_net_state.seqnum < m_net_state.seqnum_max_available)
    {
        /* Check if we've reached the seqnum threshold for a state transition. */
        uint32_t threshold = NETWORK_SEQNUM_IV_UPDATE_START_THRESHOLD;
        if (m_net_state.iv_update.state == NET_STATE_IV_UPDATE_IN_PROGRESS)
        {
            threshold = NETWORK_SEQNUM_IV_UPDATE_END_THRESHOLD;
        }
        bool ivu_triggered = false;
        if (m_net_state.seqnum >= threshold)
        {
            m_net_state.iv_update.pending = true;
            ivu_triggered = iv_update_trigger_if_pending();
        }

        if (!ivu_triggered && m_net_state.seqnum >= m_net_state.seqnum_max_available - NETWORK_SEQNUM_FLASH_BLOCK_THRESHOLD)
        {
            seqnum_block_allocate();
        }
        /* Get the sequence number after doing the state updates, as they might
         * trigger changes to it. */
        uint32_t was_masked;
        _DISABLE_IRQS(was_masked);
        *p_seqnum = m_net_state.seqnum++;
        _ENABLE_IRQS(was_masked);

        return NRF_SUCCESS;
    }
    else
    {
        seqnum_block_allocate();
        return NRF_ERROR_FORBIDDEN;
    }
}

My question is, why is it happening that (m_net_state.seqnum > m_net_state.seqnum_max_available), which is causing the publish to fail. and how can i recover from this? Powering down and powering the ANNA-B112 does not help. The only way i have recovered from this is to unprovision the server, and provision again. But this is not practical for the application.

Thank you in advance for your assistance.

Regards, 

Nishant

[Hung Bui]

Hi NIshant, 

Could you let me know the SDK version you are using ? 

The reason you are getting this issue is that the IV update was not performed resulting in the sequence number reached max sequence number. And the root cause was that your device was sleeping most of the time and didn't catch or didn't perform an IV index update.

Normally a mesh node is designed to stay active and listen all the time. For your use, a LPN node is a better solution. 

I'm checking with the team to see what would be the best solution for this. 

[nish]

Hi Hung, 

I am using Mesh SDK 3.2.0 and nRF5_SDK_15.3.0_59ac345.
In our application we are running our device off a battery and thus require to unpower the NRF52 MCU to preserve battery. 

I shall await for further feedback from you . 

Thanks

[nish]

Hi Hung, 

Since the mesh node should stay powered all teh time, Would calling nrf_mesh_disable() and then putting the NRF to sleep (as opposed to power off), and then wake up from external interrupt and nrf_mesh_enable() work? Will the NRF do a chip reset on wake up? or will it continue from where it went to sleep?

Thus hopefully meaning the chip will not reset, and hence the sequence number will not reach the maximum so quickly?

[Hung Bui]

That can help a little bit as the sequence number will not be increased on each reset a NETWORK_SEQNUM_FLASH_BLOCK_SIZE. But it will still end up in the same situation if you don't keep the device long enough to receive and perform IV index update. 

If you plan to have the device running on battery, you should use set it up as LPN node instead of normal node. 

I'm still waiting for the reply from our team. 

[nish]

Thanks Hung, 

I initially started from the Light Switch example and have built my firmware a long way from there. 
My question is, that i see the LPN has only an "experimental" example. What exactly would be involved to now convert my project to use LPN instead of normal?