Thread PER Measurement Example

[Fabian Frei]

Hello,

I'm working with the nRF52840 PDK and the SDK for Thread V0.11.0. The RTT Viewer shows that the program uses the Thread version OPENTHREAD/ga89eb88-dirty.

I try to do some measurements with the PER measurement example to get a feeling for the range. Later on, I'd like to compare it with our own design.

Sometimes (like every 5th-10th time) I get the following error message: "app: Failed to allocate message for UDP port." So it seems like there is no message buffer available for the otUdpNewMessage function. But why? By now, I could not find any relationship from this error to the distance between receiver and transmitter or something else. Is this a known issue or am I doing something wrong? I directly flashed the .hex files from the SDK with the nRFgo Studio without any changes.

Also I'd like to know what results I can expect. Have you published some results on that? I only found the long range tests with the nRF52840.

Thanks in advance!

[Jedrzej Ciupis]

Hello,

A probable reason for such a behaviour is running the example in a busy radio environment. With a number of packets in the air, radio CSMA-CA procedure is often repeated and some packets are retransmitted too. Thread specification defines that if an ACK frame expected in response to a sent packet is not received, the packet is retransmitted. The time between retransmissions is equal to 16ms and there can be 4 such retransmissions. The PER measurement example sends a UDP packet once every fixed amount of time. If the time is not long enough to let all the possible retransmissions take place, the application allocates a buffer before a previously used buffer is freed. That might lead to a buffer shortage, which results in the error message you have provided.

As a solution, I would suggest increasing the time between UDP test packets. It is defined in the main.c file of per_measure_transmitter as TEST_PACKET_SEND_PERIOD and by default is equal to 10ms. You can experiment with that period, but I couldn't reproduce the problem after setting it to 30ms. Setting it to 65ms should leave you on the safe side in the worst case (total time needed for the CSMA-CA procedure and retransmissions should not exceed 65ms).

In concern to your last question - it is difficult to say what results could be expected of a PER measurement, because it depends on a number of factors. The desired value is 0 and perfect radio conditions should result in PER equal to 0. However, due to presence of other nodes in the network, packet collisions, distance between nodes, random noises etc. it is near to impossible to achieve PER equal to 0. To have a functional network, it should be as close as possible to 0 though.

[Fabian Frei]

Thanks for your answer. Your explanation seems reasonable and I will test it  with increased period time as soon as I've got the time to do so.