next topic »

[Reply #15 on:]

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!

[Reply #16 on:]

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.

Code:

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);
}

[Reply #17 on:]

Hi Jack,

I'm not at home so I cant test the ATPN command to know the limit of my module but thanks you very much 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?

[Reply #18 on:]

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.

[Reply #19 on:]

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.

[Reply #20 on:]

Hi Jack,

I'm not at home so I cant test the ATPN command to know the limit of my module but thanks you very much 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?

No problem, it was an interesting exercise. Unfortunately I can't suggest an alternative module, but that is strictly out of ignorance, maybe someone else can.

[Reply #21 on:]

Hi Jack and thanks to jraskell for joining this discussion


I'm now back home (late) and I tryed this ATNP command but it was not working so I had a look on datasheet and of course this command is available on S2 but not on S1...

But anyway it's seems that S2 and S1 Xbee module is not adapted to my project, even if I succeed make it works, it will be used at the limit of its transmition capacity and that's not really good (it'll become sensible to any perturbation)

So I have two choice now:
- I can use two xbee module with two arduino with different frequency.
- Or I have to find another techonology :

What do you think about that for example : http://www.sparkfun.com/products/10822

Thanks a lot for your long help !

[Reply #22 on:]

Hi everybody,

Just to say few month later that my project is working really well with bluetooth mobule which is much faster than Xbee. I use that board : http://www.sparkfun.com/products/9358

Thanks all