Xbee not working with multiple data

Hi everybody,

As I am a newbie I have a newbie question :-) I hope that it's not so stupid...

I'm trying to estblish a xbee communication between my arduino and my computer at 115200 bate rate (because I send data from 9DOF gyro/acc/magnetometer sensor board and I need a maximum reactivity).

I folow the X-CTU tutorials, I change the baud rate in the two Xbee module, check the ID and the channel.

I succeed to establish communication for a small amount of data like that :

void setup()
{

  Serial.begin(115200); 

}
void loop()
{
   Serial.print("hello");
   delay(50);
}

But when I send huge amont of data (which is what I need for my project) it's is working really bad and I receive incomplete data with strange caracter merge in it...

void setup()
{

  Serial.begin(115200);

}
void loop()
{
  Serial.print("XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDD");
  Serial.print("EEEEEEEE,FFFFFFFF,GGGGGGGG,");
  Serial.print("OOOOOOOOOOO,");
  Serial.println("1024,1024,1024,1024,1024,1024");
  delay(50);
}

I hope it's not due to physical limit of my xbee module, or if so, do you know a tips to make it's works?

Thanks by advance for your help

But when I send huge amont of data (which is what I need for my project) it's is working really bad and I receive incomplete data with strange caracter merge in it...

So, where is the receiving code? There are limits to the size of the receive buffer on the Arduino. If you are not receiving data as fast as it is being sent, you may be overrunning the buffer, resulting in incomplete data. You didn't show any output, so we have no idea what the strange characters are, and you didn't show the receiver code, so we have no idea why.

There is a big difference between sending large amounts of binary data, like the device is producing, and sending, receiving, parsing, and converting large amounts of ASCII data. You almost certainly will not be able to obtain the transfer rate you need sending ASCII data.

What throughput do you need? See http://arduino.cc/forum/index.php/topic,72672.msg550963.html#msg550963

Thank you both for you help,

[u]First, PaulS ;[/u]

I dont really understand when you say :

There are limits to the size of the receive buffer on the Arduino. If you are not receiving data as fast as it is being sent, you may be overrunning the buffer, resulting in incomplete data

Because I dont receivce data on the arduino, I send it with the arduino to the computer?

You didn't show any output, so we have no idea what the strange characters are, you didn't show the receiver code

I use the arduino Serial Monitor as receiver (or in VVVV software wich is similar to Max) and I obtain that on both software:

XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1?¢b???¢
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1?¢
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1??¢b???¢
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1????¢b???¢b???¢
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,121024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1?XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1?XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1?XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1024,1024,1024,1024,1024
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1????¢b???¢b???¢b??24
XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDDEEEEEEEE,FFFFFFFF,GGGGGGGG,OOOOOOOOOOO,1024,1

Sorry but I also dont really get the difference between sending Binary data and ASCII data as for the moment I'm just playing with different tutorial to build my project (wich is a glove music controller) and I dont really have the basic knowledge of all that programming stuff (but I motivated to learn!)

So I just know that I have to send 4+3=7 hexadecimal values wich come from the 9DOF board, I need hexadecimal because It's allows me to have more precision as Fabio Varesano, the inventor of this nice board explain here :http://www.varesano.net/blog/fabio/sending-float-variables-over-serial-without-loss-precision-arduino-and-processing And and I also have to send 11 char code wich come from my RFID reader, and 6 sensor analog values read on the arduino !

[u]And to answer Jack[/u], all that data have to be send as fast as possible because my 9DOF board is fixed on a player hand. And I would like a quick and precise reaction as different sound will be launch depends of the player movements. It's working well with a cable at 115200 bits/sec, but very bad at 9600 bits/sec (I can heard the sound time reaction).. so I dont really know the throughput I need but the maximum would be the best. ( for information, I have 1-2 meter distance between the computer and the player )

Hope that precision anwser your question.

Because I dont receivce data on the arduino, I send it with the arduino to the computer?

I missed that. I thought you were having 2 Arduinos talk to each other.

Sorry but I also dont really get the difference between sending Binary data and ASCII data as for the moment I'm just playing with different tutorial to build my project (wich is a glove music controller) and I dont really have the basic knowledge of all that programming stuff (but I motivated to learn!)

ASCII data will require that you convert the floats to strings, to send. Binary data will send the float as 4 bytes.

So I just know that I have to send 4+3=7 hexadecimal values wich come from the 9DOF board, I need hexadecimal because It's allows me to have more precision as Fabio Varesano, the inventor of this nice board explain here :http://www.varesano.net/blog/fabio/sending-float-variables-over-serial-without-loss-precision-arduino-and-processing And and I also have to send 11 char code wich come from my RFID reader, and 6 sensor analog values read on the arduino !

7 floats = 28 bytes. 11 characters = 11 bytes. 6 ints = 12 bytes. 28 + 11 + 12 = 51 bytes. Add a pair of packet markers for a total of 53 bytes.

Serial.print("XXXAAAAAAAA,BBBBBBBB,CCCCCCCC,DDDDDDDD");

That one line is 38 bytes.

It's unlikely that every packet sent by the Arduino will contain RFID data. So, you really should consider 3 types of packets - one for the 7 floats, one for the 11 characters, and one for the 6 ints.

Use different start and end markers for each, so you know what kind of packet it is.

The test you are performing now is unrealistic in terms of the amount of data you really need to send.

rogerlette: [u]And to answer Jack[/u], all that data have to be send as fast as possible because my 9DOF board is fixed on a player hand. And I would like a quick and precise reaction as different sound will be launch depends of the player movements. It's working well with a cable at 115200 bits/sec, but very bad at 9600 bits/sec (I can heard the sound time reaction).. so I dont really know the throughput I need but the maximum would be the best. ( for information, I have 1-2 meter distance between the computer and the player )

Hope that precision anwser your question.

I was hoping you would quantify how fast you need to send data. Sounds like 115kbps is enough, but how much is actually being sent and in what period of time. See the link to the other thread I posted earlier. Looks like the best that can be expected is around 35kbps, and that's ideal conditions with no safety margin.

Hi again,
(sorry for the reply delay I was not at home this week)

So following your advices PaulS, I modify my test which is now more realistic I think :

void setup()
{

  Serial.begin(115200); 

}
void loop()
{
  int integer = 1024;
  
  Serial.print("!"); // start marker for float packet = 1 byte 
  Serial.print("AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG"); // 7*8 char = 56 bytes (float convert to char)
  Serial.println("#"); // end marker for float packet = 1 byte 
  
  Serial.print("&"); // start marker for rfid packet = 1 byte 
  Serial.print("OOOOOOOOOOO"); // 11 char = 11 bytes
  Serial.println("*"); // end marker for rfid packet = 1 byte

  Serial.print("+"); // start marker for integer packet = 1 byte
  Serial.print(integer); // 6 int = 12 bytes
  Serial.print(integer);
  Serial.print(integer);
  Serial.print(integer);
  Serial.print(integer);
  Serial.print(integer);
  Serial.println("-"); // end marker for integer packet = 1 byte

  delay(50);
}

I assume that it would be better to not convert all the floats to char because it’s less heavy in terms of byte to send. But as they are well transfered (see below) and as I would prefer to receive it as char I want to keep it like this for the moment.

So finally I need to send 85 byte, and here is a result of the test in the serial monitor:

!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+102410241024102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+10241ó!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+102410241024102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+10241ó4102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+102410241024102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+102410241024102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+102410241024102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+102410241024102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+102410241ó102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+10241ó102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+102410241024102411024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+1ó10241024102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+110241024102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+102410241024102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+102410241102410241024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+10241024102411!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+1024102410241ó41024-
!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+10241024102411!AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG#
&OOOOOOOOOOO*
+10241ó

So I have different questions :

  • It’s seems that the char are always transfered correctly compare to the integer why ? I also observed that phenomena in my previous test (see my previous post above) this is just about sending bytes it should be the same ?

  • Anyway I was thinking to reject all the bad packets and just keep the good ones, but of course I have another problem ! This test is working just few second, then the communication is stopped do you have a idea why ?(I tryed two different serial monitor software…)

  • To answer Jack C., If I consider that my project works well when I send 85 bytes every 50ms, it’s means that I send 85*(1000/50)=1700bps so with 3500bps connexion it should be ok ?

I’m working a lot to understand all that communication stuff so sorry if I misunderstood some stuff…
Thanks for your help.

rogerlette: - To answer Jack C., If I consider that my project works well when I send 85 bytes every 50ms, it's means that I send 85*(1000/50)=1700bps so with 3500bps connexion it should be ok ?

I figure it as follows, "bps" (lower case b) in the Digi product manual meaning bits per second.

85 bytes/50ms = 1700 bytes/sec * 8 bits/byte = 13.6k bits/sec

Which seems like it should be OK if only one hop is involved (and I'd keep security disabled, which is the default setting), but I wouldn't be surprised if the occasional retry could possibly gum up the works.

Thanks Jack,

I was thinking "bps" was "byte per sec" ... (This illustrate my level with eletronic stuff!)

Anyway the good news is that with 13.6 kbps it still seems to be ok ! But I dont get the details because I'm french so my english vocabulary is poor (and google translate is lost too)... So what do you mean by :

if only one [u]hop[/u] is involved

?

I have keep the security mode of the two Xbee module disable and I understand that the occasional retry can reduce the communication speed but I want to understand the two other questions of my previous post before just give up and reduce the speed...

Hey if you hadn't told me, I wouldn't have known, some of us USAnians aren't real great with English either! XD

If you only have two XBees, then it's only one hop. A hop is counting any intermediate nodes the packet goes through. So if I have three XBees, and if a packet is sent from "A" to "C" and gets routed through "B", then that's two network hops. With multiple nodes, especially with mesh networking, we can never be 100% sure how many hops a packet will take, as the network decides dynamically.

Thanks for that clear lesson :-)

Do you have any idea about the causes of that two observations ?

  • It's seems that the char are always transfered correctly compare to the integer why ? I also observed that phenomena in my previous test (see my previous post above) this is just about sending bytes it should be the same ?
  • Anyway I was thinking to reject all the bad packets and just keep the good ones, but of course I have another problem ! This test is working just few second, then the communication is stopped do you have a idea why ?(I tryed two different serial monitor software...)

I see that, it does seem odd. Which XBees are you using? Do I understand the setup correctly? Arduino with XBee is sending the data, and the other XBee is just connected to a terminal program for testing?

Exactly, here is the detailed setup :

On one side :
An arduino

On the other side :
A computer

So I just send data from the arduino to the computer, and I read it with the arduino serial monitor or (other serial monitor software to check that the problem is not the serial monitor)

To configure the Xbee module, I just use X-CTU and change the baud rate (I put the same on both module).

I'd offer to try and duplicate the setup and run the test sketch, it wouldn't take long, but I have only S2 XBees. Still I may give it a go as that's a lot more data than I've tried to pump through them before, might be interesting.

Hi,

Thanks a lot it could be really nice to you if you could do the same test at home :-) And if it's working with your Xbee module I'll buy the same because after two week spend on this communication problem I begin to be desperate...

Is there an other Xbee module or an other wireless way to send a lot of data from an arduino to a computer?

Sorry did not get around to it today, events conspired against me :~ It may be a couple days until I get a chance, so be patient. I am curious to try it though!

Stole some time back.

The second sketch as posted above overruns the XBees, it sends too much data. Check the ATNP command, this is the maximum number of RF payload bytes that can be sent in a unicast transmission. On my S2 modules, it's 0x54, or 84 bytes. The sketch as above sends 103 bytes with 50ms pauses. The XBees keep up for a little while, but then lose their brains and start garbling up the data. Not surprising as we are exceeding the maximum number of bytes!

If I comment out the third section of code (that sends the integer number six times) as shown below, that reduces the payload to 75 bytes and it seems to run fine. If it were me, given the high data rate, I'd try to not push too close to the 84-byte maximum, I'd leave a 10%-20% safety margin. BTW if you have S1 modules, your ATNP value may be different.

One final comment, the third section of code that sends the integer is sending it as four ASCII characters, not as two binary bytes. This is why "1024" can be read on the receiving end.

Hope this helps.

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

void loop()
{
  int integer = 1024;
  
  //following three lines send 56 + 2 marker + 2 CR/LF = 60 bytes
  //Serial.println appends a Carriage Return 0x0D and Line Feed 0x0A
  Serial.print("!"); // start marker for float packet = 1 byte 
  Serial.print("AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGG"); // 7*8 char = 56 bytes (float convert to char)
  Serial.println("#"); // end marker for float packet = 1 byte 
  
  //following three lines send 11 + 2 marker + 2 CR/LF = 15 bytes
  Serial.print("&"); // start marker for rfid packet = 1 byte 
  Serial.print("OOOOOOOOOOO"); // 11 char = 11 bytes
  Serial.println("*"); // end marker for rfid packet = 1 byte

  //following lines send 24 + 2 + 2 CR/LF = 28 bytes (with integer=1024)
  //note that the variable "integer" is not being sent as two bytes, but as ASCII characters,
  //specifically four characters when integer=1024.
  //total is 103 bytes
//  Serial.print("+"); // start marker for integer packet = 1 byte
//  Serial.print(integer); // 6 int = 12 bytes
//  Serial.print(integer);
//  Serial.print(integer);
//  Serial.print(integer);
//  Serial.print(integer);
//  Serial.print(integer);
//  Serial.println("-"); // end marker for integer packet = 1 byte

  delay(50);
}

Hi Jack,

I'm not at home so I cant test the ATPN command to know the limit of my module but thanks you [u]very much[/u] for this test and this precious help.

I'll check that as soon as I go back home (end of the week).

In case of my module is similar than yours or worst, I have just a last question... Do you know an Xbee module wich can send more than 103 bytes (+20%) ? Or an other technology tiny enouth to be mounted on a glove?

My experience with Xbee S1 modules is that they're only reliable at 115200 in clean environments. These modules operate in the 2.4ghz band. If they're in close proximity to any sort of wifi router that also operates in the 2.4ghz band, then 115200baud even at short ranges was unreliable for me.

I've had no problem working at 57600 baud though, even in close proximity to wifi routers, and by close proximity I mean a wifi router sitting mere inches from the Xbee on an RC rover.

At 57600 baud, you get a theoretical max throughput of 5760 characters per second (there's a minimum of 10 bits per character. 8 data bits, but also 1 start and 1 stop bit). With an 85 character data packet, this will provide a maximum theoretical update rate of about 67hz. 50hz should be a real world attainable rate though.

85 bytes every 50ms, it's means that I send 85*(1000/50)=1700bps so with 3500bps connexion it should be ok ?

Your data rate is whatever baud rate you are operating at. Periods of inactivity are irrelevant in that respect as, when you send 85 bytes of data, it is being sent at the baud rate specified. From a transmission point of view, there is no credit for periods of inactivity. That's not to be confused with any processing time requirements on the backend or frontend, which may or may not benefit from periods of inactivity.

jraskell: Your data rate is whatever baud rate you are operating at.

If you are simply referring to the speed at which the MCU or whatever communicates with the XBee locally on the serial wire, then yes, but if we want to look at throughput, then we must consider all links in the chain, notably the RF link between modules. Your own experience shows this. The throughput on the RF link was obviously greater than 57kbps but less than 115kbps, despite the fact that the serial link was operating at 115kbps. Regardless of the local connection to the XBee, its baud rate or mode (AT or API), the RF link between modules operates identically. Obviously I have no way of knowing, but given your observations, it would seem reasonable to assume that interference from the WiFi router was causing retries on the RF link which reduced overall throughput. Reducing the serial link speed to 57kbps had no effect whatsoever on the interference, the retries likely continued exactly as before, now things were just operating at a data rate that the RF link could handle, including retry overhead.