Beware of retries in XBee modules
In the ROSE (robotics and embedded systems) class at Télécom ParisTech, we use Digi’s XBee (and XBee Pro) modules. One of our use cases is a day-long contest named “communication challenge” in which around 20 students must each implement an embedded software over ChibiOS/RT requiring frequent communications in a structured way with a server using the wireless 802.15.4 protocol.
This year, the students had to be able to receive questions over the air, to display them on a 16×2 LCD screen using a 4 bit bus, to choose an answer using push buttons or a potentiometer, and to send the right answer over the air again. Then, once this was done, they had to take a (graded) quizz about the theoritical courses using their newly programmed device.
To ensure succesful communication, the server configures its XBee gateway with the maximum number of retries. The documentation for the RR parameter states:
If the transmitting module does not receive an ACK within 200 msec, it will re-send the packet within a random period up to 48 msec.
However, we got many transmission issues when several boards were addressing the server at the same time, as if the internal buffers were full. By tracing the messages between the server (written in Scala and Akka) and
the gateway board, we noticed that by using RR6 (6 extra transmissions at the XBee layer) we got 7 ACK messages instead of one. It meant that the packets were retransmitted 6 times even though they were succesfully delivered
to the target, thus filling one internal buffer with every packet until all 7 transmissions went through.
By setting RR back to 0, that is up to 4 transmissions at the MAC layer and no retransmission at the XBee layer, everything went back in order. So beware: retries aren’t always good, especially when the module doesn’t behave as documented.
For people interested in technical details, the HV (hardware version) command returns 17 44 while the VR (firmware version) command returns 10 ec for one of the faulty modules.