Skip to main content
David Abrahams
David Abrahams
Associate
January 17, 2020
Question

STM32WB OpenThread UDP send completion status

  • January 17, 2020
  • 1 reply
  • 666 views

Is there any plans to support some sort of Transmission Complete Status after sending a UDP packet?

I am noticing that packets are failing to transmit and silently dropped by the WB M0 with no notification passed up to the M4 that this has occurred.

In the main OpenThread implementation, otUdpSend responds correctly once a packet has been sent or dropped, but I believe your implementation is only

indicating the packet was successfully queued by the M0.

I can see that packets have been dropped by the otMacCounters field mTxErrBusyChannel incrementing but as these count lower level IPv6 and 802.15.4 packets

I cannot reliably query this to detect a failed transmission.

Having a reliable notification that a transmission was successful or failed will allow us to have more reliable communication between nodes.

This topic has been closed for replies.

1 reply

JNewe.1
JNewe.1
Visitor II
January 21, 2020

It feels like the retry code on the WB M0 is not sufficient.

When dealing with multiple devices on a network, the WB M0 drops packets without sending them.

Current tests ( although this is a black box) indicate that the Packet has been Queued, however this packet is never transmitted. Multiple tools have been used to check this and we get consistent results with random failures.

The current theory is that while it is queued, the code is not handling a busy wireless network well enough. Maybe the number of retires is too short, maybe the time given for it to send is too short, maybe its not handling collisions correctly, but one thing is for sure, when this does happen it does not indication of the failure.

While the re-transmission code should be fixed as a priority, providing feedback on a failure is critical and would allow the user code to retry or do some other task

I would really want to know when ST will fix this issue.

It looks like the Thread certification and testing doesn't check the reliability when payloads are sent over UDP.

Terms & ConditionsAccessibility statement