ZigBee
ZigBee network architecture
So far I was able to make a wireless chat channel in which every letter I typed on one computer would also appear at a second computer and vice versa (through my own Java software). As my task is to set up a communications network where we can query remote data of multiple sensors, you may have already guessed that the network design might get a bit more complicated than the basic AT mode point-to-point connections that I’ve been experimenting with so far. With ZigBee we have 3 different types of devices that can be found in a network:
Coordinator (PAN coordinator): this devices coordinates every networking traffic, it acts more or less like a gateway modem in most applications. There must always be at least one, and only one coordinator per network.
Router (full function device): this devices can act as an end device in such a way that it can receive commands and send I/O data, but furthermore it can also route data to other devices. Routers acts more or less like devices in between the coordinator and endpoints, they can for example extend the reach of a network when the transmitting power of the coordinator is not strong enough.
Endpoints (reduced function device): these are the most basic ZigBee devices and allow only queries to be executed or (I/O) to be send to the coordinator.
The above image shows few example of how XBee modules might be interconnected. We can determine few things from this picture:
1) the PAN coordinator is the one we’re going to have to connect to our RaspBerry-Pi linux server which we will use as gateway to our home IP network.
2) the more advanced network topology requires us to use API mode firmware on our XBee devices (see my previous post)
Also know that end devices do not need to be set up as API mode devices. API frames says something about the communication between our computer and our XBee module, not about what data is being transmitted in between XBee modules.
Most of this information kind be found in Robert Faludi’s book Building Wireless Sensor Networks (ISBN: 978-0-596-80773-3), which due to its practical examples is also recommended for every XBee/ZigBee newbie. Furthermore it seems that other people all ready have been working on implementing the ZigBee API in Java. Andrew Rapp has mode his code available at the following location: https://code.google.com/p/xbee-api/
At this moment I can confirm this API to be working in a test application, I have made a basic ZigBee network with one Coordinator API connected to my pc and another Router AT device at a remote location sending the analog voltage at its AD0 pin.
In real life I don’t actually use 2 computers though, I connect the two XBee modules to the same computer but at different USB ports. The idee remains the same though, we’re transmitting the data through the ether, not through the USB controller. The Arduino uController boards act as a USB to Serial converter (like mentioned in previous posts).
What’s next? I hope to have some good news about the delivery of the Raspberry-Pi computer, I’ll also try to set up a more advanced sensor network.
The ZigBee wireless protocol stack
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.
AAL4ALL project details
As mentioned earlier, my project involves setting up a sensor gateway and trying to get sensor data through the ZigBee wireless protocol. As sensor gateway I’ll be using a Raspberry-pi computer:
This computer has the size of a credit card and can in terms of processing power be compared to a Pentium 3 computer. It’s been released in 2012 and it has build up some popularity as a media center device, but it’s also used a lot in electronic projects. Because of it’s low power usage, it’s ability to run Linux and it’s ability to directly connect to other electronics through it’s IO pins and USB ports, makes this board perfect for using it as sensor gateway. The board will run Linux and we will use it to collect sensor data and afterwards make the data available on the home network or even to online internet services. The R-Pi has an RJ45 ethernet port which allows us to connect our gateway directly to our home router. The sensor data will be collected wireless through the ZigBee protocol. ZigBee communication is in some way comparable with Wi-Fi and uses radio frequency waves. To use ZigBee I’ll be using XBee modules, one at the gateway side and one per sensor that I want to interconnect.
XBee modules support UART which is also supported by the Raspberry-pi board, and the R-Pi also provides the correct supply voltage so we can directly attach the XBee modules to the Raspberry-Pi, but due to the pin layout and size we will also need a breadboard and a breakout board and some electrical wires off course:
Currently I’m still waiting for the Raspberry board to arrive but the coming weeks I’ll spend some time exploring the ZigBee protocol by connecting XBee modules to my portable through the USB-port. I’ll also try to write a basic Java program which allows me to easily configure these XBee modules and with which I can send and receive data. Once again, wish me luck!
after hours coding 