design report bluetooth automation - … · exterior lights using bluetooth compatible mobile...

29
IMPERIAL COLLEGE LONDON ELECTRICAL AND ELECTRONIC ENGINEERING 2006/07 PROJECTS FOR 3EM/3T STUDENTS GROUP DESIGN AND BUILD PROJECT FOR WIZZY ELECTRONICS LIMITED DESIGN REPORT BLUETOOTH AUTOMATION 22 FEBRUARY 2007 GROUP NAME : BLUEBERRY GROUP SUPERVISOR : DR CARLOS HERNANDEZ-ARAMBURO GROUP MEMBERS : 1. Ahmad Lutfi MOHAYIDDIN 2. Ijeoma Pamela NWANERI 3. Mohamad Hanafi SALEHUDDIN 4. Mohd Fairuz Azri YAHYA ARIF 5. Muhammad Fadhli MUSTAFFA 6. Ojiugo Chukwunonso NDUKWE

Upload: trinhhanh

Post on 03-Jul-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

IMPERIAL COLLEGE LONDON ELECTRICAL AND ELECTRONIC ENGINEERING

2006/07 PROJECTS FOR 3EM/3T STUDENTS

GROUP DESIGN AND BUILD PROJECT FOR

WIZZY ELECTRONICS LIMITED

DESIGN REPORT

BLUETOOTH AUTOMATION

22 FEBRUARY 2007

GROUP NAME

:

BLUEBERRY

GROUP SUPERVISOR

:

DR CARLOS HERNANDEZ-ARAMBURO

GROUP MEMBERS : 1. Ahmad Lutfi MOHAYIDDIN 2. Ijeoma Pamela NWANERI 3. Mohamad Hanafi SALEHUDDIN 4. Mohd Fairuz Azri YAHYA ARIF 5. Muhammad Fadhli MUSTAFFA 6. Ojiugo Chukwunonso NDUKWE

Bluetooth Automation Design Report

Blueberry i

CCOONNTTEENNTTSS__________________________________________________________________________________

EXECUTIVE SUMMARY........................................................................................................ 1

1. INTRODUCTION.................................................................................................................. 2

2. SOFTWARE DEVELOPMENT............................................................................................ 3

2.1 Introduction ................................................................................................................ 3

2.1.1 J2ME and JABWT ............................................................................................. 3

2.1.2 Development Tools and Resources .................................................................... 4

2.2 Top-Level Design – Flow Diagram ................................................................................. 5

2.3 Module Design ........................................................................................................... 8

2.3.1 Stack Initialisation Module ................................................................................ 8

2.3.2 Device Discovery Module.................................................................................. 9

2.3.2.1 Simple Device Discovery via retrieveDevices() Method............................... 9

2.3.2.2 Device Discovery via startInquiry() Method ................................................. 9

2.3.3 Service Discovery Module ............................................................................... 10

2.3.4 Communication Module................................................................................... 10

2.3.5 Record Management Module ........................................................................... 11

2.3.6 Graphical User Interface (GUI) Module .......................................................... 12

2.4 Test Specifications ................................................................................................... 12

2.4.1 Testing on Emulator ......................................................................................... 12

2.4.2 Testing on Mobile Phone ................................................................................. 13

2.4.3 Testing the Real Bluetooth Networking........................................................... 13

2.4.4 Software Testing Checklist .............................................................................. 13

3. HARDWARE DEVELOPMENT ........................................................................................ 15

3.1 Top-Level and Module Design ................................................................................ 15

3.1.1 List of Components and Modules .................................................................... 15

3.1.1.1 BlueSMiRF................................................................................................... 15

3.1.1.2 PIC Microcontroller ..................................................................................... 16

3.1.1.3 RJ-11 Connector........................................................................................... 17

3.1.1.4 XM10 Two-Way Interface Module.............................................................. 17

3.1.1.5 LM12U Controller Module .......................................................................... 18

3.1.1.6 Serial Cable RS-232 DB9 Male/Female Connector..................................... 19

3.1.2 The Analogue Circuitry.................................................................................... 19

3.1.3 PCB Design ...................................................................................................... 20

3.2 Risk Evaluation ........................................................................................................ 21

3.3 Test Specifications ................................................................................................... 21

3.4.1 DC Bias Test of the Circuit .............................................................................. 21

3.4.2 Timing Requirement Test................................................................................. 21

3.4.3 Blueberry Product Test..................................................................................... 22

3.4.4 Hardware Testing Checklist ............................................................................. 23

4. CONCLUSION .................................................................................................................... 23

5. REFERENCES..................................................................................................................... 24

APPENDIX 1: Electrical Characteristics of the PL513 and TW523 .......................................... i

APPENDIX 2: List of Commercially Available JABWT Mobile Phones................................. ii

APPENDIX 3: Glossary............................................................................................................. ii

Bluetooth Automation Design Report

Blueberry 1

EEXXEECCUUTTIIVVEE SSUUMMMMAARRYY______________________________________________________________ Technology is a never-ending process. To be able to design a product using the current technology that will be beneficial to the lives of others is a huge contribution to the community. Our group, Blueberry, hopes that we could play a role in taking home automation one step further. The project’s aim is to enable users to control interior and exterior lights using Bluetooth compatible mobile phones. In this design report, we present the technical features to develop our Blueberry product. We first briefly describe the concept of our product, aided by the top-level layout of the system as a whole. The subsequent two main sections describe the software and hardware developments for our product. The software development section begins with an overview of the Java 2 Platform, Micro Edition (J2ME) and Java application programming interfaces for Bluetooth wireless technology (JABWT). We explain the result of our research on these technologies and how they are used to create Java applications with Bluetooth functionalities on devices. This is followed by a review of the development tools and resources needed for the prototyping stage. Next, the top-level design of the software is illustrated in the form of flow diagrams. There is also a table showing the hierarchy of the main menu and submenus in the Blueberry software. Subsequently, the different modules that will be applied are explained. The main modules are the stack initialisation module, device discovery module, service discovery module, communication module, record management module and the graphical user interface (GUI) module. This will be followed by the strategies that will be used to test the software prototype and a checklist to ensure everything is according to plan. Similar to the software development section, the hardware development section also has descriptions of its top-level design, module design and test specifications. This part of the report gives details of the design of the Blueberry transceiver. It begins with a diagram of the hardware top-level design. We then describe the list of components and modules that will be implemented in the transceiver. The components are the BlueSMirF Bluetooth receiver, the PIC16F688 microcontroller, the RJ-11 Connector, the XM10 Two-Way Interface Module, the LM12U Controller Module and lastly, the Serial Cable RS-232 DB9 Male/Female Connector to be the link between the BlueSMirF Bluetooth receiver and the prototyping board. The analogue circuitry of the XM10’s interface followed by a diagram of our printed circuit board (PCB) layout will then be shown and explained. Subsequently, the risks involved in building the hardware are assessed and the test specifications for the transceiver are laid out. A hardware testing checklist is also included in this section. At the end of the report, we have added an appendix with three segments. Appendix 1 shows the electrical characteristics of two X10 devices while Appendix 2 displays a list of commercially available JABWT mobile phones. In Appendix 3, we have included a glossary of terms for all the abbreviations and uncommon terminologies used in our design report for the benefit of our readers.

Bluetooth Automation Design Report

Blueberry 2

11.. IINNTTRROODDUUCCTTIIOONN______________________________________________________________________ The report is intended to present the technical aspects for developing the Blueberry product. It acts as a technical note for one who is interested in realising the product or extending it further. It consists of the software and hardware developments. Each development will consist of its top-level design, module design and test specifications. The aim of this project is to incorporate Bluetooth technology with X10 technology which is popular in home automation. Specifically, we would like to remotely control the home lighting system using a mobile phone or personal digital assistance (PDA). Hence, we have to create a device that will be the interface between the mobile phone and the X10 interface module. The top-level layout is given as follows:

Figure 1: Top level diagram of Blueberry

Handheld devices which are either PDAs or mobile phones with Bluetooth will be installed with the Blueberry software. The Bluetooth protocol would be the standard to be used to send X10 commands wirelessly to the X10 interface. Using the power line, the commands will then pass on to the switching module. It will respond to the command which will instruct the luminaire to be either on, off or a certain level of brightness. All these require the development of two important components which are software and hardware. In the next sections, we will be presenting these two parts. The software must be able to interface with the user and also send the X10 commands using the Bluetooth protocol, while the hardware must ensure the flow of data reaches the controller module to execute the commands given. Apart from that, there will be some added features to the product.

Bluetooth Automation Design Report

Blueberry 3

22.. SSOOFFTTWWAARREE DDEEVVEELLOOPPMMEENNTT________________________________________________

22..11 IInnttrroodduuccttiioonn This section of the report describes the design for the software prototype in detail. We begin with a brief overview of the Java 2 Platform, Micro Edition (J2ME) and Java APIs for Bluetooth wireless technology (JABWT) and how these two technologies are used to create Java applications with Bluetooth functionalities on devices. Next, we will discuss the development tools and resources needed for the prototyping process. After that, the top-level design of the software is presented by means of flow diagrams with explanations. We will continue to go deeper into discussing the design of the individual modules in Java. The last part specifically deals with the testing strategies.

22..11..11 JJ22MMEE aanndd JJAABBWWTT

Java 2 Platform, Micro Edition (J2ME) is the collection of technologies and specifications to create a Java platform for applications running on a wide range of embedded devices such as mobile phones, pagers, personal organizers, set-top boxes and printers. [1] Due to the diversity of the devices, the J2ME architecture defines configurations, profiles and optional packages to allow modularity and customisability. One of the optional packages includes a set of application programming interface (API) that extends the J2ME by adding support for accessing Bluetooth wireless technology. In the year 2000, a team of experts was assembled under Java Specification Request 82 (JSR-82) with the task of defining a standard API for Bluetooth. The result of this collaboration was a specification for Java APIs for the Bluetooth wireless technology (JABWT). [2] The main goal of JABWT is to present access to Bluetooth technology by exploiting the easy but powerful features of Java language. To summarise, the JABWT enables programmers to develop Java applications for embedded devices with the following Bluetooth functionalities:

• Device discovery, service discovery and service registration

• Establishing connections for Bluetooth communication over protocols such as Radio Frequency Communication Protocol (RFCOMM), Logical Link Controller Adaptation Protocol (L2CAP) and Object Exchange Protocol (OBEX)

• Device management that deals with managing the connections, controlling device states and facilitating the security aspects of connections

Our team will utilise the Bluetooth functionalities offered by the JABWT to implement the solution for this project. One major advantages of using J2ME with JABWT for Bluetooth application development is that the software can be developed, debugged and tested on a computer before being deployed to a mobile phone. This will significantly speed up the development process and hence reduce the development cost. However, the choice may mean that the finished software could only be run on a limited number of mobile phones. The list of commercially available JABWT mobile phones can be found in Appendix 2.

Bluetooth Automation Design Report

Blueberry 4

22..11..22 DDeevveellooppmmeenntt TToooollss aanndd RReessoouurrcceess

1. Development Tool for Creating Java Wireless Applications

In this project we will use the Sun Java Wireless Toolkit 2.5 (JWTK) that can be downloaded from http://java.sun.com. In order to use this toolkit for Java applications development, the Java 2 Platform, Standard Edition Software Development Kit (J2SE SDK) must be pre-installed. The Sun Java Wireless Toolkit comes with build tools, utilities and a device emulator. The device emulator enables software emulation of a wide range of devices that support the Connected Limited Device Configuration (CLDC) and the Mobile Information Device Profile (MIDP) specifications.

2. Tool for Bluetooth Networking Simulation

A separate tool is needed to simulate the Bluetooth networking among devices. A simulation package, Impronto Simulator, developed by Rococo Software can be downloaded from http://www.rococosoft.com/java.html. This tool can be combined with the JWTK to provide an environment for quick testing before the application is deployed on real devices.

3. Java Integrated Development Environment (Java IDE)

Although the JWTK provides software emulation of devices, it lacks source code editing facility and debugging facility. Therefore, one might consider using a visual development environment such as the Netbeans IDE 5.5. The NetBeans Mobility Pack for CLDC/MIDP is an add-on that extends the functionality of the IDE for the creation of applications for mobile devices. [3]

4. JABWT Supported Mobile Phone

Figure 2: The Siemens SK65 [4]

We will use the Siemens SK65 mobile phone, shown in Figure 2, for final testing. This mobile phone supports these Java APIs:

• CLDC 1.1

• MIDP 2.0

• Java Technology for the Wireless Industry 1.0 (JSR-185)

• Mobile Media API 1.1 (JSR-135)

• Bluetooth API (JSR-82/JABWT)

• Location API (JSR-179)

• Mobile 3D Graphics API (JSR-184)

• Wireless Messaging API 1.1 (JSR-120)

Bluetooth Automation Design Report

Blueberry 5

22..22 TToopp--LLeevveell DDeessiiggnn –– FFllooww DDiiaaggrraamm This section will explain the flow of the software. It is assumed that the software has been installed on a compatible mobile phone or PDA. Users must enable Bluetooth on their phones before starting the program because there is no function to do so in the software. Bluetooth-compatible devices perform ‘inquiries’ to detect and find other Bluetooth-enabled devices within the area. When performing an inquiry, an application must wait to about 10 seconds for a 95% chance of detecting every device. Not only does this process take time, it also consumes power. To minimise the need for an inquiry and hence saving time and power, JABWT allows an application to retrieve a list of devices that would probably be in an area without performing an inquiry. These devices are called ‘predefined devices’. These devices are those already found and stored during previous inquiries. [5.1] Figures 3 and 4 show the flow diagrams of the Blueberry software. Figure 3 shows the initialisation procedure while Figure 4 shows the Main Menu user interface flow, which is the continuation of Figure 3. Two-way arrows mean that the process can flow in either direction. When starting the program, it first checks if Bluetooth is already enabled on the phone. If Bluetooth is enabled, the device and service discovery process will be run. The software will check if there are already predefined devices stored in the phone’s memory. If they do exist, they will be listed down for the user to select one. The program then checks to see if the selected device is in range. It will then verify if the device is a Blueberry transceiver. Now if they are no devices stored in memory, the program will search for Bluetooth-enabled devices within the area. Once discovered, these devices will be displayed on the screen and also stored in memory. Similar to the other option (when there are already predefined devices stored in memory), the selected device’s service will first be checked to ensure that it is a Blueberry transceiver. Once it is confirmed that the device is indeed a transceiver, the software will store the unique addresses of all the controller modules connected to it. If the address of a controller module has not been saved, then it will be designated a number i.e. ‘Light 1’. Otherwise, it will be given its saved name. After storing all connected controller modules’ names inside the phones’ memory, the Main Menu user interface will be displayed. If Bluetooth has not been enabled or the transceiver has not been detected, the user can still access the Main Menu, but there will be no lights stored in memory and of course, no data can be sent to the transceiver. In other words, the user can only browse through the program without making any changes. The Main Menu displays five options: ‘Profiles’, ‘List of Lights’, ‘Instructions’, ‘Refresh’ and ‘Exit’. All the submenus are shown in Table 1. The ‘Profiles’ section is the most challenging part of the software. A profile is a combination of one or more lights which have been preset to a certain status or state. These states are either on, off or a certain levels of brightness. There are two options to choose from in the ‘Profiles’ interface: ‘Create New Profile’ and ‘Open Existing Profile’. When creating a new profile, the user will first name it. Then, a controller module or lamp will be selected and its status set. This process will be repeated until the user does not want to add anymore lights or there are no more lights to be added to the profile. When done, the profile can be saved to the memory and applied. When the profile is to be applied, the software will send data to the Blueberry transceiver, which in turn will send the data to the controller modules.

Bluetooth Automation Design Report

Blueberry 6

Is Bluetooth

enabled?

End program

No

Yes

Are there any

predefined devices stored

in memory?

Store address of

switching module

connected to

transceiver

Start

program

Does user

want to

continue?

Yes

No

Yes

Is address already

saved in memory?

Name switching

module with saved

name

Name switching

module

(numbering)

Yes

No

Any more

switching

modules?

Yes No

No

Store in memory

Search for

Bluetooth-enabled

devices

List discovered

devices and store

in memory

List predefined

devices

User select device

Is selected

device a Bluetooth

transceiver?

User select device

Is

selected device

in range?

Yes

Yes

No

Any

discovered

devices?

No

Yes

Try

again?

No

No

Yes

Go to Main

Menu window

(Figure 4)

Is selected

device a Bluetooth

transceiver?

Try

again?

Yes

Yes

No No

Refresh (from Figure 4)

Figure 3: Flow chart of Blueberry software (Part I - Initialisation)

Bluetooth Automation Design Report

Blueberry 7

Send data to

transceiver

End program

Main Menu window

(from Figure 3)

Exit

Change

name?

Change

status?No No

Yes

Store in

memory

Yes

Create new

profile

Open existing

profile

Name profile

Select light

Select status

Done?

Save profile?

Apply profile?Send data to

transceiver

Store in

memory

Edit

profile

View

profile

Yes

Yes

Yes

No

No

No

Delete

profile

Apply

profile

Store in

memory

RefreshProfiles Instructions List of lights

User select

light

Display

instructions

Search for Bluetooth-

enabled devices (go to

Figure 3)

Figure 4: Flow chart of Blueberry software (Part II – Main Menu)

Bluetooth Automation Design Report

Blueberry 8

The second option in the ‘Profiles’ interface, ‘Open Existing Profile’, will list down all saved profiles, including default profiles already saved in the software. In this section, the user can ‘Edit’, ‘View’, ‘Apply’ or ‘Delete’ the profiles. To edit a profile, the software will go to the ‘Create New Profile’ flow. ‘View Profile’ will list down the profile’s name, selected lights and their status. The user also has the option to apply or delete the profile from the ‘View Profile’ interface. After a profile is applied and data sent to the transceiver, the Main Menu interface will be displayed again. The ‘List of Lights’ option in the Main Menu will display all the controller modules saved in memory. The user can modify the lights’ names and status from here. ‘Refresh’ will repeat the initialisation process while ‘Instructions’ will display instructions on how to use the software. Lastly, ‘Exit’ will let the user end the program.

Menu Function

1. Profiles Display profile options

1.1 New Create new profile

1.2 Open Open existing profile

1.2.1 View View profile

1.2.2 Apply Apply profile

1.2.3 Edit Edit profile

1.2.4 Delete Delete profile

2. List of Lights Display list of lights connected to transceiver

2.1 Name Name light

2.2 Set status Set status of light

3. Instructions Display instructions on how to use program

4. Refresh Check Bluetooth connectivity again

5. Exit End program

Table 1: Functions of the main menu and submenus for the user interface of the Blueberry software

22..33 MMoodduullee DDeessiiggnn Our Java application can be broken down into several modules to perform different tasks. The intention here is not to present the Java classes, methods and events extensively but to briefly discuss how JABWT is used to implement some main modules.

22..33..11 SSttaacckk IInniittiiaalliissaattiioonn MMoodduullee

Bluetooth stack is a piece of software or firmware that manages and controls a Bluetooth device. The stack initialisation process will involve a number of steps to get the Bluetooth device ready for wireless communication. This means setting several parameters such as serial port name, baud rate, connectable mode and discoverable mode. However, this process is vendor-dependent and is not part of the JABWT. [6] In this project, we will use the software provided with the BlueSMiRF device for the initialisation.

Bluetooth Automation Design Report

Blueberry 9

22..33..22 DDeevviiccee DDiissccoovveerryy MMoodduullee

The main aim of this module is to perform the device discovery or also known as inquiry in Bluetooth terminology. We will use the DiscoveryAgent class defined in the JABWT. This class provides two ways of discovering devices, via the retrieveDevices() method and the startInquiry() method.

22..33..22..11 SSiimmppllee DDeevviiccee DDiissccoovveerryy vviiaa rreettrriieevveeDDeevviicceess(()) MMeetthhoodd

Since sending inquiry signals consumes a lot of power, it is wise to interact with the local device (mobile phone) first to retrieve the information of the pre-known and the cached Bluetooth devices. Pre-known devices are the devices that the mobile phone communicates regularly with, while cached devices are the devices that have been found via previous inquiries. This educated guess may mean that no new inquiry signal has to be sent if the remote device’s information is already known. As previously stated, this reduces the power consumption and hence saves battery. The following algorithm shows the approach taken to interact with the mobile phone Bluetooth stack and display the list of known devices: Get the DiscoveryAgent object of the local device If retrieving local Bluetooth device causes error, stop application and display error message Else create a new list to be displayed, check the pre-known device array If not null, append the addresses of the pre-known Bluetooth devices to the list, move to cached device array when finish If null, move to cached device array, append all the addresses of the cached Bluetooth devices to the list Display the list

22..33..22..22 DDeevviiccee DDiissccoovveerryy vviiaa ssttaarrttIInnqquuiirryy(()) MMeetthhoodd

The startInquiry() method requires the Bluetooth radio to issue requests for all Bluetooth devices within the reachable area to respond according to their discoverable mode. As devices are found, they are passed back to the application via the deviceDiscovered() event along with the information such as the type of device and the services available. The JABWT also provides the event inquiryCompleted() to notify the application that the inquiry has been completed. There are three reasons for completion: the inquiry has been executed successfully, the user/application terminates the inquiry or an error occurs during the process. The following is the algorithm for the inquiry process:

Bluetooth Automation Design Report

Blueberry 10

Get the DiscoveryAgent object of the local device If retrieving local Bluetooth device causes error, stop application and display error message Else start inquiry process If error occurs, end inquiry process Else If user/application terminates inquiry process, end inquiry process Else call deviceDiscovered() event for each time a new device is discovered Display device’s Bluetooth address on screen When finish, end inquiry process When inquiry ends call inquiryCompleted() event, display reason for completion

22..33..33 SSeerrvviiccee DDiissccoovveerryy MMoodduullee

Once the list of devices has been retrieved via the device discovery, the next step is to search for services available on the remote Bluetooth device. Similar to the inquiry, the service records are passed to the application as events. Also, at the end of a service search, a notification is sent to the application. The JABWT provides a simple method that performs both device and service discovery: the selectService() method. This method allows the application to specify a single Universally Unique Identifier or UUID that is used to locate the requested service on the remote device. The method then returns a connection string that can be used to connect to the service found. Before the services on the remote device can be discovered, they must be registered as service records in the Service Discovery Database (SDDB). However, since most of the process involving service records is done automatically by the JABWT [5.2], there is no need to be concerned about service records management. To put the discussion into context, we will describe how service discovery works between the application on the mobile phone and the Blueberry transceiver. After device discovery, the user will be presented by the list of Bluetooth devices. From this list, the user selects the Blueberry transceiver. At this point, the application will request for the RFCOMM service from the Blueberry transceiver by specifying the UUID for that service. If an error occurs, the user will be notified by the application or else the RFCOMM connection is ready to be established. One important point to note is that most of the process is done in the background and is transparent from the user. In the next section, we will discuss more about the connection over the RFCOMM protocol.

22..33..44 CCoommmmuunniiccaattiioonn MMoodduullee

The Serial Port Profile (SPP) is the Bluetooth profile that realises the RFCOMM connection between two devices. The RFCOMM protocol is an emulation of the RS-232 serial port connection of two devices over a wireless link [5.3]. In our project, we are interested to establish an RFCOMM connection between the application on the mobile phone and the

Bluetooth Automation Design Report

Blueberry 11

Blueberry transceiver. Once the connection is established, binary streams can be exchanged between the two devices. The RFCOMM communication will begin with the Connector.open() method and a valid connection string which is passed by the selectService() method during the service discovery process. Along with the valid string, several optional parameters can be specified whether to authenticate, encrypt or authorise the connection for security reason. We will design the connection between the mobile phone and the Blueberry transceiver as a client-server model. The former will act as the client while the latter as the server. After the RFCOMM connection has been made, the client will start sending the binary streams or the X10 commands. To make sure the correct data is received, the client will wait for the server to echo an acknowledgement signal back or until a specific time has run out. During this verification procedure, the process of sending data is halted. This is to ensure that the server is not bombarded with binary streams when it is not ready. However, this may mean that the application will appear to be frozen to the user. One solution that could be considered is by implementing a queue structure to buffer the data received by the server.

22..33..55 RReeccoorrdd MMaannaaggeemmeenntt MMoodduullee

In our application, there is a need to store information such as the lighting profiles and the light names. The nature of mobile wireless devices with limited memory means that a new approach must be taken on how to store data. In a mobile device, the database file known as record store is technically stored somewhere in the device’s memory system. So far our discussion revolves around the APIs defined in the JABWT but this time we will introduce the MIDP Record Management System (RMS). [7.1] The main premise behind RMS is to allow data to exist even after the application is terminated. The RMS package comes with classes, methods and interfaces for RMS-related functions. This package not only allows developers to add, delete, open and close records but also traverse forward and backward through the record store. It also provides ways to compare and filter records. In our design, we will define two record stores, Profile and Lamp. The relationship between these two record stores is a one-to-many relationship. Each element in the record store is given a unique identifier (ID) along with the relevant attributes. Figure 5 shows the relationship diagram of the two record stores.

PROFILE

Profile_ID

Profile_Name

Lamp_ID

LAMP

Lamp_ID

Lamp_Address

Lamp_Name

Lamp_Setting

Figure 5: Relationship diagram of record stores. Each profile is associated with one or more lamps via the common field.

Bluetooth Automation Design Report

Blueberry 12

22..33..66 GGrraapphhiiccaall UUsseerr IInntteerrffaaccee ((GGUUII)) MMoodduullee

The most important feature of our application is to hide several processes from the user while allowing some degree of interaction with the application. Although the limitation imposed by the mobile device display might mean that the user interface will not be as rich as the standard Java GUI, the MIDP API still packs a lot of GUI components to interact with the user. By using the GUI package, we will be able to customise the application to include a variety of user interface elements such as text boxes, choice groups, alert messages, lists and command buttons. Figure 6 illustrates some designs for the graphical user interface.

Figure 6: Design examples for the GUI

22..44 TTeesstt SSppeecciiffiiccaattiioonnss

22..44..11 TTeessttiinngg oonn EEmmuullaattoorr

The Sun Java Wireless Toolkit 2.5 comes with an emulator to test the application during the development stage on a computer. This emulator is quite flexible and can emulate a wide range of target devices such as mobile phones, pagers and even custom devices defined by the programmer. However there are some limitations of the emulator that will be discussed in the next section. This emulator is a useful tool to test the parts of the application that do not involve Bluetooth networking such as the RMS and the GUI. To test the Bluetooth capability of the application on a computer, we combine the Sun Java Wireless Toolkit 2.5 with the Impronto Simulator by Rococo Software. By using these tools, we could emulate the device discovery process, service discovery process and perform RFCOMM connection for various operating conditions.

Bluetooth Automation Design Report

Blueberry 13

22..44..22 TTeessttiinngg oonn MMoobbiillee PPhhoonnee

As stated in the previous section, the emulator has some limitations that cannot replace the real device testing. Physical mobile devices have different hardware implementation with different processor speeds. The J2ME emulator has no feature that allows the emulation of application on various processor speeds. Therefore, there is no other way to assess the execution speed of an application but through testing on real devices. Another feature that is not supported by the emulator is the amount of memory available in target devices. This is important particularly when we want to make sure the design of the RMS and GUI will not exhaust the limited memory resource of a mobile device. The last limitation of the emulator is that it cannot emulate on how the application manager for a particular mobile phone installs, removes or executes Java applications.

22..44..33 TTeessttiinngg tthhee RReeaall BBlluueettooootthh NNeettwwoorrkkiinngg

While the software might work flawlessly on its own, there is no guarantee that it will work with the Blueberry transceiver. This is the time when the software development team and the hardware development team will sit together to test, debug and eliminate errors that might become apparent when both software and hardware are integrated together to make the final product.

22..44..44 SSooffttwwaarree TTeessttiinngg CChheecckklliisstt

The table below shows the checklist for the testing. The main aim is to test some of the crucial parts of the software. This checklist will be reviewed accordingly during the prototyping stage.

No. Test Expected Result

1 Device Discovery and Service Discovery

1.1 Retrieve information from local Bluetooth device (Mobile phone).

Bluetooth address, friendly name, discoverable mode, class of device, device properties.

1.2 Retrieve information from remote Bluetooth device (BlueSMiRF).

Bluetooth address, friendly name, discoverable mode, class of device, device properties.

1.3 Retrieve pre-known and cached devices by using retrieveDevices() method.

List of pre-known and cached device.

1.4 Clear all pre-known and cached devices in memory. Perform device discovery when remote device is within reachable area.

Blueberry transceiver detected.

1.5 Remote device information is already stored in memory. Perform device discovery when remote device is within reachable area.

Blueberry transceiver detected.

1.6 Perform device discovery when remote device is not reachable.

Alert message.

Bluetooth Automation Design Report

Blueberry 14

1.7 Once device discovery process is completed, select Blueberry transceiver from the device list (First time).

Service discovery is done in the background. A message will appear asking user’s permission to establish serial port connection. User will be asked to enter PIN.

1.8 Once device discovery process is completed, select Blueberry transceiver from the device list (Pairing process has been completed).

Service discovery and serial port connection is done in the background. Main Menu is displayed.

1.9 Select a non-Blueberry transceiver device from the device list.

Alert message.

2 Communication

2.1 Turn ON a light. Correct X10 commands are transmitted and received.

2.2 Turn OFF a light. Correct X10 commands are transmitted and received.

2.3 Test the bright and dim functions. Correct X10 commands are transmitted and received.

2.4 Create a new profile with 3 lights. Set Light 1 to ON, Light 2 to OFF and Light 3 to 40%. Apply profile. Measure delay between commands.

Correct X10 commands are transmitted and received one at a time. Delay between commands is reasonable.

2.5 Try cancelling the commands while the application is sending them.

Not allowed.

3 RMS and GUI

3.1 Go back and forth through the GUI screens. The screens are linked together correctly.

3.2 Check layout on every GUI screens. Appear correctly relative to the mobile phone’s screen display.

3.3 Add three new lights. Change the last light’s name. Save setting.

Default name for lights are Light 1, Light 2, Light 3 and so on. No problem when renaming lights.

3.4 Delete Light 1. Alert message asking user to confirm deletion.

3.5 Create a new profile. Add lights to profile from list of lights. Set status of lights.

Only lights that have been registered are displayed. Default name for profiles are Profile 1, Profile 2, Profile 3 and so on. No problem when setting lights status.

3.6 Open profile and delete profile. Alert message asking user to confirm deletion.

3.7 Turn off mobile phone. Turn on mobile phone and open Blueberry application. Check saved lights and profiles.

Saved lights and profiles remain in memory.

Table 2: Software Testing Checklist

Bluetooth Automation Design Report

Blueberry 15

33.. HHAARRDDWWAARREE DDEEVVEELLOOPPMMEENNTT________________________________________________ This section is dedicated to describing the components that will be used in the creation of the hardware prototype for this project. We need to design a circuitry to establish a physical connection between the Bluetooth receiver and the X10 device. The current task at hand is the design and implementation of the Blueberry transceiver.

The top-level and module design process will focus more on the hardware that we have to create in order for us to interface the Bluetooth aspect of this project to an ordinary non-radio-frequency or non-RF device. It will consist of all the fundamental designs and decisions made towards the completion of the prototype. We will be introducing the products that we intend to use in the production process and the tests that we have planned for our final product.

33..11 TToopp--LLeevveell aanndd MMoodduullee DDeessiiggnn

Figure 7: Top Level Design of Blueberry Transceiver

Figure 7 illustrates the top-level design of the hardware. The Bluetooth antenna in our module will pick up the packets sent from the mobile device. The arrows in the diagram above indicate the number of connections whether physical or virtual that is occurring while the device is in operation i.e. 4 arrows will lead to 4 connections. Subsequently, these packets containing the X10 commands are pipelined through to the PIC microcontroller and the designed analogue circuitry block according to the definition of each output. The output of the circuit is then connected to an RJ-11 connector. This RJ-11 connector would make the program much simpler.

33..11..11 LLiisstt ooff CCoommppoonneennttss aanndd MMoodduulleess

We have searched the market for the parts that will be implemented in the hardware. The crucial point of this task is to transmit a Bluetooth packet which contains the X10 commands and make it go through to the XM10 via an RJ-11 connector.

33..11..11..11 BBlluueeSSMMiiRRFF

Figure 8: BlueSMiRF Bluetooth Receiver [8]

Bluetooth Automation Design Report

Blueberry 16

Figure 9: Microchip

PIC16F688 [9]

For the Bluetooth receiver, we want something that is as convenient as the current Bluetooth dongle and also to be as open-sourced as possible which will allow us the freedom of what to do with it. The BlueSMiRF, shown in Figure 8, fulfils all these requirements. This raw component will allow us to understand more about the send-receive process and expand our creativity with the functions of our hardware. This device has 6 output pins, each with different functions. What we will do is attach this to a PCB board with the correct supply biasing as the start of our circuitry. We will be using a 5V power supply to bias the receiver. From the datasheet, it is stated that the current consumption will be around 48mA on the first time of activation. This can be reduced to an average of 25mA depending on its current activity. For example, when a constant stream of data is sent to the receiver, the current consumption was measured to be 33mA. The pins on the BlueSMiRF have different functions. The following table would briefly explain all of them:

Pins Description

PWR Power supply input 3-10V

GND Common ground for the component

TX-O Transmit from BlueSMiRF – Serial Output

RX-I Receive into BlueSMiRF – Serial Input

CTS-I Clear-To-Send into the BlueSMiRF

RTS-O Ready-To-Send from the BlueSMiRF Table 3: Descriptions of BlueSMiRF pins' functions

The pins that will be implemented are the PWR, GND, TX-O and RX-I. The CTS-I pin and RTS-O pin, which are not used are connected together to short-circuit them. Those pins are compatible with the Universal Asynchronous Receiver/Transmitter (UART). We can use it with the RS-232 protocol along with the serial cable. Power supply for the Bluetooth module will be supplied from the cable.

33..11..11..22 PPIICC MMiiccrrooccoonnttrroolllleerr

The X10 input data must meet the timing requirement to ensure it is synchronised with the AC power line at zero crossing point. Only one bit will be sent at every zero crossing point. In order for us to comply with the requirement, we will use a microcontroller as the solution. We have selected the PIC Microcontroller to be the microprocessor as it is cheap and widely used in home automation.

For this project, we chose the PIC16F688 as our microcontroller chip. It is a 14-pin chip with an 8-bit processor and runs up to 20 MHz. The microcontroller will be programmed using assembly language. It will then be implemented in the prototype board shown in Figure 10. There is a 20 MHz external oscillator to drive up the chip. The RS-232 DB9 port will be the interface for the external device. As mentioned earlier, we will use it as the interface

for the BlueSMiRF module.

Bluetooth Automation Design Report

Blueberry 17

Figure 11: 6-pin RJ-11

Connector [11]

Figure 10: Prototyping board [10]

33..11..11..33 RRJJ--1111 CCoonnnneeccttoorr

If the BlueSMiRF is the starting point of our transceiver, then this component will surely be the finisher for our hardware. This is the 6-pin RJ-11 (Figure 11) connector which allows us to connect the output of our circuit directly into the XM10 through an RJ-11 cable. It has a 6-pin input which can be defined separately. We are only going to use 4 pins of this component since the output for the circuitry is 4.

33..11..11..44 XXMM1100 TTwwoo--WWaayy IInntteerrffaaccee MMoodduullee

Figure 12: XM10 Two-way Interface Module [12]

The figure above shows the main device of this project. This is the X10 XM10 two-way interface module. This is the UK version of the TW523 module from the US. It basically does the same thing with the only difference being that it is suitable for appliances here. This module works both ways as a transmitter as well as a receiver. The device will receive the

Bluetooth Automation Design Report

Blueberry 18

signal sent by a Bluetooth-enabled mobile device which propagates through the designed hardware that will be explained later on. The XM10 uses the X10 code format that is the standard for Power Line Carrier (PLC) transmission. When an X10 instruction is sent from our hardware, the XM10 will modulate this command with a 120 kHz carrier. This modulated signal will take the form of small bursts of 1ms which is propagated into the 50Hz power line carrier. The signal will be transmitted two more times to coincide with the three-phase shifts in the three-phase distribution system. The transmission theory defines the ‘1’s and ‘0’s according to the synchronicity of the packet bursts with the zero crossing of the 50Hz carrier. A ‘1’ is defined from the presence of this signal at a zero crossing while a ‘0’ is due to its absence. The code transmission consists of 11 cycles of the power line. The first two cycles are for the Start Code. The next four cycles represent the House Code and the last five cycles are for the Number Code or Function Code. This complete code has to be transmitted twice with a gap of three power line cycles in between. Hence, the overall power line cycles is 25 cycles. The codes will make their way to our controller module which is located at another output socket. Beforehand, the controller module has been assigned a specific House Code and Number Code. If both codes sent are an exact match with the controller’s address then the command will be taken in and executed. [15]

33..11..11..55 LLMM1122UU CCoonnttrroolllleerr MMoodduullee

Figure 13: LM12U Controller Module [13]

Once the XM10 receives an X10 command, it will propagate the instructions through the use of the power line. These instructions will reach the controller module above which is readily connected with a lamp. The LM12U can interpret the X10 commands and control the light with several features. This module has the capability of providing a lighting profile such as DIM to dim the light accordingly. From the figure above, we can see the 2 dials which are labelled alphabetically on the left and numerically on the right. This is what assigns the House Code and Number Code to the module. By turning these dials to A and 1 then this module is recognized as unit A1. Hence due to the unique addressing format we can clearly choose some personalized functions to any unit as long as it is connected to the same power line network. The electrical characteristics of the TW523 and PL513, which are similar to the XM10 and LM12U devices respectively, are shown in Appendix 1.

Bluetooth Automation Design Report

Blueberry 19

33..11..11..66 SSeerriiaall CCaabbllee RRSS--223322 DDBB99 MMaallee//FFeemmaallee CCoonnnneeccttoorr

Figure 14: Serial Cable DB9 Male/Female Connector [14]

This cable is essential for the interface between the BlueSMiRF and the prototyping board as explained in previous sections.

33..11..22 TThhee AAnnaalloogguuee CCiirrccuuiittrryy

The following circuit is obtained from the XM10 technical notes. It is the suggested circuitry for those who intend to use their own hardware to connect with the XM10.

Figure 15: Circuitry to interface XM10 from microcontroller [15]

The circuit shown in Figure 15 will act as the data level shifter from the output of the Original Equipment Manufacturer (OEM) product to XM10. This will ensure the data voltage level that

Bluetooth Automation Design Report

Blueberry 20

arrives at the input of the XM10 conform to the requirements stated in the technical note. SPICE analysis has been done on the circuit above. In terms of DC biasing, output 4 has been found out to be 2.4V. Output 1 and 3, which bear the same configuration, have the same voltage output, which is 0.098V.

33..11..33 PPCCBB DDeessiiggnn

In order for us to have that professional finish we decided to have a printed circuit board according to our analogue circuitry by designing it using the EAGLE software used in our second-year design project. This easy-to-use software will allow us to create the circuit schematics and printed circuit board (PCB) layout. The designed circuit board and schematics is shown below in Figure 16.

Figure 16: PCB Layout of the Hardware

Bluetooth Automation Design Report

Blueberry 21

33..22 RRiisskk EEvvaalluuaattiioonn We believe that the hardware component of the project will certainly have several risks. One of them is the reliability of the core component which is the XM10. Up until this point all the explanations are based on technical notes, speculations and other references. Not being able to confirm the details has proven to be a disadvantage for us because of the unknown factor. However, this problem will surely be overcome once we have acquired all the components for our prototype. Another unknown for this project is the existence of feedback in our system. It has been questioned whether it is possible for the XM10 or the controller module to provide us some kind of feedback maybe stating the successful execution of a command. This matter is yet to be investigated.

33..33 TTeesstt SSppeecciiffiiccaattiioonnss For every stage of building the hardware, we will run a number of tests to ensure that it is operational.

33..44..11 DDCC BBiiaass TTeesstt ooff tthhee CCiirrccuuiitt

This test is to check whether the DC levels of the circuit are in accordance with the expected value. Correct biasing is critical as supplying an electronic device with a higher voltage then rated will cut short its lifespan. The circuit will be supplied with 9 V. All the devices however need 5 V to operate. Hence, we must ensure that output of the voltage regulator is about 5 V. The voltage input at all the devices’ supply input must be 5 V.

33..44..22 TTiimmiinngg RReeqquuiirreemmeenntt TTeesstt

There is a strict timing requirement as specified in the X10 Technical Note. [15] Hence, we have to run a test to ensure that the data flow follow the timing diagram shown in Figure 17. There will be various points between the microcontroller and the XM10 for this test to be carried out. A trigger signal which is a 60 Hz square wave will be sent from the XM10 when it detects zero crossing of the AC power line. Within 50 µs, an X10 envelope of 1 ms width must be transmitted by the microcontroller. The envelope will represent bit ‘1’ if it is high or ‘0’ otherwise. Using an oscilloscope, we will put a probe at the input of the XM10 and also the zero crossing output pin. Then, we will compare both signals to see whether it meets the timing requirement as illustrated in Figure 17. Adjustments are made to the microcontroller software to ensure that both the transmitted and trigger signals are synchronised.

Bluetooth Automation Design Report

Blueberry 22

Figure 17: Timing Diagram taken from X10 Technical Note [15]

33..44..33 BBlluueebbeerrrryy PPrroodduucctt TTeesstt

When all the different components of the hardware are in place, the product will be tested to ensure that it works according to the specifications outlined earlier. Along with the software, the communication test as mentioned in the software specification checklist will be run.

Bluetooth Automation Design Report

Blueberry 23

33..44..44 HHaarrddwwaarree TTeessttiinngg CChheecckklliisstt

The tables below show the checklist for the testing of the hardware. Table 4 shows the DC bias test checklist while Table 5 shows the timing requirements checklist. These checklists will be reviewed accordingly during the prototyping stage.

Test Expected

DC voltage level at the voltage regulator output in prototype board

5 V

DC voltage supplied to PIC microcontroller

5 V

DC voltage at the PWR pin of BlueSMiRF

3.3 V < V < 10 V

DC voltage supplied to interface between microprocessor and XM10

5 V

X10 envelope voltage level representing bit ‘1’

> 4 V

X10 envelope voltage level representing bit ‘0’

< 0.8 V

Table 4: DC Bias Test

Test Expected

Width of X10 envelope 1 ms - 50 µs + 100 µs

Delay between X10 envelope at XM10 input and trigger signal rising edge

Maximum 50 µs

Table 5: X10 Timing Requirements

44.. CCOONNCCLLUUSSIIOONN________________________________________________________________________

This report encompasses the technical discussion of our Bluetooth automation project. From the report we can say that the hardware and software parts of this project have equal weightings. We are certain that the development of both parts will be time consuming and challenging. For the hardware we will worry about programming the PIC microcontroller while for the software, we will have to handle the Bluetooth protocols and Java programming. We had also taken into account the possible risks that we will be facing in both areas of this project. This risk evaluation is a measure of precaution that must be taken so that we can prepare ourselves for what is ahead during the implementation session of this project.

Bluetooth Automation Design Report

Blueberry 24

55.. RREEFFEERREENNCCEESS________________________________________________________________________ [1] The Java ME Platform - the Most Ubiquitous Application Platform for Mobile Devices,

http://java.sun.com/javame/index.jsp [2] JSR 82: JavaTM APIs for Bluetooth, http://jcp.org/en/jsr/detail?id=82 [3] NetBeans IDE Products, http://www.netbeans.org/products/index.html [4] JSR-82 Devices, http://www.javabluetooth.com/jsr82devices.html [5] Bluetooth Application Programming With The JAVA APIs, C Bala Kumar, Paul J Kline,

Timothy J Thompson, Morgan Kaufmann Publishers, 2004 [5.1] pp. 113 [5.2] pp. 139-204 [5.3] pp. 51-76

[6] The Java APIs for Bluetooth Wireless Technology, Qusay H. Mahmoud, April 2003, http://developers.sun.com/techtopics/mobility/midp/articles/bluetooth2

[7] Sams Teach Yourself Wireless Java with J2ME in 21 Days, Micheal Morrison, Sams Publishing, 2001 [7.1] pp. 281-307

[8] Bluetooth Modem - BlueSMiRF, http://www.sparkfun.com/commerce/product_info.php?products_id=582

[9] http://www.picbasic.it/E-commerce/Immagini/imgpiccole/16F688ISL.jpg [10] 14 Pin PIC Development Board,

http://www.sparkfun.com/commerce/product_info.php?products_id=16 [11] RJ11 6-Pin Connector,

http://www.sparkfun.com/commerce/product_info.php?products_id=132 [12] Two-way PLC Interface,

http://www.simplyautomate.co.uk/productDisplay.asp?prodId=3523 [13] LM12U - UK 3-pin Lamp Module,

http://www.laser.com/?page=shop/flypage&product_id=30&category_id=& [14] Serial Cable DB9 M/F - 6 Foot,

http://www.sparkfun.com/commerce/product_info.php?products_id=65 [15] X10 Technical Note, Powerhouse, ftp://ftp.x10.com/pub/manuals/technicalnote.pdf [16] Bluetooth: Connect Without Cables, Jennifer Bray, Charles F Struman, Prentice Hall

PTR, 2001 Note that all the websites above were available when accessed on 21 February 2007.

Bluetooth Automation Design Report

Blueberry i

AAPPPPEENNDDIIXX 11________________________________________________________________________________

EElleeccttrriiccaall CChhaarraacctteerriissttiiccss ooff tthhee PPLL551133 aanndd TTWW552233 [15]

Bluetooth Automation Design Report

Blueberry ii

AAPPPPEENNDDIIXX 22________________________________________________________________________________

LLiisstt ooff CCoommmmeerrcciiaallllyy AAvvaaiillaabbllee JJAABBWWTT MMoobbiillee PPhhoonneess [4] 1. BenQ P30 2. Motorola A1000 3. Nokia 3230 4. Nokia 6230 5. Nokia 6260 6. Nokia 6600 7. Nokia 6620 8. Nokia 6630 9. Nokia 6670 10. Nokia 7710 11. Nokia 9300 12. Nokia 9500 13. Sendo X 14. Siemens S65 15. Siemens S66 16. Siemens SK65 17. Sony Ericsson P900 and P908 18. Sony Ericsson P910a, P910c and P910i

AAPPPPEENNDDIIXX 33________________________________________________________________________________

GGlloossssaarryy

TERM DEFINITION

API Application Programming Interface. A set of routines, protocols and tools for building software applications.

CLDC Connected Limited Device Configuration. The J2ME configuration for small handheld devices that are usually battery operated, low in memory and with limited processing power.

GUI Graphical User Interface. A type of user interface used for interaction with a computer which employs graphical images and text to represent the information and actions available to a user.

IDE Integrated Development Environment. A programming environment integrated into a software application that provides a GUI builder, a text or code editor, a compiler and/or interpreter and a debugger.

J2ME Java 2 Platform, Micro Edition. J2ME allows developers to use Java and the J2ME wireless toolkit to create applications and programs for wireless and mobile devices.

J2SE Java 2 Platform, Standard Edition. A collection of Java programming language APIs useful to many Java platform programs.

JABWT Java APIs for Bluetooth Wireless Technology. A standardisation of Java APIs to incorporate Bluetooth technology with Java MIDlets.

Bluetooth Automation Design Report

Blueberry iii

TERM DEFINITION

JSR-82 Java Specification Request-82. A Java Micro Edition specification for APIs that allow Java MIDlets to use Bluetooth on supporting devices.

JWTK Sun Java Wireless Toolkit 2.5. This is Sun Microsystems' answer to a consumer wireless device platform.

L2CAP Logical Link Control and Adaptation Protocol. Used within the Bluetooth protocol stack. It passes large packets across Bluetooth links and also provides multiplexing for higher layer protocols and services.

MIDlet A Java application that conforms to the MIDP specification for mobile devices.

MIDP Mobile Information Device Profile. A set of J2ME APIs that define how software applications interface with mobile phones and pagers. Applications conforming to this standard are called MIDlets.

OBEX Object Exchange Protocol. A communications protocol which allows devices to exchange binary objects, using IrDA or Bluetooth.

RFCOMM Radio Frequency Communication. A protocol for RS-232 serial cable emulation over a wireless link.

RJ-11 Registered Jack-11. A telephone connector that holds up to four wires.

RMS Record Management System. A set of classes and interfaces that provide support for a simple database system that is geared to storing MIDlet data.

RS-232 Recommended Standard-232. A standard developed by the Electronic Industries Association that governs the interface between data processing and data communications equipment, and is widely used to connect microcomputers to peripheral devices.

SDDB Service Discovery Database. Information about services supported by a Bluetooth device.

SDK Software Development Kit. A programming package that enables a programmer to develop applications for a specific platform. An SDK usually includes one or more APIs, programming tools, and documentation.

SPP Serial Port Profile. A Bluetooth specification on how serial ports should be emulated in Bluetooth products.

UART Universal Asynchronous Receiver/ Transmitter. A hardware which translates data between parallel and serial interface.

UUID Universally Unique Identifier. A 128-bit number derived by a method which guarantees it will be unique.