NRF52840 Thread Mesh packet drop in vast spread network

RE: NRF52840 Thread Mesh packet drop in vast spread network

Piotr Szkotak — Thu, 19 Apr 2018 08:31:09 GMT

Hello Wojciech,

It seems that this thread slowed down.

Writing to let you know that we have just released the nRF5 SDK for Thread and Zigbee v1.0.0 where many improvements have been introduced.

Could you check if you can still observe the issue with the v1.0.0 release?

Kind Regards,

Piotr Szkotak

RE: NRF52840 Thread Mesh packet drop in vast spread network

Lukasz Duda — Tue, 06 Mar 2018 19:57:49 GMT

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

RE: NRF52840 Thread Mesh packet drop in vast spread network

Wojtek — Mon, 05 Mar 2018 08:14:48 GMT

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

RE: NRF52840 Thread Mesh packet drop in vast spread network

Lukasz Duda — Thu, 01 Mar 2018 07:29:37 GMT

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