Speed related XBee issue


I’m having some issues getting a pair of XBees up and running at 57600.

I’ve got the Arduino set up on a breadboard, and can program it fine using an FTDI breakout board. I’m using the sparkfun XBee explorer boards. I’ve changed the interface rate to 57600 and they can talk to each other, and I can even program the arduino wirelessly. But I’ve written a little application that reads a character, displays in on an LCD, and responds with that character surrounded by ‘#’:

#include <Streaming.h>
#include <ks0108.h>
#include "SystemFont5x7.h"   // system font

void setup(){

  pinMode(3, OUTPUT);
  digitalWrite(3, HIGH);
  GLCD.CursorTo(0, 0);
  GLCD.Puts("hello, world!");
  GLCD.CursorTo(0, 1);

int line = 1;
void  loop()
  if ( Serial.available() )
    GLCD.CursorTo(0, line++);
    char c = Serial.read();
    GLCD << _BIN(c) << " = " << c;

When I enter characters into the serial monitor one at a time (ie. enter one, press send, enter another) it works as expected. When I enter a string and send it, the response becomes garbled.

Eg. I enter “12345”, and the response should be:


but instead I get:


These incorrect characters also show up on the LCD, and the hashes are always correct, which suggests to me that it is the PC to Arduino link that is to blame.

I tried dropping the baud rate of the xbees down to 38400, and that fixes the problem and it works fine. This would be acceptable, but I would rather like to be able to program wirelessly.

I’ve tried a different FTDI board on the PC side, and I’ve tried using the xbees standalone without the sparkfun explorer boards, but the issue persists.

Anybody have any ideas what I could look at next, or what could be causing this?


There have been a number of posts lately, centering around Serial.read needing, or not needing a delay after it. For some people/boards/code, it is not needed. For others, it is. It seems like Serial.read() is not a blocking function. It begins the transfer process, moving the character into c, and returns. If the next instruction access c, sometimes it gets the right value, and sometimes it doesn't.

Try adding a very short delay after the Serial.read statement - around 5 milliseconds seems to be enough.

Unless the reading of the serial data is time-critical, the delay shouldn't cause any problems.

There have been a number of posts lately, centering around Serial.read needing, or not needing a delay

I am interested in understanding more about this, I found [u]this[/u] thread but the OP wanted to receive more bytes than the serial buffer holds so perhaps that could explain why a delay was needed in his application. Have you come across another situation where a delay was needed after serial.available returned a non-zero value, but immediatly reading a byte returned an incorrect character?

The other threads I'm thinking of, I guess, involve needing to do a Serial.print after the Serial.read, which introduces a small delay.

That's how I initially found the problem. With Serial.print after Serial.read, the program worked as expected. Removing the Serial.print statements cause the program to quit working. Adding a short delay caused the program to resume working.

Do you have links to any threads that could provide sufficient detail to try and reproduce this issue.

I couldn't find the specific thread that got me looking into this in the first place. The code I put together was to answer a question, so I didn't save it, either.

I tried adding the delay, but that hasn't helped. I went up to 50ms and the issue remained.

I've been examining the output, and if you observe the binary, it seems that the values are getting shifted around somehow. The value for '4' is almost right.