And so, we now have our own homemade strawberry jam in Bragas house. It took me a while because finding one of the ingredientes, pictine, was quite hard and so I ended up extracting the pectine from apples. This ‘morning’ the first samples have been approved by the Austrians, so Bragas people, if you need jam it’s in the left fridge, inside the door, 2nd or 3rd floor, next to the lemon. Bon appetit!
After ‘Ai se te pego’, this is probable the next Brazilian canção that’s going to be a big hit in Europe. In fact, in Porto it already is. Learn the moves 😉
Munhoz & Mariano – Camaro Amarelo
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.
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.
‘La canzone del sole’… yesterday another bunch of Italians arrived at Bragas house (or Bragas as we call it) and it seems that aside of studying Architectura (most Italians I met so far do so, for real!) they’re also quit found on sitting together with the whole group and singing classic Italian songs. Okay, I don’t want to start any clichés here but it is mostly the Italians that ‘tocam na guitarra’, or play on the guitar as you would say in English. But I like it, they’re nice people and I’m learning some Italian too! The following song is one that always seem to come back though, I’ve never heard it before and probable neither do you (if you’re not from Italy at least), but take a few minutes and try to image how it would sound like with 10 people and one guitar player. La Canzone Del Sole by Lucio Battisti:
Oh, and by the way: Berc’hed, happy birthday! beijinhos!
The weather in Porto can be really shitty sometimes, and until now we may have gotten as much rain as we had sunny days. But then again, summer is coming so it will only get better from here on. I’m looking forward for the Brazilian BBQ’s!! Us in the garden for the whole day, nice food and good drink, perfect! Speaking of the garden, even now it can get pretty hot here, it’s March and we’re already sunbathing!!!
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.