XBee data collecting

So, before I take a few days of vacation to explore the city with some of my friends, a few words about my XBee project. Last week I made a XBee API coordinator node which collected IO sampels from remote XBee devices in AT mode. The analog data was generated by connecting a potentiometer to the AD0 port, with one end tied to Vcc (3.3V) and the other end to ground. Afterwards I collected all the data in a imaginary database by writing all data into a textfile. Data packages I save in the ‘database’ look more or less like this:

4-apr-2013 16:11:43#0008#ZNET_IO_SAMPLE_RESPONSE#0x40,0x2e#0x00,0x13,0xa2,0x00,0x40,0x79,0x5a,0xff#

Last week I also set up a TomCat webserver on which I’m running a .JSP website. When requesting the web page I’m at this moment reading from the text file that is used as database, and afterwards I sort all data in a Treemap<String, TreeSet>. Then, I use the RGraph library which shows the analog sample in a nice interactive graph. A dropdown list lets you select the data from each individual network node, as you can see from the picture below:



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.

“xbee unable to communicate with modem”

It seems that one can quite easily lockup these XBee modules. Today I used the X-CTU application to change the XBee configuration from Router AT to Coordinator AT (more on that later) and after writing to the XBee module completed I suddenly lost all communication. “xbee unable to communicate with modem”. So I tried using other XBee modules and reflashing the Arduino board but in the end I got to the conclusion that the XBee modules was causing the errors. Searching on the web I found not to much information that could really help me, the documentation on Digi’s website didn’t get me any further and on others sites they tell you to mess around with the COM-port settings and to check if it’s the correct COM-port, etc. But I noticed that sometimes after I reset the XBee module (unplug and plug the Vcc wire) I would have a small amount of time to enter some commands. Not enough for the X-CTU software to query the whole device but enough to enter 3 or 4 commands. So here is how I fixed it:

1) open X-CTU and use 9600 baud rate and other default communication parameters
2) open the terminal tab in X-CTU
3) reset XBee module (you can unplug and plug the power connections for example)
4) after XBee has been reset, try to enter AT command mode by pressing ‘+++’ (without enter!)
5) if XBee replies with ‘OK’ communication is working and your now in command mode. If it does not, try entering command mode again few seconds later by again pressing the same ‘+++’ command (without enter!). If it still doesn’t respond try resetting again and wait a little longer or a little less before you give send the command.
6) In command mode, give the ‘ATRE’ command which will erase the custom configuration and which will send you back to the default config. XBee will confirm with ‘OK’. Then send the ‘ATWR’ command which will save the current (default) configuration in the non volatile memory so that the next time you boot up you’re back at defaults. XBee will once again reply with ‘OK’.

The reason why the communication failed in the first place is not very clear to me. I found some info that explained that perhaps one of the XBee sleep mode configuration settings got wrongly set by X-CTU and that perhaps the module goes to sleep soon after it has booted. So that’s why you have to enter these commands after a reset. I don’t know if this is correct because there is a pin on XBee (pin 13) which tells you if the XBee is on or sleeping. If I use a LED to display the status of this pin it stays HIGH all the time indicating that the module is not sleeping. Anyway, if you run into the same problems as I did than this might be a fix, bon chance.

Early XBee tests

And so I received some tools to play around with: 3 XBee modules + breakout board, 2 breadboards and 2 Arduino Uno micro-controller boards. I didn’t get enough electrical wires yet to put all at good use, but as far now I’m only trying some basic configuration commands with only one XBee module. You can see the setup below: 3,3V and GND supply voltages are taken from the Arduino board while Arduino’s pin 0 (RX) is connected to XBee’s RX pin and Arduino’s pin 1 (TX) is connected to XBee’s TX pin. This way we can use the Arduino board as a USB to RS232 converter (straight connection), if you would use Arduino in the normal way you would have to make cross connections.


To talk to the XBee module I first tried Putty and Digi’s X-CTU software, afterwards I wrote my own Java software to send commands and receive data through a console application. So far everything seems to be going great, let’s hope we can keep on going like this.

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:

r-pi to xbee connection


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!

Ambient Assisted Living 4 All


It is no secret to you that the group of people at the age of at least 65 is continuously growing. We live longer, but this also has its impact on assisted living and retirement homes: people never required so much help from nurses and other educated people to support them in their live. The Ambient Assisted Living for All project I’ll be working on is an IT system which aim is to support people who can still live more or less on their own but require additional help for some of their daily tasks. My exact objective is to set up a gateway device which collects data from remote sensors. Once the data is collected it can be interpreted and/or be send to remote servers and services in the local LAN and internet. The data which could be collected by the gateway could be for example is simple as monitoring the pressence of someone through a radar detector or monitoring the health of a person through his heartbeat. As gateway device I’ll be using a Raspberry-Pi computer, communication between the Pi and the difference sensors will be done via the ZigBee protocol (wireless radio frequency) and XBee modules. Depending on how fast I get through this project I can try to implement different types of sensors and for example make a  web interface around all the attached sensors (display the data).

Aside of that, assisted living is actually a lot more than just monitoring some stuff:

It can not only help elderly people but also people with disabilities like those who are for example in a wheelchair, or in general people who just need some extra help living on their own. AAL can help them not to forget taking their medicine, it can monitor the lifestyle and health but it can also add make sure the people feel less isolated by offering social services and entertainment. The AAL4ALL system is also aiming to connect the AAL4ALL gateway to remote medical services and patient files in order to automate and aid when medical assistance should be provided.

The picture below shows how, not AAL4ALL precisely, but IT in general can help in the daily tasks of people:

However, my main task will be to set up the sensor gateway and to set up the ZigBee communication. Later you learn more on how I did this and how this is done precisely.