Problems running API mode @115200


I’m trying to operate XBEE modules in API Mode with 115200 Baud. I’ve read throu some articles here about 115200 Baud issues. My real baudrate is 113636 (10MHz crystal) and I’m using two stop bits. Single commands like a query on a variable with an API AT command are working, but if I send a couple of these command, they are ignored.

For example: query PAN, query SH, query SL

If I add a pause of 10ms after each command, communication is working. If I reduce the pause to 2ms, only the first command is answered, the rest is ignored.

I also have RTS/CTS activated (D6 and D7 set to 1), but I’ve never seen a signal on these lines.

I haven’t tried a lower baudrate, for some other reasons I want to use the 115k setting.

What can be done to ensure reliable communication?

best regards and thank you for a reply


UARTs usually work by being fed with a clock at some frequency, which they then divide by 16 to get the baud rate. The clock with which the UART is fed is derived from the master clock frequency by dividing the master clock by an integer value.

Articles in these forums usually assume an XBee connected to a PC. The PC will generate an accurate 115,200 baud signal, and the closest the XBee can get to that is 111,111 baud. To get that, the XBee divides its 16MHz master clock by 9 for the feed to the UART: 16M / 9 / 16 = 111,111. The difference between 111,111 and 115,200 is enough that to make it work reliably the PC must be configured for two stop bits.

Your situation is different, because neither the 10MHz processor nor the 16MHz XBee can accurately generate 115,200 baud.

You say your processor generates 113,636 baud from a 10MHz crystal, but I don’t understand how that can be true because it implies dividing the 10MHz clock by 5.5. You can divide by 5 or by 6, but to divide by 5.5 you must have some pretty exotic circuitry in there…

To get good communication between a 10MHz and a 16MHz device, I’d recommend using 125,000 as the baud rate. Both devices can do this: the divider on the 10MHz device is 5, and the divider on the 16MHz XBee is 8. There should then be no need for the two stop bit trick, because the baud rates will match exactly.


>You say your processor generates 113,636 baud from a 10MHz crystal

I’m running an atmega @10MHz; Clock prescaler is 8 (U2X bit enabled) and UBBR is 10. This gives me: 10,000,000 / 8 = 1,250,000 as oversampling clock and then 1,250,000 / (10+1) = 113636.3636 as bitclock.

> I’d recommend using 125,000 as the baud rate

On the XBEE I haave to set BD and baud value as 32 bit, big endian, right?

best regards



anyway, it looks more like a software issue. I don’t believe it is a baudrate issue, since commuication is working if enough time is given after each command. At simple query to PAN takes about 10ms on the module until I get the answer. Is not allowed to queue more than one at-command at a time?

best regards


Ah - the divide-by-eight is a new one on me. Thanks for the explanation, and I stand corrected.

I don’t believe you can queue commands - you must wait for the response after each one before sending the next. Maybe that will fix the immediate problem.

To set the XBee to 125,000 baud you’d send ATBD1E848. I think you may regret it if you don’t take care of this issue - short command sequences may work fine, but longer data transmissions will be more likely to fail. The data rate discrepancy in your setup is 2.2% which doesn’t sound like a lot, but I think an 8-factor divider will leave less room for error (eg noise) than a 16-factor divider. Given that 125,000 baud is achievable at both ends, why not use it?