THE CHINESE UNIVERSITY OF HONG KONG

BlueGuard: A Bluetooth Security Centre

Lau Chun Ning Charles

Department of Electronic Engineering

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

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.

C. Contents
Abstract...................................................................................................................... 3 Acknowledgement ..................................................................................................... 3 Contents ..................................................................................................................... 4 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 A. B. C. D.

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!

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

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.

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

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.

Host

Tags

Figure E1.

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

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

10

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.

11

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

12

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].

13

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.

14

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.

15

Slave

Slave

A M aster

Slave

Slave

Slave

Figure E2.3 Piconet formation

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.

16

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.

17

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.
18

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

19

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

20

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.

21

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.

22

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.

23

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.

24

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

25

Power management unit

120dB Siren Driver

MCU

BT module

Power Management
Figure E3.1

Other that the main parts, the tag also contains the following components: Reset button Pin- header for in-system programming 2 status LEDs

26

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

27

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
28

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

29

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

30

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

31

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:

FMOD =

2850 Hz CMOD (61.5 + RT ( EXT )

where CMOD in uF, RT ( EXT ) in k

FOUT =

1710 Hz COUT (61.5 + RT ( EXT )

where COUT in uF, RT ( EXT ) in k

32

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.

33

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.

34

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].

35

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.

36

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.

37

MCU
Command

BT module

Status

Figure E4.3 Communication between MCU and BTR110

All command/status has the following format:

Cmd

Len

Payload

0xff

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.

38

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.

39

Main Routine Initialize UART/ Enable receive interrupt

Initialize IO Port

Initialize Timer/ Enable Timer interrupt

Set Connect as Slave always

Connected?

Yes

Reset Timer

No

Timer interrupt routine Timer elapsed

UART Receive interrupt routine Data Received

Reset Timer counter

Yes

Signal too weak? No Return

Trigger alarm

Trigger alarm

Return

Figure E4.4 Flow Chart of MCU program

40

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.

41

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.

42

BT1 BT2 BT3 BT4

. .
Time
Figure E.5.2 Simultaneous connections

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.

43

BT1 BT2 BT3 BT4 BT1 BT2

Time
Figure 5.3 Simultaneous connections

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.
44

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 Programmers Guide of WIDCOMM Bluetooth for Windows CE SDK [17].

45

Start session

Search Bluetooth devices in neighborhood

Filter out non-tag devices

Discover services

Initiate connection to nth tag

n=n+1
Alert user

Yes No
Connected?

No Yes
Signal too weak?

No

Stop button clicked?

Stop session Figure E5.6 Flowchart of host software

46

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

47

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)

48

Figure F.3 Connecting status

Figure F.4 Warning window

49

G. Cost Summary

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

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

Atmega8 BTR110B ZSD100 Speaker LS 14250 lithium battery MPS2222 ZTX790A ZTX690B

2 2 2 2 2

25 80 10 5 20

50 160 20 10 20

10 10 10

5 5 5

50 50 50

Miscellaneous components (Crystal, resistor, capacitor switch)

50

Grand Total Cost = ($HK) 460 Table G1. Cost summary of project.

50

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.

51

IBS: Integrated BlueGuard System

Securit

Remote Control

Do o r access

Figure H.1 Concept of the Integrated Blueguard SystemBluetooth

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.

52

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, Programmers Guide of WIDCOMM Bluetooth for Windows CE SDK

53

J. Appendix

Command sets of SPP330

Cmd Reserved Inquiry Pair as slave Connect as master Connect paired device Connect as slave Pair as master Connect as slave for paired device List paired devices Clear paired devices list Set discoverable Connect as Slave always Connect as Slave for paired devices always Reserved Connect with Bluetooth address Set baudrate Enter binary command mode Number

Value 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x24 0xfe

54