The UART stands for Universal Asynchronous Receive/Transmit. UART is used in reference to the standard protocols like RS 232, Rs 422 or RS 485. The most common RS-232 protocol has been defined to operate at a high voltage level relative to the supply to the controller. This was in conjunction to the industry requirements so that it is immune to noise. Hence it needs a separate driver circuitry which translates the low voltage output of the UART of the controller to a recognized level for RS-232 communications.
Wireless ZigBee Protocol :
For the wireless communication, we used the Zigbee Protocol. This protocol is used with low power wireless radio in communication systems which require low data rate, high battery life and secure networking. The Xbee module manufactured by Digikey implements this protocol. We have been using the Xbee modules which are directly compatible with the Arduino boards and work on a standard UART interface. Hence communication with the PC at the receiving end is also very straightforward. Also sending data from the controller is also as simple as putting data on the UART transmitter line of the controller. The module takes care of the implementation of the protocol and transmits the data. All the modules having the same Personal Area Network ID can form a mesh network. Hence the user does not need to actually care about connecting several nodes to a master node. This is the biggest advantage of using this module.
The Zibgee protocol is somewhat new in the communication Arena, compared to the RS 232. This protocol was designed for digital radios which worked at low power and low data rates that can be used for Wireless Personal Area Networks (WPAN). It has a data rate of 250 kbps, probably sufficient for sensors designed for intermittent data transmission. The operating frequency is 915 MHz in the US. The implementation of this protocol is cheaper than some of its counterparts for WPAN like Bluetooth. The advantage of using Zigbee is that it can automatically create an ad-hoc network amongst the nodes. Hence the user does not have to worry about setting up a network; just setting the correct parameters in the module is all that it takes for the node discovery and network formation. The typical protocol frames for some modes we have used/tested are discussed in the appendix.
The Zigbee modules work in different modes. API mode is one of them. This mode sets the module to accept and put out data on the UART in a predefined frame which is basically defined by the protocol. This gives more encapsulation to the actual data and is really useful in setting up a mesh network wherein we have to deal with data from multiple nodes. The details of this protocol are defined in the appendix. The drawback to this protocol is that the decoding of data becomes complex at the receiving end. But the advantage is that each frame has a payload which consists of information on the senders address, number of data bytes in the frame and checksum for error checks. Hence there is a tradeoff between the complexity of the design and the features offered by the design.
The transparent version, as the name suggests is more of a user friendly form of communications. In this mode, it just puts out the data it received from another node on to the UART. Vice versa, it accepts the data from the serial terminal without having to form any framing operations manually. This makes the decoding tasks at the receiver really simple and straightforward. Nevertheless in this mode, the Zigbees’ communicate within them using the appropriate protocol, just that now its hidden from the user. The drawback here is that the module truncates all the frame information which is provided in the API mode, and instead just puts out the actual data transmitted on the serial. This reduces the complexity but hides the sender information from us. Hence to implement a mesh network, we may need to send out the address of the sending node before transmitting the actual data.
We tried using both the API and the transparent (AT) mode. This project is a research project which needs to be followed up for a few semesters. We had to keep in mind the changes which will be made to the system over the coming semesters by different students. Hence using the transparent mode will help them make these changes a bit smoothly compared to the API mode. So we propose using the AT mode keeping in mind the future developments necessary in the system.