Why API 2 mode

XBee & XBee Gateway XBee - 802.15.4
1

Maybe I’m missing something, but why would you want to use API-2 mode over API-1 mode. Is it for the case where the serial devices that talk to the XBee modules use XON-XOFF and you cannot just have them use hardware flow control. But the XBee doesn’t support XON-XOFF, is this just using the least common denominator approach. Basically, with API-2 mode the XBee will talk to just about anything?

Just wondering. I’ve had pretty good luck with getting a couple basic stamps to talk to each using XBee’s and to a central computer running linux with an XBee attached to it. I’ve always used API-2 mode but I really cannot say exactly why other than that is what the java api mode I found for the linux end of thing supports.

2

Your idea is right: hardware flow control is between each XBee and its host, whereas XON/XOFF is between the two hosts. XBees don’t take any special notice of XON/XOFF characters but API mode 2 is provided so that XON and XOFF can be transmitted from host to host without misinterpretation.

If you’re not using XON/XOFF then you don’t need API mode 2 (though it does no harm). Well, there’s one exception there: because the 0x7e character is also escaped when it happens inside a packet, API mode 2 does also make it easier to synchronize to the start of the next packet when things go wrong.

(Next time I reissue the cookbook you’ll find an added section on this.)