XBee latency

Hello everyone,

I’m sometimes having 1 second latency with a XBee device. The XBee (XBee pro 868) is powered by the arduino mega 3.3V output and is wired to a 868MHz antenna.
For the software, I use the “serialEvent” to read each byte and since it is called after “loop()”, I made “loop()” not blocking for more than 5ms. I’m sending 10 bytes every 50ms.
10 bytes8 bits per byte20 times per second = 1600 which is under the 10% capabilities of the XBee (24kbps). I think it happends more frequently when it is hot in my room so it may come from the fact that the XBee puts itself in security mode and use this 10% duty cycle over 1 second. So does this device takes into account the transmission overhead ? I configured the XBee to create packets of 10 bytes in the transparent mode with :
“ATROA”
The code is in many files and it may be hard to read it so I didn’t give anything but I can give parts or explenations if you think it comes from it.
Any idea ?

Thank you,
Mickael

I’m not familiar with the 868 models, but I have observed the occasional long latency with low-power XBee ZB (S2) modules, e.g. XB24-Z7WIT-004. In API mode, time to transmit a packet and receive the ack is usually < 40ms. But occasionally I see something significantly longer, like 500-800ms. Pure speculation, but my assumption is that this might be due to route discovery or other protocol overhead, or MAC-level retransmissions.

An XBee Pro 868 needs up to 800mA current in transmit mode. According to the specs currently on the Arduino web site, a Mega 2560 can only supply 50mA from the 3.3V pin. Not sure if that’s part of the problem, but either way I’d certainly address it.

Thanks a lot,

I'm using the transparent mode and disabled the ack mechanism. That did not solve the problem. I will try to power properly the XBee. See you soon...

Nothing changed, I powered both XBees with a stabilized power supply (they used about 0.5 A together at 3.3V) and I still have a latency.

mickael86:
I’m using the transparent mode and disabled the ack mechanism.

Yes, well that doesn’t change what goes on between the XBees. The transparent vs. API distinction only concerns what happens on the XBee’s serial interface, not the RF link.

Thank you for the info. It could be that some packets are simply not received, I really don't see what is going on and I will buy new devices, one day...

I had another look at the specs, and noted:

RF Data Rate 24 Kbps (limited to 10% duty cycle)

If I understand your application, it is operating right at that limit; I might expect throughput problems especially with encryption turned on. If it were me, I'd try to keep throughput under half of the spec for starters (so 1.2 kbps), maybe less.

The device is sending 1.6Kbps, see my first post. I also tried with a period of 80ms which gives 1Kbps.
Even with the following, it does not work properly :
the remote control

void setup()
{
   Serial3.begin(115200);
}

void loop()
{
   char c = map(analogRead(A0), 0, 1023, 0, 255);
   Serial3.write(c);
   delay(50);
}

the robot

#include <Servo.h>

Servo s;

void setup()
{
   Serial.begin(115200);
   Serial3.begin(115200);
   s.attach(2);
}

void loop()
{
}

void serialEvent3()
{
   while (Serial3.available()) 
   {
      char c = Serial3.read();
      Serial.println((int)c);
      s.write(map(c, 0, 255, 0, 179));
   }
}

It is this example that made me think that some packets are lost, with a more complex example, I (think I) had a precise latency. I just had an idea : could it be the baudrate’s fault ?

I might try slowing it way down, maybe a period of 150-200 ms, just to see what happens. Using API mode would be a huge improvement; waiting for the Transmit Status frame before sending the next packet would maximize throughput yet dynamically adapt to variations in propagation which will naturally occur. OTOH transparent mode is an open-loop situation from the viewpoint of the application, and to be reasonably reliable, throughput has to be significantly sub-optimized and even then reliability cannot exceed that of API mode.

mickael86: I just had an idea : could it be the baudrate's fault ?

I don't see how. My usual approach is to use the highest baud rate that I can. Note again that the characteristics of the XBee's serial interface really have no direct effect on the RF traffic, specifically changing the baud rate does nothing to change the RF data rate or throughput capabilities. In using the highest baud rate possible, my thinking is only to minimize communication overhead between the XBee and the MCU (or whatever the XBee is connected to). Of course, higher baud rates make it easier to overrun the XBee's capability, but we always strive to operate all components well within their specifications, be they complex radio modules or simple resistors.

It does not work, I think I broke the devices, I remember it was working some months ago. Thank you for your help, I'm giving up for now and I will try with another devices.