Today I will write about a small chat client which I had made using Xbees. It is a peer-to-peer based chat system. Here I describe using only two nodes, but later in the post, I shall explain on how to develop chat system with more than 2 nodes.
Firstly for a simple 2 node chat system, we need one co-ordinator node and one end/sensor node. Any wireless sensor network is not functional without a co-ordinator node. So we configure the XBee using XCTU.
Let us connect one Xbee to one laptop and another to a different laptop. Once you “Test/Query” after connecting the Xbee, ie
you can now move on to the “Modem Configuration” tab and select proper Xbee Model and Function Set. After selecting the right settings, click on “Read”. During this, the XCTU will read all the previously stored information from the Xbee and apart from the system settings, other details can be easily edited simply by double clicking it! ( There is another way of editing the settings using commands from the Terminal , but this is lot easier!) . This process till now is same for both the Xbees.
You need to make sure that both the Xbees are on the same channel and have the same PAN ID. It is utmost important. Xbees on different channels do not communicate with each other. Channels and PAN IDs are helpful when there are many clusters of sensors spread across. Now each Xbee has a pre defined Source Address High and Low. It cannot be changed. Copy the source high address of the co-ordinator to the destination high address of the sensor/end node. Similarly copy the source low address of co-ordinator to destination low address of the sensor/end node. Once done, this establishes communication from Sensor node to the Co-ordinator node. Now copying the sensor node source low and high to the co-ordinator node destination low and high shall enable two-way communication.
The above way is known as direct addressing way. Sometimes, when the nodes to be accessed locally, we use a different addressing method. There is a provision to define a 16 bit Source address for every Xbee. We can give any suitable 16 bit number as the Source address to a Xbee. Giving different 16 bit source addresses to Xbee will enable us to address them locally. Say the 16-bit source address for Co-ordinator is 0001 and for the Sensor node is 0002. Now we can put the destination low of the Co-ordinator as 0002 and destination low of the sensor node as 0001 to set up a two-way communication. This simplifies methods where every Xbee has to be numbered, say in a cluster, spread over a vast area. This indirect mode of addressing is popular.
Now once the addresses issue is resolved, we now need to make sure that the co-ordinator node is the real Co-ordinator. There is a provision for that. We define Co-ordinator enable as 1 to make sure that the Node is a co-ordinator. Note that successful communication in a Sensor network is possible only when there is one and only one sensor Co-ordinator. Let the Co-ordinator enable be 0 in the Sensor node. You can leave the remaining settings as default. Do not forget to “Write” these settings on the Xbee. Once these settings are saved, you are good to go!
Now let’s get to chat part!
Switch to the terminal part, and you can do this!
The red ones show that it is received from the other node, while the blue ones show what is being typed.
Communicate all the way!
Now as mentioned earlier, we can also have a chat system with more than 2 nodes. When there is say more than one node, we can all have them communicate to one particular node. Say we have four nodes with addresses 1,2,3,4. Now the destination address of all the nodes can be 1 ( say the co-ordinator node ). In this way, whatever message is being relayed on any of the nodes, it is transferred to the co-ordinator node. It is a star based topology.
Now while chatting, there is an option to assemble packets. Individual packets can be assembled and sent across. The packet assembling is important in cases when you either want to send all the data together or you want to use remote AT Commands as follows:
Sending remote AT commands is as good as retrieving all the info from the node remotely. More on using remote AT commands can be read in Rob Faludi’s book on Wireless Sensor Networks, whose link is in here.