I've been experiencing some delay issues communicating between processing, xbees and an arduino. The delay is significant enough, anywhere from 2 -10 seconds, that I must have something setup incorrectly.

Essentially, I've got a processing test sketch controlling and reading the sensors and motors off of my arduino.  I have a sparkfun xbee dongle attached to the computer and an xbee shield attached to my arduino. I loaded Standard Firmata onto the arduino. Similar to what was done to the Firmata library at michaelclemow.com's blog (I can't post the full link)  I instead modified the Arduino library slightly to recieve the xbee parameters from processing, rather than hard code them into the Firmata.cpp file.
I added this to the constructor of Arduino, passing in a new object called XBee
Code:

if(xb!=null){
    xb.writeToSerial(serial);
}
 

The xb is just a helper class and the meat of the writeToSerial method is this:
Code:

serial.write("+++");
serial.write("ATDH"+destinationHigh+", DL"+destinationLow+"\r");
serial.write("ATMY"+myAddress+"\r");	
serial.write("ATID"+panId+"\r");
serial.write("ATCN\r");
 

All that works great. the problem is, that like I said earlier, the sketch controller seems to have a delay of 2-10 seconds. If I remove the xbees from the architecture, everything responds correctly and quickly.

When I reattach the xbees, its response times slow to a crawl. At first I didn't think they were working, but I've been able to confirm it's just delayed. I've added print statements pretty much everywhere and it seems as though the arduino receives the commands, but hangs somewhere.

I have the baud set to 115200 and the packetization timeout set to 0 and it's faster than it was at the default of 3, but something is still wrong. I've changed to a lower baud rate and that seemed slower as well. The xbees are right next to each other right now.

The coordinator zdnet 2.5 Destination address is set to FFFF, which is broadcast all. Are there any optimal performance settings that can be tweaked?

Even without running through Processing, and just testing the radios through gtkterm, the response is slow. So I'm pretty sure it's something with the xbees.

Running on Ubuntu 8.10, jdk6, arduino 15, processing 1.0.3, xbee series 2.5's. I am running avr-gcc 4.3, which I know has a major bug with long's to int's; is it possible that this bug is being exposed though the timing protocols?

Any Ideas?

No actually, using gtkterm, I can query the remote xbee with the command "ATND" and that command takes a couple of seconds to respond as well.  And when I turn on my Processing sketch that is reading and sending commands via the Arduino Processing library the delay is greater.

The Arduino for Processing library assumes that the Standard Firmata is loaded onto the Arduino. Under the hood, it's just interpreting the serial commands.

I have a feeling it has something to do with the coordinator being set to broadcast all (0xFFFF). I've been reading through all the digi specs, but haven't found anything to support that theory yet.