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, 

From SDK v4.1 LPN has been pulled out of experimental. 
When it's experimental it meant that it's not fully tested and not qualified. But please use the latest SDK v4.1 if possible. 

[nish]

Hi Hung, 

I have been reading on the LPN feature and network topology that include LPN's & normal nodes. 

From my understanding, in order to use the LPN feature, you are required to have a Friend node. This friend node can for example be the light switch server example , does this mean that the friend node will be permanently powered?

In my use case, I actually have one Client node and three servers nodes. All nodes are supposed to run off a battery and should be sleeping and wake up periodically to send a message to the client. 

If I understand correctly, in order to use LPN feature, I will need one friend node that is permanently powered and that friend node has a friendship with each server node as well as the client node. 
Please advise if this is the correct network topology for my use case?

Thanks. 

[Hung Bui]

Yes, your understanding is correct. The friend node has to be main powered. 

But I'm not sure why you need a mesh network if your network is comprised of only a "central" node and a few "server" nodes that inside the central's range. It's a star network and you can easily do it with normal Bluetooth Low Energy. This would make it much more simple. And the client/central node can run on low energy as well.