Cellsius: Wireless Laboratory Monitoring System Austin Barlis SID: 200459705 Submitted in accordance with the requirements for the degree of Master of Engineering in Electronic Engineering Supervisor: Prof. Christoph Walti Assessor: Dr. Dragan Indjin The University of Leeds School of Electronic and Electrical Engineering May 2013
78
Embed
Cellsius: Wireless Laboratory Monitoring System · interface are the Itron Smart TFT module and 4D-Systems uLCD43 TFT module. The Itron Smart TFT module comes in 3.5”, 4.3”, 5.7”
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Cellsius: Wireless Laboratory Monitoring System
Austin Barlis
SID: 200459705
Submitted in accordance with the requirements for the degree of
Master of Engineering
in Electronic Engineering
Supervisor: Prof. Christoph Walti
Assessor: Dr. Dragan Indjin
The University of Leeds
School of Electronic and Electrical Engineering
May 2013
- ii -
Declaration of Academic Integrity
The candidate confirms that the work submitted is his/her own, except where work which
has formed part of jointly-authored publications has been included. The contribution of the
candidate and the other authors to this work has been explicitly indicated in the report. The
candidate confirms that appropriate credit has been given within the report where reference
has been made to the work of others.
This copy has been supplied on the understanding that no quotation from the report may be
published without proper acknowledgement. The candidate, however, confirms his/her
consent to the University of Leeds copying and distributing all or part of this work in any
forms and using third parties, who might be outside the University, to monitor breaches of
regulations, to verify whether this work contains plagiarised material, and for quality
assurance purposes.
The candidate confirms that the details of any mitigating circumstances have been submitted
to the Student Support Office at the School of Electronic and Electrical Engineering, at the
University of Leeds.
Austin Barlis
01/05/2013
- iii -
Acknowledgements
I am truly indebted and thankful to my supervisor Prof. Walti for his hands-on support
throughout the course of this project. His constructive suggestions and knowledge have
helped me reach the project’s objectives. In addition to that, his willingness to give his time
so generously has been very much appreciated. I would also like to thank the following
Noritake-Itron Engineers, namely Andrew Goodings, Mike Keeble, Mark Wyer for their
guidance with the TFT module debugging. I would also like to thank the electronics
workshop technician Punitha and family friend Joseph Siron for their guidance on PCB
soldering.
Finally, my sincere gratitude also goes to my family and my girlfriend for their continuous
love and support through this stressful time.
- iv -
Abstract
A sensor system for the Bioelectronics lab at the University of Leeds was required. The
system should be capable of monitoring fridges, freezers and ambient sensor values. Users
should be notified remotely when attention to a sensor station is needed. Various interfaces
were analysed and selected to provide communication for intra/inter stations. Both iDev and
C programming languages were used to create the firmware and software for the different
components. A generic system was created containing one substation connected to a
sensor and a base station with a temperature and humidity sensor. The substation was
connected to the base station wirelessly.
- v -
Table of Contents
Declaration of Academic Integrity ....................................................................... ii
Acknowledgements ............................................................................................. iii
Abstract ................................................................................................................ iv
Table of Contents .................................................................................................. v
List of Abbreviations ......................................................................................... viii
I2C Inter-Integrated Circuit communication protocol
AS Asynchronous Serial communication protocol
SMS Short Message Service
ICSP In-Circuit Serial Programming
RSSI Received Signal Strength Indication
1
Introduction
The motivation of this project is to provide a sensor monitoring system for the Bioelectronics
laboratory in the School of Electronic and Electrical Engineering at University of Leeds.
There are highly valuable components inside the laboratory freezers that must be preserved
within a consistent temperature. It is paramount that those components are constantly
monitored. Since these freezers are sometimes left unattended, this monitoring system is the
instrument to ensure that the temperature in laboratory freezers stay within the ‘acceptable’
temperature range. The Itron Smart TFT module was used to provide user interface,
together with the Arduino platform to control the sensors and use Zigbee. The system was
designed using a ‘generic’ temperature and humidity sensor but user-defined sensor support
was added to allow the user to connect their own type of sensor. A total of 12 sensors can
be connected to the system. The system created is capable of notifying the users via SMS.
For example, if the freezer temperature has exceeded the threshold specified, users are
alerted by sending SMS messages. System substations communicate with the base station
via Zigbee protocol. This wireless communication made it easier to deploy substations to the
system.
This report covers the development of the base station and substation. Also the user
interface’s main features are discussed.
2
Chapter 1 System Overview
1.1 Final system architecture
The project’s aims and objectives were constantly refined throughout the project. For a
detailed discussion about the alterations made to the monitoring system see Appendix A.1.
Figure 1 Block diagram to show the final system created in the project
The diagram above show the final system which comprises one substation with one sensor
connected and the base station with a combined humidity and temperature sensor
connected to it (See 2.3). The base station and substation configurations can be modified
depending on the users purpose i.e. the number of sensors connected to the stations can be
altered. Note that the TFT module, GSM module, wireless module and microcontroller setup
in both stations is fixed and cannot be changed. Another block diagram shows how the
system with another user specified configuration is implemented in practice.
3
Legend
** - serial communication medium is not specified
Figure 2 Block diagram displaying a theoretical user-specified configuration of the system in practice
4
Chapter 2 Hardware Identification/Selection
Thorough research was executed to determine the appropriate modules and platforms
required for the project. For each part, an analytical approach was taken. The requirements
for each part were defined and matched with the options. The components analysed were
narrowed down to two for each part.
2.1 Microcontroller
The microcontroller for the system has to fit the specified requirements below:
Has a compatible interface that allows communication with other wireless modules,
microcontrollers and/or display module
Has digital input and output pins which are compatible with available temperature
and humidity sensors
Operates ideally at 5V with relatively low power requirement so it is possible to be
powered from a battery
Programmable through USB for easier development
Software can be developed in familiar language
The two alternatives chosen that are deemed capable of meeting the requirements set are
PIC and Arduino platforms. Both platforms have been used previously by myself, thus
providing an advantage when using them in practice. The most important advantage of the
PIC platform is its wide range of products. This can be utilised to create the most cost-
effective system and create a design that is specific for the system. Another benefit of this
platform is its debugging method; this platform have been designed to perform debugging
quicker and more efficient. The Arduino platform’s biggest strength is its wide community
support. This can be beneficial for projects that involve general sensor controls since
libraries will be readily available. Although Arduino boards have a limited variety, it is
possible to create custom-made shields to fit the desired project requirements. This platform
has boards that are already pre-made, significantly reducing design and implementation
time. Both platforms chosen have their strengths, but the Arduino platform outweigh the
PIC’s advantages for the purpose of the microcontroller in this project. Therefore, the
Arduino platform is chosen for this project. An Arduino Mega is selected to be used in the
5
base station because it has 4 asynchronous interfaces. Whilst for the substation an Arduino
Uno would suffice.
2.2 User interface provision
The user interface for the system should achieve the following requirements:
Approximately 3” to 6” colour display
Have a compatible communication interface with the microcontroller and GSM
module chosen
Touch screen capability with relatively good touch sensitivity
Operates ideally at 5V with relatively low power requirement
Software can be developed in familiar language
After researching for possible candidates, the two main alternatives chosen to provide user
interface are the Itron Smart TFT module and 4D-Systems uLCD43 TFT module. The Itron
Smart TFT module comes in 3.5”, 4.3”, 5.7” and 7.0”. Both use the same ARM processor
and offer various interfaces. The 3.5” module would be too small for the monitoring system
as it would restrict the user-friendliness of the interface. The 5.7” and the 7.0” however,
would be too big for the purpose of the monitoring system. The optimum size for the TFT
module to be used is 4.3”. All the module sizes have got the appropriate interfaces required
to provide communication between the TFT module and the microcontroller and GSM
module. Having a 4.3” TFT module allows the enclosure of the base station to be compact
and mobile which is ideal for the monitoring system. The 4D-Systems uLCD43 TFT module
comes in 4.3” size as well. It has the correct communication interface and it suits all the
requirements stated above. The advantage of the Itron Smart TFT module over the other
alternative is its varied communication interfaces. The Itron Smart TFT module offers
RS232, RS485, SPI, I2C (Slave mode) interfaces but the other one does not. In terms of
providing communication versatility and expandability to control other devices running on the
stated interfaces, the Itron Smart TFT module is definitely better than the alternative.
Another factor that makes the Itron module a better choice is the programming language
used as it is a highly familiar language.
6
2.3 Temperature and humidity sensor
Providing temperature and humidity measurements is critical requirement for the system. It
is also important to bear in mind that the sensors chosen are meant to be ‘generic’ and
therefore suitable for most applications. The temperature and humidity sensor for the system
should have the following features:
Capable of measuring temperature with the range -55°C to +125°C with ±1°C
accuracy
Capable of measuring humidity with the range 0 % to 100 % with ±1% accuracy
Operate ideally at 5V with relatively low power requirement
Controllable with the microcontroller chosen
Small size for easier PCB and enclosure integration
The temperature sensors chosen for the system are Dallas DS18B20 and Dallas DS18S20.
The sensors are controlled via 1-Wire interface which can be controlled by any
microcontroller with a digital IO port. Both sensors contain the features required for the
temperature module. The DS18B20 sensor resolution can be specified when used whereas
the DS18S20 sensor has a fixed resolution. Thus, it is possible to reduce the resolution to 9-
bits if needed for the first sensor mentioned. According to the manufacturer’s website, the
DS18B20 sensor offers much more flexibility and is easier to use than the DS18S20 sensor
[1]. Therefore, the Dallas DS18B20 temperature sensor is chosen as the ‘generic’
temperature sensor for the system.
For the humidity measurement, the only suitable sensor identified is the DHT22 module. This
module has the features specified in the list above for the ‘generic’ humidity sensor. Also it
has the capability of measuring temperature simultaneously. Extracting measurement data
from the sensor is straightforward which makes this an ideal ‘generic’ sensor to provide
humidity sensor for the system.
2.4 Wireless communication
The wireless technology to communicate between the base station and substations should
meet the following criteria:
The operating range should be approximately 100 m
Operates ideally at 3.3V or 5V with relatively low power requirement so it can be
powered from a battery
7
Expandability and substation deployment should be possible with minimal signal
issues
Contains a communication interface that is compatible with the microcontroller
Reasonably low device and application complexity
There are various wireless protocols available that can be used for the system but the two
that were chosen that fit most of the requirements are ZigBee and 802.11 Wi-Fi
communication standards. Both modules can operate at approximately 100 m and can be
configured to reach a longer range e.g. mesh topology. Zigbee modules are typically used in
the industry for sensory applications, making it ideal for the system. The Zigbee protocol is
one of the wireless protocols existing with extreme low power consumption. This is a great
advantage for systems that uses batteries as a power source. Another significant benefit of
this protocol is its mesh capability, allowing expandability to be implemented. The only
drawback with this protocol is its limited data rate which caps at 250 Kbits/s compared to the
Wi-Fi protocol with extremely high data rate (up to 54 Mbit/s) [2]. This protocol is used and
highly prevalent around the vicinity where this system will be used. Therefore, there would
be no signal issues. This ensures that the connection between the main station and the
substation would be stable for most of the time. However, the protocol’s major disadvantage
is its high power consumption. Making it problematic for substations that are battery
powered. It is evident that Zigbee technology is a better contender to provide wireless
communication in this system. Although the data rate isn’t high, this protocol is still suitable
since the data size being passed on wirelessly are relatively low. The Zigbee module
purchased for the system is the Maxstream Series 2 1mW Xbee fitted with wire antenna.
2.5 GSM module
The GSM capability of this module is vital in making the sensor system effective. It acts as a
medium to notify the users remotely through SMS messaging. The criteria set for the GSM
module are the following:
Operates ideally at 3.3V or 5V
Has a communication interface that is compatible with the microcontroller or TFT
module
Small size
Compatible to run GSM 900/1800 MHz frequency bands (UK bands)
Reasonably low device and application complexity
The two modules selected are SPREADTRUM SM5100B and SIMCOM SIM900. Both
modules satisfy the criteria set above. The SIMCOM module is cheaper compared to the
8
SPREADTRUM module. By analysing the online forum posts and other people’s experience
on both modules, it seems that the SM5100B module is more reliable. A lot of people seem
to have trouble in setting up the SIMCOM SIM900 GSM module. Also since the SM5100B
module is more ubiquitous than the other alternative, there are detailed guides found on the
internet that can aid when it is integrated in the system.
9
Chapter 3 Base Station and Substation Configuration
3.1 Base station communication development
As evident in the final system overview (See 1.3) the base station comprises the TFT
module (Itron TFT module) and the microcontroller (Arduino Mega). It is paramount for the
base station to have reliable and stable communication. During the development stages, the
common interfaces between the touchscreen module and the Arduino were tested and
analysed. Both modules contain SPI, I2C and asynchronous interfaces but the Arduino’s
logic levels are set at 5V whereas the TFT module is at 3.3V. This means that a bi-
directional logic level shifter has to be incorporated to compensate for the difference in logic
levels. An external logic level shifter manufactured by Adafruit (4 channel I2C-safe Bi-
directional Logic Level Converter-BSS138) was used during development stages. Although
the part number states I2C explicitly, the external logic level shifter used is compatible with
the other interfaces. The TFT module that was used for the final system had a company-
fitted logic level shifter that lets the I2C, SPI and AS1 (1st asynchronous interface) to operate
at 5V logic levels.
3.1.1 I2C interface
The I2C interface was tested first. Data can be sent from either modules but it can only be
done in one configuration. Due to incompatibility issues and logic level difference, only the
master device can send data that can be correctly interpreted by the slave device. In other
words, two-way communication is not possible without any modification. In order to enable
bi-directional communication between the two modules a pseudo-multi master protocol was
created. Since both modules have digital input/output ports and the I2C protocol lets the user
change the operation mode dynamically, these properties were utilised to implement this.
Two pins were used in each module, one set as an input to detect which module should be
the master device and the other as an output to tell the other module that the current module
should be the master device. The setup created is shown in the flow chart from two
perspectives.
10
Figure 3 Flowchart showing processes for pseudo-multi master mode from the Arduino side
During the development stages the Arduino was set to be the default Slave I2C device when both modules are turned on. The TFT Master Active input is constantly monitored to avoid bus contention.
Figure 4 Flowchart showing processes for pseudo-multi master mode from the TFT module side
Similar processes occur on the TFT module’s perspective. The TFT module is the default master device (TFT Master Active output is set HIGH at power on). The Arduino Master Active input is constantly checked to determine whether the bus is ‘busy’ and therefore the TFT module should stay as a slave device and vice-versa.
11
3.1.1.1 Testing and conclusion (I2C)
A series of tests were made to determine if the setup is robust enough to be used for the
communication between the Arduino Mega and the TFT module. In all the tests made, the
TFT module was the default master I2C device with the baud rate set at 9600 bit/s and the
termination character 128. The first test was to send a string to the Arduino slave device and
it was sent successfully. Then a function was added to set the Arduino Mega as the master
device and send a reply back to the TFT module when a command from the TFT module
was received. To emulate how this protocol will be used, a basic TFT module program was
created which allows the user to send commands from a touch of a button. When the button
from the TFT was pressed, the reply command was received successfully. However, there
was noticeable latency when the reply command was accepted. This latency was caused by
the delays added after the Arduino/TFT Master Active output’s state was changed. These
delays are needed to ensure that the change of state has been detected correctly before
changing the I2C operation mode. Although correct strings are received, this configuration is
deemed cumbersome and therefore would not be suitable for the system due to the latency
and reliability issues. For those reasons, the pseudo-multi master mode created here was
not used.
3.1.2 Asynchronous interface
The TFT module and the Arduino module both have asynchronous interfaces. In the
development process, a logic level shifter (See 3.1) was used to compensate for the logic
level differences. A similar issue to the I2C protocol was observed using this interface. Data
can only be interpreted correctly in one direction. This may be due to incompatibility issues
and bus contention. Since the asynchronous interface does not support slave/master
operation mode then the configuration created for the I2C cannot be used. Both the TFT
module and the Arduino have multiple asynchronous interface pins and they can be used
simultaneously. This can be utilised to provide two way communication. Each interface
would be dedicated to either receiving or sending data.
3.1.2.1 Testing and conclusion (AS)
Two way communication is an important property that the interface should have if it will be
used in the base station. Using the asynchronous interface would require two separate ones
used for each module which would unnecessarily waste resources. Although data is
received and sent correctly, dedicating two asynchronous interfaces would not be ideal. The
other asynchronous interface on the TFT module was used to communicate with the GSM
module which further disapproves the suggested configuration.
12
3.1.3 Final interface protocol
A compromise between the two interface protocols analysed were used in the final system.
The I2C interface was used to enable communication from the Arduino to the TFT module.
On the contrary, the communication medium used to allow data to be sent from the TFT
module to the Arduino is the asynchronous interface. The asynchronous interface has higher
data transmission rate compared to that of the I2C interface. The length of data sent from
the TFT module is significantly longer compare to the string from the Arduino module. For
this reason, the configuration described was chosen. A major advantage of this setup is that
there will be no bus contention that can occur since an interface is dedicated to send data
one way. Thus, the data sent is guaranteed to arrive at its destination. Another benefit of this
setup is that it minimises the latency on the data’s arrival rate. These properties aid in
improving the robustness of the communication between the two modules in the base
station. The only drawback of this arrangement is that two separate interfaces were used
rather than a single one but it can also be argued that if the resources are available, then it
might as well be utilised properly.
The TFT module has another asynchronous interface that was used to communicate with
the GSM module. There are no issues experienced with that setup, hence it was used in the
final design. The wireless module (Zigbee) is connected to the Arduino module via
asynchronous interface. The Zigbee module’s logic level is 3.3V so during development
stages an external logic level shifter was used. But in the final PCB design this logic level
shifter was integrated into the base station PCB.
3.2 Intra-base station communication
It is paramount that a stable protocol is established that will easily consolidate the data being
transmitted in the base station. There are two types of communication protocol created.
Each one is tested and analysed thoroughly to determine which method is more suitable.
The analysis is found in Appendix A.2. The following criteria are set to help choose the
correct protocol:
The possibility of data corruption and/or incomprehension should be miniscule
The length of data being transmitted back and forth should be moderately short
The data rate to implement the protocol should agree with the capability of the
proposed interface protocol used
The first criteria is the most important out of the three. Correct data interpretation is
paramount for a monitoring system. If data corruption occurs, major complications can
13
propagate throughout the sensor stations. Thus, inaccurate parameter calculations and
incorrect notifications would probably be carried out.
3.2.1 Final communication protocol
Both protocols concur the criteria set (See 3.2) to some extent. A modification is needed to
fulfil the criteria fully. A ‘hybrid’ approach was used which employs a mixture of both setups
proposed. The data type for all the transactions between the modules is the standard 8-bit
ASCII. There are two sets of parameters on how data is handled in this setup. From the
Arduino module’s perspective there are parameters that are needed to determine correctly
which substation and sensor data is required.
Table 1 Table describing parameters that the Arduino requires from the TFT module
Parameter Example
usage Definition Acceptable/Valid Values
Sensor
number 2
parameter to specify the target
sensor station number 1 to 12
Type h
type of sensor in the target
sensor station, leave blank if
disabled or turned off
x or ‘blank’, t(temperature),
h(humidity), e(temp &
humidty), b(battery), o(other)
Local Pin
number 5
specify which pin number the
sensor is connected to
base station: 0 to 53(for
Arduino mega),substation: 0
to 13 (for Arduino uno)
Xbee
Address
MSB
0013A200
state the 32-bit HIGH Xbee
Address in hexadecimal, leave
blank if connected to base
station
00000000 to FFFFFFFF or
‘blank’
Xbee
Address
LSB
4079BD35
state the 32-bit LOW Xbee
Address in hexadecimal, leave
blank if connected to base
station
00000000 to FFFFFFFF or
‘blank’
Instruction
type a
specify whether the action type is
an acquire (a) or reply (r) a or r
14
An example instruction command syntax sent from the TFT to the Arduino is found below.
2:h:5:0013A200:4079BD35:a(termination character)
This received string is interpreted appropriately in the Arduino module. The string is parsed
and the necessary parameters are placed in appropriate variables (See Appendix B.2 for
details). Some parameters have to be converted to a long data type using strtol. The Xbee
Address field is used to determine which substation the sensor station is connected to. The
instruction type a(acquire) notifies the substation to start collecting relevant data so that
when the action type r(reply) is sent the sensor data is ready to be sent back to the TFT
module. Therefore the value for the sensor station concerned is updated correctly. The rest
of the parameters are self-explanatory. Unlike the parameters from the Arduino’s point of
view, the parameters from the TFT module’s viewpoint is much simpler with only three. The
TFT module only requires the sensor station number, type of sensor and sensor value data.
The reply syntax sent from the Arduino to the TFT is:
2h:66(termination character)
The response example from above would be interpreted as humidity sensor data with
current value of 66%, read from sensor station 2. On the TFT module’s side, the built-in
SPLIT function was used to separate the string. Then a function is created to update the
necessary entities for the specified sensor station. The sensor data is extracted using the
BCOPY function where 2 bytes after the ‘:’ are copied and placed into an suitable variable.
The sensor value is stored in an integer variable which is 2 bytes long. Overall, this
structured ‘hybrid’ protocol fits the criteria to provide a robust communication protocol in the
base station.
3.3 Substation and sensor integration
This system is designed in such a way that multiple substation can have multiple sensors
connected to them. The base station is meant to communicate with the substations
wirelessly on a regular basis. A communication protocol similar to the intra-base one is
created for the base station and substation. The ‘generic’ temperature sensor chosen (See
2.3) requires a unique address to work but the humidity sensor does not. A procedure was
created to simplify how these sensors are added.
3.3.1 Base station and substation communication protocol
Data sent over Zigbee is parsed per byte, so adding a separator is not necessary. Instead,
the data can be allocated dynamically whilst its being processed. Also a termination
character is not required in a Zigbee API mode data transaction. The parameters required
15
from the substation’s perspective only consist of 3, namely sensor station number, type of
sensor and sensor pin location. So only three bytes would be received from the base station
e.g. 2h10. For the base station’s (Arduino Mega) viewpoint, 3 parameters are also needed.
The parameters are identical to the TFT module’s perspective (See 3.2.3) which are the
sensor station number, type of sensor and sensor value data. Essentially the same string is
‘passed’ on from the Arduino Mega at the base station to the TFT module. The reply from
the substation to the base station would look like this, 2h66. The only difference is the
absence of the separator ‘:’. When the Arduino at the base station received this string, it is
processed to add a separator in: 2h:66(termination character). Since the sensor station is
unique on its own, this configuration removes the need to identify the sensor data’s origin.
3.3.2 Temperature and humidity sensor detection
The ‘generic’ temperature sensor chosen is the DS18B20 (See 2.3). In addition to the pin
location, this sensor also requires the 64-bit ID (unique address) before it can be used. This
address requirement allows the capability to connect multiple DS18B20 sensors on one
digital pin. However, a disadvantage of this is the need to identify the address prior to use. A
plug and play capability would be ideal in this system. The sensor’s address can be
identified by using the manufacturer’s library for the 1-wire sensor. The system is designed
with the assumption that one sensor will be connected to one digital IO pin. By following this
assumption, the Arduino sketch is modified so that it identifies the temperature sensor’s
unique address dynamically. Note that this plug and play capability would only be applicable
to temperature sensors made by Dallas such as DS18B20 or DS18S20, both of which use
the 1-wire bus system. If a temperature sensor is required then from the substation’s point of
view the proposed base station and substation protocol would suffice with this modification.
In contrast, the humidity sensor selected is the DHT22 module. The DHT22 does not support
multiple identical sensors to be connected in a single pin. This means that there’s no
addressing system require for operation. So there is no software alteration necessary to
accommodate the humidity sensor’s compatibility with the communication protocol.
3.4 GSM module incorporation
The GSM module is added to the system using the second asynchronous interface (AS2) on
the TFT module. The GSM module and AS2 both operate at 3.3 V logic levels which means
that there is no need for a logic level shifter. There were no issues experienced when the
GSM was integrated to the system. For more details about GSM incorporation See A.3.
16
3.5 Zigbee protocol integration
Wireless communication plays an important role in the system, it provides a ‘link’ between
the main station and the substations. The wireless protocol selected is Zigbee and the
module is Maxstream Series 2 Xbee. (See 2.4). This protocol operates in AT (Transparent)
or API (Application Programming Interface) mode. An external Xbee adapter board was
used to identify and apply different characteristics of the Xbee module. The software used to
manipulate these characteristics is X-CTU. The 64-bit unique addresses of the Xbee
modules were identified using X-CTU. The necessary settings to operate in AT mode were
applied.
Table 2 Parameters applied to Xbee modules to operate in AT mode
Parameter Base station Xbee Substation Xbee
Firmware uploaded Znet 2.5 Coordinator AT Znet 2.5 Router/End Device AT
Destination Serial Address
HIGH (HEX) 0013A200 4079BD34
Destination Serial Address
LOW (HEX) 0013A200 4079BD35
In AT mode, the connection between the base station and substation is almost identical to
asynchronous interface. A basic equivalent Xbee.print(<data here>); line of code would
suffice to send data wirelessly. This ingenuous setup and implementation is AT mode’s main
advantage. However, this mode is only optimised for point-to-point data packet transfer.
Consequently, the system requires point-to-multipoint communication (base station to
multiple substations) so AT mode would not be ideal. To realise packet transfer between
base station and multiple substations then manual AT commands have to be used to specify
the packet destination address per data transaction. This can be cumbersome and could end
up producing latency than can propagate throughout the system. Whereas API mode
permits implementation of point-to-multipoint network communication. API mode requires
one coordinator and one or more router/end device as well, but more parameters have to be
set. The extra parameters are required to allow the destination address to be assigned
dynamically.
17
Table 3 Parameters applied to Xbee modules to operate in AT mode
Parameter Base station Xbee Substation Xbee
Firmware uploaded Znet 2.5 Coordinator API Znet 2.5 Router/End Device API
NI (Node Identifier) COORD BASE1
PAN ID (Personal Area
Network) 128 128
OPERATING CHANNEL 12 12
AP (API mode) 2 2
Data packet transaction in API mode is not as simple as Xbee.print(<data here>); statement
anymore. The Xbee.h library created by Andrew Rapp was used to employ and realise Xbee
API mode in Arduino. Sending and receiving data would require different paths to the Zigbee
API mode layers. The Xbee library [3] used involves the following method to transmit data.
1. Store the data in an array of uint8_t
2. Create the Xbee object - Xbee xbeeobj = Xbee();
3. Specify the destination address using the XbeeAddress64 class
4. Initialise the Xbee object and assign to applicable serial pin (asynchronous interface)
5. Use the ZbTxRequest class to define the combine the destination address and the