Xbee Pro XSC latency testing with various RR (Retries)

My understanding is that when retries(RR) is greater than zero, the sending radio will wait for an acknowledgement. If it does not receive and acknowledgement it will send the data again up to the RR number.

I set up two radios (Xbee Pro XSC Firmware 3114) and looped back a one byte message and measured the following:
RR Loop-back time
0 100ms
1 ~200ms
2 ~300ms
3 ~400ms

The radios were within a few feet of each other and there were no data errors or dropped communications. It would seem that the loop-back time should always be 100ms. Why does it increase with RR?
I tried changing RN but that only made things worse.

The following is from the XSC documentation and seems to be contradictory:
(RR Command)After transmitting a packet, the transmitter will wait to receive an acknowledgment from a receiver. If the acknowledgment is not received in the period of time specified by the RN (Delay Slots) Command, the transmitter will transmit the original packet again.

RN Command is used to adjust the time delay that the transmitter inserts before attempting to resend a packet. If the transmitter fails to receive an acknowledgment after sending a packet, it will insert a random number of delay slots (ranging from 0 to (RN minus 1)) before attempting to resend the packet. Each delay slot lasts for a period of 38ms. If two modules

In the first case the RN value specifies the amount of time to wait before resending the data. In the second case it determines the variability in the random delay slots after failing to receive the acknowledgement. So which is it?

Sure wish this firmware had the muilti-transmit(MT) function. So my question is, why the loop back time increase increase linearly with RR?


What was the MY value of your receiving radio?

If you set the DT to 0xFFFF, then the RR value is used as a Multi-transmit instead.