THE CHINESE UNIVERSITY OF HONG KONG

BlueGuard: A Bluetooth Security Centre

Lau Chun Ning Charles

香港中文大學電子工程學系

Department of Electronic Engineering

2

BlueGuard: A Bluetooth Security Centre

Author: Lau Chun Ning Charles

Student I.D.: 04521362

Supervisor: Professor Keli. Wu

Associate Examiner: Professor J.B.Xu

A project report presented to the

Chinese University of Hong Kong

in partial fulfillment of the

Degree of Bachelor of Engineering

Department of Electronic Engineering

The Chinese University of Hong Kong

May, 2007

3

A. Abstract

A prototype of Bluetooth Anti-lost system has been design and built that enables people

to safeguard their own personal properties, children, elderly and pets. This document

describes the hardware and software implementation of the system and is intended as a

reference for future use. The system given been given the name “BlueGuard”.

B. Acknowledgement

I would like to express my sincere thanks to my FYP supervisor, Professor Keli Wu, for

his patience, guidance and advice throughout the year, which proved valuable for the

success of this thesis.

Also, I would like to thanks Jacky Chak from Avantwave Ltd, who has given me

technical support and provided me the Bluetooth module and development kit.

Not forgetting also, my friends and family, heartfelt thanks to all of them for their support

and encouragement throughout the year.

4

C. Contents

A. Abstract...................................................................................................................... 3 B. Acknowledgement ..................................................................................................... 3 C. Contents ..................................................................................................................... 4 D. Introduction ............................................................................................................... 5

D1. Why use Bluetooth ........................................................................................ 7 E1. System Overview ........................................................................................... 9 E2. Overview on Bluetooth ............................................................................... 10

E2I Bluetooth architecture .........................................................................11 E2II Piconet .................................................................................................. 15 E2III Bluetooth links................................................................................. 16 E2IV Bluetooth services............................................................................ 18 E2V The Bluetooth Profiles ........................................................................ 19 E2VI Application Layer ........................................................................... 24 E2VII Establish Link/Setup Virtual Serial Connection.......................... 24

E3. Tag Design ................................................................................................... 25 E3I Hardware Description ........................................................................ 25 E3II Bluetooth Module................................................................................ 27 E3III MCU ................................................................................................. 28 E3IV 120dB siren driver........................................................................... 30 E3V Power Management ............................................................................ 33

E4. Software Description .................................................................................. 35 E5. Host Design .................................................................................................. 41

F. Results ...................................................................................................................... 47 G. Cost Summary ......................................................................................................... 50 H. Conclusion ....................................................................................................... 51 I. References ................................................................................................................ 53 J. Appendix .................................................................................................................. 54

5

D. Introduction

Losing your personal belongings can be a painful and heartbreaking experience,

especially when the items are important and valuable. Important documents, identity card,

hand phones are just representative examples that are lost so easily, but can hardly or

impossible to get retrieve back. It happens in everyday: a person lays down a book,

backpack or purse and comes back and the belongings are gone. Adequate educations are

given, telling people never to leave their personal belongings unattended. True as it is,

but the psychological stress of keeping an eye on your stuffs all the time it imposes on the

owner is tremendous. Consider the scenario when at 6a.m, you are in the waiting area of

the airport, waiting to board the long distance flight to London. Your luggage besides you

contain all the important documents, and you keep reminding yourself to stay awake as

people around is all suspicious looking and they might take your luggage away at any

moment. You can neither take a nap nor read the newspaper as they will take away your

attention on the luggage. What a daunting task! It just drives you crazy.

Besides personal items, children, elderly and pets are ever more problematic. Unlike the

lug gages, which are stationary, children and elderly can wander off themselves without

parents or supervisors noticing them. Once they ran away, have fun on the search

operation or call the police to look for them!

6

There are existing products in the market to prevent losing. It operation principle is very

simple. The tag, which is tied to the luggage, emit radio frequency continuously. The

receiver, which is kept by the owner, monitor any signal in the same frequency, when no

signal is receiver, the alarm will be triggered. A picture of this simple device is shown in

figure D1. Despite the low price and simplicity of this product (HK$ 65), it suffers from

many drawbacks. The most obvious one is that thefts can easily jam the device by putting

a tag which radiate the same frequency nearby the owner of the luggage, so that the

receiver on the owner side would be tricked as if the luggage is nearby, and the theft can

then take his time to steal the luggage away. The other disadvantage is that the receiver

cannot monitor more than one item simultaneously, thus limiting the application value.

Finally, the owner must carry an extra receiver with him, which is troublesome and not

fashionable. Overall, this simple device is not suitable as an anti-lost device for important

and valuable items.

Figure D1. Anti-lost device

7

In my Final Year Project, an improved version of the anti-lost device is proposed, design

and a functional prototype has been worked out. The new device uses Bluetooth to link

between the owner and his/her personal items. This device is generic in the sense that it

can be used for many different applications other for anti-lost purpose, but the software

has to be tailored to the specific use. This report will describe the hardware and software

specifications of the device.

D1. Why use Bluetooth

During the last couples of years, Bluetooth has become a very popular technology for

short-range wireless link between handheld devices. Devices regardless of their types can

communicate with each other as long as they are Bluetooth enabled, Bluetooth has

already secured its position in the market as the recognized standard in short-range

wireless links and is still spreading rapidly. The number of Bluetooth chipsets shipped

per year has doubled from 2002 to a total of 69 million chipsets in 2003 [1]. The

overwhelming popularity of Bluetooth means that the technology is easily accessed and

any new products with Bluetooth incorporated will be easily accepted by the public, as

they are already familiar and with the technology.

Bluetooth was primarily a cable replacement technology, enabling users to connect to a

wide range of computing and telecommunications devices without using cables. However,

the real magic of Bluetooth is that the technology can be used for applications other than

cable replacement by forming Personal Area Network (PAN) and ad hoc connectivity.

8

Through the Discovery Service, PAN devices are capable of spontaneously joining into a

network as they approach each other [2]. This occurs only while the devices are in close

proximity: the devices leave the network as they are removed from proximity. The

opportunity for automatic, unconscious connections between mobile devices provides

freedom for end-users, and also makes Bluetooth an ideal technology for my application.

With the above arguments, Bluetooth has been chosen to be the driving technology of the

new anti-lost device so that the advantages of the technology can be appropriately

utilized in my application. Since the device utilizes Bluetooth technology to protect

personal properties, it has been named “BlueGuard”. A logo of BlueGuard has been

designed by me and is shown in figure D2.

Figure D2 Logo of BlueGuard

9

E. Theory and/or Paper Design

E1. System Overview

The whole system can be divided into two parts: the host and the tags (Figure E1). The

single host is kept by the owner and is basically a Bluetooth enabled pocket PC. The tags

can be multiple in numbers and are to be put together with the items to be protected.

The work I have contributed in this project is as follow:

1. Develop the software with graphical user interface on the pocket PC

2. Develop the hardware of the tag

3. Develop the software on the tag

Host

Tags

Figure E1.

10

The requirement of the system is as follow:

1. User can monitor from 1 to multiple items at the same time

2. When the item(s) has been moved away from the user outside a predefined distance,

the host will alert the user and the alarm on the tag will be triggered

3. The host should only monitor the tags but not other Bluetooth devices

4. The tag should be small in size so that it can fit into handbags and luggage

5. Cannot be jammed easily

6. Additional functions can be included

E2. Overview on Bluetooth

In order to provide readers a better understand the later parts of this thesis, this section

will cover the basic elements of Bluetooth which are related to my work Topics include

the Bluetooth architecture, basic Bluetooth actions like device discovery and service

discovery. The Bluetooth Profiles will also be discussed in detail and special emphasis is

given to the Serial Port Profile (SPP), as this profile is essential for implementation in this

thesis. This background knowledge is needed to develop applications for Bluetooth.

For the interested reader, references to in-depth information about the Bluetooth

technology are included throughout the section. This section is based on the Bluetooth

lectures from Bergen University [3], the Bluetooth book by Bray and Sturman [4], and

the Bluetooth Specification version 1.1 [5] available for download on the Bluetooth

11

Special Interest Group (SIG) website [6].

Bluetooth is a low cost, low power, short-range radio technology intended to replace

cable connections between cellphones, PDAs and other portable devices. Ericsson Mobile

Communications started developing the Bluetooth system in 1994, looking for a

replacement to the cables connecting cellphones and their accessories. The Bluetooth

system is named after a tenth-century Danish Viking king, Harald Blatand, who united

and controlled Norway and Denmark. The first Bluetooth devices hit the market around

1999. The Bluetooth SIG is responsible for further development of the Bluetooth

standard. Sony Ericsson, Intel, IBM, Toshiba, Nokia, Microsoft, 3COM, and Motorola

are some of the companies involved in the SIG. The composition of the Bluetooth SIG is

one of the major strengths of the Bluetooth technology. The mixture of both noticeable

software and hardware suppliers participating in the further development of the Bluetooth

technology ensures that Bluetooth products are made available to end users.

E2I Bluetooth architecture

The Bluetooth specification aims to allow Bluetooth devices from different

manufacturers to work with one another, so it is not sufficient to specify just a radio

system. Because of this, the Bluetooth specification does not only outline a radio system

but a complete protocol stack to ensure that Bluetooth devices can discover each other,

explore each other's services, and make use of these services.

12

Figure E2.1 The Bluetooth protocol stack

The Bluetooth stack is made up of many layers, as shown in Figure 2.1. The HCI is

usually the layer separating hardware from software and is implemented partially in

software and hardware/firmware. The layers below the HCI are usually implemented in

hardware and the layers above the HCI are usually implemented in software. Table E.1

gives a short description of each layer shown in Figure E2.1

13

Table E.1 Descriptions of Bluetooth protocol layers

For application developers like me, they do not need to know all the details about the

layers in the Bluetooth stack. However, an understanding of how the Bluetooth radio

works is of importance. The Bluetooth radio is the lowest layer of Bluetooth

communication. The Industrial, Scientific and Medical (ISM) band at 2.4 GHz is used for

radio communication. Note that several other technologies use this band as well. Wi-Fi

technologies like IEEE 802.11b/g and kitchen technologies like microwave ovens may

cause interference in this band [7].

14

The Bluetooth radio utilizes a signaling technique called Frequency Hopping Spread

Spectrum (FHSS). The radio band is divided into 79 sub-channels. The Bluetooth radio

uses one of these frequency channels at a given time. The radio jumps from channel to

channel spending 625 microseconds on each channel. Hence, there are 1600 frequency

hops per second (figure E2.2) . Frequency hopping is used to reduce interference caused

by nearby Bluetooth devices and other devices using the same frequency band.

Figure E2.2 Channel division

Every Bluetooth device is assigned a unique Bluetooth address, being a 48-bit hardware

address equivalent to hardware addresses assigned to regular Network Interface Cards

(NICs). The Bluetooth address is used not only for identification, but also for

synchronizing the frequency hopping between devices and generation of keys in the

Bluetooth security procedures.

15

E2II Piconet

A piconet is the usual form of a Bluetooth network and is made up of one master and one

or more slaves. The device initiating a Bluetooth connection automatically becomes the

master. A piconet can consist of one master and up to seven active slaves. The master

device is literally the master of the piconet. Slaves may only transmit data when

transmission-time is granted by the master device, also slaves may not communicate

directly with each other, and all communication must be directed through the master.

Slaves synchronize their frequency hopping with the master using the master's clock and

Bluetooth address.

Piconets take the form of a star network, with the master as the center node, shown in

Figure 7.2. Two piconets may exist within radio range of each other. Frequency hopping

is not synchronized between piconets, hence different piconets will randomly collide on

the same frequency.

16

E2III Bluetooth links

Two types of physical links are defined in version 1.1 of the Bluetooth specification,

Synchronous Connection Oriented (SCO) links and Asynchronous ConnectionLess (ACL)

links. The SCO and ACL links are part of the baseband specification.

SCO links are intended for audio transmission. When setting up a SCO link time slots are

reserved for transmission of data, thus providing a Quality of Service (QoS) guarantee.

Lost or erroneous packages are not re-transmitted which makes sense for voice

transmissions. All SCO links operate at 64 kbps. A master device can have up to three

simultaneous SCO links at a time, all to the same slave or to different slaves. Slave

devices can have up to three SCO links to the Master device.

MMaasstteerr

BB

EE

CC

DD

AA Slave

Slave

Slave

Slave Slave

Figure E2.3 Piconet formation

17

ACL links are intended for data communication. An ACL link provides error-free

transmission of data which means that lost or erroneous packets are re-transmitted. No

QoS guarantee is provided. The maximum data rate at the application level is around 650

kbps for an ACL link. A master device can have a number of ACL links to a number of

different devices, but only one ACL link can exist between two devices. User data is

usually transferred to and from the Logical Link Control and Adaption Protocol (L2CAP)

layer of the Bluetooth stack. Application developers usually refer to L2CAP and

RFCOMM links when talking about Bluetooth links.

L2CAP provides multiplexing between different higher layer protocols over a single

physical ACL link, enabling several logical data links to be set up between two Bluetooth

devices. L2CAP also provides segmentation and reassembly of packets from higher

layers. Different protocols use different packet sizes, some of these may need to be

segmented in order to be sent over an ACL link due to package size constraints. An ACL

packet can have a maximum of 339 bytes of payload data, while an L2CAP packet can

have a maximum of 65,535 bytes of payload data.

The RFCOMM layer emulates RS-232 serial ports and serial data streams. RFCOMM

relies on L2CAP for multiplexing multiple concurrent data streams and handling

connections to multiple devices. The majority of Bluetooth profiles make use of the

RFCOMM protocol because of its ease of use compared to direct interaction with the

L2CAP layer.

18

E2IV Bluetooth services

Bluetooth devices keep information about their Bluetooth services in a Service Discovery

DataBase (SDDB) as shown in Figure E2.4. The SDDB contains service record entries,

where each service record contains attributes describing a particular service. Each service

has its own entry in the SDDB.

Figure E2.4 The service discovery database

Remote devices can retrieve service records during service discovery and will then

possess all information required to use the services described. We see from Figure 7.3

that a service record has several attributes. Each attribute is assigned an attribute ID,

being a hexadecimal identifier.

Different attributes contain values of various types and sizes. To cope with this, data

elements are used for storing values. A data element consists of a data element type

descriptor and a data field as seen in Figure E2.5. The data element type descriptor

contains information about the type and size of the data and the data field contains the

actual data. A remote device will then know what kind of data and how much data it is

receiving when retrieving a service attribute.

19

Figure E2.5 Data element construct

The Universally Unique IDentifier (UUID) is the data type used for identifying services,

protocols and profiles etc. A UUID is a 128-bit identifier that is guaranteed to be unique

across all time and space.

E2V The Bluetooth Profiles

Bluetooth defines device Profiles to document how specific types of devices should

operate. These Profiles are intended to promote interoperability. If devices from different

manufacturers conform to the same Bluetooth SIG profile specification, they can expect

to interoperate when used for that particular service and usage case [8]. This mechanism

allows simpler devices to implement only those features necessary for their intended

application.

There are four different types of general profiles used by each various usage models.

They are namely the Generic Access Profiles (GAP), the Serial Port Profiles (SPP), the

Service Discovery Application Profiles (SDAP), and the Generic Object Exchange

Profiles (GOEP). In this section, the Serial Port Profiles (SPP) will be emphasis more as

20

this thesis is implemented on this profile. Before proceeding further, brief introductions

of the various profiles name earlier.

Generic Access Profile

GAP defines how two Bluetooth units discover and establish a connection with each

other. GAP handles discovery and establishment between units that are unconnected. The

profile defines operations that are generic and can be used by profiles referring to GAP

and by devices implementing multiple profiles. GAP ensures that any two Bluetooth units,

regardless of manufacturer and application, can exchange information via Bluetooth in

order to discover what type of applications the units support. Bluetooth units not

conforming to any other Bluetooth profile must conform to GAP to ensure basic

interoperability and co-existence. It also handles security. Figure E2.6 below show the

relationship of the GAP with the other Bluetooth profiles.

Figure E2.6 Bluetooth profiles

21

Service Discovery Application Profile

SDAP defines the investigation of services available to a Bluetooth unit. This profile

handles the search for known and specific services as well as a general service search.

SDAP involves an application, the Service Discovery User Application, which is required

in a Bluetooth unit for locating services. This application interfaces the Service

Discovery Protocol that sends and receives service inquiries to and from other Bluetooth

units. The SDAP is dependent on the GAP, i.e. SDAP re-uses parts of the GAP.

Generic Object Exchange Profile

GOEP defines the set of protocols and procedures to be used by applications handling

object exchanges. Several usage models are based on this profile, e.g. File Transfer and

Synchronization. Typical Bluetooth units using this profile are notebook PCs, PDAs,

mobile phones and smart phones. The GOEP is dependent on the Serial Port Profile. The

OBEX-standard is used.

Serial Port Profiles

The Serial Port Profile, or SPP, is a transport protocol profile that defines the

fundamental operations necessary to established RFCOMM communications between

two peer devices. Another explanation is that this profile defines how to setup virtual

serial ports on two devices and connecting these with Bluetooth. Figure E2.6 below

shows the protocol model that emulates serial cable connection.

22

Figure E2.6 The Serial Port Profile Protocol Model

The user data is being transmitted through using the RFCOMM. Application running on

either device will use the virtual serial port as if a physical serial cable, with RS-232

control signaling, were connecting the two devices. Therefore the application running on

both devices would expect the communication between them to occur over the SPP,

which emulate a serial cable connection. Since both applications is not aware of

Bluetooth procedures for setting up the virtual cable link, some assistance is needed from

the application to help it to utilize the Bluetooth specification on both side of the link.

The SPP does not define a specific role for master or slave between the devices. It does

not matter which devices is the master or the slave. In fact one device will take the

initiative and initiates with the other device for a serial communication link. The device

targeted for the connection is known as the acceptor. The SPP outlines the necessary

steps to establish an RFCOMM emulated serial port connection. These steps are

illustrated in Figure E2.7 below.

23

Figure E2.7 Serial port profile connection

The establishment or setup of the virtual serial connection is examined in more detail in

the later section. After the procedure outlined in the SPP is completed, the wireless link

connection would be completed instead of a physical cable being used. This connection

without the used of a cable is transparent to the application, as the function described by

the SPP is what that is needed to replaced a wired connection with a wireless one. Some

form of security such as the devices might require some degree of authentication or

perhaps some encryption, prior to establishing a connection between them. The SPP

specifies that these security considerations are optional, because the SPP is a generic

profile upon which others are built. However if the use of security features is

implemented, the two devices will be paired together during the connection establishment

phase.

24

E2VI Application Layer

The Bluetooth specification described three application-level of procedures that are

required for establishing a virtual serial cable connection between two devices.

E2VII Establish Link/Setup Virtual Serial Connection

This procedure describes the step taken to setup a connection with an emulated serial port

of a remote device.

1. Using the Service Discovery Protocol (SDP) to submit a query to determine the

RFCOMM server channel number of the application in the remote device. User can

select from the available ports in the peer device, if browsing capability is included in

the application.

2. It may be necessary for the remote device to authenticate itself. As an option, it may

require encryption be enabled.

3. A request for a new L2CAP channel to the remote RFCOMM entity.

4. Initiates an RFCOMM session on the L2CAP channel.

5. A new data link connection is started on the RFCOMM session using the server

channel number given by remote device, mentioned in step 1.

After this procedure is completed, the establishment of the emulated serial cable

connection is ready to be use by the applications on both devices.

25

Accept Link/Establish Virtual Serial Connection

For this procedure, the Acceptor would have to be involved in the following steps:

1. Authentication must be provided if requested, and upon further request, encryption has

to be turn on.

2. It will have to accept a new channel connection indicated by the L2CAP.

3. It will accept an RFCOMM session establishment on that particular channel.

4. It will accept a new data link connection on the RFCOMM session.

E3. Tag Design

The tag should serve the following tasks:

1. Wait for a virtual serial port connection from the host

2. When no connection request is received within a certain time period, set-off the

alarm

E3I Hardware Description

The block diagram of the tag hardware is shown in figure E3.1. It consists of 4 main

parts:

BTR110B Bluetooth module

Atmel AVR microcontroller

120dB siren driver and speaker

26

Power management unit

Other that the main parts, the tag also contains the following components:

Reset button

Pin- header for in-system programming

2 status LEDs

MCU BT module

120dB Siren Driver

Power Management

Figure E3.1

27

E3II Bluetooth Module

A Bluetooth module is a single wireless solutions consisting of hardware and software.

The Bluetooth module used here is BTR110B from the Bluetron™ 200 Series

( Avantwave ). BTR110B is built on CSR BC02 [9]. In standard configuration the module

includes a baseband processor with on board 4 Mbit Flash memory, a radio front-end,

antenna interface, supporting circuitry, together with some higher-level software

protocols and applications such as L2CAP, SDP, SPP, HSP and HFP are resided in the

Flash. Its firmware stack include the serial port profile (SPP330).

Figure E3.2 is the block diagram of the module.

Figure E3.2 BTR110B Bluetooth module

28

The schematic of the BTR110B is given in figure E3.3.

Figure E3.3 Schematic of BTR110B

E3III MCU

The MCU used is ATMega8 from the AVR series of Atmel. And is used to control the

Bluetooth module and the 120 dB siren driver. This controller is very simple and easy to

use, and has features that make it good for this kind of application. It has low power

consumption and supports different power down modes. It also supports in-system

programming that makes it very easy to reprogram the controller even when it is in use,

and without the use of a serial port. It has a very limited memory area (8 KB), but

29

supports extended memory up to 64 KB, although this is not used for this tag. Software

for this controller can be written using either standard C compiled with a special AVR C

compiler, or assembler code directly. Finally, the microcontroller is one of the cheapest

on the market, enabling low cost solutions. The data book describes the microcontroller

in detail [10].

The microcontroller is driven by a crystal oscillator at a frequency of 12 MHz. It

connects to the Bluetooth chip through a UART interface, and the baud rate can be

selected by software ranging from 2400 bit/s to 115 200 bit/s. In the tested application,

we have used 9600 bit/s.

The schematic of ATmega8 is shown in figure E3.4.

Figure E3.4 Schematic of Atmega 8

30

E3IV 120dB siren driver

Since the tag is usually located inside the luggage, the alarm must be able to generate a

loud noise so that it can catch people attention. The siren driver chip ZSD100 from Zetex

is chosen. It is designed to drive an 8 ohm horn speaker which is commonly available.

The addition of a few external components is all that is required to produce an ear

piercing 120dB alarm driver. The device operates from supplies of 4V up to 18V and is

ideal for security systems in battery powered applications, burglar alarms and car

Anti-theft systems. The detail of this chip can be found in its datasheet [11].

The block diagram of the siren driver is shown in figure E3.5 below.

Figure E3.5 Bock diagram of 120dB siren driver

The audio signal of the ZSD100 is generated using a square wave oscillator whose output

is capable of directly driving a wide range of output circuits. To produce a characteristic

alarm siren sound, the frequency of the audio oscillator is swept over a fixed 2:1 range by

31

a second, low frequency oscillator. The frequencies of both oscillators are controlled by

RT(INT) and capacitors CMOD and COUT.

PIN DESCRIPTIONS

1. RT Optional external resistor for improved frequency control. An external resistor

improves the control of both the modulating and output oscillators.

The RT pin is also used to power the device down. Either connecting RT to VCC or an

open circuit will result in the device being disabled.

2. SAW Selection of modulation waveform is made using the SAW pin. Leaving this pin

open creates the rising and falling modulated tone of a classic siren. Linking pin 2 to

pin 3 creates a rising ramp sound (sawtooth). Jumper J1 is provided for this function.

An open circuit produces a triangle wave, sawtooth is achieved by connecting SAW to

the CMOD pin.

3. CMOD An external capacitor is used to program the low frequency modulating

oscillator. The value of CMOD recommended is between 0.1mF and 100mF.

4. GND

5. COUT An external capacitor is used to program the output oscillator. The value of

COUT recommended is between 1nF and 100nF.

6. Q Non inverted output driver

7. Q Inverted output driver

8. VCC

32

The actual schematic of the 120dB siren driver is shown in figure E3.6.

Figure E3.6 120dB siren driver schematic

From the figure above, CMOD sets the sweep rate of the low frequency oscillator. COUT

sets the base frequency or “pitch” of the signal generator. Different siren effects can be

obtained by combining the two capacitor values.

The modulation frequency is calculated as follows:

2850(61.5 ( )

where in uF, ( ) in k

MODMOD T

MOD T

F HzC R EXT

C R EXT

=+

Ω

1710(61.5 ( )

where in uF, ( ) in k

OUTOUT T

OUT T

F HzC R EXTC R EXT

=+

Ω

33

In my design, I have chosen the value of CMOD and COUT to be 100uF and 0.1uF

respectively, and RT(EXT) is not used since the accuracy is not important here. The

frequencies generated are:

FMOD = 0.46Hz, FOUT = 278Hz

The complimentary outputs directly driving a H-bridge output circuit. When Q Inverted

is high, Q1 switches on and drives Q3 and Q6. When Q non Inverted is high, Q2 switches

on and drives Q4 and Q5. Only one pair of transistors in the output bridge is switched on

at any one time and this directly drives the speaker.

E3V Power Management

The tag is powered by a 3.6 V lithium battery ( LS 14250 ) as shown in figure E3.7. A

regulator LM1086 is used to down-convert the voltage to 3.3V for the MCU and

Bluetooth module.

According to the datasheet [12], the batter has a capacity of 1.0 Ah, which is enough to

fulfill the power requirement of the tag.

34

Figure E3.7 LS 14250 lithium battery

The Bluetooth chip uses about 33 mA when connected and about 26 mA in Page and

Inquiry scan mode. The microcontroller uses about 3.6 mA in active mode. In order to

reduce the current consumption, the Bluetooth chip can be powered down by hardware

from the microcontroller by disabling the ON and VCC_IO pins, reducing the current

consumption to 1 mA. The microcontroller itself can also be powered down to about 1

mA current consumption, but to wake-up the microcontroller from this mode, an external

interrupt signal must be present. To provide this interrupt signal, an external RC circuit is

included on the tag to allow a wake- up interrupt signal to be generated at intervals

ranging up to a few minutes.

The 120 dB driver chip ZSD100 draws 10mA in operating mode.

35

E4. Software Description

Tools

The software is needed so that the tag can correctly communicate with the host. The

principle hardware modules used for the development is the STK500 Flash MCU Starter

Kit and the BTR010 evaluation board provided by Avantwave Ltd. These kits allowed

me to program the MCU and to test the program quickly by monitoring the output using

HyperTerminal. The photo of the setup is shown in figure E3.8.

Figure E4.1 STK500 connected to BTR010

Another useful tool I used for the development is the AVR Studio. This software allows

me to write and debug program easily. The software was downloaded at the official

Atmel homepage [13].

36

Operation Mode

Before BTR110B can communicate with the MCU, it must first enter the binary

command mode. The concept is further illustrated in the state diagram as obtained from

[14] as given in figure 8.8:

Figure E4.2 State diagram of BTR110B

BTR110B has three modes: Standby mode, Text Command mode and Binary Command

mode.

Standby Mode: It is entered automatically after the module has been powered up.

Text Command Mode: It is used during application development for the convenience of

evaluation and testing of the module using HyperTerminal in PC.

37

Binary Command Mode: It is used for normal operation and application, and is the most

direct way the MCU can talk to the module.

Since I am using an MCU to control the module, it must be in the binary command mode.

To enter the binary mode from the standby mode, a rising-edge is given to PIO5 to enter

the text command mode, the binary command mode is subsequently entered after the

MCU has sent the bytes 0x24 to the module, and now the MCU is ready to communicate

with the module.

SPP330 Command Set

The communication between the MCU and BTR110B is bidirectional. The messages that

the MCU forwards to BTR110B is called COMMANDS. On the other hand, the

messages that BTR110B forwards to the MCU is called STATUS.

38

All command/status has the following format:

where:

Cmd = type of command / Status [ 1 Byte]

Len = Number of bytes in Payload [ 1 Byte]

Payload = Depends on the command or status. Can have zero length

Every command ends up with a 0xff

As a reference, the list of commands and status provided by the firmware SPP330 [10] is

given in the appendix.

Cmd Len Payload 0xff

Command

MCU BT module

Status

Figure E4.3 Communication between MCU and BTR110

39

The flowchart of the MCU program is given in figure E3.11. There are two conditions

that the program will trigger the alarm:

1. The distance between the host and the tag is too far (signal too weak)

2. The tag does not receive any connection request from the host within the time-out

period

The minimal distance that will set-off the alarm is determined by the user at the host side.

It will be discussed in more detail in the next section.

40

Main Routine

No

Yes

Initialize UART/ Enable receive

interrupt

Initialize IO Port

Initialize Timer/ Enable Timer interrupt

Set Connect as Slave always

Connected? Reset Timer

Timer interrupt routine

Reset Timer counter

Trigger alarm

Timer elapsed

Return

Figure E4.4 Flow Chart of MCU program

No

Yes

UART Receive interrupt routine

Trigger alarm

Data Received

Return

Signal too weak?

41

E5. Host Design

Tools

The application was developed for the pocket PC ipaq hw6595 (Figure E.5.1). The PPC

has the CPU PXA270, which can run at 416MHz, the operating system is Windows

Mobile 5.0. It use the Bluetooth stack from Boardcom.

Figure E.5.1 iPaq hw8595

Original, I intended to develop the Bluetooth application using the Java Bluetooth APIs

JSR82, however, it was found out from [15] that hw6595 does not support the APIs, as a

result I had to look for alternative. Since the machine uses the Bluetooth stack from

Boardcom, I went to Boardcom website [16] to look for hints on how to program the

Bluetooth on this machine. There, I found that the company provides a software

development kit for developing Bluetooth application on Windows Mobile. The kit is

called BCM1000-WCE.

42

BCM1000-WCE is a software solution for adding Bluetooth wireless technology to

Windows Mobile/Pocket PC operating system platforms. The software solution is fully

compliant with the Bluetooth 1.2 core protocol specification. BCM1000-WCE is

designed for Microsoft Mobile 2003 Second Edition for Pocket PC and includes the

Bluetooth protocol stack, application programming interfaces (APIs), hardware interfaces,

user application programs, support and trace tools, and documentation. With this tool at

hand, I was able to develop the application much more easily.

The software was written in C++ and was developed using Visual Studio.Net & Window

Mobile 5.0 PPC SDK.

Software Description

Original, I wanted the host to connect to multiple tags at the same time, so that several

items can be monitored simultaneously. This concept of this approach is depicted in

figure E5.2.

43

However, it was later discovered that this ideal approach did not work out. The reason is

that the Bluetooth stack for the serial port profile of the pocket PC is limited to one serial

port. In other words, only one outgoing COM port could be opened at any time. Since I

could not access the lower layer of the Bluetooth stack, there is no way that this problem

could be overcome by the hard way.

Instead, I solved the problem by attacking it by another approach. This approach use

time-multiplexing to connect to different tags in turns. The concept of this approach is

shown in figure 5.3.

Time

BT1

BT2

BT3

BT4

.

. Figure E.5.2 Simultaneous connections

44

The disadvantage of this approach is clear: It takes longer time to monitor the tags. Since

there are no better choices, this approached was adopted.

The requirements of the application software are as follow:

1. Search for any Bluetooth device within the range of the host

2. From those Bluetooth devices found, keep only those which are the tags

3. For all the devices in the list, discover their available services

4. If serial port profile is found on any of the devices, attempt a connection to them

5. If the connection was successful and the signal is above a certain range, disconnect and

initiate connection to the next device the list

6. If connection could not be made or the signal is too weak, alert the user

Moreover, the user should be able to switch on or turn off the Bluetooth module of any

discovered tag remotely.

Time

BT1 BT2 BT3 BT4

Figure 5.3 Simultaneous connections

BT1 BT2

45

As for the minimal distance outside which the warning is set-off, the definition is

depicted in figure E5.4:

0-1m: Safety zone, no warning

2-6m: Warning zone, light warning

6-10m: Heavy warning

Figure E5.4 Definition of warning zone

The flowchart that describe the host application is shown in figure E5.6.

The main reference during the software development was the Programmer’s Guide of

WIDCOMM Bluetooth for Windows CE SDK [17].

46

Start session

Search Bluetooth devices in neighborhood

Filter out non-tag devices

Yes

Discover services

Initiate connection to nth tag

Connected? Alert user

n = n + 1

No

Signal too weak?

Yes

No

Stop button clicked?

No

Stop session

Figure E5.6 Flowchart of host software

47

F. Results

Testing

The tag behaved as expected during the test. The resulting prototype functions quite well.

Alarm is triggered and warning is given when the items are too far. However, one defect

of the system is that it takes about 5 seconds to monitor each tag. This delay is due to the

intrinsic nature of the Bluetooth that the processing power is very limited. After each

connection, enough time must be provided to it to do the internal clearing jobs. This

limits the practical ness of the system. Except using a Bluetooth module with higher

computing power, this problem is not likely to be solved easily.

When the user executed the host program, it will display a GUI shown in the Figure F1.

Figure F.1 Main screen of host GUI Figure F.2 Addresses and services window

48

The user will have to click on the ‘Start!’ button to start the inquiry for the tags. If the

user does not select the “Act as server” box, the host will act as a client and the tag will

act as server. If the “Act as server” box is selected, the host will act as a server and wait

for the tag to connect to it. In the “Safe Range” box, the user can input the safety

distance.

When the tags are found, the host GUI will receive the address and services of the tags.

The addresses and services of the tags will appear in another GUI window as shown in

Figure F.2. If the services discovery process is completed the “OK” button on the

services window will be enabled.

The user will then be able to highlight the addresses and click on the ‘OK’ button and the

services window will close and the main window will be opened again. This will allows

the host to request a connection to the selected tags. If the connection is successful and

the signal is strong enough, the RFCOMM will then create a virtual serial COM port

connection between the host and the tags. When the two devices are connected, a

message will appear in the main window, informing the user that which tags was

connected (Figure F.3). When any of the tag has been moved away, the host will detect it

and immediately, a warning window will pop-up, informing the user which tags has been

moved. Also, a warning alarm will be set-off. (Figure F.4)

49

Figure F.3 Connecting status Figure F.4 Warning window

50

G. Cost Summary

The Cost of the whole project is listed in Table G1.

Part Quantity Unit Cost ($HK) Total Cost ($HK)

Atmega8 2 25 50

BTR110B 2 80 160

ZSD100 2 10 20

Speaker 2 5 10

LS 14250 lithium

battery

2 20 20

MPS2222 10 5 50

ZTX790A 10 5 50

ZTX690B

10 5 50

Miscellaneous

components (Crystal,

resistor, capacitor

switch…)

50

Grand Total Cost = ($HK) 460

Table G1. Cost summary of project.

51

H. Conclusion

This thesis had presented the relevant theory behind the technology. In my FYP, I have

successfully design and implemented a prototype of the Bluetooth anti-lost system. There

were many problems encountered during the project, but I was able to overcome them.

Thus this thesis concludes that the basic aim and objectives in the implementation of the

Bluetooth security system is fulfilled.

Looking out to the future, the Bluetooth security system presented in this thesis can

integrate additional functions to add its value and improve its market potential. In this

way, it is possible to make an all-in-one Bluetooth integrated Centre just on the usual

handphone. The system can have additional functions like remote control, door access

and other functions that you can imagine. The idea is shown in figure H.1.

Also, the issues of interpretability, low cost, small size and low power are all essential

factors that must be worked on if my work is to become a good-selling product in the

market.

52

In conclusion, Bluetooth has already become part of our life; t will be only a matter of

time where Bluetooth products will be available anywhere in the market.

IIBBSS:: IInntteeggrraatteedd BBlluueeGGuuaarrdd SSyysstteemm

SSeeccuurriitt RReemmoottee CCoonnttrrooll

DDoooorr aacccceessss

??

Figure H.1 Concept of the Integrated Blueguard SystemBluetooth

53

I. References

[1]: See http://www.mobilemag.com/content/100/104/C2783/

[2]: D. Gratton, Bluetooth Profiles, The Definitive Guide, First Edition, Prentice Hall,

2003.

[3]: See http://www.kjhole.com

[4]: J. Bray and C. Sturman, Bluetooth 1.1, Connect Without Cables, Second Edition,

Prentice Hall, 2002.

[5]: Bluetooth SIG, Specification of the Bluetooth System version 1.1, 2001.

[6]: See http://www.bluetooth.org

[7]: M. S. Gast, 802.11 Wireless Networks, First Edition, O'Reilly, 2002.

[8] N.J. Muller, Bluetooth Demystified: Understandable Guide to Bluetooth

Technology, McGraw-Hill, United States of America, 2001.

[9] CSR corporation, BlueCore2 datasheet

[10] Atmel Corporation, AVR 8-bit RISC microcontrollers data book, May 1997.

[11] Zetex Ltd, ZSD100 AVR 8-bit RISC microcontrollers data sheet

[12] Saft corporation, LS 14250 3.6 V Primary lithium – thionyl Chloride battery

datasheet

[13] Atmel homepage: www.atmel.com/avrstudio

[14] SPP330 user manual, v1.8, Avantwave Ltd

[15] See http://www.javabluetooth.com/jsr82devices.html

[16] Boardcom corporation, http://www.broadcom.com

[17] Boardcom corporation, Programmer’s Guide of WIDCOMM Bluetooth for

Windows CE SDK

54

J. Appendix

Command sets of SPP330

Cmd Value

Reserved 0x00

Inquiry 0x01

Pair as slave 0x02

Connect as master 0x03

Connect paired device 0x04

Connect as slave 0x05

Pair as master 0x06

Connect as slave for paired device 0x07

List paired devices 0x08

Clear paired devices list 0x09

Set discoverable 0x0a

Connect as Slave always 0x0b

Connect as Slave for paired devices always 0x0c

Reserved 0x0d

Connect with Bluetooth address 0x0e

Set baudrate 0x0f

Enter binary command mode 0x24

Number 0xfe