I am having problem in finding the difference between between API 1 and API 2 mode of XBee . I have done my programming stuff and i have my master's thesis defence on Wednesday. I know how to use XBee but i am very weak in basics of RF. Please explain this difference in few basic words which i can speak in my thesis defense.
I personally don't like API mode 2 because it adds to the complexity of sending and receiving data unless you handle it at a low level of your serial driver.
The benefit of API mode 2 is that you can watch the byte stream and know that any 0x7E
byte you see is definitely a "start of frame". With API mode 1, it's possible to see that byte within a frame's contents.
If you pick up a stream in the middle, you need to do additional work to verify you've found the start. It isn't very difficult to do, especially if you include a sanity check on the 16-bit frame length following the 0x7E
start of frame. In most cases you'll be decoding complete frames and not need to look for the start of the next frame.
Since escaping also include XON and XOFF characters, I guess API mode 2 might be necessary if there are other devices in the serial stream (wired in between the XBee and the host sending/receiving frames) that can't handle those characters.
Edit to include details on API mode 2:
In either API mode, the byte 0x7E
indicates start of frame.
In mode 2, if the following bytes appear inside the frame, they're replaced with an escaped two-byte sequence of 0x7D
followed by the original byte XORed with 0x20
:
byte in frame | escaped sequence |
---|---|
0x7E (start of frame) |
0x7D 0x5E |
0x7D (start of escape sequence) |
0x7D 0x5D |
0x13 (XOFF) |
0x7D 0x33 |
0x11 (XON) |
0x7D 0x31 |
Note that the frame length and checksum are based on the original, unescaped sequence of bytes. If you are writing code to handle escaping outbound frames and unescaping inbound frames, you want it to happen at a fairly low level of your serial driver.