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”

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

Introduction ........................................................................................................... 1

Chapter 1 System Overview ................................................................................. 2

1.1 Final system architecture ....................................................................... 2

Chapter 2 Hardware Identification/Selection ....................................................... 4

2.1 Microcontroller .......................................................................................... 4

2.2 User interface provision ............................................................................ 5

2.3 Temperature and humidity sensor ............................................................ 6

2.4 Wireless communication ........................................................................... 6

2.5 GSM module ............................................................................................ 7

Chapter 3 Base Station and Substation Configuration ...................................... 9

3.1 Base station communication development ................................................ 9

3.1.1 I2C interface ................................................................................. 9

3.1.1.1 Testing and conclusion (I2C) ................................................... 11

3.1.2 Asynchronous interface .............................................................. 11

3.1.2.1 Testing and conclusion (AS) .................................................... 11

3.1.3 Final interface protocol ................................................................ 12

3.2 Intra-base station communication ........................................................... 12

3.2.1 Final communication protocol ..................................................... 13

3.3 Substation and sensor integration .......................................................... 14

3.3.1 Base station and substation communication protocol .................. 14

3.3.2 Temperature and humidity sensor detection ............................... 15

3.4 GSM module incorporation ..................................................................... 15

3.5 Zigbee protocol integration ..................................................................... 16

3.6 System configuration .............................................................................. 18

- vi -

3.6.1 User-defined sensor station parameters ..................................... 18

3.6.2 Compatible sensor types............................................................. 19

3.6.3 Sensor station expansion procedure ........................................... 20

Chapter 4 User Interface ..................................................................................... 21

4.1 Homepage layout ................................................................................... 21

4.2 Summary page ....................................................................................... 23

4.3 Sensor station page ................................................................................ 24

4.4 Settings page ......................................................................................... 26

4.4.1 Sensor Setup .............................................................................. 27

4.4.2 Alarm settings ............................................................................. 29

4.4.3 Time and date page .................................................................... 30

4.4.4 Console and Lock settings .......................................................... 31

4.4.5 GSM settings .............................................................................. 33

4.4.6 Info page ..................................................................................... 39

4.4.7 Help page ................................................................................... 40

4.5 Miscellaneous pages/features ................................................................ 41

4.5.1 QWERTY keyboard .................................................................... 41

4.5.2 Number pad ................................................................................ 42

4.5.3 Dynamic LED notification ............................................................ 44

4.5.4 Real time clock feature ............................................................... 44

4.5.5 Current penalty indicator ............................................................. 45

4.5.6 EEPROM memory ...................................................................... 45

4.5.7 GSM control response ................................................................ 45

Chapter 5 System Algorithms ............................................................................ 46

5.1 Penalty calculation algorithm .................................................................. 46

Chapter 6 Software Implementation .................................................................. 48

6.1 Sensor notification procedure ................................................................. 48

6.2 Monitor system realisation ...................................................................... 49

Chapter 7 Hardware PCB Design ....................................................................... 55

7.1 Base station PCB ................................................................................... 55

7.1.1 Schematic ................................................................................... 56

7.1.2 Board layout................................................................................ 57

7.1.3 Testing and results...................................................................... 58

7.2 Substation PCB ...................................................................................... 58

7.2.1 Schematic ................................................................................... 59

- vii -

7.2.2 Board layout................................................................................ 60

7.2.3 Testing and results...................................................................... 60

Chapter 8 Further Work and Improvements ...................................................... 61

8.1 Event data logging .................................................................................. 61

8.2 Remote system control ........................................................................... 61

8.3 Sensor data graph .................................................................................. 61

8.4 Multiple user support .............................................................................. 61

8.5 Interactive tutorial ................................................................................... 61

Appendix A .......................................................................................................... 62

A.1 System Development ............................................................................. 62

A.1.1 Initial planning ............................................................................ 62

A.1.2 Changes made to initial plan ...................................................... 65

A.2 Intra-base communication development ................................................. 67

A.2.1 Using separators/delimiters for each sensor station data ............ 67

A.2.1 Using keywords for each command which triggering an action when

detected ...................................................................................... 67

A.3 GSM module integration and development ............................................ 68

Appendix B .......................................................................................................... 69

B.1 IDev user interface implementation ........................................................ 69

B.2 Arduino code implementation ................................................................. 69

References .......................................................................................................... 70

- viii -

List of Abbreviations

GSM Global System for Mobile applications

TFT Thin Film Transistor Liquid Crystal Display

IO Digital Input-Output port

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

data to be sent in a single register e.g.

ZBTxRequest zbsend = ZBTxRequest(address, data, sizeof(data);

6. Transmit data by using this statement – xbeeobj.sent(zbsend);

Data status response detection is supported in API mode. This can be added to the

transmitter’s sketch to detect if data has been received successfully by the recipient. On the

contrary, the following steps are carried out to process data arriving.

1. Create the Xbee object – Xbee xbeeobj = Xbee();

2. Declare Xbee response object – ZbRxResponse zbresp = ZbRxResponse();

3. Initialise the Xbee object and assign to applicable serial pin (asynchronous interface)

4. Use the readpacket() to declare that incoming packets are to be processed –

xbeeobj.readpacket();

5. Then the getResponse class is used to encode the data received –

if(xbeeob.getResponse().isAvailable()) { <do something with the data> }

The recipient’s code can be altered to distinguish the packet’s API ID. The API ID aids in

quickly identifying the type of data response received. There are many data response types

18

such as a modem status response (API ID = MODEM_STATUS_RESPONSE). To make

sure that the ‘actual’ data is being processed the response type to be selected is the Zigbee

Rx Response (API ID = ZB_RX_RESPONSE or 144 in raw bytes). This API ID identification

method was employed in the system. Note that the method used and specified here are

minimal, there are a number of other parameters and features that can be monitored in API

mode but the setup described delivers sufficient reliability.

Table 4 Advantage of Xbee API and AT mode [4]

API mode AT mode

Mesh and point to multipoint

topology capable

Acknowledgement and checksum

support

The source address of the packet

received can be determined

RSSI (signal strength) of the packet

received can be obtained

Optimised for point to point topology

only

Simple and easy to implement

Compatible to any microcontroller

that has asynchronous interface

3.6 System configuration

This part focuses on sensor station parameters that are required for full functionality/correct

initialisation and the procedure to add multiple sensor stations to the system.

3.6.1 User-defined sensor station parameters

Each sensor station needs a set of parameters to initialise and function properly. These

parameters are defined by the user on the TFT screen. When a sensor station is turned on

the parameters are set to their default values. Thus, if some parameters are left untouched

then the default values were assumed and used.

Table 5 Table defining all user-defined sensor station parameters

Parameter Default

Value Definition

Acceptable/Valid

Values

Target Sensor

Value 0

This user-defined parameter is always

compared with the current sensor value data -100 to 150

Sensor Value

Margin 1

This parameter is used to calculate the

‘acceptable range’ of sensor values 0 to 100

19

Monitor

Frequency 5

This factor determines how often (in minutes)

the current sensor data is collected and

updated on the display

1 to 999

Notification

Penalty 20

This parameter determines when the user/s

have to be notified if the current sensor data

has surpassed the ‘acceptable range’

0 to 100

Sensor Station

Type Disabled

This parameter identifies what type of sensor

is connected to the relevant sensor station

concerned

Temperature, Humidity,

Temperature and

Humidity, Temperature

and Humidity Off,

Battery, ‘Other’

Deployed

Wirelessly No

Defines if the sensor station is deployed

locally (base station, wired) or wirelessly

(substation)

Yes or No

Xbee MSB/LSB

Address ‘blank’

If the sensor is deployed wirelessly, the Xbee

addresses in hexadecimal have to be defined

here, otherwise leave it blank

00000000 to

FFFFFFFF for Xbee

Addresses or ‘blank’

Note that these parameters define the sensor station’s independent property. Therefore,

each sensor station can have its own unique set of parameters without affecting the others.

This feature is important for system expandability and allows deployment of diverse sensors.

3.6.2 Compatible sensor types

The system can accommodate 4 different types of sensors, namely temperature, humidity,

batter and ‘other’. The temperature and humidity sensor types can be enabled

simultaneously but the others can only be enabled in isolation. This is due to the humidity

sensor’s (DHT22 module, See 2.3) capability of gathering temperature and humidity values

at the same time.

20

Table 6 Definition of supported sensor types

Sensor Type Definition Supported operation Mode

Temperature

This sensor type should be applied when

the DS18B20 (See 2.3) temperature

sensor is connected

Isolated or Simultaneously with

Humidity sensor

Humidity

This sensor type should be applied when

the DHT22 (See 2.3) humidity sensor is

connected

Isolated or Simultaneously with

Temperature sensor

Battery

The battery sensor type, allows the user to

monitor the substation’s battery percentage

level

Isolated

‘Other’

If the user wants to use other types of

sensors then this type should be used;

note that this sensor type’s name can be

changed by the user

Isolated

In the final system prototype built, the sensor types used are temperature and humidity only.

The base station is connected to the DHT22 humidity sensor and the substation is

connected to the DS18B20 temperature sensor. On the TFT module, the base station’s

sensor type is defined as temperature and humidity whereas on the substation the sensor

type is defined as temperature only.

3.6.3 Sensor station expansion procedure

This system was designed to minimise the steps to add sensor stations. Up to 12 sensor

stations can be enabled simultaneously. On the user interface, there’s a page called

Summary page which displays condensed information about the relevant sensor station

parameters. On this page there is also a toggle button which allows the user to enable or

disable sensors. In essence, the user would only need to go to the summary page and

enable the sensor and then to the sensor station settings (See 4.4.1) and sensor station

(See 4.3) pages to specify other significant properties.

21

Chapter 4 User Interface

The User interface is the bridge between the user and the system. It is designed to be both

as efficient and aesthetically pleasing as possible to give a better user experience. The

images were all created on Adobe Photoshop CS5 and Adobe Illustrator CS5. Some of the

icons used however were taken from websites that source and offer copyright-free images.

4.1 Homepage layout

The majority of the time, the homepage is what the user interacts with. Since there are 12

sensor stations, it would be difficult to fit all the sensor parameters in the homepage. As a

compromise, the LED notification (See 4.5.3) was introduced. Thereby, removing the

necessity to display all the sensor parameters in the home page. A brief description on how

the summary page was implemented in iDev language can be found in Appendix A.2.1.

Figure 5 Screenshot of the Homepage with annotations

1 2

3 4 5

6 7

7

22

Table 7 Definition of the Homepage screen features/entities

Image

Legend Features/Entities Definition

1 Dynamic LED

indicator

The LED’s colour changes depending on the sensor

station’s status e.g. it will turn red and blink rapidly if

attention is required (See 4.5.3)

2 User-defined sensor

station name

This field can be changed by the user by tapping its

location on the screen, also the font colour/type changes

depending on the sensor’s status (if enabled or

disabled)

3 Screen Dim On/Off This is a toggle button that lets the user dim the screen

also this feature conserves power consumption

4 Summary page button This button links to summary page 1 (See 4.2)

5 Settings page button This button links to the settings page (See 4.4)

6 Lock screen button Allows the user to lock the system to prevent undesired

changes

7 System time and date The current system time and date is shown (See 4.5.4)

23

4.2 Summary page

The summary page gives a quick overview of information about the sensor station. This can

be accessed from the homepage and the sensor station pages. This page saves the user

from having to navigate to the specific sensor station page. There are 3 summary pages,

each of which contains a summary for 4 sensor stations. A brief description on how the

summary page was implemented in iDev language can be found in Appendix A.2.2.

Figure 6 Screen shot of Summary Page 1 with relevant annotations

Table 8 Definition of the Summary Page features/entities

Image


1 Dynamic LED indicator

The LED’s colour changes depending on the sensor

station’s status e.g. it will turn red and blink rapidly if

attention is required (See 4.5.3)

2 User-defined sensor

station name (shortened)

The font colour/type changes depending on the

sensor’s status (if enabled or disabled)

3 Sensor station toggle

button

Allows the user turn the appropriate sensor station

on or off

4 Current sensor station

parameter value summary

Displays the specified target sensor value, current

sensor value/s and alarm notification’s status

8

8

1

2 3

4

5 6 7

24

5 Homepage button This button links to the Homepage (See 4.1)

6 Navigation buttons This button lets the user to ‘scroll’ through the

different summary pages


8 System time and date The current system time and date is shown (See

4.5.4)

4.3 Sensor station page

This page allows the user to change most of the sensor station parameters. The other

parameters are accessible in the Sensor station setup page (See 4.4.1). This page has

dynamic font indicators to help the user distinguish what type of sensor has been enabled.

There are 12 sensor station pages and they are all identical to each other. The settings

changed here will also appear on the sensor station setup i.e. changes can be applied on

either page and it will appear appropriately. A brief description on how the sensor station

pages were implemented in iDev language can be found in Appendix A.2.3.

Figure 7 Screenshot of Sensor Station 1 with annotations

10

10

1

2

2

3 4

5

6

7 8 9

25

Table 9 Definition of the Sensor Station page features/entities

Image


1

User-defined sensor

station name

(shortened)

The shortened sensor name can be changed by the

user by tapping this field, note that the shortened name

should be assigned separately to the name assigned in

the Homepage (See 4.1)

2

User-defined sensor

station parameter

value summary

By tapping the up/down button the target value, monitor

frequency, margin and penalty values can be changed

A user can also specify a parameter value by tapping

the relevant value’s location (number pad will show up

See 4.5.2)

The ‘TARGET’ font colour dynamically changes to notify

the user what type of sensor is being monitored

3 Sensor type

These are toggle buttons that allows the user to

enable/disable temperature and humidity sensor types,

other types can be enabled in the sensor station setup

page (See 4.4.1)

4 Alarm notification

toggle

User can specify whether SMS notification is needed for

the sensor station concerned

5 Current/’Live’ Sensor

value This field shows the current sensor value

6 Dial indicator

This ‘dial’s’ position depends on the current penalty

value and it indicates the level of the current penalty

value relative to the user-defined penalty parameter

(See 4.5.5)

7 Summary Page button This button links to relevant Summary Page (See 4.2)

8 Navigation buttons This button lets the user to ‘scroll’ through the different

sensor station pages



26

4.4 Settings page

The settings page is basically a ‘portal’ to access the different relevant setup pages of the

system such as GSM settings. This page is accessible to almost all the pages in the user

interface due to its high importance. A brief description on how the settings page was

realized in iDev language can be found in Appendix A.2.4.

Figure 8 Screenshot of Settings Page with annotations

Table 10 Definition of the Settings Page features/entities

Image


1 Screen Brightness Slider

Bar

This slider allows the user to change the screen

brightness (0 darkest, 100 brightest)

2 Sensor setup button This page links to the Sensor station setup page

(See 4.4.1)

3 Alarm settings button This page links to the Alarm settings page (See

4.4.2)

4 Time & Date settings button This page links to the Time & Date settings page

(See 4.4.3)

5 Console & Lock settings

button

This page links to the Console & Lock settings

page (See 4.4.4)

9

1

2 3 4

8 7

6 5

9 10 11

27

6 GSM Settings button This page links to the GSM Settings page (See

4.4.5)

7 Info page button This page links to the System Information page

(See 4.4.6)

8 Help page button This page links to the System Help page (See

4.4.6)


10 Summary button This button links to relevant Summary Page (See

4.2)


4.5.4)

4.4.1 Sensor Setup

The other parameters that cannot be set in the sensor station page (See 4.3) can be

manipulated in this page. Although there are 12 different stations, all the different sensor

field parameters dynamically change depending on which current sensor station is selected.

Although implementing this setup is complicated, it saves a lot of memory. Memory is scarce

in a project of this size. The settings changed here will also appear on the sensor station

page i.e. changes can be applied on either page and will appear appropriately.

Figure 9 Screenshot of Sensor Setup page with annotations

1

2

2 3

4

5

5

6

7

8 8

9

10 11 12 13 14

14

28

Table 11 Definition of Sensor Setup features/entities

Image


1 Active sensor

station indicator

This field tells the user which sensor station the parameters

in current page belong to, note that the font colour/type to

signify whether the sensor is enabled/disabled

2

Sensor station

navigation

buttons

Left/right buttons that allows the user to change the ‘active’

sensor station

3 Current sensor

station status

Displays the current sensor station’s status, this updates

depending on the monitor frequency

4 Sensor type The current sensor type applied is shown here

5

Sensor type

navigation

buttons

Left/right buttons that allows the user to change the current

sensor type, user can only change sensor type to battery or

‘other’ here

6 Pin assignment This field allows the user to assign the pin where the sensor

is connected to

7 Connection type

toggle

This is where the user specifies whether the sensor is

connected locally (base station) or wirelessly (substation)

8 Xbee MSB/LSB

Address

If the sensor is connected wirelessly, the user can specify

the Xbee address in this field

9 Connect button The user can press this button to initialise sensor connection

10 Clear button Pressing this button sets all the sensor parameters to their

default values


12 Summary button This button links to relevant Summary Page (See 4.2)

13 Settings page

button This button links to the settings page (See 4.4)

14 System time and

date The current system time and date is shown (See 4.5.4)

29

4.4.2 Alarm settings

This page enables the user to specify all the alarm notification related settings. The alarm

status can be changed from the sensor station page or here. The relevant page entities on

both pages are updated dynamically. There is another page for sensors 9-12, which can be

accessed by pressing the Next button. The user can specify the control response in this

page. The control response is what the user should send back as an SMS to the system.

This feature allows the system to stop sending SMS notification constantly.

Figure 10 Screenshot of Alarm Settings with annotations

Table 12 Definition of Alarm Settings features/entities

Image


1 Current SMS

notification value

The current SMS notification value is shown here,

tapping this field allows the user to specify the value

(number pad opens, See 4.5.2)

2 SMS notification

navigation buttons

Left/right buttons that allows the user to change current

SMS notification interval in minutes

3 Control Response

field

User can change this field by tapping it (keyboard is

displayed, See 4.5.1)

4 Alarm notification

toggle

User can specify whether SMS notification is needed for

the sensor station concerned

1

2 2 3

4 5

6

7 8 9 10

10

30

5

User-defined sensor

station name

(shortened)

The font colour/type changes depending on the sensor’s

status (if enabled or disabled) and if enabled, by tapping

this field the relevant sensor station page is opened

6 Next button This button links to the second Alarm settings page,

which displays information about sensor station 9 to 12





4.4.3 Time and date page

This page is where the time and date settings can be modified. The system supports 12/24

hour time format. The date can also be displayed as a word or a number. Lastly, the time

and date location on the screen can be swapped.

Figure 11 Screenshot of Time & Date page with annotations

1

5

3

4

2

6 7 8

31

Table 13 Definition of Time & Date page features/entities

Image


1 Current date

value The current date value is displayed in this field

2 Date Navigation

buttons


system date

3 Current time

value The current time value is displayed in this field

4 Date Navigation

buttons


system time

5

Time/Date Format

and Time

Location toggles

These toggle buttons allows the user to change the time

format (12/24), date format (word/number) and time location

(top/bottom)



8 Settings page


4.4.4 Console and Lock settings

The user can enable the system lock screen in this page. An autolock feature is added in the

system which works by detecting how long the screen has been idle for and based on the

current autolock setting the lock screen is shown. This feature is evident on most

smartphones available today. The user can also calibrate and change the screen’s

orientation on this page.

32

Figure 12 Screenshot of Console & Lock page with annotations

Table 14 Definition of Console & Lock settings page features/entities

Image


1 System Lock toggle This toggle button dictates whether the system lock

should be enabled or disabled

2 System Autolock

toggle

This toggle button enables/disables system autolock, with

the default value when enables set at 1m (1 minute)

3 Current Passcode

indicator

This text entity shows the current system passcode

applied

4 Set new passcode

field

When pressed, the user can change the current passcode

(maximum 10 characters, number pad opens See 4.5.2)

5 Confirm new

passcode field

When pressed, a number pad is displayed to allow the

user to confirm the new current passcode set (, number

pad opens See 4.5.2)

6 Autolock setting This text entity displays the current system autolock

setting

7 Different autolock

buttons

These 6 buttons allows the user to set which autolock

setting is required

8 Calibrate screen

button

When pressed, the TFT module’s calibration screen is

opened.

1

2

3

4

5

6

7

8

9

10 11 12 13 14 15

15

33

9 Rotate screen button When pressed, the screens orientation is rotated by 180°

10 Apply lock settings

button

This button applies the current lock settings inputted by

the user, the current passcode indicator will be updated to

signify that the settings have been successfully applied

11 Discard lock settings

button

This button discards the current settings and apply the

system’s default values




15 System time and


4.4.5 GSM settings

There are 6 pre-set AT commands that are deemed as important, each are easily accessible

on the main GSM page. However, if the user desires to enter other AT commands, the GSM

terminal can be used. The main GSM page also contains a mini terminal which displays the

response from the GSM module.

Figure 13 Screenshot of GSM Settings page with annotations

1

2 3 4 5

6

7

8 9 10 11

11

34

Table 15 Definition of GSM settings page features/entities

Image


1 GSM connectivity

status This displays the current GSM module connectivity status

2 Main destination

field

The main user’s mobile number where the SMS notification

will be sent can be changed here, number pad opens when

pressed to allow the user to enter the mobile number

(number pad See 4.5.2)

3 Dest Nos button This button links to the Destination Numbers page (See

4.4.5.1)

4 SMS Mode button This button opens the SMS Mode page (See 4.4.5.2)

5 GSM Terminal

button This button displays the GSM Terminal page (See 4.4.5.3)

6 6 pre-set AT

command buttons

These 6 buttons allows the user send these pre-set AT

commands to the GSM module

7 Mini-terminal The response from the GSM module is shown on the Mini

Terminal



10 Settings page


11 System time and


4.4.5.1 Destination numbers

In addition to the main destination number set in the GSM settings page, 10 more

destination numbers can be added by users. These added destination numbers can be

enabled/disabled on this page as well. There are two destination number pages and on each

page 5 user-defined destination numbers are shown.

35

Figure 14 Screenshot of the Desti Nos 1 page with annotations

Table 16 Definition of Desti Nos pages features/entities

Image


1 User Name field

The user can add a ‘tag’/’identifier’ to a

notification destination mobile number through

this field, by tapping this field a keyboard shows

up to input the user name (See 4.5.1)

2 Destination Number field

The user’s mobile number where the SMS

notification will be sent can be changed here,

number pad opens when pressed to allow the

user to enter the mobile number (number pad

See 4.5.2)

3 Notification toggle

This toggle button enables/disables notification

status for the relevant user name/mobile number,

note that disabling this toggle means that the

user won’t be notified by SMS anymore

4 Next button

This button links to the second Desti Nos page,

which displays information about user

name/mobile number 6 to 10


1 2 3

4 5 6 7 8

8

36

6 Back button This button links to the GSM settings page (See

4.4.5)



4.5.4)

4.4.5.2 SMS mode page

Since the GSM module is capable of sending messages, the SMS mode page was created.

On this page, the user can compose a personal SMS message (maximum 128 characters)

and send it to the desired destination mobile number.

Figure 15 Screenshot of SMS Mode page with annotations

Table 17 Definition of SMS Mode page features/entities

Image


1 Destination

Number field

The SMS message’s destination mobile number where can

be changed here, number pad opens when pressed to allow

the user to enter the mobile number (See 4.5.2)

2

Received/GSM

module response

messages widow

The SMS message received is displayed on this page and

also the response from the GSM module to determine

whether the SMS message has been sent successfully

2

1

3

4 5 6 7 8 9

9

37

3 Sent messages

widow

Tapping this window allows the user opens the full-size

keyboard (See 4.5.1) to compose the user’s SMS message

4 Send message

button

As the name suggests, pressing this button sends user-

defined SMS message, note that the message status is

shown on the received/GSM module reponse window

5 Clear message

button

Pressing this button clears the current composed SMS

message


7 Back button This button links to the GSM settings page (See 4.4.5)

8 Settings page


9 System time and


4.4.5.3 GSM Terminal page

The SM5100B GSM module (See 2.5) can be controlled by sending AT commands through

a Terminal software in Windows/Mac OS/Linux. A full-sized terminal software is created on

iDev that enables the user to enter any AT commands without having to connect the GSM

module to a computer. This is an imperative feature for the system, hence giving the user full

control of the GSM module.

Figure 16 Screenshot of Terminal Mode page with annotations

3

1

2

4

5 6 7 8

8

38

Table 18 Definition of Terminal Mode page features/entities

Image


1 Main GSM

response window

This big window displays the response from the AT

command sent to the module

2 AT command field

The AT command that the user wants to send to the GSM

module can be inputted here, tapping this field opens the

keyboard (See 4.5.1)

3 Send command

button

The AT command inputted by the user is sent to the GSM

module, note that carriage return character is automatically

added when this button is pressed

4 Add ‘Ctrl-z’

character button

Some AT commands require the ‘Ctrl-z’ character, this

button allows the user to add it the command


6 Back button This button links to the GSM settings page (See 4.4.5)

7 Settings page


8 System time and


39

4.4.6 Info page

This page displays the current system version number and important information about the

system.

Figure 17 Screenshot of System Info page with annotations

Table 19 Definition of System Info page features/entities

Image


1 System Info The current system information is displayed here



4 Settings page


5 System time and


2

1

3 4 5

5

40

4.4.7 Help page

This page displays guideline information about all the pages in the system. A concise

information is shown for each page.

Figure 18 Screenshot of Help page with annotations

Table 20 Definition of Help page features/entities

Image


1 Various page

buttons

These buttons link to the relevant pages showing information

about it



4 Settings page


5 System time and


1

5

2 3 4 5

41

4.5 Miscellaneous pages/features

4.5.1 QWERTY keyboard

The code for the full-sized on screen keyboard is adapted from the screen manufacturer’s

website [4]. All the features are kept the same except the clear button. The clear button was

added for ease of use.

Figure 19 Screenshot of Keyboard page with annotations

Table 21 Definition of Keyboard page features/entities

Image


1 Clear button

This button clears the current text entered, saves the user

having to keep on pressing the ‘BS’ (backspace)/ ‘DEL’

(delete) button

2 Text field The current text entered by the user is shown here

3 Keyboard keys

These are the standard qwerty keyboard keys, some

characters are accessible by pressing the shift/caps lock

button

1 2

3

42

4.5.2 Number pad

4.5.2.1 Default number pad

This number pad appears when numbers are required to be inputted by the user. This is

created to avoid having to use the keyboard page unnecessarily.

Figure 20 Screenshot of Default Number pad page with annotations

Table 22 Definition of Default Number pad page features/entities

Image


1 Number field The current number entered by the user is shown here

2 Number pad indicator The number pad indicator varies to inform the user

which parameter they are about to change.

3 Clear button

This button clears the current number entered, saves

the user having to keep on pressing the Undo

(backspace) button

4 Number pad keys

These are the standard number pad keys, the cancel

button shows the previous page, note that the ‘-‘ and ‘,’

characters change to ‘*’ and ‘#’ in some number pad

types such as the destination number one


1

2

3

4

5

43

4.5.2.2 Lock screen number pad

This page is displayed when the system is locked. This page has a dim screen toggle which

helps to reduce power consumption.

Figure 21 Screenshot of the Lock Screen number pad page with annotations

Table 23 Definition of Lock Screen number pad page features/entities

Image


1 Number field The current number entered by the user is shown here

but isn’t visible, characters are replaced by asterisks

2 Dim screen toggle

button

The user can dim the TFT module screen by pressing

this button, note that when the screen is dimmed, the

screen is automatically brightened up when any button

is pressed.

3 Number pad keys

These are the standard number pad keys, the cancel

button clears the current passcode entered which is

different from the default number pad page (See 4.5.2.1)


4 1

2

3

44

4.5.3 Dynamic LED notification

The LED system is added to provide visual feedback to the user. This feature saves time

from the user having to navigate to the sensor station page. If the user needs to determine

the current sensor status, they will only need to look at the LED’s colour. There are 4 LED

colours, each of which signify different sensor status levels. The difference between the

target level and the highest/lowest acceptable value are divided by 3. The quotient is used to

determine 4 different ranges. The LED shown in the Homepage (See 4.1) and Summary

page (See 4.2) indicates which range the current sensor value lies in.

Figure 22 LED colours used in the system

Table 24 Definition of different LED colours

LED

colour

Sensor

Alert/Status

Level

LED blink

frequency

(ms)

Definition

Grey OFF None Indicates that the sensor station is disabled

Green LOW 1000 Indicates that the current sensor value lies

closest to the target value (1st dividend)

Amber MID 750 Indicates that the current sensor value is in the

middle level from the target value (2nd dividend)

Purple HIGH 500 Indicates that the current sensor value is in the

furthest level from the target value (3rd dividend)

Red EXTREME

250 Indicates that the current sensor value has

exceed the acceptable threshold and attention

is required

4.5.4 Real time clock feature

The Real time clock support allows the system to notify the user ‘time-stamp’ incidents

where the sensor value has exceeded ‘acceptable’ threshold. The time and date is ‘global’ in

the system and is visible in majority of pages. Settings changed in the Time and Date page

(See 4.4.3) is applied ‘globally’.

45

4.5.5 Current penalty indicator

There are 10 different ‘dial’ levels that can be shown on the screen. If the current sensor

value is above the ‘acceptable’ higher threshold value then the dial moves towards the top of

the screen and vice-versa. There are 6 different current penalty thresholds calculated which

are used to determine the screen position of the ‘dial’. A combination of built-in calculation

functions and complex flagging system was used to implement this on iDev language. The

current penalty calculation is explained in 5.1.

Figure 23 Screenshot of Sensor station page demonstrating what will be displayed if the current

penalty exceeds the penalty parameter threshold and the current sensor value is below the

‘acceptable’ lower threshold

4.5.6 EEPROM memory

The TFT module has EEPROM support. This is utilised in the system, thus all the user-

defined parameters are retained even when the system is turned off. This features saves a

lot of setup time and improves the system’s user-friendliness.

4.5.7 GSM control response

The users can send the system a control SMS message to signify that the users attention is

caught so there is no need to keep on sending SMS notifications.

46

Chapter 5 System Algorithms

5.1 Penalty calculation algorithm

This algorithm warrants that inaccurate SMS notification does not happen. A scenario where

the sensor is connected to a fridge and the user opened the door can cause the sensor

reading to go beyond the ‘acceptable’ range. The system can interpret this as notification-

worthy, and send unnecessary SMS alert message (See 6.1) to the users. To avoid

situations like this to occur, the penalty system is introduced. The user will set the

acceptable penalty level on sensor setup. If the current sensor value exceeds the acceptable

threshold, an arbitrary value based on the difference between the sensor value and the

target value is added to the penalty variable. As long as the penalty parameter specified is

sensible, the user will only be notified (through SMS) when ‘real’ attention is required.

47

Figure 24 Flowchart to demonstrate current penalty level manipulation

48

Chapter 6 Software Implementation

6.1 Sensor notification procedure

SMS notification is the medium that the system contact the users remotely. The user defines

how often the penalty value is monitored. Once the current penalty level has exceeded the

acceptable level then an SMS message is sent to the users. The users enabled in the

Destination Numbers page ( See 4.4.5.1) including the main destination number are the only

ones alerted. The penalty dial level indicator also moves appropriately to provide visual

feedback.

49

Figure 25 Flowchart demonstrating the sensor notification procedure

6.2 Monitor system realisation

In this section the process that takes place when one sensor station is enabled from initial

stimulus (user enabling the sensor station and specifying the necessary parameters) to the

remote substation and back to the source substation is explained. The sensor station status

and parameters are first checked. Then the appropriate instruction strings are constructed to

be ‘passed’ along to the correct destination. This destination is based on the sensor’s

location.

- 50 -

Figure 26 Flowchart demonstrating the processes occurring in the TFT module

- 51 -

Figure 27 Flowchart describing the processes in the Arduino Mega (base station) when the instruction

from the TFT module has arrived

- 52 -

Figure 28 Flowchart showing the processes in the substation when an instruction has arrived from the

base station (via Xbee)

- 53 -

Figure 29 Flowchart describing the processes that occur when a response from the substation module

has arrived at the Arduino Mega (base station)

- 54 -

Figure 30 Flowchart demonstrating the processes that occur in the TFT module when a response

from the Arduino Mega(base station) has arrived

- 55 -

Chapter 7 Hardware PCB Design

7.1 Base station PCB

The base station PCB is designed on EAGLE CAD software. The two-layered PCB designed

has an approximate size of 8 by 15 cm. For minimal board size, a ‘shield’ was created for the

Arduino Mega. The Xbee and GSM module is integrated in the shield as well. LED indicators

for the modules on the shield were also added for debugging purposes. All the components

used are surface-mount. The analogue and digital pins are left accessible via pin headers.

- 56 -

7.1.1 Schematic

Figure 31 Screenshot of the base station PCB's schematic

- 57 -

7.1.2 Board layout

Figure 32 Screenshot of the base station PCB's board layout

- 58 -

7.1.3 Testing and results

Due to unforeseen circumstances, the PCB designed did not function properly. This may be

due to inappropriate soldering of surface mount PCB components. In addition to this, heat

dissipation from the power supply was not anticipated when the PCB was designed. The

power supply for the TFT module produces dissipates heat a lot during testing. A heat sink

should have been fitted to mend this issue. An external power supply designed on vero

board was used to make the final system work. The GSM module integrated on the PCB did

not work during testing as well. This may be caused by incorrect soldering of the small

contacts required for the GSM module. On the other hand, the Xbee integration is

functioning successfully.

7.2 Substation PCB

The substation PCB only consists of an Arduino Uno and Xbee module and a battery

connector was added. The ICSP functionality of the board was adapted in this board as well

to allow the user to upload sketches conveniently. The analogue and digital pins are left

accessible via pin headers.

- 59 -

7.2.1 Schematic

Figure 33 Screenshot of the substation PCB’s schematic

- 60 -

7.2.2 Board layout

Figure 34 Screenshot of the substation PCB’s board layout

7.2.3 Testing and results

Unfortunately the substation PCB designed didn’t function properly. The Xbee module didn’t

work properly because the serial communication was not connected properly (highlighted in

yellow box in Figure 34). Issues were experienced soldering surface mount components on

the board as well. Some tracks were damaged during the soldering process. The

combination of these issues has impeded the PCB’s functionality.

- 61 -

Chapter 8 Further Work and Improvements

8.1 Event data logging

The TFT module supports micro-SD card file manipulation. This can be utilised to add data

logging feature to the system. The important incidents when notifications have occurred and

other important properties can be logged into .txt file. Data logging settings page can also be

added in the system to manipulate logging information.

8.2 Remote system control

The system currently has the response control feature (See 4.5.7). This can be modified to

allow the user to send an array of control messages that can dynamically change sensor

station parameters. A keyword system can be used to implement this e.g. to change sensor

1’s target sensor value to 28, the message: s1:t:28 can be sent by the user to the system.

8.3 Sensor data graph

The TFT module has graph plotting capability. Sensor value data over time can be plotted on

graph using this feature. A graph setup page can added to allow the user to manipulate

which sensor parameters should be plotted on the graph.

8.4 Multiple user support

Similar to iOS/Android applications the system can be modified to have personalised user

interface. A user profile setup page can be added to allow the user to specify certain system

properties such as user interface theme and sensor station starting values.

8.5 Interactive tutorial

An interactive tutorial can be added that can be accessed from the help page. This tutorial

will be similar to iOS/Android applications that is shown to users who have recently installed

their app. This can be implemented by cycling through different parts of the user interface

whilst allowing the user to navigate to a specific part.

Word count (not including captions, headings and tables) : approximately 7000

- 62 -

Appendix A

A.1 System Development

A.1.1 Initial planning

The TFT module can be used to provide a user interface for the monitoring system. The user

can set the temperature and humidity range, weight of gas tank to be monitored through the

TFT module. There are many factors that determine the accuracy of the data collected such

as the frequency on how often to collect the current value. Multiple factors have to be taken

into account when creating an algorithm to determine when to notify the user. This algorithm

has to take the frequency of data collection, temperature range and monitoring duration.

Another feature that can be added is to let the user set when to send a notification e.g. if the

temperature reaches 2°C beyond the threshold a notification is sent rather than when the

temperature reaches beyond the threshold. The notification to the user is sent through the

GSM module and a visual notification if necessary. There are three theoretical system

configurations created for the laboratory monitoring system.

- 63 -

1st Alternative System Configuration

Legend

* - Humidity sensor is an optional sensor that may be omitted

Figure 35 Block diagram of 1st proposed system configuration

This system configuration uses 1 TFT module and 5 microcontrollers. This arrangement

assumes that each microcontroller has one serial interface. This configuration may use more

components in total but an advantage is that it each microcontroller would be dedicated to

perform minimal processes so the possibility of failure in each system is reduced

significantly, provided that the software and hardware of the system is robust. Another

advantage is that debugging would be easier. However, a major disadvantage is increased

cost of the total system and increased power consumption.

- 64 -

2nd Alternative System Configuration

Legend


Figure 36 Block diagram of 2nd proposed system configuration

This configuration is highly similar to the 1st one but it uses less microcontrollers. This

configuration uses microcontroller that have multiple serial interfaces. An advantage of this

configuration is that the overall cost and energy consumption would be less and there is no

need to link with the other two microcontrollers via i2c, decreasing the chances of data

transmission failure. A disadvantage of this configuration however is that some shields may

be incompatible with the microcontroller used in the 2nd sensor station and debugging may

be more difficult.

- 65 -

3rd Alternative System Configuration

Legend


** - serial communication medium is not specified

Figure 37 Block diagram of 3rd proposed system configuration

This last configuration uses 4 TFT modules and no external microcontrollers. This setup

would have the highest cost out of all the three systems that would be a disadvantage. A

major advantage of this arrangement is that providing communication between different

modules would be straight forward as it would all be in the same language, thus making

debugging much easier.

A.1.2 Changes made to initial plan

The initial plan was modified to a more realistic plan with the allotted time given. Instead of

creating a sensor station system with two sub stations that is specifically designed for the

specified freezers, it was decided to create one substation that is designed to function with

most freezers. To compensate for the need of monitoring other substations an approach that

allows expandability was applied. Thus, it would be possible to create another substation

and just by specifying it on the main station. The ‘general’ substation that was added has a

temperature sensor that is capable of measuring temperature with the range -55°C to

+125°C with ±1°C accuracy. This is suitable for monitoring one of the freezers in the

Bioelectronics laboratory and the ambient temperature of the room. Another major change to

the plan is the removal of monitoring the gas backup for the HETO MF80 freezer. This was

- 66 -

carried out since this feature is very specific to that freezer and cannot be generalised to

other freezer systems. Also the main aim of this system is to monitor temperature and

humidity. In the start, it was assumed that each substation would have a maximum of 2

sensors connected but this is changed so one substation can have a maximum of 11 sensor

connected, provided that the main station have one sensor connected to it and that there is

only one substation. The rest of the details of the plan was left the same and deemed

appropriate. It’s has been discussed to create a system where applying expandability of

sensor stations is as easy as possible. It is of high importance to create a system that allows

the user to add sensor station as quick as possible and achieve a system that’s as close to

the ‘plug and play’ approach that most electronic devices have. Another addition to the plan

is to make the substations powered from either a power supply or battery source. This would

make deployment of substations more convenient for the user.

- 67 -

A.2 Intra-base communication development

A.2.1 Using separators/delimiters for each sensor station data

In the development stages, a simple protocol to implement the use of separators/delimiters

for each command was created and tested. This involved using a unique character that is

allocated for each command. The ‘:’ is used as to separate sensor number station and the

sensor value, ‘+’ to separate data from sensor stations and lastly ‘,’ is used to separate

sensor data in one sensor station. An example of the string sent to the Arduino from the TFT

to request temperature and humidity data from sensor station 1 and 4, humidity data from

sensor 2 and lastly temperature data from sensor 3 would as follows:

1th+2h+3t+4th(termination character)

An example of the reply string sent from the Arduino to the TFT which contain temperature

and humidity data from 4 sensor stations would be as follows:

1t:-15,1h:65+2t:0,2h:29+3t:52,3h:0+4t:28,4h85(termination character)

In the TFT module, this string is separated and assigned to the allocated variables to store

separated sensor station data. String manipulation at the TFT module was implemented by

using built-in data string functions in the iDev language. On the Arduino’s side however, a

similar approach is applied. For detection of separators and string manipulation built-in string

functions in the stdlib.h and stdio.h libraries were used such as strcmp() function. Although

using separators/delimiters for string manipulation is definitely viable it can however, be

inefficient. It is important to remember that the system was designed to accommodate 12

sensor stations and the example shown is only for 4 sensor stations. For example, if only

one setting needs to be changed then a whole string containing the current/previous values

for the other settings still have to be sent. This makes this whole configuration prone to

errors. On the other hand, if loads of settings have to be changed then this configuration is

more efficient.

A.2.1 Using keywords for each command which triggering an action when

detected

This method was implemented using the same functions as how the other configuration was

applied on both modules. However, string manipulation functions won’t be required for this

method since each setting is sent individually. For example if a temperature was required

from sensor station 6. Then the string 6t(termination character) is sent from the TFT and the

Arduino replies with 67(termination character) which is the temperature data. Single sensor

station data is handled separately per transaction to avoid confusion. A disadvantage of this

- 68 -

method is that changing multiple settings at a time and activating multiple sensor stations

are not easy to realize. A simple case/switch select method/function for the TFT module and

Arduino module can be used to apply this configuration. The low complexity of this method is

its main advantage. This configuration only requires shorter strings to be transmitted at a

time and hence, it has a lower probability of creating errors and data corruption to occur.

A.3 GSM module integration and development

The GSM module is connected to the TFT module. The communication interface used is

asynchronous interface. Both modules operate at 3.3V logic levels so a logic level shifter

isn’t necessary. There are no significant issues experienced during the GSM incorporation

process. The asynchronous setup requirements on the TFT module are:

baud rate should be set to 9600

proc parameter set to CRLF (Carriage Return and Line Feed)

procDel set to Y(Yes)

Clearly the transmit and receive parameters should be enabled. For correct data

interpretation on the TFT module, the setup specified must be applied. The responses from

the GSM module uses a carriage return and line feed as a termination character. Hence, the

proc parameter is set to CRLF. The procDel parameter is enabled only to delete the

termination character from the asynchronous buffer. The GSM module also requires specific

syntax to correctly process AT commands. Most commands sent to the GSM module should

terminate with a carriage return (0D in HEX) but some commands should end with ctrl+z (1A

in HEX). An example literal string to check the current baud rate set would be as follows:

AT+APR?\\0D. In essence, functions were created in the TFT module to send the applicable

AT commands to the GSM module to send SMS messages and check current settings.

- 69 -

Appendix B

B.1 IDev user interface implementation

The software written to control the TFT module is found in the separate zip file. It contains all

the images and the correct file types. Approximate lines of code: 20000

B.2 Arduino code implementation

The Arduino sketch for the base station (Arduino Mega) and substation (Arduino Uno) are

found in a separate zip file. Approximate lines of code: 450 (Arduino Mega) and 300

(Arduino Uno)

- 70 -

References

[1] Maxim Integrated. (2009, Mar) www.maximintegrated.com. [Online].

http://www.maximintegrated.com/app-notes/index.mvp/id/4377

[2] software technologies group. www.stg.com. [Online].

http://www.stg.com/wireless/ZigBee_comp.html

[3] Andrew Rapp, xbee-api A Java API for Digi XBee/XBee-Pro OEM RF Modules, taken

from https://code.google.com/p/xbee-api/.

[4] Noritake-Itron UK, 4.3 inch Keyboard project, code is modified and used in the project,

from http://www.noritake-itron.com/NewWeb/TFT/Project/ExampleProjects/mnu/key.asp.

http://www.maximintegrated.com/app-notes/index.mvp/id/4377

http://www.stg.com/wireless/ZigBee_comp.html

Documents

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”