wireless tyre pressure monitoring system using zigbee

WIRELESS TYRE PRESSURE MONITORING SYSTEM

USING ZIGBEE

FINAL YEAR PROJECT REPORT

BEng Honours Electronic & Communications Engineering

University of Kent, Canterbury

Department of Electronics

Author: Odafe Ojenikoh

Project Supervisor: Adam Jastrzebski

March 2008

TABLE OF CONTENTS

ABSTRACT ............................................................................................................................................................. I ACKNOWLEDGEMENTS ........................................................................................................................................ II TERMS AND ABREVIATIONS ................................................................................................................................III 1 INTRODUCTION ............................................................................................................................................ 1

1.1 AIM AND SCOPE .............................................................................................................................................. 1

1.2 APPROACH ..................................................................................................................................................... 2

2 BACKGROUND RESEARCH ............................................................................................................................ 3 2.1 TPMS OVERVIEW ........................................................................................................................................... 3

2.1.1 Types of TPMS ..................................................................................................................................... 3 2.1.1.1 Direct TPMS ..................................................................................................................................................... 3 2.1.1.2 Indirect TPMS .................................................................................................................................................. 4 2.1.1.3 Hybrid TPMS .................................................................................................................................................... 4

2.2 ZIGBEE OVERVIEW ........................................................................................................................................... 5

2.2.1 Zigbee Device Types ............................................................................................................................ 7

2.2.2 Zigbee Stack Architecture ................................................................................................................... 8

2.2.3 Zigbee Network Formation ................................................................................................................. 9

2.2.4 Zigbee Data Transmission ................................................................................................................. 10

3 PROJECT SPECIFICATION ............................................................................................................................ 12 3.1 FUNCTIONAL SPECIFICATION ............................................................................................................................ 12

3.2 ADDITIONAL FEATURES ................................................................................................................................... 12

4 DESIGN AND IMPLEMENTATION ................................................................................................................ 13 4.1 OVERVIEW ................................................................................................................................................... 13

4.2 ANATOMY OF ZIGBEE BASED WIRELESS TPMS .................................................................................................... 13

4.2.1 The Hardware ................................................................................................................................... 13 4.2.1.1 Microchip PICDEM Z Demonstration Kit ........................................................................................................ 13 4.2.1.2 Freescale Combined Temperature and Pressure Sensor ............................................................................... 14 4.2.1.3 Interfacing The Sensor Board With the Demo Board .................................................................................... 17

4.2.2 The Software ..................................................................................................................................... 21 4.2.2.1 Zigbee Stack................................................................................................................................................... 21 4.2.2.2 TPMS Application .......................................................................................................................................... 22

4.2.2.2.1 Sending Messages.................................................................................................................................... 23 4.2.2.2.2 Receiving Messages ................................................................................................................................. 24 4.2.2.2.3 The Control Unit ...................................................................................................................................... 25 4.2.2.2.4 The Tyre Unit ........................................................................................................................................... 26 4.2.2.2.5 Running the TPMS Application ................................................................................................................ 32

4.3 CHALLENGES FACED ....................................................................................................................................... 35

4.3.1 Understanding The Zigbee Stack Implementation ............................................................................ 35

4.3.2 Programming in C ............................................................................................................................. 36

5 TESTING AND RESULT VERIFICATION .......................................................................................................... 37 5.1 TESTING THE MPXY8020 SENSOR ................................................................................................................... 37

5.1.1 Apparatus ......................................................................................................................................... 37

5.1.2 Technique.......................................................................................................................................... 37

5.1.3 Results............................................................................................................................................... 38

5.2 TESTING THE ZIGBEE COMMUNICATION LINK ...................................................................................................... 39

5.2.1 Apparatus ......................................................................................................................................... 39

5.2.2 Technique.......................................................................................................................................... 39

5.2.3 Results............................................................................................................................................... 40

5.3 TESTING THE SYSTEM’S OVERALL FUNCTIONALITY ................................................................................................ 40

5.3.1 Apparatus ......................................................................................................................................... 40

5.3.2 Technique.......................................................................................................................................... 41

5.3.3 Results............................................................................................................................................... 41 5.3.3.1 Parking Mode ................................................................................................................................................ 41 5.3.3.2 Driving Mode ................................................................................................................................................. 42

5.4 KNOWN ISSUES ............................................................................................................................................. 42

5.4.1 Sensor ............................................................................................................................................... 42

5.5 ANALYSIS ..................................................................................................................................................... 43

6 CONCLUSIONS ............................................................................................................................................ 47 6.1 FUTURE ENHANCEMENTS ................................................................................................................................ 47

6.1.1 Tyre Identification Feature ............................................................................................................... 47

6.1.2 Additional System Operational Modes ............................................................................................. 47

6.2 FINAL CONCLUSIONS ...................................................................................................................................... 48

7 BIBLIOGRAPHY ........................................................................................................................................... 50 8 TABLE OF FIGURES...................................................................................................................................... 51 9 APPENDICES ............................................................................................................................................... 52

9.1 SCREEN CAPTURE OF TEST RESULTS ................................................................................................................... 52

9.2 SENSOR ROUTINES ......................................................................................................................................... 60

9.2.1 Sensor Initialization Routine ............................................................................................................. 60

9.2.2 8 Bit Data Shift Routine .................................................................................................................... 60

9.2.3 Successive Approximation Routine ................................................................................................... 61

9.2.4 Pressure Measurement Routine ....................................................................................................... 62

9.2.5 Temperature Measurement Routine ................................................................................................ 62

9.3 TPMS APPLICATION ...................................................................................................................................... 64

9.3.1 Application Project File Organization ............................................................................................... 64

9.3.2 Configuring the Application .............................................................................................................. 65

9.3.3 TPMS Application CD ........................................................................................................................ 66

WIRELESS TYRE PRESSURE MONITORING SYSTEM USING ZIGBEE

i

ABSTRACT

This report gives an insight to a final year project involving developing a Tyre Pressure monitoring

system using Zigbee for its wireless communication protocol. Also, the report gives a brief overview of

Tyre pressure monitoring systems, its features and various types. It then goes further to examine the

Zigbee communication protocol and its features. Furthermore, the report gives detailed information

about the actual design, implementation and testing of a demonstrator system used to analyse the

feasibility of using Zigbee communication protocol in a Tyre Pressure Monitoring System. Also

highlighted in the report are additional features that can be implemented in a Tyre Pressure

Monitoring System as a result of Zigbee being used. It also contains analysis carried out focusing on the

power consumption of the System while Zigbee is being used and draws a conclusion as to the

suitability of using Zigbee in a wireless Tyre Pressure Monitoring System.


ii

ACKNOWLEDGEMENTS

Firstly, I would like to thank my Supervisor, Adam Jastrzebski for providing the tools and helping me lay the

foundation upon which this project was based. Also, I would like to express my sincere gratitude to Dr Robert B.

Reese of the Department of Electrical and Computer Engineering at Mississippi State University whose extensive

research and implementation of the Zigbee stack helped in successfully completing the project. Furthermore, I

would like to thank the Support staff in the Digital Simulation Laboratory in the Electronics Department at the

University of Kent for their help with resolving technical issues during the course of the project.

Finally, I thank my parents Mr & Mrs J.O Omongagah for their constant financial and moral support during my

five years studying at the University of Kent.


iii

TERMS AND ABREVIATIONS

APL Application layer of the Zigbee stack

APS Application support layer of the Zigbee stack

Coordinator The network coordinator, forms the network

FFD full function device

FSM Finite State Machine

HAL Hardware Abstraction Layer of the Zigbee stack

IDE Integrated Development Environment

IEEE Address 8-byte 802.15.4 network address of a node, also called the long address

MAC Medium access control layer of the Zigbee stack

MCU Microcontroller Unit

Network Address 2-byte network address of a node, also called the short address

NWK Network layer of the Zigbee stack

PAN personal area network

PAN ID personal area network identifier

PHY Physical layer of the Zigbee stack

RF Radio Frequency

RFD reduced function device

TPMS Tyre Pressure Monitoring System


1

1 INTRODUCTION

Tyre Pressure Monitoring Systems (TPMS) are electronic systems in motor vehicles to monitor the air

pressure inside its tyres. Several years ago, TPMS were installed as a factory default in high end vehicles

only. This was generally because extending the technology to mid-range-higher volume production

models will require that the systems be more cost effective. However, due to legislations and

improvements in technology, there are increasing number of low end vehicles fitted with TPMS and also

a significant increase in the availability of after-market systems.

TPMS are implemented using radio frequency (RF) technology to avoid expensive and rather

complicated rotating contact wiring. A typical TPMS comprises an electronic control unit fitted inside the

vehicle and battery powered sensors with transmitters within the tyre cavities of the vehicle. The

control unit provides the necessary processing functionality that interprets pressure data coming from

battery powered sensors and delivers alerts and warnings to the driver.

1.1 AIM AND SCOPE

Most TPMS systems that utilize RF technology use proprietary techniques in communicating between

sensors and their control unit and as such, there is little or no room for interoperability with units

supplied by other vendors. One of the reasons is the use of non-standards based communication

techniques. Also, most proprietary RF based systems only allow the sensors in the tire cavities transmit

data in a pre determined pattern. This means the control unit have little or no control as to when the

sensors send data. This creates the problem of an inefficient use of battery power as a result of the data

not being of interest to the control unit at the time it is being send. Thus, the need to send data

sometimes exceeds the demand for it.

The project examines the use of an industry standard RF communication protocol called Zigbee in the

design of a wireless TPMS. The deliverables in the project include a demonstrator TPMS that exploits the

Zigbee protocol and how it affects the power consumption of the system due to the fact that it

facilitates two way communication and paves a way for the innovation of additional features in TPMS

design. Long battery life is a key feature when it comes to enhancing the capability of TPMS as battery


2

operated systems usually have a unit embedded inside the vehicle tyre and as such it is impractical and

not cost efficient to frequently replace the battery. The project also examines the power consumption of

the tyre unit and uses the information to estimate the duration of the battery life.

1.2 APPROACH

In carrying out the project, it was necessary to carry out an extensive research on tyre pressure

monitoring systems and their properties. It was also important that the Zigbee communication protocol

and the relevant standards associated with it were understood. The demonstrator system built

comprises an evaluation kit obtained from Microchip Ltd, containing two Microprocessor boards with

software for evaluating the Zigbee communication protocol. A Sensor unit was built by myself

containing a combined temperature and pressure sensor and was attached to one of the evaluation

boards, together, mimicking the unit found in the tyre cavity of a TPMS. Further details of the System is

discussed in section 4. In developing the software, the System was first modelled at a high level using

flowcharts and pseudo codes to map out its intended operation. Software algorithms were developed

and implemented to meet the project specification and the system was tested and analyzed using the

project specification as a benchmark to measure the level to which the project achieved its goals.


3

2 BACKGROUND RESEARCH

2.1 TPMS OVERVIEW

In the United States, accidents involving sport utility vehicles led to tyre recalls and claims that vehicle

design, tyre quality, tyre pressure, or driver error were the underlying causes. As a result, the

Transportation Recall Enhancement, Accountability and Documentation (TREAD) Act was passed in the

fall of 2000 following the Ford-Firestone crisis which saw a wave of road accidents involving Ford

Explorers fitted with Firestone tyres. It was found that the tyres experienced high rates of thread

separation from the tyre. It was also established that the problem was due to poor tyre design. The

United States Congress wanted to make tyres safer for the motoring public, hence, the introduction of

the Act. The TREAD Act has nine components that affect the tyre industry one of which is Tyre Pressure

Monitoring Systems. The purpose of this regulation was to warn drivers if their tyres are losing air

pressure. The final rule was published June 5, 2002.

Whilst in the US TPMS legislation grew from safety-related issues, The European Union (EU) legislators

are looking at TPMS as a way of reducing Carbon emissions and are presently considering mandatory

tyre pressure monitoring from an environmental stance.

2.1.1 TYPES OF TPMS

2.1.1.1 DIRECT TPMS

Direct TPMS use a small pressure sensor located inside each wheel. The sensor has a built-in transmitter

that broadcasts a radio signal to an external control unit. The control identifies the signal from each

wheel and keeps monitors the pressure. If the pressure drops below a predetermined threshold, the

module turns on a light or displays a message to warn the driver. The pressure sensors may be mounted

in the drop centre inside the wheel, or on the end of the valve stem inside the wheel. Stem mounted

pressure sensors use the valve stem as the antenna, so don't replace the standard valve caps with

anything else. Sensors attached to the rim drop centre are typically held in place by a long steel strap

that wraps all the way around the wheel.


4

FIGURE 2.1.1.1: DIRECT TPMS TYRE UNIT

2.1.1.2 INDIRECT TPMS

Indirect TPMS measures the pressure by monitoring the individual wheel speeds of the vehicles tyres.

Most indirect systems use the fact that an under-inflated tyre has a slightly smaller diameter than a

correctly inflated tire and therefore will rotate more times to cover a specific distance to detect under-

inflation. Such systems can detect under-inflation in up to three tyres simultaneously but not in all four

since the operating principle of these systems is to compare the different wheel speeds and if all four

tyres lose the same amount of air the relative change will be zero. Newer developments of indirect

TPMS can detect simultaneous under-inflation in all four tyres due to vibration analysis of individual

wheels or analysis of load shift effects during acceleration and cornering. Indirect TPMS is cheap and

easy to implement since most modern vehicles already have wheel speed sensors for anti-lock braking

systems and electronic stability control systems. The disadvantage is that they rely on user recalibration

when the tyres are changed or re-inflated. Not performing this recalibration may lead to potentially

dangerous, false or misleading alerts.

2.1.1.3 HYBRID TPMS

Hybrid TPMS combines the advantages of both direct and indirect TPMS. The accuracy of the direct

system and some of the cost savings of the indirect systems are evident in hybrid systems. The pressure

sensors are on two of the vehicles wheels instead of four, and the wheel speed sensors compare the

differences in speed to these wheels to detect a dip in pressure.


5

2.2 ZIGBEE OVERVIEW

ZigBee is a low-cost and low-power wireless networking standard that builds on the IEEE 802.15.4

standard which defines the physical (PHY) and media access control (MAC) layers. Zigbee defines the

application and security layer specifications hence, enabling interoperability between products of

different vendors.

FIGURE 2.1.1.1: ZIGBEE COMMUNICATION PROTOCOL STACK

Zigbee operates in the industrial, scientific and medical (ISM) bands which is 868MHz in Europe, 915MHz

in the USA and 2.4GHz in most parts of the world. Data rate ranges from 20 to 250kbit/s per channel

depending on band in use:

Frequency (MHz) 868 915 2400

Data Rate (Kbps) 20 40 250

Number of Channels 1 10 16

TABLE 2.1.1-1: ZIGBEE OPERATING FREQUENCIES

Zigbee radios use direct-sequence spread spectrum coding, which is managed by the digital stream into

the modulator. Binary Phase Shift Keying (BPSK) is used in the 868 and 915 MHz bands and Orthogonal

Quadrature Phase Shift Keying (O-QPSK) that transmits two bits per symbol is used in the 2.4 GHz band.

The raw, over-the-air data rate is 250 Kbit/s per channel in the 2.4 GHz band, 40 Kbit/s per channel in


6

the 915 MHz band, and 20 Kbit/s in the 868 MHz band. Transmission range is between 10 and 75 meters

(33 and 246 feet), although it is heavily dependent on the particular environment. The maximum output

power of the radios is generally 0 dBm (1 mW).

Furthermore, the basic channel access mode specified by IEEE 802.15.4-2003 is Carrier Sense, Multiple

Access/Collision Avoidance (CSMA/CA). That is, the nodes talk in the same way that people converse;

they briefly check to see that no one is talking before they start. There are three notable exceptions to

the use of CSMA. Beacons are sent on a fixed timing schedule, and do not use CSMA. Message

acknowledgements also do not use CSMA. Finally, devices in Beacon oriented networks that have low

latency real-time requirements may also use Guaranteed Time Slots (GTS), which by definition do not

use CSMA.

Zigbee has a mesh network architecture but also supports a star topology and cluster-tree topology. In a

mesh topology, each node may communicate with any other node within range, it gives many possible

routes through the network, hence, bad performing routes can be ignored. The star topology is very

simple, all nodes communicate with one central node. The cluster tree topology is a combination of star

and mesh topologies.

FIGURE 2.1.1.2: MESH NETWORK TOPOLOGY1

1 (Microchip Technology Inc, 2007)


7

FIGURE 2.1.1.3: STAR NETWORK TOPOLOGY2

FIGURE 2.1.1.4: CLUSTER TREE NETWORK TOPOLOGY3

2.2.1 ZIGBEE DEVICE TYPES

IEEE 802.15.4 defines two types of devices. These devices types are:

Full Function Device (FFD): offer most of the services available on an IEEE 802.15.4 based system,

typically powered from the Mains and usually remains powered up even when Idle.

Reduced Function Device (RFD) : has limited functionality, it is usually battery powered and typically

switched off when idle.

Listed in Table 2.2.1-1 are the three types of ZigBee protocol devices as they relate to the IEEE device

types.




8

Zigbee Protocol Device IEEE Device

Type Typical function

Coordinator FFD

One per network. Responsible for forming the network, allocating network addresses and may monitor and control other devices on the network

Router FFD

This is an optional device in the network, it extends the physical range of the network by way of allowing more nodes to join the network. It may also perform monitoring and control functions

End device RFD

Performs monitoring and control functions only

TABLE 2.2.1-1: RELATIONSHIP BETWEEN ZIGBEE & IEEE DEVICE TYPES4

2.2.2 ZIGBEE STACK ARCHITECTURE

The ZigBee stack architecture is made up of a set of blocks called layers. Each layer performs a specific

set of services for the layer above. The stack architecture is shown in Figure 2.2.2.1.

FIGURE 2.2.2.1: ZIGBEE PROTOCOL STACK ARCHITECTURE5



9

A data entity provides a data transmission service and a management entity provides all other services.

Each service entity exposes an interface to the upper layer through a service access point (SAP), and

each SAP supports a number of service primitives to achieve the required functionality. IEEE 802.15.4

standard defines the lower two layers: the physical (PHY) layer and the medium access control (MAC)

sub-layer. The ZigBee Alliance builds on this foundation by providing the network (NWK) layer and the

framework for the application layer, which includes the application support (APS) sub-layer, the ZigBee

device object (ZDO) and the manufacturer-defined application objects. The IEEE 802.15.4 MAC sub-layer

controls access to the radio channel. Its responsibilities may also include transmitting beacon frames,

synchronization and providing a reliable transmission mechanism. The responsibilities of the ZigBee

NWK layer include mechanisms used to join and leave a network, to apply security to frames and to

route frames to their intended destinations. In addition, the discovery and maintenance of routes

between devices devolve to the NWK layer. Also the discovery of one-hop neighbours and the storing of

relevant neighbour information are performed by the NWK layer. The NWK layer of a ZigBee coordinator

is responsible for starting a new network, when appropriate, and assigning addresses to newly

associated devices. The ZigBee application layer consists of the APS sub-layer, the ZDO, and the

manufacturer-defined application objects. The responsibilities of the APS sub-layer include maintaining

tables for binding, which is the ability to match two devices together based on their services and their

needs, and forwarding messages between bound devices. The responsibilities of the ZDO include

defining the role of the device within the network (e.g., ZigBee coordinator or end device), discovering

devices on the network and determining which application services they provide, initiating and/or

responding to binding requests and establishing a secure relationship between network devices. The

ZigBee stack is small in comparison to other wireless standards. For devices with limited capabilities, the

stack requires about 4Kb of the memory. Full implementation of the protocol stack takes less than 32Kb

of memory. The network coordinator may require extra RAM for a node devices database and for

transaction and pairing tables.6

2.2.3 ZIGBEE NETWORK FORMATION

5 (Meshnetics, 2008)

6 (Meshnetics, 2008)


10

A new ZigBee protocol network is first established by a ZigBee protocol coordinator. On start-up, a

ZigBee protocol coordinator searches for other ZigBee protocol coordinators operating on its allowed

channels. Based on the channel energy and number of networks found on each allowed channel, it

establishes its own network and selects a unique 16-bit PAN ID. Once a new network is established,

ZigBee protocol routers and end devices are allowed to join the network. Once a network is formed, it is

possible that due to the physical changes, more than one network may overlap and a PAN ID conflict

may arise. In that situation, a coordinator may initiate a PAN ID conflict resolution procedure and one of

the coordinators would change its PAN ID and/or channel. The affected coordinator would instruct all of

its child devices to make the necessary changes. ZigBee protocol devices store information about other

nodes in the network, including parent and child nodes, in an area of non-volatile memory called a

neighbour table. On power-up, if a child device determines through its neighbour table that it once was

part of a network, it may execute an orphan notification procedure to locate its previously associated

network. Devices that receive the orphan notification will check their neighbour tables and see if that

device is one of their children. If so, the parent device will inform the child device of its place in the

network. If orphan notification fails or the child device has no parent entry in its neighbour table, then it

will try to join the network as a new device. It will generate a list of potential parents and try to join an

existing network at the optimal depth.

2.2.4 ZIGBEE DATA TRANSMISSION

Data is transmitted in packets, Zigbee packets have a maximum size of 128 bytes including a 16-bit Cyclic

Redundancy Check (CRC) value. The 16-bit CRC value verifies the frame integrity. Zigbee uses two kinds

of addressing, there is a 64 bit IEEE address that can be compared to the IP address of a computer on a

network and a 16 bit short address. The short addresses are used once a network is setup, thus making a

total of 216, approximately 64000 nodes within one network possible.

In addition, IEEE 802.15.4 optionally uses an Acknowledged data transfer mechanism. With this method,

all frames with a special ACK flag set are Acknowledged by its receiver. This makes sure that a frame is in

fact delivered. If the frame is transmitted with an ACK flag set and the Acknowledgement is not received

within a certain timeout period, the transmitter will retry the transmission for a fixed number of times

before declaring an error. It is important to note that the reception of an Acknowledgement simply


11

indicates that a frame was properly received by the MAC layer. It does not, however, indicate that the

frame was processed correctly. It is possible that the MAC layer of the receiving node received and

Acknowledged a frame correctly, but due to the lack of processing resources, a frame might be

discarded by upper layers. As a result, the upper layers may require additional Acknowledgement

response.


12

3 PROJECT SPECIFICATION

3.1 FUNCTIONAL SPECIFICATION

1) A demonstrator wireless Direct Tyre Pressure Monitoring System should be

implemented utilizing the Zigbee communication protocol for its communication

requirements

a. The system must consist of a control unit acting as the Zigbee network coordinator

and also be responsible for controlling the other node(s) on the network.

b. The system must also consist of at least one tyre unit with a combined temperature

and pressure sensor attached responsible for measuring temperature and pressure

and also sending relevant data to the control unit.

c. The system must be capable of detecting a low tyre pressure and alert the user no

more than 10 minutes after the inflation pressure in one or more of the tyre units,

up to a total of four units, is equal to or less than 25 percent below a pre-defined

inflation pressure.

d. The system must continue to alert the user that the low tyre pressure exists as long

as the pressure in the tyre unit(s) is/are equal to or less than the pre-defined

pressure as stated in c above.

2) Assess the feasibility of practically using the implementation in TPMS focusing on its

Power consumption by estimating the life expectancy of a battery operated tyre unit in

the System.

3.2 ADDITIONAL FEATURES

There are a number of additional features possible using a Zigbee based system, these are discussed

briefly in the Conclusions section of this report.


13

4 DESIGN AND IMPLEMENTATION

4.1 OVERVIEW

The system was designed with strong emphasis placed on efficient use of battery power. The battery life

of the tyre unit has to last for a very long period of time, ideally, over 5 years. As such, some key

features of the system’s design are combining Zigbee’s low power specification and various power

saving techniques such as putting the tyre unit to sleep when it is not required to transmit any data and

also, powering down the tyre unit’s transmitter when performing only measurement related tasks.

4.2 ANATOMY OF ZIGBEE BASED WIRELESS TPMS

4.2.1 THE HARDWARE

4.2.1.1 MICROCHIP PICDEM Z DEMONSTRATION KIT

The PICDEM Z Demonstration Kit is designed to allow developers to evaluate and experiment with

Microchip solutions for the ZigBee protocol. The PICDEM Z Demonstration Kit provides two ZigBee

nodes (boards) each containing a Microchip PIC18F4620 Microcontroller Unit (MCU) running at a clock

frequency of 16MHz to create a simple two-node network. The kit also contains two Chipcon CC2420

Zigbee compliant transceivers attached to the Zigbee boards and CD containing Microchips Zigbee

protocol stack source code and Demonstration applications.


14

FIGURE 4.2.1.1: ZIGBEE DEMONSTRATION BOARD WITH ZIGBEE COMPLIANT TRANSCEIVER

4.2.1.2 FREESCALE COMBINED TEMPERATURE AND PRESSURE SENSOR

The combined temperature and pressure sensor was integrated into a fabricated board to form the

sensor board. The board was designed taking into consideration the need for testing, hence, each of the

I/O pins connected to the Sensor has a test pin attached so the signals on the pins can be monitored by

an oscilloscope, see 5.1 for more details on testing. The complete board and its schematic diagrams are

shown in Figure 4.2.1.2 and Figure 4.2.1.3 respectively:


15

FIGURE 4.2.1.2: SENSOR BOARD

FIGURE 4.2.1.3: SENSOR BOARD SCHEMATIC DIAGRAM

The Freescale Semiconductor MPXY8020 sensor is an 8-pin tyre monitoring sensor which is comprised of

a variable capacitance pressure sensing element, a temperature sensing element, and an interface

circuit with a wake-up feature all on a single chip. It is housed in a Super-Small Outline Package (SSOP).

Specifically designed for the low power consumption requirements of tire pressure monitoring systems.

The block diagram of the MPXY8020 series sensor is shown in Figure 4.2.1.4.


16

FIGURE 4.2.1.4 - MPXY8020 SERIES SENSOR BLOCK DIAGRAM7

The pressure sensor is a capacitive transducer constructed using surface micromachining while the

temperature sensor is constructed using a diffused resistor, and the interface circuit is integrated onto

the same die as the sensors using a standard silicon CMOS process.

The conditioning of the pressure signal begins with a capacitance to voltage conversion (C to V) followed

by a switched capacitor amplifier. This amplifier has adjustable offset and gain trimming. The offset and

gain are factory calibrated, with calibration values stored in the EEPROM trim register. This amplifier

also has temperature compensation circuits for both sensitivity and offset, which also are factory

adjusted using the EEPROM trim register.

The pressure is monitored by a voltage comparator, which compares the measured value against an 8-

bit threshold adjusted by a serial input. By adjusting the threshold and monitoring the state of the OUT

7 (Freescale Semiconductor, 2004)


17

pin the external device can check whether a low-pressure threshold has been crossed, or perform up to

8-bit A/D conversions.

The temperature is measured by a diffused resistor with a positive temperature coefficient driven by a

current source, thereby creating a voltage. The room temperature value of this voltage is factory

calibrated using the EEPROM trim register.

A two-channel multiplexer can route either the pressure or temperature signal to a sampling capacitor

that is monitored by a voltage comparator with variable threshold adjust, providing a digital output for

temperature. An internal low frequency, low power 5.4 kHz oscillator with a 14-stage divider provides a

periodic pulse to the OUT pin (divide by 16384 for 3 seconds). This pulse can be used to wake up an

external MCU to begin an interface with the device. An additional 10-stage divider will provide a pulse

every 52 minutes which can be used to reset an external MCU. The power consumption can be

controlled by several operational modes selected by external pins.

4.2.1.3 INTERFACING THE SENSOR BOARD WITH THE DEMO BOARD

The sensor board is interfaced with one of the demo boards being used as the Tyre unit via the pins on

the latter that are connected to PORTD of the Microcontroller on the demo board.


18

FIGURE 4.2.1.5: COMPLETE DEMONSTRATOR TYRE UNIT

The block diagram of the port mapping between the microcontroller and the sensor is shown in Figure

4.2.1.6.

FIGURE 4.2.1.6: MICROCONTROLLER AND SENSOR PORT MAPPING

PORTD of the microcontroller was chosen because it was one of the only ports not in use by any other

component on the PICDEM Z board. The pin functions of the Sensor are as follows:

The S0 and S1 pins are used to select the mode of operation, as shown in Table 1. They both contain

an internal Schmitt trigger as part of their input to improve noise immunity. These pins also have an

internal pull-down device to provide a low level when the pin is left unconnected. In addition, the S1

pin also serves the purpose of enabling factory trim and test of the device.


19

The DATA pin is the serial data in (SDI) function for setting the threshold of the voltage comparator.

The DATA pin contains an internal Schmitt trigger as part of its input to improve noise immunity.

The CLK pin is used to provide a clock used for loading and shifting data into the DATA pin. The data

on the DATA pin is clocked into a shift register on the rising edge of the CLK pin signal. The data is

transferred to the D/A Register on the eighth falling edge of the CLK pin. This protocol may be

handled by the SPI or SIOP serial I/O function found on some MCU devices. However, in relation to

this project, the SPI port on the demo board is being used by the Zigbee transceiver.

The RST pin is normally driven high and will be clocked low when an overflow is detected from total

clock divider driven by the LFO. This allows the RST pin to reset an external device such as a

Microcontroller. This pulse appears on the RST pin approximately every 52 minutes regardless of the

operating mode of the sensor. The pulse lasts for two cycles of the LFO oscillator. Since the RST pin

is clocked from the same divider string as the OUT pin, there will also be a pulse on the OUT pin

when the RST pin pulses every 52 minutes.

The OUT pin is driven by a voltage comparator whose output state depends on the level of the input

voltage on the sample capacitor and the level of an adjustable 8-bit threshold voltage. The threshold

is adjusted by shifting data bits into the D/A Register (DAR) via the DATA pin while clocking the CLK

pin. The timing of this data is shown in Figure 4.2.1.7. Data is transferred into the serial shift register

on the rising edge of the CLK pin. On the falling edge of the 8th clock the data in the serial shift

register is latched into the parallel DAR register. The DAR remains powered up whenever VDD is

present. The serial data is clocked into the DATA pin starting with the MSB first.

FIGURE 4.2.1.7: SENSOR DATA TIMING8

8 (Freescale Semiconductor, 2004)


20


21

4.2.2 THE SOFTWARE

4.2.2.1 ZIGBEE STACK

The Zigbee stack used was developed by Professor Robert Reese of the Department of Electrical and

Computer Engineering at Mississippi State University and provided free of charge. This was used as it

was a lot easier to comprehend in comparison with Microchip’s Zigbee protocol stack. The Zigbee stack

(see Figure 2.1.1.1) layers each have their own Finite State Machine (FSM) for keeping track of what it is

doing. FSM is a model of behaviour of a system composed of a predetermined number of states,

transitions between those states, and actions. The top level FSM function is called apsFSM() and has

to be called periodically to keep the stack running. All application level functions start with apl or aps

and are contained in the stack header file “apl.h”. The application functions are split into two categories:

1. Simple access functions (set/get): for modifying/retrieving internal stack data values. These calls are

finished upon return and access internal stack data structures.

2. Service calls: These trigger a chain of events within the stack regarding packet transmission. A stack

service call is not necessarily finished when the function returns; another function named

apsBusy() must be called while making repeated calls to apsFSM() to determine if the stack is

still busy with the last service call. Service calls cannot be overlapped – the stack can only be

executing one service call at a time. Any apl function that invokes a service does a check with

apsBusy() and will not allow service calls to be overlapped – this wastes some code space and

few instruction cycles for this check, but prevents the programming error of overlapped service

calls.

Service calls explicitly used in the TPMS application with their descriptions are shown in Table 4.2.2-1

below.

Stack Service Description Parameters

aplFormNetwork() Forms a network None aplJoinNetwork() Attempts to Join a

network None

apsFSM() Runs the stack’s finite state machine

None

apsBusy() Checks if the stack is None


22

TABLE 4.2.2-1: SERVICE CALLS EXPLICITLY USED IN THE APPLICATION

4.2.2.2 TPMS APPLICATION

The TPMS application was developed using the C programming language. The Microchip MPLAB

integrated development environment (IDE) version 7.60 was also used in developing the application.

The Compiler used to compile the application’s source code was the Microchip MPLAB C18 compiler.

Source files for the Control unit and the Tyre unit are the same but pre-processor definitions were used

to perform selective compilation of the source code for both units. So in actual fact, some of the

compiled code for both units are different. The definitions that distinguish the two units are

LRWPAN_COORDINATOR for the Control unit and LRWPAN_RFD for the Tyre unit. So in the

configuration file of the IDE, if either of the definitions are used, the processor will compile codes below

where it finds #ifdef LRWPAN_COORDINATOR or #ifdef LRWPAN_RFD and stops when it

sees an #endif. All other codes that do not fall within these definitions are compiled for both units.

This also made modifying and referencing modes of operation easy throughout the code as enumerated

data types were used to store the variables for different modes. Declaration of the modes are shown

below. This was common code shared by the Control and Tyre Units, with the difference being in their

implementation when the modes are detected.

enum tpms_state{

parking = 1,

driving

};

busy or not aplGetStatus() None halInit() initialize the HAL

layer None

evbInit() initialize the evaluation board

None

aplInit() initialize the rest of the stack

None

aplSendMSG(arguments

omitted)

Sends messages See 4.2.2.2.1 below


23

CODE 1: TPMS MODE DECLARATION

4.2.2.2.1 SENDING MESSAGES

The aplSendMSG() function is used to send a packet from a user application; the arguments and their

data types are shown below:

aplSendMSG (BYTE dstMode, LADDR_UNION *dstADDR, BYTE dstEP,

BYTE cluster, BYTE srcEP, BYTE* pload, BYTE plen, BYTE tsn,

BYTE reqack)

CODE 2: STACK FUNCTION TO SEND MESSAGE

BYTE dstMode – specifies addressing mode of the destination address (dstADDR). Can be one of

three values: APS_DSTMODE_NONE(no destination address specified, used for indirect messages),

APS_DSTMODE_SHORT (destination address is a short address), or APS_DSTMODE_LONG

(destination address is a long address).

LADDR_UNION *dstADDR – a pointer to a destination address – the LADDR_UNION type is

defined in lrwpan_common_types.h and can contain either a short address (2 bytes) or long

address.

BYTE dstEP – destination endpoint (not used if indirect message)

BYTE cluster – cluster identifier (only used in indirect messages)

BYTE srcEP – source endpoint of this message

BYTE* pload – pointer to a buffer containing the user payload

BYTE plen – the number of bytes in the user payload

BYTE tsn – the transaction sequence number for this message, can be manually generated or

have the stack generate one by calling the apsGenTSN() function

BYTE reqack – if non-zero, then request an APS ACK for this message.

Figure 4.2.2.1 and Figure 4.2.2.2 below shows the user payload packet as sent by the Control and Tyre

units respectively.


24

0 Redundant data 7 8 Mode Command 15

8 Bits 8 Bits

FIGURE 4.2.2.1: CONTROL UNIT USER PAYLOAD PACKET

0 Temperature 7 8 Pressure 15 16 Current Mode 23 24 Status 31

8 Bits 8 Bits 8 Bits 8 Bits

FIGURE 4.2.2.2: TYRE UNIT USER PAYLOAD PACKET

4.2.2.2.2 RECEIVING MESSAGES

Whenever the stack receives a message for the current node, the user callback function

usrRxPacketCallback() in the application code is called. APL access functions can be used to

retrieve parts of the packet, these access functions are:

aplGetRxDstEp() – returns destination endpoint

aplGetRxCluster()– returns the cluster ID

aplGetRxSrcEp()– returns the source endpoint

aplGetRxSrcSADDR()– returns the short address of the source endpoint

aplGetRxMsgLen()– returns the message length

aplGetRxMsgData()– returns a BYTE pointer to the message data

aplGetRxRSSI()– returns the received signal strength of the returned message (the RSSI

value is a value between 0 and 255, where higher means a stronger signal).

The usrRxPacketCallback() function processes the data in the user payload, saves it in some

user data structure, and sets a flag that indicates to the TPMS application that data has been received.

The pointer returned by aplGetRxMsgData() is in the stack heap and this memory is immediately

freed on exit of usrRxPacketCallback(), so the application saves this data in a different location

as it may get overwritten by the next received packet. The usrRxPacketCallback() function

returns a status value of type LRWPAN_STATUS_ENUM; a value of LRWPAN_STATUS_SUCCESS indicates

success. Any other value indicates failure, and if an APS acknowledgement was requested for this

packet, then the APS acknowledgement will not be returned.


25

4.2.2.2.3 THE CONTROL UNIT

The control unit on power up or reset initializes its hardware by calling the halInit(), evbInit()

and aplInit() functions. It then forms the Zigbee network by calling the aplFormNetwork()

stack function. After all initialization and network formation is completed, the unit then runs the stack’s

FSM by calling the apsFSM() which listens for incoming data and also sends outbound data. When a

node, in this case a tyre unit joins the network, the control unit then assigns it a short address and starts

executing one of its modes of operation as listed in 4.2.2.2.3.1 :

4.2.2.2.3.1 MODES OF OPERATION

1. DRIVING

In driving mode, the Control unit receives data from the tyre unit at a rate that is determined by the

tyre unit. It compares the received pressure with a predefined recommended pressure and alerts the

user if the pressure has fallen below the requirement for TPMS. It then continues requesting more

pressure data until the pressure falls within the bounds of acceptable limits. This mode implements

the core functionality required by the projects specification. This mode is intended for when the

vehicle is in motion. Figure 4.2.2.3 and Figure 6.1.2.15 describes the Control Unit’s operation in this

mode

FIGURE 4.2.2.3: CONTROL UNIT DRIVING MODE FLOWCHART


26

2. PARKING

In this mode, the control unit just continues running the stack’s FSM waiting for incoming messages

from the tyre unit. This mode is intended for when the vehicle is stationary.

FIGURE 4.2.2.4: CONTROL UNIT PARKING MODE FLOW CHART

4.2.2.2.4 THE TYRE UNIT

The main function of the tyre unit is to measure the temperature and pressure, perform a comparison

against its previous values and decide whether to send data or not to the control unit.

4.2.2.2.4.1 MODES OF OPERATION

1. DRIVING

In Driving mode, the tyre unit constantly measures temperature and pressure and compares the

current value with its previous value. If the current value remains the same or does not change by a

predefine percentage, the unit does not transmit any data, rather, it goes to sleep until the OUT pin

of the sensor wakes the Microcontroller on the Tyre unit. However, if it changes above or below the

predefined threshold, it then sends the data to the control unit, runs the stack FSM to listen for data,

then goes to sleep.


27

FIGURE 4.2.2.5: TYRE UNIT DRIVING MODE FLOWCHART

2. PARKING

In parking mode, the tyre unit is put to sleep and the Stack operates at minimum capability only

enough to wake up the microcontroller through the SPI port connected to its antenna. It comes out of

sleep on receipt of a message from the controller unit as it stimulates the antenna which produces

and interrupt on the microcontroller. This mode is at the heart of the systems power saving scheme

because the tyre unit consumes very little power.

FIGURE 4.2.2.6: TYRE UNIT PARKING MODE FLOWCHART


28

4.2.2.2.4.2 MEASURING TEMPERATURE & PRESSURE

Shown in Table 4.2.2-2 are the various operating modes of the MPXY8020 sensor. To measure pressure

or the temperature, after configuring the PORTD pin directions on the Microcontroller, the Sensor is first

put into RESET by driving the pins connected to the S1 and S0 low. The Serial Data counter on the sensor

is then put in a known state by toggling either of the S1 and S0 pins high and then low, in this case, the

S1 pin is toggled. The next step is to put the sensor on standby before performing any measurement.

S1 S0 Operating Mode Pressure Measure System

Temperature Measurement

System

A/D Output Comparator

LFO Serial Data

Counter

0 0 Standby/Reset OFF OFF OFF ON ACTIVE

0 1 Measure Pressure ON OFF OFF ON RESET

1 0 Measure

Temperature OFF ON OFF ON RESET

1 1 Output Read ON OFF ON ON ACTIVE

TABLE 4.2.2-2: SENSOR OPERATING MODES

Pressure and temperature are measured by performing an analogue to digital conversion using a

successive approximation algorithm. This is accomplished after setting the S1 and S0 pins on the sensor

to measure pressure or temperature, then writing 8 bits to the DATA pin while clocking the data using

the CLK pin on the sensor. On the 8th clock pulse, the value of the OUT pin is captured and used to

perform another round of approximation. The sequence is repeated 8 times to get an 8 bit value of

temperature or pressure. Figure 4.2.2.8 shows the pulse from the Microcontroller to the sensor pins and

the values returned by the sensor after the successive approximation. After completing pressure or

temperature measurement, the sensor is put on standby. The code used to perform these operations

can be found in the appendix. The flowchart for the successive approximation is shown in Figure 4.2.2.7.

A single successive approximation is achieved in the application using 4 variables with bitwise

manipulation techniques at the heart of its operation. The variables and their uses are:

count which is an integer value used to keep track of the number of bits that has been read

from the sensor so far, it is initially 8 and after 8 bits of data is written to the sensor and the


29

state of the out pin has been examined, it is decremented by 1 until it reaches 0 indicating that

an 8 bit value has been obtained from the sensor.

temp is a variable updated each time a bit is examined on the sensor to form an approximation

of what the application believes that sensor has stored.

guess is the test data written to the sensor and is equal to temp at the end of an approximation

lookup is an 8-bit variable used to construct the 8 bit result using bitwise masking techniques to

set the bits of temp to correspond to the bits read each time an 8 bit value is written to the

sensor’s DATA pin and the state of the OUT pin is examined. As an example, starting off with

temp = 00000000 (0) and lookup = 10000000 indicating we are examining bit number 8 of the

sensors stored value, assuming the sensor has 10110000(176) stored in it, writing

10000000(128) to the sensor’s data pin should result in the OUT pin of the Sensor producing a

logic 1 indicating that it has a higher value stored in it than that written to it (176 is greater than

128). The logic 1 received would be used as a condition to set the first bit of temp to 1 as

illustrated when Count = 8 and OUT = 1 in Table 4.2.2-3. The general operation is that whenever

OUT = 1, perform lookup ANDed with 11111111, when OUT = 0, perform lookup ANDed with

00000000, then OR the result with the current value of temp, rotate temp 1 bit to the right, for

next approximation and repeat the successive approximation. Table 4.2.2-3 shows the operation

for every value of count and lookup and what OUT would be in each case and how this value is

used to reconstruct the data using lookup and temp showing previous and current values of

temp.

Count = 8, OUT = 1 Count = 7 , OUT = 0 Count = 6, OUT = 1 Count = 5, OUT = 1

𝑙𝑜𝑜𝑘𝑢𝑝 = 𝟏0000000 & 11111111 𝑟𝑒𝑠𝑢𝑙𝑡 = 𝟏0000000 𝑡𝑒𝑚𝑝 = 𝑜𝑟10000000 𝑡𝑒𝑚𝑝 = 𝟏0000000

𝑙𝑜𝑜𝑘𝑢𝑝 = 0𝟏000000 & 00000000 𝑟𝑒𝑠𝑢𝑙𝑡 = 0𝟎000000 𝑡𝑒𝑚𝑝 = 𝑜𝑟10000000 𝑡𝑒𝑚𝑝 = 1𝟎000000

𝑙𝑜𝑜𝑘𝑢𝑝 = 00𝟏00000 & 11111111 𝑟𝑒𝑠𝑢𝑙𝑡 = 00𝟏00000 𝑡𝑒𝑚𝑝 = 𝑜𝑟10000000 𝑡𝑒𝑚𝑝 = 10𝟏00000

𝑙𝑜𝑜𝑘𝑢𝑝 = 000𝟏0000 & 11111111 𝑟𝑒𝑠𝑢𝑙𝑡 = 000𝟎0000 𝑡𝑒𝑚𝑝 = 𝑜𝑟10100000 𝑡𝑒𝑚𝑝 = 101𝟏0000

Count = 4, OUT = 0 Count = 3, OUT = 0 Count = 2, OUT = 0 Count = 1, OUT = 0




𝑙𝑜𝑜𝑘𝑢𝑝 = 0000000𝟏 & 00000000 𝑟𝑒𝑠𝑢𝑙𝑡 = 0000000𝟎 𝑡𝑒𝑚𝑝 = 𝑜𝑟10110000 𝑡𝑒𝑚𝑝 = 1011000𝟎

TABLE 4.2.2-3: SUCCESSIVE APPROXIMATION EXAMPLE OPERATION


30

Note: The bits in bold fonts emphasises the current position of the bit being manipulated

When count = 0, this means that an 8-bit value has been formed also indicated by when lookup

= 00000000.

FIGURE 4.2.2.7: SUCCESSIVE APPROXIMATION ROUTINE FLOWCHART


31

FIGURE 4.2.2.8: SENSOR WAVEFORM DURING MEASUREMENT

4.2.2.2.4.3 BUILDING THE APPLICATION

The project directory must be copied to the top level directory of the computer, i.e. C:\. All project files

are for the PICDEMZ target are located at C:\msstate_lrwpan\obj\compiletest\mcc18_picdemz. This

contains a file called ping_pong.c and is the main TPMS application source code. Steps to run the TPMS

application are:

1. Open MPLAB, and open the project named compiletest_coord.mcp project.

2. Use Project → Clean to remove any pre-existing object files.

3. Use Project → Build Options → Project and click on the MPLAB C18 target. The result is as shown in

Figure 9.3.2.1. Replace the aExtendedAddress_B7 (MSB) through aExtendedAddress_B0 (LSB) Macro

Definitions with the long address values of the PICDEMZ node that will serve as the coordinator.

4. Use Project → Make to build the application.

5. Program the PICDEMZ with the resulting hex file. When the board is powered up, you should see the

TPMS welcome message appear if you have a HyperTerminal window connected to the PICDEMZ node

at 57600 baud.


32

6. Close this project, and open the project named compiletest_rfd1.mcp – this project will be used to

program the second PICDEMZ board as an RFD. Repeat steps 2 through 5 to specify this node’s long

address, build the application and program the PICDEMZ node with your application.

7. When the RFD board is powered up, you should see its RA0 LED turn on indicating that the node

connected to the network formed by the coordinator (this assumes the coordinator node is powered on

first). Both boards after this will then operate as described in 4.2.2.2.4.3.

4.2.2.2.5 RUNNING THE TPMS APPLICATION

4.2.2.2.5.1 CONTROL UNIT START UP SEQUENCE

The control unit starts off by forming the Zigbee network and going into parking mode as described in

4.2.2.2.4.1. It then waiting for tyre unit(s) to join. When a unit joins the network, by default, it executes

parking mode unless the Control unit explicitly changes its mode. The flowchart of the start up operation

is shown in Figure 4.2.2.9

FIGURE 4.2.2.9: CONTROL UNIT STARTUP FLOWCHART


33

4.2.2.2.5.2 TYRE UNIT START UP SEQUENCE

The tyre unit on power up or reset attempts to join a network by calling the stack function

aplJoinNetwork(), if it fails, it keeps on trying and eventually resets itself. On successfully joining

the network, it runs the stack FSM which listens for inbound data. The flowchart below describes the

initial operation of the Tyre unit:

FIGURE 4.2.2.10: TYRE UNIT STARTUP OPERATION FLOWCHART

4.2.2.2.5.3 CONTROL UNIT MODE CHANGE AND MESSAGE RECEIPT

On receiving a message from the tyre unit, the control unit extracts the relevant information from the

user payload and uses the pressure information to determine if the pressure is still within acceptable

limits by comparing it with the previously received value, if not, it alerts the user. It also uses the Mode

received to determine if the Tyre unit’s mode is in sync with its own mode, if not, it forces a mode

change by sending a command to put the Tyre unit in the same mode as the Control unit. When the

control unit detects a change in the vehicles mode, in this case, if the RB4 or RB5 buttons are toggled, it

then changes its current mode of execution to that which is selected. The Control unit then runs the


34

Stack’s FSM to listen for incoming data. The sequence of operations that ensue are shown in Figure

4.2.2.11.

FIGURE 4.2.2.11: CONTROL UNIT MODE CHANGE AND MESSAGE RECEIPT FLOWCHART

4.2.2.2.5.4 TYRE UNIT MODE CHANGE AND MESSAGE RECEIPT

On receiving a message from the Control unit, the tyre unit extracts the relevant information from the

user payload and uses the Mode information to determine the next mode to execute. The message

received contains information as shown in Figure 4.2.2.1. The sequence of operations that ensue are:


35

FIGURE 4.2.2.12: TYRE UNIT MESSAGE RECEIPT FLOWCHART

4.3 CHALLENGES FACED

4.3.1 UNDERSTANDING THE ZIGBEE STACK IMPLEMENTATION

Understanding the operation of the Zigbee stack was a key to the success in the project. At the start of

the project this proved challenging as the Microchip Zigbee stack was used and was in my view not

comprehensive from reading just the datasheet alone. The example applications code available with the

stack did not reveal a lot as to how messages were sent and received. These were core features required

by the TPMS application in order to meet the project specification. However, after extensive research

into other available Zigbee stacks, a more comprehensive educational and research purpose built stack

was discovered and used as specified in 4.2.2.1.


36

4.3.2 PROGRAMMING IN C

At the start of the project, my knowledge of the C programming language was minimal. The system had

to be programmed in C because the MCU on the Demonstration boards were only compatible with C

and Assembly language. C was chosen because I had a basic understanding of the language and also the

Zigbee stack was also written in the language. This challenge was eventually overcome by continuously

accessing online resources and Text books on the C programming language whilst progressing with the

project.


37

5 TESTING AND RESULT VERIFICATION

5.1 TESTING THE MPXY8020 SENSOR

5.1.1 APPARATUS

A Computer Running Windows XP and Microsoft HyperTerminal Program

1 Microchip PICDEM Z board with Sensor board attached as Tyre Unit

A Serial Port Cable

A 9v Power Supply

A 3v Power Supply

An Agilent 54622D Mixed Signal Oscilloscope

5.1.2 TECHNIQUE

In testing the Sensor, the 9v power supply was connected to the Tyre Unit board. The 3v power supply

was connected to the Sensor. Power could not be drawn from the PICDEM Z board due to a voltage

regulator on the latter. The Unit was connected to the Serial Port of the Computer using the serial port

cable. The test pins of the Sensor were connected to the Oscilloscope’s signal probes. A logical view of

the connection is shown below. The TPMS application was run and calling just the routine to measure

pressure and temperature, the software’s output was observed on the HyperTerminal window showing

the temperature and pressure readings.


38

FIGURE 5.1.2.1: TEST SETUP FOR THE MPXY8020 SENSOR

5.1.3 RESULTS

The datasheet for the MPXY8020 specifies the following control timings as shown in the table below:

Parameter Symbol Minimum Typical Maximum Units

Wake Up Pulse

Pulse Timing Pulse Width

tWAKE tWPW

- -

16384 2

- -

LFO clocks

Reset Pulse

Pulse Timing Pulse Width

tRESET tRPW

- -

16,777,216 2

- -

LFO clocks

Minimum Setup Time (DATA edge to CLK rise)

tSETUP 100 - - nSec

Minimum Hold Time (CLK rise to DATA change)

tHOLD 100 - - nSec

Measurement Response Time

Temperature Pressure

tTMEAS tPMEAS

- -

200 500

- -

µSec

Read Response Time tREAD - 50 100 µSec

Sample Capacitor Discharge Time From initial full scale D/A count (255) to drop 2 counts (253)

tSH 20 - - mSec

TABLE 5.1.3-1: MPXY8020 SENSOR CONTROL TIMING

The control timings on the sensor critical to the measurement of pressure and temperature directly

influenced by the MCU are tSETUP , tHOLD, tTMEAS, tPMEAS, tREAD and tSH. From observing the waveforms


39

generated as shown in Figure 6.1.2.1 to Figure 6.1.2.4 by the Sensor and the Tyre unit while running the

TPMS Application, the following results were obtained:

Parameter Value

Achieved Recommended Acceptable

tSETUP 120 µSec 100nSec Yes

tHOLD 130 µSec 100nSec Yes

tTMEAS tPMEAS

250 µSec 510 µSec

200 µSec 500 µSec

Yes

Maximum D/A conversion completion time before tSH

16 mSec 20mSec Yes

FIGURE 5.1.3.1: ACHIEVED CONTROL TIMING RESULTS FOR MPXY8020 SENSOR

In the waveforms in 9.1, the Sensor Pins are labelled on the vertical axis and the dotted vertical lines on

the waveform shows the start and end points of the measurement. The ∆X parameter shows the actual

value of the measurement.

5.2 TESTING THE ZIGBEE COMMUNICATION LINK

5.2.1 APPARATUS

2 Computers Running Windows XP and Microsoft HyperTerminal Program

1 Microchip PICDEM Z board as Control Unit

1 Microchip PICDEM Z board with Sensor board attached as Tyre Unit

2 Serial Port Cables

2 9v Power Supply

1 3v Power Supply

5.2.2 TECHNIQUE

In testing the Zigbee communication Link, the 9v power supplies were connected to the Control Unit and

the Tyre Unit board. The 3v power supply was connected to the Sensor because it could not draw power

from the PICDEM Z board due to a voltage regulator on the latter. Both Units were connected to the


40

Serial Port of two different Computers using the 2 serial port cables. Their outputs were monitored using

Microsoft’s HyperTerminal program. A logical view of the setup is as shown below:

FIGURE 5.2.2.1: ZIGBEE COMMUNICATION LINK TEST SET UP

5.2.3 RESULTS

When both units were switched on, at first the Tyre Unit was unable to join the network. It continued to

retry and as soon as the Network was formed by the Control Unit, the Tyre Unit joined the network and

established a communication link with the Control Unit. The control unit and the Tyre Unit both output

the join notification on the HyperTerminal window. The figures below show the results of the test.

5.3 TESTING THE SYSTEM’S OVERALL FUNCTIONALITY

5.3.1 APPARATUS

The apparatus used was the same as for Testing the Zigbee Communication Link. See 5.2.1, with the

addition of an Agilent 54622D Mixed Signal Oscilloscope.


41

5.3.2 TECHNIQUE

The technique used was the same as for Testing the Zigbee Communication Link. See 5.2.1, with the

addition of the Oscilloscope’s signal probes connected to the test pins on the sensor. Also, the RB4

button on the Tyre Unit was configured to initiate sending a message when the unit was in Driving mode

and when in Parking mode, wakes the MCU to perform a measurement, comparison and then send the

data to the Control Unit if required. Both units were configured to go into parking mode on power up.

The RB4 button on the Control Unit was configured to change its mode and that of the tyre Unit to

driving mode by sending a command to the tyre unit via the wireless link. The RB5 button on the Control

Unit was also configured to change its mode and that of the tyre Unit to parking using the same

technique as for driving. These buttons are as shown in Figure 5.3.2.1.

FIGURE 5.3.2.1: CONTROL UNIT BUTTONS

5.3.3 RESULTS

The results obtained during network formation and joining by the Control and Tyre Unites respectively

were exactly the same as those for Testing the Zigbee Communication Link, See 5.2.3 . Both Units

started executing parking mode as soon as the Tyre unit joined the network. On receiving the mode

command, the Sensor operated as described in section 4.2.2.2.4.3 giving results as described below.

5.3.3.1 PARKING MODE

The Control Unit, on changing mode to parking, outputted the data intended to be sent along with other

information and sent the command to the tyre unit as shown in Figure 6.1.2.9. On receiving the Parking

mode command, the Tyre unit acknowledged the command by outputting text on the HyperTerminal

window indicating the receipt of the command, and also informing that it is putting itself to sleep as


42

shown in Figure 6.1.2.10. When, Tyre unit was asleep, pressing the RB4 button on the Control Unit woke

the up the tyre unit as shown in Figure 6.1.2.11.

5.3.3.2 DRIVING MODE

The Control Unit, on changing mode to driving, outputted the command intended to be sent along with

other information and sent the command to the tyre unit. On receiving the driving mode command, the

Tyre unit acknowledged the command by outputting text on the HyperTerminal window indicating the

receipt of the command, and also informing that it was now operating in driving mode as shown in

5.4 KNOWN ISSUES

5.4.1 SENSOR

The time taken to complete a single 8-bit successive approximation was longer that typical hence, the

Sensor pressure and temperature measurements produce unsatisfactory results. Although, the control

timings achieved fits within the specification of the Sensor’s datasheet, the Sensor was non-responsive

to changes in temperature and pressure. The most likely cause is the fact that the clock signal being

used to shift data into the Sensor is being generated in software, hence is subject to latencies caused by

the MCU carrying out calculations. A possible solution is generating the clock pulse for shifting data into

the Sensor from the MCUs hardware Timer and on completion, using an interrupt generated on

completing the data transfer to check the output of the Sensor. Another possible solution is increasing

the clock frequency of the MCU so it can perform the transfer faster.

Theoretically, the System would be able to respond to a low pressure on the tyre unit if it goes below

25% of a pre defined pressure in less than 10 minutes as required by the Projects Functional

Specification. However, due to the non-responsiveness of the Sensor to temperature or pressure

changes, the system could not be tested to see how it reacts to these changes. The issue with the Sensor

will be further looked into and if satisfactory results are still not obtained, a different approach will be

taken to test this feature such as using a potentiometer interfaced to the tyre unit to demonstrate

increasing and decreasing the pressure and observing how the system reacts to it in driving mode.


43

Another approach is to design and program a MCU to mimic the expected operation of the Sensor and

allow for the reading to be varied in real-time.

5.5 ANALYSIS

Assuming the Sensor, MCU and Zigbee Transceiver share a 3V battery source

PIC18F4620 Modes Max Current drawn in Mode

µA

Run 3000

Sleep 2

TABLE 5.4.1-1: PIC18F4620 CURRENT CONSUMPTION

Sensor Mode Max Current drawn

µA

Typical time Per 8 Bit Successive Approximation

ms

Standby Mode 1.5 -

Output Read Mode 400 3.15

Measure Temperature Mode 400 3.15

Measure Pressure Mode 1400 3.15

TABLE 5.4.1-2: MPXY8020 SENSOR CURRENT CONSUMPTION

TABLE 5.4.1-3: CC2420 ZIGBEE TRANCEIVER CURRENT CONSUMPTION

∴ Total Current Consumption Per Measurement of Temperature

= Output Read Mode + Measure Temperature Mode

= 400 + 400 = 𝟖𝟎𝟎𝝁𝑨 𝒑𝒆𝒓 𝒎𝒆𝒂𝒔𝒖𝒓𝒆𝒎𝒆𝒏𝒕

Current Consumption for Pressure Measurement = Output Read Mode + Measure Temperature Mode

= 400 + 1400 = 𝟏𝟖𝟎𝟎𝝁𝑨 𝒑𝒆𝒓 𝒎𝒆𝒂𝒔𝒖𝒓𝒆𝒎𝒆𝒏𝒕

In driving mode,

Transmitter Current

Consumption

Max Current drawn in Mode

µA

Receive 18800

Power Down 20

Transmit at 0dBm 17400


44

measure temperature +transmitter idle+ MCU run = 800µA+20µA +3000µA = 3.820mA

measure pressure +transmitter idle + MCU run = 1800µA+20µA +3000µA = 4.82mA

Send/Sleep operation turns transmitter to transmit/idle and sensor to standby

If idle:

MCU sleep + Transmitter Idle + Sensor standby = 2 µA+20 µA+1.5 µA = 23.5 µA

Else If send:

MCU Run+ Transmitter send + Sensor standby = 3000 µA+17400 µA+1.5 µA = 20.40 mA

Else if Tyre unit receives a command:

MCU run + Transmitter Receive + Sensor Standby = 3000µA+18800µA+1.5 µA = 21.80mA

Putting it all together, current consumption :

In driving mode when transmitting data = 4820+3820+20400 = 29.04mA

In driving mode without transmitting data = 4820+3820+23.5 = 8.66mA

On receiving a command in driving mode = 4820+3820+21800 = 30.44mA

In Parking mode, consumption = 20+2+1.5 = 23.50µA

On receiving a command in Parking mode = 18800+3000+1.5 = 21.80mA

When the tyre unit is in Parking mode, it does not perform any measurements, the Sensor and

MCU are in Standby and Sleep mode respectively and the transmitter is powered down. The

MCU wakes up every three seconds, performs one 8-bit successive approximation of pressure

and temperature. It does not send until there is a significant change in pressure. Thus,

𝑅𝑢𝑛 𝐶𝑦𝑐𝑙𝑒 𝑓𝑜𝑟 𝑀𝐶𝑈 𝑎𝑛𝑑 𝑆𝑒𝑛𝑠𝑜𝑟 𝑖𝑛 1𝑕𝑟 = 3600𝑠 = (3𝑠 + 0.00315𝑠) × 𝑥

𝑥 =3600

3 + 0.00315= 1198.74 𝑐𝑦𝑐𝑙𝑒𝑠

𝑅𝑢𝑛 𝐶𝑦𝑐𝑙𝑒 𝑓𝑜𝑟 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑟,𝑀𝐶𝑈 𝑎𝑛𝑑 𝑆𝑒𝑛𝑠𝑜𝑟 𝑖𝑛 1𝑕𝑟 𝑖𝑛 𝑃𝑎𝑟𝑘𝑖𝑛𝑔 𝑚𝑜𝑑𝑒 = 3600𝑠

= 1𝑠 × 𝑥

𝑥 = 3600𝑐𝑦𝑐𝑙𝑒𝑠


45

𝑅𝑢𝑛 𝐶𝑦𝑐𝑙𝑒 𝑓𝑜𝑟 𝑀𝐶𝑈 𝑎𝑛𝑑 𝑇𝑟𝑎𝑛𝑐𝑒𝑖𝑣𝑒𝑟 𝑖𝑛 1𝑕𝑟 𝑎𝑠𝑠𝑢𝑚𝑖𝑛𝑔 𝑎 𝑠𝑖𝑔𝑛𝑖𝑓𝑖𝑐𝑎𝑛𝑡 𝑐𝑕𝑎𝑛𝑔𝑒 𝑖𝑛 𝑝𝑟𝑒𝑠𝑠𝑢𝑟𝑒 𝑜𝑐𝑐𝑢𝑟𝑠

50 𝑡𝑖𝑚𝑒𝑠 𝑖𝑛 𝑎𝑛 𝑕𝑜𝑢𝑟 𝑎𝑛𝑑 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑟

𝑖𝑠 𝑠𝑤𝑖𝑡𝑐𝑕𝑒𝑑 𝑜𝑛 𝑓𝑜𝑟 10𝑚𝑠 𝑒𝑎𝑐𝑕 𝑡𝑖𝑚𝑒 =3600

3600

50 + 0.001

= 49.99 𝑐𝑦𝑐𝑙𝑒𝑠

𝑇𝑕𝑒 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑑𝑢𝑡𝑦 𝐶𝑦𝑐𝑙𝑒 𝑓𝑜𝑟 𝑡𝑕𝑒 𝑀𝐶𝑈 𝑎𝑛𝑑 𝑠𝑒𝑛𝑠𝑜𝑟 =1198.74 × 0.00315

3600× 100

= 0.104%

𝑇𝑕𝑒 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑑𝑢𝑡𝑦 𝐶𝑦𝑐𝑙𝑒 𝑓𝑜𝑟 𝑡𝑕𝑒 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑟 𝑎𝑛𝑑 𝑀𝐶𝑈 = 49.99 × 0.001

3600× 100

= 0.0014%

𝑇𝑕𝑒 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑑𝑢𝑡𝑦 𝐶𝑦𝑐𝑙𝑒 𝑓𝑜𝑟 𝑡𝑕𝑒 𝑆𝑒𝑛𝑠𝑜𝑟,𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑟 𝑎𝑛𝑑 𝑀𝐶𝑈 𝑖𝑛 𝑝𝑎𝑟𝑘𝑖𝑛𝑔 𝑚𝑜𝑑𝑒

= 3600

3600× 100 = 100%

𝐵𝑎𝑡𝑡𝑒𝑟𝑦 𝑙𝑖𝑓𝑒𝑡𝑖𝑚𝑒 𝑇 𝑕𝑟𝑠 =𝐶𝑡

𝐼𝑛, 9

𝑤𝑕𝑒𝑟𝑒 𝐶 = 𝑡𝑕𝑒𝑜𝑟𝑒𝑡𝑖𝑐𝑎𝑙 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦 𝑖𝑛 𝐴𝑚𝑝𝑠 − 𝑕𝑜𝑢𝑟 𝐴𝑕

𝑡 = 𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑎𝑔𝑒 𝑑𝑢𝑡𝑦 𝑐𝑦𝑐𝑙𝑒 𝑜𝑓 𝑡𝑕𝑒 𝑏𝑎𝑡𝑡𝑒𝑟𝑦

𝐼 = 𝑐𝑢𝑟𝑟𝑒𝑛𝑡 𝑑𝑟𝑎𝑤𝑛

𝑛 = 𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝑜𝑓 𝑕𝑜𝑤 𝑤𝑒𝑙𝑙 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑕𝑜𝑙𝑑𝑠 𝑢𝑝 𝑢𝑛𝑑𝑒𝑟 𝑕𝑖𝑔𝑕 𝑟𝑎𝑡𝑒𝑠 𝑜𝑓 𝑑𝑖𝑠𝑐𝑕𝑎𝑔𝑒

𝑀𝑎𝑛𝑢𝑓𝑎𝑐𝑡𝑢𝑟𝑒𝑟 𝑠𝑝𝑒𝑐𝑖𝑓𝑖𝑐

𝑛 = 1.2 𝑓𝑜𝑟 𝑚𝑜𝑠𝑡 𝑙𝑖𝑡𝑕𝑖𝑢𝑚 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑐𝑒𝑙𝑙𝑠 𝑤𝑖𝑡𝑕 𝐶 = 300𝑚𝐴𝑕

∴ 𝐼𝑛 𝐷𝑟𝑖𝑣𝑖𝑛𝑔 𝑚𝑜𝑑𝑒 𝑤𝑕𝑖𝑙𝑒 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑖𝑛𝑔, 𝑇 =0.3

(29.04 × 10−3)1.2×

100

0.104 + 0.0014=

20.97 × 948.77 = 19892.4 𝑕𝑟𝑠 ≈ 𝟐 𝒚𝒆𝒂𝒓𝒔

𝐼𝑛 𝐷𝑟𝑖𝑣𝑖𝑛𝑔 𝑚𝑜𝑑𝑒,𝑤𝑖𝑡𝑕𝑜𝑢𝑡 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑖𝑛𝑔 𝑇 =0.3

(8.66 × 10−3)1.2×

100

0.104 + 0.0014=

89.55 × 948.77 = 84969𝑕𝑟𝑠 ≈ 𝟏𝟎𝒚𝒆𝒂𝒓𝒔

𝐼𝑛 𝐷𝑟𝑖𝑣𝑖𝑛𝑔 𝑚𝑜𝑑𝑒,𝑤𝑕𝑖𝑙𝑒 𝑟𝑒𝑐𝑒𝑖𝑣𝑖𝑛𝑔, 𝑇 =0.3

30.44 × 10−3 1.2×

100

0.104 + 0.0014=

19.81 × 948.77 = 18799.6𝑕𝑟𝑠 ≈ 𝟐 𝒚𝒆𝒂𝒓𝒔

𝐼𝑛 𝑃𝑎𝑟𝑘𝑖𝑛𝑔 𝑚𝑜𝑑𝑒, 𝑇 =0.3

23.5 × 10−6 1.2×

100

100=

107606.82𝑕𝑟𝑠 ≈ 𝟏𝟐 𝒚𝒆𝒂𝒓𝒔

9 (M, 2005)


46

𝐼𝑛 𝑃𝑎𝑟𝑘𝑖𝑛𝑔 𝑚𝑜𝑑𝑒, 𝑟𝑒𝑐𝑒𝑖𝑣𝑖𝑛𝑔 𝑐𝑜𝑚𝑚𝑎𝑛𝑑𝑠,𝑇 =0.3

30.44 × 10−3 1.2×

100

100=

19.81𝑕𝑟𝑠 = 𝟐.𝟐 × 𝟏𝟎−𝟑 𝒚𝒆𝒂𝒓𝒔

𝑨𝒗𝒆𝒓𝒂𝒈𝒆 𝒃𝒂𝒕𝒕𝒆𝒓𝒚 𝒍𝒊𝒇𝒆 =𝟐 + (2.2 × 10−3) + 𝟐 + 𝟏𝟎 + 𝟏𝟐

𝟓≈ 𝟓𝒚𝒆𝒂𝒓𝒔


47

6 CONCLUSIONS

6.1 FUTURE ENHANCEMENTS

6.1.1 TYRE IDENTIFICATION FEATURE

Tyre Identification can be used to physically locate the position of tyre units in order to allow the system

determine what side (front right, front left, rear right, rear left and spare) of the vehicle a tyre sits.

There is currently only one tyre unit available for the purpose of demonstration and as such, this feature

is of minimal interest. However, in a system with 4 or 5 Tyre Units, this can be implemented by means of

using the signal strength received from a tyre node by calling the Zigbee stack function in the TPMS

application aplGetRxRSSI() when a message is received from a tyre node. The signal strength can

be compared to a known range of signal strength at a distance from all tyre locations hence giving each

tyre a unique signal range.

6.1.2 ADDITIONAL SYSTEM OPERATIONAL MODES

1. INFLATION

The control unit can be put in this mode by the tyre unit when the tyre unit detects a rapid increase or

decrease in pressure. The control unit then uses the pressure data received from the tyre unit as the

basis for determining if the pressure has gone below the recommended limit for a TPMS and alerts the

user by means of displaying messages on the screen, it continues requesting data and alerts the user

until it notices the pressure is stabilized within the limits set for TPMS. A typical use case for this mode is

for alerting the user when a tyre is being pumped and also when the tyre has a puncture causing it to

lose pressure rapidly.

2. ENQUIRY

In Enquiry mode, the control unit sends a single request to the tyre unit for the tyre unit’s current

temperature and pressure and displays the values to the user. A typical scenario for using this mode is if

the user has a Zigbee compatible handheld device that is running a TPMS application, the user can

obtain data from the tyre unit just by connecting to the network as a Zigbee End device with a bit more

functionality and request for data via the Control Unit. The only limiting factor for this mode is that the

user has to be within the range of the Zigbee network.


48

6.2 FINAL CONCLUSIONS

The project examined the use of Zigbee as the wireless communication protocol for implementing a

Direct Tyre Pressure Monitoring System. The implementation was mainly focused on investigating the

length of time the battery in the tyre unit of a battery operated system would last and additional

features that could result due to the use of Zigbee.

Several tests and analysis were done to determine the level to which the project achieved its goals. The

most important ones being Testing the systems overall functionality and estimating the life expectancy

of the battery being used in the System.

While testing the system’s overall functionality, it was established that the Control unit was able to

communicate with the tyre unit and vice versa. The control unit was also able to request data from the

tyre unit, hence the tyre unit did not have to send data when it was of no interest to the Control unit. It

was also established that the tyre unit was able to send data when an event requiring it to do so

occurred. This resolves the issue of inefficient use of battery life by making the tyre unit transmit data

based on necessity rather than in a pre determined pattern to the Control unit. This makes the system

Battery efficient.

Based on the analysis and values obtained from the datasheets of the components used in the design of

the system and the tests carried out, it was found that the system whilst operating in driving mode and

transmitting data, it draws 29.04mA of current. In driving mode without sending data, it draws 8.66mA

and in parking mode, it draws 23.5 µA. Also, it was found that when the tyre unit is in driving mode and

receiving data, it consumes 30.44mA and when in parking mode and receiving data, it consumes

21.80mA. It was then estimated from the current consumption in these different modes that the

average life expectancy of the battery in a wireless TPMS using Zigbee is 5 years.

This value was based on a number of assumptions such as the fact that the Sensor, MCU and transmitter

are connected to the same battery. Also, it is assumed that the MCU completes a single 8 bit successive

approximation A/D conversion within 3.5 milliseconds. This was a value obtained from the report of a

previous project carried out using the same Sensor but with a Motorola HC908 MCU running at


49

13.5MHz. The MCU used for this project was a Microchip PIC18F4620 running at 16MHz. In theory, the

value that would be obtained using the PIC18F4620 MCU would be relatively less than 3.5 milliseconds

but this value was chosen as a worst case scenario. The value obtained from the test was not used for

reasons explained in section 5.4.1.

In addition, it was assumed that when the system is in driving mode, the sensor only sends data at the

rate of 50 times per hour. This value was used because the sensor only needs to send data in driving

mode when it detects a change in pressure over or below a specified threshold, the threshold selected

would allow enough room to ensure the change is not due to minor pressure fluctuations non indicative

of the tyre being inflated or deflated. Assuming the tyre is not losing pressure, the threshold would

barley be crossed except if a sudden external force is exerted on the tyre causing the pressure to

fluctuate, for example, if a vehicle climbs a curb or drives into a pot hole. It was assumed that such a

scenario would rarely occur that frequently in practice.

Also, it was assumed that the transceiver operates at its maximum output power of 0dBm during

transmission. As such, lowering the output power of the transmitter could increase the battery life

expectancy. From figures obtained from the transceivers data sheet, it consumes about half the current

used for the analysis at -25dBm.

Furthermore, the result of the battery life expectancy does not take into account, temperature and

humidity of its operating environment which may extend or shorten the life expectancy of the battery

because this could not be pre determined.

A conclusion can be drawn that using Zigbee for the wireless communication requirement of a TPMS is

feasible and is recommended due to the fact that it allows for additional functionality and efficient use

of battery power.

As the original project objectives were achieved and the majority of the Projects functional specification

were implemented successfully, the project can be concluded to be a success.


50

7 BIBLIOGRAPHY

Daintree Networks. (May 2006). Understanding 802.15.4TM and ZigBeeTM NetworkingWhite Paper.

Daintree Networks.

Freescale Semiconductor. (2004). MPXY 8020A Technical Datasheet. Revision 1 . Freescale Semiconductor.

Kerninghan, B. K., & Ritchie, D. M. (1999). The C Programming Language. New Delhi: Prentice Hall of

India.

M, M. (2005). Wireless Link for Tyre Pressure Monitoring System. Canterbury: University of Kent.

Meshnetics. (2008). Zigbee FAQ. Retrieved 2008, from Meshnetics Website:

http://www.meshnetics.com/zigbee-faq/

Microchip Technolgy Inc. (2004). PIC18F2525/2620/4525/4620 Datasheet. Microchip Technology Inc.

Microchip Technology Inc. (2005). Microchip Stack for Zigbee. Microchip Technology Limited.

Microchip Technology Inc. (2007). Microchip Stack for Zigbee Protocol. Microchip Technology Inc.

National Highway Traffic Safety Administration. (n.d.). Tire Pressure Monitoring System, The Final Rule.

Retrieved 2007, from National Highway Traffic Safety Administration Website:

http://www.nhtsa.dot.gov/cars/rules/rulings/TirePresFinal/index.html

Reese, R. B. (2007). A Zigbee subset/IEEE 802.15.4 Multi-platform Protocol Stack , Version 0.2.6 . Dr.

Robert B. Reese.

Texas Instruments. (2006). Chipcon CC2420 Datasheet. 2.4 GHz IEEE 802.15.4 / ZigBee-ready RF

Transceiver . Texas Instruments.

The Alliance for Telecommunications Industry Solutions. (2007). ATIS Telecoms Glossary. Retrieved

January 2007, from http://www.atis.org/glossary/default.aspx.

Tyre Pressure Monitoring System. (2007). (Wikipedia) Retrieved from Wikipedia:

http://en.wikipedia.org/wiki/Tire_pressure_monitoring_system


51

8 TABLE OF FIGURES Figure 2.1.1.1: Direct TPMS Tyre Unit ............................................................................................................. 4 Figure 2.1.1.1: Zigbee Communication Protocol Stack .................................................................................... 5 Figure 2.1.1.2: Mesh Network Topology ......................................................................................................... 6 Figure 2.1.1.3: Star Network Topology ............................................................................................................ 7 Figure 2.1.1.4: Cluster Tree Network Topology ............................................................................................... 7 Figure 2.2.2.1: Zigbee Protocol Stack Architecture ......................................................................................... 8 Figure 4.2.1.1: Zigbee Demonstration Board with Zigbee Compliant Transceiver ........................................ 14 Figure 4.2.1.2: Sensor Board ......................................................................................................................... 15 Figure 4.2.1.3: Sensor Board Schematic Diagram ......................................................................................... 15 Figure 4.2.1.4 - MPXY8020 Series Sensor Block Diagram .............................................................................. 16 Figure 4.2.1.5: Complete Demonstrator Tyre Unit ........................................................................................ 18 Figure 4.2.1.6: Microcontroller and Sensor PORT Mapping .......................................................................... 18 Figure 4.2.1.7: Sensor Data Timing................................................................................................................ 19 Figure 4.2.2.1: Control Unit User Payload Packet ......................................................................................... 24 Figure 4.2.2.2: Tyre Unit User Payload Packet .............................................................................................. 24 Figure 4.2.2.3: Control Unit Driving Mode Flowchart ................................................................................... 25 Figure 4.2.2.4: Control Unit Parking Mode Flow Chart ................................................................................. 26 Figure 4.2.2.5: Tyre Unit Driving Mode Flowchart ........................................................................................ 27 Figure 4.2.2.6: Tyre Unit Parking Mode Flowchart ........................................................................................ 27 Figure 4.2.2.7: Successive Approximation Routine Flowchart ...................................................................... 30 Figure 4.2.2.8: Sensor Waveform During Measurement .............................................................................. 31 Figure 4.2.2.9: Control Unit Startup Flowchart ............................................................................................. 32 Figure 4.2.2.10: Tyre Unit Startup Operation Flowchart ............................................................................... 33 Figure 4.2.2.11: Control Unit Mode Change and Message Receipt Flowchart.............................................. 34 Figure 4.2.2.12: Tyre Unit Message Receipt FlowChart ................................................................................ 35 Figure 5.1.2.1: Test Setup for The MPXY8020 Sensor ................................................................................... 38 Figure 5.1.3.1: Achieved Control Timing Results For MPXY8020 Sensor ...................................................... 39 Figure 5.2.2.1: Zigbee Communication Link Test Set Up ............................................................................... 40 Figure 5.3.2.1: Control Unit Buttons ............................................................................................................. 41 Figure 6.1.2.1: 8 Bit D/A Conversion Time Waveform .................................................................................. 52 Figure 6.1.2.2: Sensor Setup Time Waveform ............................................................................................... 53 Figure 6.1.2.3: Sensor Hold Time Waveform................................................................................................. 53 Figure 6.1.2.4: Complete Measurement Time From Reset To 8 Bit D/A Conversion .................................... 54 Figure 6.1.2.5: Tyre Unit Network Join AtTempt ........................................................................................... 54 Figure 6.1.2.6: Control Unit Network Formation .......................................................................................... 55 Figure 6.1.2.7: Tyre Unit Network Join Acknowledgement ........................................................................... 55 Figure 6.1.2.8: Control Unit Acknowledgement of Tyre Unit Join ................................................................. 56 Figure 6.1.2.9: Parking Mode Command As Sent By Control Unit ................................................................ 56 Figure 6.1.2.10: Parking Mode Command Receipt ........................................................................................ 57 Figure 6.1.2.11: Tyre Unit Awaken on Driving Mode Command Receipt ...................................................... 57 Figure 6.1.2.12: Driviing Mode Command As Sent by the Control Unit ........................................................ 58 Figure 6.1.2.13: Driving Mode Command Receipt By Tyre Unit .................................................................... 58 Figure 6.1.2.14: Message Sent By Tyre Unit in Driving Mode ....................................................................... 59 Figure 6.1.2.15: Message Received By Coordinator in Driving Mode ........................................................... 59 Figure 9.2.5.1: TPMS Application Configuration ........................................................................................... 65


52

9 APPENDICES

9.1 SCREEN CAPTURE OF TEST RESULTS

FIGURE 6.1.2.1: 8 BIT D/A CONVERSION TIME WAVEFORM


53

FIGURE 6.1.2.2: SENSOR SETUP TIME WAVEFORM

FIGURE 6.1.2.3: SENSOR HOLD TIME WAVEFORM


54

FIGURE 6.1.2.4: COMPLETE MEASUREMENT TIME FROM RESET TO 8 BIT D/A CONVERSION

FIGURE 6.1.2.5: TYRE UNIT NETWORK JOIN ATTEMPT


55

FIGURE 6.1.2.6: CONTROL UNIT NETWORK FORMATION

FIGURE 6.1.2.7: TYRE UNIT NETWORK JOIN ACKNOWLEDGEMENT


56

FIGURE 6.1.2.8: CONTROL UNIT ACKNOWLEDGEMENT OF TYRE UNIT JOIN

FIGURE 6.1.2.9: PARKING MODE COMMAND AS SENT BY CONTROL UNIT


57

FIGURE 6.1.2.10: PARKING MODE COMMAND RECEIPT

FIGURE 6.1.2.11: TYRE UNIT AWAKEN ON DRIVING MODE COMMAND RECEIPT


58

FIGURE 6.1.2.12: DRIVIING MODE COMMAND AS SENT BY THE CONTROL UNIT

FIGURE 6.1.2.13: DRIVING MODE COMMAND RECEIPT BY TYRE UNIT


59

FIGURE 6.1.2.14: MESSAGE SENT BY TYRE UNIT IN DRIVING MODE

FIGURE 6.1.2.15: MESSAGE RECEIVED BY COORDINATOR IN DRIVING MODE


60

9.2 SENSOR ROUTINES

9.2.1 SENSOR INITIALIZATION ROUTINE

void initSensor(void)

{

TRISD = confMcuPins; //configuring MCU pin

directions

clk = 0; // initialise clock

//cycling high and low to put serial bit counter in

//known state (Reset)

S1 = 1;

wait(1);

S1 = 0;

resetDAR();//Resetting sensor internal DAR

//Putting Sensor in Reset mode

sensorResetMode();

}

9.2.2 8 BIT DATA SHIFT ROUTINE /************************************************

*Routine writes an 8 bit value to Sensor Data Pin

*************************************************/

int writeToSensor(int value)

{

int count;

count = 0;

while(count!=8)

{

if((value&msb) == 0x80)

{

dataToSensor = 1;

toggleClk();

}

else if((value&msb) == 0x00)

{

dataToSensor = 0;

toggleClk();


61

}

value = value<<1;

count++;

}

return dataFromSensor;

}

9.2.3 SUCCESSIVE APPROXIMATION ROUTINE

/*********************************

*Successive Approximation Routine*

**********************************/

int getSensorValue(void)

{

int temp = 0;

int lookup = 0x80;

int count = 8;

int sensorOut = 0;

int val = 0;

int guess = 128;

int temp2 = 0;

while(count!= 0)

{

sensorReadMode();

sensorOut = writeToSensor(guess);

if((sensorOut == 1)&&(count == 8))

{

temp = 0x80&lookup;

}

else if((sensorOut == 0)&&(count == 8))

{

guess = 64;

temp = 0&lookup;

}

else if((sensorOut==1)&&(count < 8))

{

temp = (0xFF&lookup)|temp;

}

else if((sensorOut==0)&&(count < 8))

{

temp = (0x00&lookup)|temp;

}


62

lookup = lookup>>1;

guess = temp|lookup;

count--;

}

return temp;

}

9.2.4 PRESSURE MEASUREMENT ROUTINE

/****************************

*Routine to Measure Pressure*

*****************************/

int measurePressure(void)

{

int pressure = 0;

initSensor(); //Initialize Sensor

setReadPressure(); //Set Sensor to Read Pressure

wait(5);

sensorReadMode(); //Put Sensor in Output Read mode

pressure = getSensorValue();

return pressure;

}

9.2.5 TEMPERATURE MEASUREMENT ROUTINE

/*******************************

*Routine that Reads Temperature*

********************************/

int measureTemperature(void)

{

int temperature = 0;

initSensor(); //Initialize PORTD Pin direction and

Reset Sensor

setReadTemperature(); //Set Sensor to Read

Temperature

wait(2);

sensorReadMode();//Can only change DAR content when

in Reset or Output read mode


63

temperature = getSensorValue();

return temperature;

}


64

9.3 TPMS APPLICATION

9.3.1 APPLICATION PROJECT FILE ORGANIZATION

C:\msstate_lrwpan\

|-obj\

|-compiletest\

|-mcc18_picdemz\ (contains IDE project files for PICDEM Z)

|-src\

|-stack\(Contains the Zigbee Stack C source files

|-simpletests\ (contains C source files to run TPMS application and other demo

applications)


65

9.3.2 CONFIGURING THE APPLICATION

FIGURE 9.3.2.1: TPMS APPLICATION CONFIGURATION


66

9.3.3 TPMS APPLICATION CD

wireless tyre pressure monitoring system using zigbee

Documents