Client 2/3 Cannot Send Error yet message is sent

[jonappleseed]

Hi,

I have modified the light switch demo so that all messages from the client are sent to all servers. I have done this by subscribing all servers to GROUP_ADDRESS_ODD in node_setup.c. Now when I send using button 2/3 (unacked) I get the message Client 2(/3) cannot send, I have found that this is because status == NRF_ERROR_INVALID_STATE. However, it still sends, the servers receive the message and even tell the client. Is it safe to ignore this message?

[jonappleseed]

The problem is actually caused in packet_alloc_and_tx() in access.c (~line 462). In the case of buttons 2/3 the if statement is true, causing the status to be returned as NRF_ERROR_INVALID_STATE rather than NRF_SUCCESS as in the case of buttons 0 and 1.

[Hung Bui]

Hi, 

If you have a look at the code you can find that on Button 0 and 1 we cancel the previous reliable message before doing the next when on Button 2 and 3 we dont. 

As I mentioned only one segmented message at a time. On button 2 and 3 if you press and hold the button for more than 400ms (which I assume you do) the stack will try to send the unreliable segmented again and will receive a NRF_ERROR_INVALID_STATE because the last one has not been finished. 

My suggestion is to try changing the HAL_BUTTON_PRESS_FREQUENCY time (button debouncing) to say 1 second and check if you still have the issue. 

How big is your data ? have you tried to test with sending one single byte ? 

[jonappleseed]

Reducing the # bytes to 3 has removed the error. Changing HAL_BUTTON_PRESS_FREQUENCY had no effect (I am using RTT to for button presses). However, I would like to test the diffrerence between Instaburst and non-Instaburst. At 3 bytes no messages will be sent with Instaburst.

[jonappleseed]

When increasing the number of bytes so that it uses Instaburst, I have found that calling generic_onoff_client_set_unack() with # repeats set to 0, removes this error. However, this is not ideal either.

[jonappleseed]

Hi, I know the error is originating from the following (in transport.c - segmented_packet_tx()):

for (uint32_t i = 0; i < TRANSPORT_SAR_SESSIONS_MAX; ++i)
    {
        if (m_trs_sar_sessions[i].session.session_type == TRS_SAR_SESSION_TX &&
            m_trs_sar_sessions[i].metadata.net.src == p_metadata->net.src &&
            m_trs_sar_sessions[i].metadata.net.dst.value == p_metadata->net.dst.value)
        {
            return NRF_ERROR_INVALID_STATE;
        }
    }

My prediction is that there is an overlap between the previous and current sending caused by the packets being larger.