Different latency in same baud rate and distance

DigiJack

I am trying to get latency of my Xbee modules. I have 2 sets of Xbee and Arduino UNO. I am using one node (Xbee Series 1+Arduino UNO) in one end and using another node in other end. The Xbees are configured with AT mode. I have uploaded required code to two of the Arduinos to send and receive 16, 32, 64 bytes of data. I am sending data by Xbee and Arduino but using docklight (http://www.docklight.de/) software to see the time it is taking to go from one end to another. Using docklight helps me record the time and it is the only purpose I am using it. So, after sending from one end I am recording the time, and when I am receiving it in another Xbee+Arduino node (this is connected with another PC), I am recording the time once again in docklight of that PC. The difference between these two time I am considering as latency. Please be informed that I have not changed any configuration in XBee except did put destination address of the receiver Xbee in the sender Xbee.

Now the problem is: though I am not changing anything (distance, baud rate etc) the latency is coming different each time. Should not the reading always come same for same data size and baud rate?

Phil Pilgrim (PhiPi)

DigiJack wrote:

Should not the reading always come same for same data size and baud rate?

With XBees, no. Between the uncertainties due to data buffering and error-correction -- possibly retransmission -- I'd be surprised if the latencies ever came back the same.

-Phil

DigiJack

Thank you very much for your reply. I was wrong assuming that it depends on interference or physical objects. And it's true that the difference is not very big but there are some milliseconds difference between them always. I am not very knowledgeable about Xbee's error correction capability. So, please pardon me if I am asking something very obvious: Then, even if I don't set any error correction scheme in AT mode, Xbee still performs error correction? So, is it something that when in back-end sender Xbee comes to know that the data it sent or the data receiver received is erroneous, it sends back another data?. Then should it show the repetition of data in serial monitor (in case of Arduino) or terminal (in case of XCTU)? Or it happens also in back-end of the process? Again thank you for your answer. Hope you will find some time to answer my query asked now.

Phil Pilgrim (PhiPi)

DigiJack wrote:

Then, even if I don't set any error correction scheme in AT mode, Xbee still performs error correction?

As I understand it, that's what makes the default "cable emulation" mode so dependable.

-Phil

Tracy Allen

There are a several AT parameters that affect latency. The "packetization timeout" ATRO has a default value of 3 character delays at the current host baud rate, say, 3+ms at 9600 baud. That is a fixed part of the latency but can be changed to a wide range of values to meet system requirements. There are also ways to send data on command and to cut short the latency. Once the packet is set to send, the radio performs CCA, clear channel assessment, which takes some time and will cause a delay, especially if there happens to be RF energy on the channel. Once the channel is assessed clear, the transmission occurs at an over-the-air baud rate of 250kbaud. The transmitter expects an acknowledgement back from the receiver. If the ACK does not come at first, the transmitter waits a random time (ATRN, random delay slots exponent), and tries again. It re-tries up to three times, and if it does not succeed, the data is lost. There is another command unique to xbee (ATRR, xbee retries) that will force the xbee to make up to 6*4=24 retries. I've not poked into the actual delays, but the literature states that the delay to wait for the ACK is 200ms with up to 48ms random time. Note that it takes about 5ms to transmit a 100 byte packet at 250kbaud. Broadcast data (DL=$FFFF) does not ACK, and has different retry logic.

I'm curious, what sorts of latency are you observing? I'd wonder, can you trust the PC/docklight to record accurate times, particularly since they are running on different PCs?

DigiJack

Tracy Allen wrote: »

I'm curious, what sorts of latency are you observing? I'd wonder, can you trust the PC/docklight to record accurate times, particularly since they are running on different PCs?

Thank you a lot for your answer. That is exactly what I was looking for to know.

About your query: I understand that PC/docklight can not be regarded as the most efficient tool to recerd times in two different PCs. But I have tried to minimize the difference in the PCs timing and also leaving some buffer time. I am just analyzing how much [tentative] time does Xbee take from going one end to another with different data size.

Thank you once again. I wish here was something to give up-vote!