nrf52840 board programmed nrf5SDKforMeshv310src, could not send two different segment messages in a short interval.

[jiurifei]

Hi all,

        Recently, I have concentrated on a mesh project using nrf52840 board programmed sdk_mesh_v_3.1.0.  There is a situation that the board needs to send two different long segment messages to another device in a very short interval. According to the Mesh Profile Specification v1.0 Section 3.6.4.1, we know that we should only ever send one transport SAR packet at the same time between a given source and destination. So, when the board did the operation above, the result was that the first SAR packet could be sent successfully, but second one failed to send out because the first one hasn't been completed yet.Here is the code where the error occurs.

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;
    }
}

So, I think the mesh_sdk should use a correct way (e.g. putting message in a queue) to support this situation rather than discard it. And if anybody has useful suggestions, please contact me! Thank you!

Jiurifei

[tesc]

Hi,

Thank you for the suggestion of providing functionality in our SDK to queue SAR packets. I will forward it to our mesh team.

As is you must do the queueing yourself. That means waiting for the NRF_MESH_EVT_TX_COMPLETE event before sending the next packet.

Regards,
Terje

[jiurifei]

Hi Tesc,

In fact, in order to implement sending consecutive sar packets normally, I have set a queue to store those packets and used a timer to ensure the packet could be sent out one by one. Anyway, I don't think it is a proper way although it must be used for now. So, I hope your mesh team can take this into consideration, and optimize it as soon as possible! 

Jiurifei

[tesc]

Hi,

I can confirm this is something that the team has thought about, and there is a feature request registered for the behavior that you are asking for. It does not seem to make it for next release, though, so I am afraid you will still have to keep track of the queue in the application.

Regards,
Terje