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
W IRELESS T YRE P RESSURE M ONITORING S YSTEM U SING Z IGBEE
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.
i
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.
ii
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
iii
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
1
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.
2
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 D IRECT 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.
3
FIGURE 2.1.1.1: DIRECT TPMS TYRE UNIT
2.1.1.2 I NDIRECT 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 H YBRID 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.
4
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
5
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)
6
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.
2
3
7
IEEE Device Typical function

Zigbee Protocol Device Type
One per network. Responsible for forming
the network, allocating network addresses
FFD
Coordinator and may monitor and control other devices
on the network
This is an optional device in the network, it
extends the physical range of the network
FFD by way of allowing more nodes to join the
Router
network. It may also perform monitoring
and control functions
Performs monitoring and control functions
RFD
End device 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
4
8
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)
9
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
10
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.
11
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.
12
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 M ICROCHIP PICDEM Z D EMONSTRATION K IT
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.
13
FIGURE 4.2.1.1: ZIGBEE DEMONSTRATION BOARD WITH ZIGBEE COMPLIANT TRANSCEIVER
4.2.1.2 F REESCALE C OMBINED T EMPERATURE AND P RESSURE S ENSOR
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:
14
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.
15
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)
16
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 I NTERFACING T HE S ENSOR B OARD W ITH THE D EMO B OARD
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.
17
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.
18
 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)
19
20
4.2.2 THE SOFTWARE
4.2.2.1 Z IGBEE S TACK
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 None
network
apsFSM() Runs the stack’s None
finite state machine
apsBusy() Checks if the stack is None
21
busy or not
aplGetStatus() None
halInit() initialize the HAL None
layer
evbInit() initialize the None
evaluation board
aplInit() initialize the rest of None
the stack
aplSendMSG(arguments Sends messages See 4.2.2.2.1
omitted) below
TABLE 4.2.2-1: SERVICE CALLS EXPLICITLY USED IN THE APPLICATION
4.2.2.2 TPMS A PPLICATION
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
};
22
CODE 1: TPMS MODE DECLARATION
4.2.2.2.1 S ENDING M ESSAGES
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.
23
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 R ECEIVING M ESSAGES
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.
24
4.2.2.2.3 T HE C ONTROL U NIT
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
25
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 T HE T YRE U NIT
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.
26
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
27
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.
Pressure Temperature Serial

A/D Output
S1 S0 Operating Mode Measure Measurement LFO Data
Comparator
System System Counter
0 0 Standby/Reset OFF OFF OFF ON ACTIVE
0 1 Measure Pressure ON OFF OFF ON RESET
Measure
1 0 OFF ON OFF ON RESET
Temperature
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
28
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 𝑙𝑜𝑜𝑘𝑢𝑝 = 0𝟏000000 𝑙𝑜𝑜𝑘𝑢𝑝 = 00𝟏00000 𝑙𝑜𝑜𝑘𝑢𝑝 = 000𝟏0000
& 11111111 & 00000000 & 11111111 & 11111111
𝑟𝑒𝑠𝑢𝑙𝑡 = 𝟏0000000 𝑟𝑒𝑠𝑢𝑙𝑡 = 0𝟎000000 𝑟𝑒𝑠𝑢𝑙𝑡 = 00𝟏00000 𝑟𝑒𝑠𝑢𝑙𝑡 = 000𝟎0000
𝑡𝑒𝑚𝑝 = 𝑜𝑟10000000 𝑡𝑒𝑚𝑝 = 𝑜𝑟10000000 𝑡𝑒𝑚𝑝 = 𝑜𝑟10000000 𝑡𝑒𝑚𝑝 = 𝑜𝑟10100000
𝑡𝑒𝑚𝑝 = 𝟏0000000 𝑡𝑒𝑚𝑝 = 1𝟎000000 𝑡𝑒𝑚𝑝 = 10𝟏00000 𝑡𝑒𝑚𝑝 = 101𝟏0000
Count = 4, OUT = 0 Count = 3, OUT = 0 Count = 2, OUT = 0 Count = 1, OUT = 0

𝑙𝑜𝑜𝑘𝑢𝑝 = 0000𝟏000 𝑙𝑜𝑜𝑘𝑢𝑝 = 00000𝟏00 𝑙𝑜𝑜𝑘𝑢𝑝 = 000000𝟏0 𝑙𝑜𝑜𝑘𝑢𝑝 = 0000000𝟏
& 00000000 & 00000000 & 00000000 & 00000000
𝑟𝑒𝑠𝑢𝑙𝑡 = 0000𝟎000 𝑟𝑒𝑠𝑢𝑙𝑡 = 00000𝟎00 𝑟𝑒𝑠𝑢𝑙𝑡 = 000000𝟎0 𝑟𝑒𝑠𝑢𝑙𝑡 = 0000000𝟎
𝑡𝑒𝑚𝑝 = 𝑜𝑟10110000 𝑡𝑒𝑚𝑝 = 𝑜𝑟10110000 𝑡𝑒𝑚𝑝 = 𝑜𝑟10110000 𝑡𝑒𝑚𝑝 = 𝑜𝑟10110000
𝑡𝑒𝑚𝑝 = 1011𝟎000 𝑡𝑒𝑚𝑝 = 10110𝟎00 𝑡𝑒𝑚𝑝 = 101100𝟎0 𝑡𝑒𝑚𝑝 = 1011000𝟎
TABLE 4.2.2-3: SUCCESSIVE APPROXIMATION EXAMPLE OPERATION
29
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
30
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.
31
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 R UNNING THE TPMS A PPLICATION
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
32
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
33
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:
34
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.
35
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.
36
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.
37
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 tWAKE - 16384 - LFO clocks
Pulse Width tWPW - 2 -
Reset Pulse
Pulse Timing tRESET - 16,777,216 - LFO clocks
Pulse Width tRPW - 2 -
Minimum Setup Time (DATA edge to
tSETUP 100 - - nSec
CLK rise)
Minimum Hold Time (CLK rise to
tHOLD 100 - - nSec
DATA change)
Measurement Response Time
Temperature tTMEAS - 200 -
µSec
Pressure tPMEAS - 500 -
Read Response Time tREAD - 50 100 µSec
Sample Capacitor Discharge Time
From initial full scale D/A count tSH 20 - - mSec
(255) to drop 2 counts (253)
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
38
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:
Value
Parameter Recommended Acceptable
Achieved
tSETUP 120 µSec 100nSec Yes
tHOLD 130 µSec 100nSec Yes
tTMEAS 250 µSec 200 µSec
Yes
tPMEAS 510 µSec 500 µSec
Maximum D/A
conversion
16 mSec 20mSec Yes
completion time
before tSH
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
39
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.
40
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 P ARKING M ODE
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
41
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 D RIVING M ODE
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.
42
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
Max Current drawn in Mode
PIC18F4620 Modes
µA
Run 3000
Sleep 2
TABLE 5.4.1-1: PIC18F4620 CURRENT CONSUMPTION
Typical time Per 8 Bit

Max Current drawn
Sensor Mode Successive Approximation
µA
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
Transmitter Max Current

Current drawn in Mode
Consumption µA
Receive 18800
Power Down 20
Transmit at 0dBm 17400
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,
43
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
𝑥= = 1198.74 𝑐𝑦𝑐𝑙𝑒𝑠
3 + 0.00315
𝑅𝑢𝑛 𝐶𝑦𝑐𝑙𝑒 𝑓𝑜𝑟 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑟, 𝑀𝐶𝑈 𝑎𝑛𝑑 𝑆𝑒𝑛𝑠𝑜𝑟 𝑖𝑛 1𝑕𝑟 𝑖𝑛 𝑃𝑎𝑟𝑘𝑖𝑛𝑔 𝑚𝑜𝑑𝑒 = 3600𝑠
= 1𝑠 × 𝑥
𝑥 = 3600𝑐𝑦𝑐𝑙𝑒𝑠
44
𝑅𝑢𝑛 𝐶𝑦𝑐𝑙𝑒 𝑓𝑜𝑟 𝑀𝐶𝑈 𝑎𝑛𝑑 𝑇𝑟𝑎𝑛𝑐𝑒𝑖𝑣𝑒𝑟 𝑖𝑛 1𝑕𝑟 𝑎𝑠𝑠𝑢𝑚𝑖𝑛𝑔 𝑎 𝑠𝑖𝑔𝑛𝑖𝑓𝑖𝑐𝑎𝑛𝑡 𝑐𝑕𝑎𝑛𝑔𝑒 𝑖𝑛 𝑝𝑟𝑒𝑠𝑠𝑢𝑟𝑒 𝑜𝑐𝑐𝑢𝑟𝑠
50 𝑡𝑖𝑚𝑒𝑠 𝑖𝑛 𝑎𝑛 𝑕𝑜𝑢𝑟 𝑎𝑛𝑑 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑟
3600
𝑖𝑠 𝑠𝑤𝑖𝑡𝑐𝑕𝑒𝑑 𝑜𝑛 𝑓𝑜𝑟 10𝑚𝑠 𝑒𝑎𝑐𝑕 𝑡𝑖𝑚𝑒 = = 49.99 𝑐𝑦𝑐𝑙𝑒𝑠
3600
+ 0.001
50
1198.74 × 0.00315
𝑇𝑕𝑒 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑑𝑢𝑡𝑦 𝐶𝑦𝑐𝑙𝑒 𝑓𝑜𝑟 𝑡𝑕𝑒 𝑀𝐶𝑈 𝑎𝑛𝑑 𝑠𝑒𝑛𝑠𝑜𝑟 = × 100
3600
= 0.104%
49.99 × 0.001
𝑇𝑕𝑒 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑑𝑢𝑡𝑦 𝐶𝑦𝑐𝑙𝑒 𝑓𝑜𝑟 𝑡𝑕𝑒 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑟 𝑎𝑛𝑑 𝑀𝐶𝑈 = × 100
3600
= 0.0014%
𝑇𝑕𝑒 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑑𝑢𝑡𝑦 𝐶𝑦𝑐𝑙𝑒 𝑓𝑜𝑟 𝑡𝑕𝑒 𝑆𝑒𝑛𝑠𝑜𝑟, 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑟 𝑎𝑛𝑑 𝑀𝐶𝑈 𝑖𝑛 𝑝𝑎𝑟𝑘𝑖𝑛𝑔 𝑚𝑜𝑑𝑒
3600
= × 100 = 100%
3600
𝐶𝑡
𝐵𝑎𝑡𝑡𝑒𝑟𝑦 𝑙𝑖𝑓𝑒𝑡𝑖𝑚𝑒 𝑇 𝑕𝑟𝑠 = 𝑛 , 9
𝐼
𝑤𝑕𝑒𝑟𝑒 𝐶 = 𝑡𝑕𝑒𝑜𝑟𝑒𝑡𝑖𝑐𝑎𝑙 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦 𝑖𝑛 𝐴𝑚𝑝𝑠 − 𝑕𝑜𝑢𝑟 𝐴𝑕
𝑡 = 𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑎𝑔𝑒 𝑑𝑢𝑡𝑦 𝑐𝑦𝑐𝑙𝑒 𝑜𝑓 𝑡𝑕𝑒 𝑏𝑎𝑡𝑡𝑒𝑟𝑦
𝐼 = 𝑐𝑢𝑟𝑟𝑒𝑛𝑡 𝑑𝑟𝑎𝑤𝑛
𝑛 = 𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝑜𝑓 𝑕𝑜𝑤 𝑤𝑒𝑙𝑙 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑕𝑜𝑙𝑑𝑠 𝑢𝑝 𝑢𝑛𝑑𝑒𝑟 𝑕𝑖𝑔𝑕 𝑟𝑎𝑡𝑒𝑠 𝑜𝑓 𝑑𝑖𝑠𝑐𝑕𝑎𝑔𝑒
𝑀𝑎𝑛𝑢𝑓𝑎𝑐𝑡𝑢𝑟𝑒𝑟 𝑠𝑝𝑒𝑐𝑖𝑓𝑖𝑐
𝑛 = 1.2 𝑓𝑜𝑟 𝑚𝑜𝑠𝑡 𝑙𝑖𝑡𝑕𝑖𝑢𝑚 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑐𝑒𝑙𝑙𝑠 𝑤𝑖𝑡𝑕 𝐶 = 300𝑚𝐴𝑕
0.3 100
∴ 𝐼𝑛 𝐷𝑟𝑖𝑣𝑖𝑛𝑔 𝑚𝑜𝑑𝑒 𝑤𝑕𝑖𝑙𝑒 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑖𝑛𝑔, 𝑇= −3 1.2
× =
(29.04 × 10 ) 0.104 + 0.0014
20.97 × 948.77 = 19892.4 𝑕𝑟𝑠 ≈ 𝟐 𝒚𝒆𝒂𝒓𝒔
0.3 100
𝐼𝑛 𝐷𝑟𝑖𝑣𝑖𝑛𝑔 𝑚𝑜𝑑𝑒, 𝑤𝑖𝑡𝑕𝑜𝑢𝑡 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑖𝑛𝑔 𝑇 = −3 1.2
× =
(8.66 × 10 ) 0.104 + 0.0014
89.55 × 948.77 = 84969𝑕𝑟𝑠 ≈ 𝟏𝟎𝒚𝒆𝒂𝒓𝒔
0.3 100
𝐼𝑛 𝐷𝑟𝑖𝑣𝑖𝑛𝑔 𝑚𝑜𝑑𝑒, 𝑤𝑕𝑖𝑙𝑒 𝑟𝑒𝑐𝑒𝑖𝑣𝑖𝑛𝑔, 𝑇= × =
30.44 × 10−3 1.2 0.104 + 0.0014
19.81 × 948.77 = 18799.6𝑕𝑟𝑠 ≈ 𝟐 𝒚𝒆𝒂𝒓𝒔
0.3 100
𝐼𝑛 𝑃𝑎𝑟𝑘𝑖𝑛𝑔 𝑚𝑜𝑑𝑒, 𝑇= × =
23.5 × 10−6 1.2 100
107606.82𝑕𝑟𝑠 ≈ 𝟏𝟐 𝒚𝒆𝒂𝒓𝒔
9
(M, 2005)
45
0.3 100
𝐼𝑛 𝑃𝑎𝑟𝑘𝑖𝑛𝑔 𝑚𝑜𝑑𝑒, 𝑟𝑒𝑐𝑒𝑖𝑣𝑖𝑛𝑔 𝑐𝑜𝑚𝑚𝑎𝑛𝑑𝑠, 𝑇 = × =
30.44 × 10−3 1.2 100
19.81𝑕𝑟𝑠 = 𝟐. 𝟐 × 𝟏𝟎−𝟑 𝒚𝒆𝒂𝒓𝒔
𝟐 + (2.2 × 10−3 ) + 𝟐 + 𝟏𝟎 + 𝟏𝟐
𝑨𝒗𝒆𝒓𝒂𝒈𝒆 𝒃𝒂𝒕𝒕𝒆𝒓𝒚 𝒍𝒊𝒇𝒆 = ≈ 𝟓𝒚𝒆𝒂𝒓𝒔
𝟓
46
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.
47
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
48
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.
49
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
50
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
51
9 APPENDICES
9.1 SCREEN CAPTURE OF TEST RESULTS
FIGURE 6.1.2.1: 8 BIT D/A CONVERSION TIME WAVEFORM
52
FIGURE 6.1.2.2: SENSOR SETUP TIME WAVEFORM
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
FIGURE 6.1.2.5: TYRE UNIT NETWORK JOIN ATTEMPT
54
FIGURE 6.1.2.6: CONTROL UNIT NETWORK FORMATION
FIGURE 6.1.2.7: TYRE UNIT NETWORK JOIN ACKNOWLEDGEMENT
55
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
56
FIGURE 6.1.2.10: PARKING MODE COMMAND RECEIPT
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
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
FIGURE 6.1.2.15: MESSAGE RECEIVED BY COORDINATOR IN DRIVING MODE
59
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();
60
}
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;
}
61
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
62
temperature = getSensorValue();
return temperature;
63
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)
64
9.3.2 CONFIGURING THE APPLICATION
FIGURE 9.3.2.1: TPMS APPLICATION CONFIGURATION
65
9.3.3 TPMS APPLICATION CD
66

Wireless Tyre Pressure Monitoring System Using Zigbee

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Wireless Tyre Pressure Monitoring System Using Zigbee

Uploaded by

Copyright:

Available Formats

WIRELESS TYRE PRESSURE MONITORING SYSTEM

BEng Honours Electronic & Communications Engineering

University of Kent, Canterbury

Author: Odafe Ojenikoh

Project Supervisor: Adam Jastrzebski

TERMS AND ABREVIATIONS

1.1 AIM AND SCOPE

2.1 TPMS OVERVIEW

2.1.1 TYPES OF TPMS

2.1.1.1 D IRECT TPMS

FIGURE 2.1.1.1: DIRECT TPMS TYRE UNIT

2.1.1.2 I NDIRECT TPMS

2.1.1.3 H YBRID TPMS

2.2 ZIGBEE OVERVIEW

FIGURE 2.1.1.1: ZIGBEE COMMUNICATION PROTOCOL STACK

Frequency (MHz) 868 915 2400

TABLE 2.1.1-1: ZIGBEE OPERATING FREQUENCIES

FIGURE 2.1.1.2: MESH NETWORK TOPOLOGY1

FIGURE 2.1.1.3: STAR NETWORK TOPOLOGY2

FIGURE 2.1.1.4: CLUSTER TREE NETWORK TOPOLOGY3

2.2.1 ZIGBEE DEVICE TYPES

IEEE Device Typical function

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

2.2.2 ZIGBEE STACK ARCHITECTURE

FIGURE 2.2.2.1: ZIGBEE PROTOCOL STACK ARCHITECTURE5

2.2.3 ZIGBEE NETWORK FORMATION

2.2.4 ZIGBEE DATA TRANSMISSION

3.1 FUNCTIONAL SPECIFICATION

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

3.2 ADDITIONAL FEATURES

4 DESIGN AND IMPLEMENTATION

4.2 ANATOMY OF ZIGBEE BASED WIRELESS TPMS

4.2.1 THE HARDWARE

4.2.1.1 M ICROCHIP PICDEM Z D EMONSTRATION K IT

FIGURE 4.2.1.1: ZIGBEE DEMONSTRATION BOARD WITH ZIGBEE COMPLIANT TRANSCEIVER

4.2.1.2 F REESCALE C OMBINED T EMPERATURE AND P RESSURE S ENSOR

FIGURE 4.2.1.2: SENSOR BOARD

FIGURE 4.2.1.3: SENSOR BOARD SCHEMATIC DIAGRAM

FIGURE 4.2.1.4 - MPXY8020 SERIES SENSOR BLOCK DIAGRAM7

4.2.1.3 I NTERFACING T HE S ENSOR B OARD W ITH THE D EMO B OARD

FIGURE 4.2.1.5: COMPLETE DEMONSTRATOR TYRE UNIT

FIGURE 4.2.1.6: MICROCONTROLLER AND SENSOR PORT MAPPING

FIGURE 4.2.1.7: SENSOR DATA TIMING8

4.2.2 THE SOFTWARE

4.2.2.1 Z IGBEE S TACK

Stack Service Description Parameters

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

4.2.2.2 TPMS A PPLICATION

CODE 1: TPMS MODE DECLARATION

4.2.2.2.1 S ENDING M ESSAGES

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

CODE 2: STACK FUNCTION TO SEND MESSAGE

0 Redundant data 7 8 Mode Command 15

FIGURE 4.2.2.1: CONTROL UNIT USER PAYLOAD PACKET

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

FIGURE 4.2.2.2: TYRE UNIT USER PAYLOAD PACKET

4.2.2.2.2 R ECEIVING M ESSAGES

4.2.2.2.3 T HE C ONTROL U NIT

4.2.2.2.3.1 MODES OF OPERATION

FIGURE 4.2.2.3: CONTROL UNIT DRIVING MODE FLOWCHART

FIGURE 4.2.2.4: CONTROL UNIT PARKING MODE FLOW CHART

4.2.2.2.4 T HE T YRE U NIT

4.2.2.2.4.1 MODES OF OPERATION