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?

[Hung Bui]

Hi Jon, 

Are you sure you haven't modified the client ? I don't think the client would act any different if you have all server to subscribe to GROUP_ADDRESS_ODD. When you are sending with unAcked message, the client wouldn't care who are subscribing. 

Please try to step into the code (or printing log) to see what exactly throwing NRF_ERROR_INVALID_STATE.

[jonappleseed]

Ok, so it is being set in segmented_packet_tx() in transport.c (line 1205)

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

[Hung Bui]

Hi Jon, 

I think I know what could be wrong here. 

As I mentioned, by spec you should not have 2 segmented messages being sent at the same time. 

This mean repeat should not be set to something but 0. If you have repeats it will call access_model_publish() multiple times and causing the issue. 

If you do want to repeat your unacknowledged message for redundancy, you can do it with your own code and retry if you see error NRF_ERROR_INVALID_STATE until you can successfully queue the message. It shouldn't take too long to send a segmented message or instaburst. 

[jonappleseed]

Thank you!