XBee, ZigBee, what’s the difference? Well, XBee is the electronic module that we had to buy for this project. ZigBee is the protocol suite that has been implemented in these XBee modules. ZigBee is more or less a set of rules that define how XBee modules can talk too each other. It can in some ways be compared with Wi-Fi, a protocol which for example allows us to send internet packets over our home or school network.
With wireless communications there a high risk of data loss due to interference and so the remote XBee module might either receive nothing or it might receive false information/queries. ZigBee makes sure that we know when things go wrong, and if there is something wrong that the information or data is being re-transmitted. ZigBee defines how two or more modules can talk to each other in a reliable way. But ZigBee is more than that, XBee has UART communication pins, I/O pins and a whole set of commands which makes it for users easier to send and capture remote data. You don’t have to build bitstrings yourself but you only have to enter the correct ASCII codes in a terminal session. This is called AT mode communication. Furthermore there is also API mode which is a set of networking layers on top of this which make it easier to use more advanced network designs. This brings us to the question what AT and API mode exactly is.
AT mode is a simplified way of sending and receiving data from your USB/Serial connected XBee module. In AT mode the user has to open a terminal and type ‘+++’ to enter command mode for 1à seconds and the XBee module will respond with ‘OK’ indicating that you can now enter AT commands. If one would for example enter ‘ATVR’, the XBee module would then answer with its firmware version. When not in command mode all data at the UART pins is being transmitted to a remote XBee module through the air, therefore the user has to enter the network address of the other XBee module in AT command mode. This makes AT mode useful for basic point-to-point communication as seen in the picture above, or when no I/O data needs to be captured.
But what if we need to communicate with more than one remote sensor? The local XBee modem would than have to be reconfigured every time we want to contact another sensor. Therefore API mode has been introduced. In a kind of OSI layers encapsulation mechanism (http://en.wikipedia.org/wiki/OSI_model) the data that we send and receive to our local XBee module is no longer send as rough data bits but now comes in packets which have a specific purpose. The XBee module also has to be loaded with different firmware in order to allow API mode communication. All together we now have a whole bunch of different API frames (=API data packets) which allow a more advanced network design as seen in the picture above, and it also allows us to receive I/O data from remote sensors.