RE: Thread PER Measurement Example

Fabian Frei — Mon, 05 Feb 2018 09:32:18 GMT

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.

RE: Thread PER Measurement Example

Jedrzej Ciupis — Wed, 31 Jan 2018 11:29:22 GMT

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.