This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52840 Thread Mesh packet drop in vast spread network

Hello!

Last time I've described issue with connection problems in large thread network https://devzone.nordicsemi.com/f/nordic-q-a/29867/thread-mesh-network-capacity-problem.  I've updated software and everything works fine on my desk. But when I've tried to locate about 25 devices across 3-storeys building packet drop rate tramendously increases for nodes with few (2-3) hops on the way to border router. My application sends packet every 1 minute by COAP and waits for acknowledgement from server. In case of lack of ACK for packet, node puts it to buffer and tries to retransmit after next wake-up. In some cases node transmits 3-4 times more packets than it should be nominally. When ACK is dropped, my server still records arrived message. I can see that some of messaages are doupled or tripled in database due to retransmissions. 

I've connected this issue with number of hops on way to BR. Nodes on path of packet are in good signal range to each other.

Is it possible to improve this situation and decrease packet drop rate?

Best regards,

Wojciech Rzepecki

Parents
  • Hello Wojciech!

    It's great to hear that you try to deploy Thread-based network!


    I have two additional questions:

    1) Does the CoAP message is fragmented on 15.4?
    2) What is the polling interval that you set on Sleepy End Devices?

    One of the potential issue could be related with the application architecture itself. If your polling interval is greater than CoAP retransmission timeout, then CoAP ACK may not be delivered on time to SED. Even though it was buffered on Router (parent). This will result with another CoAP message send from the SED (which would explain that you have duplicated message in the server).

    If that is the case, you may adjust the polling interval after CoAP packet is sent (e.g. to 0.5s), and restore regular polling interval (e.g. 5s) after ACK is received (or ACK timeout event).

    Regards,

    Łukasz

  • Hi Łukasz!

    My CoAP messages are not fragmented. I've set length of my data to fit 128 bytes limit. I've already implemented variable poll period time. Is there way to change CoAP timeout without recompiling whole openthread libraries? 

    Best regards,

    Wojciech Rzepecki

Reply Children
  • Hello,

    CoAP timeout is configured compile-time right now. You can create a feature request in OpenThread github to make it run-time configurable.

    Just to get more informations, could you try to reproduce your issue with smaller CoAP Payload sizes (80, 100 bytes 15.4 frame in total). There is one more issue created today which aligns with your finding.

    We will try to reproduce this issue on our side.

    Do you use OpenThread libraries from 0.11 SDK or you have the newest one? If from SDK, are you able to reproduce the issue with libraries from current github's master?

    Regards,
    Łukasz

Related