DESIGN REPORT BLUETOOTH AUTOMATION

Transcription

1 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

2 CONTENTS EXECUTIVE SUMMARY INTRODUCTION SOFTWARE DEVELOPMENT Introduction J2ME and JABWT Development Tools and Resources Top-Level Design Flow Diagram Module Design Stack Initialisation Module Device Discovery Module Simple Device Discovery via retrievedevices() Method Device Discovery via startinquiry() Method Service Discovery Module Communication Module Record Management Module Graphical User Interface (GUI) Module Test Specifications Testing on Emulator Testing on Mobile Phone Testing the Real Bluetooth Networking Software Testing Checklist HARDWARE DEVELOPMENT Top-Level and Module Design List of Components and Modules BlueSMiRF PIC Microcontroller RJ-11 Connector XM10 Two-Way Interface Module LM12U Controller Module Serial Cable RS-232 DB9 Male/Female Connector The Analogue Circuitry PCB Design Risk Evaluation Test Specifications DC Bias Test of the Circuit Timing Requirement Test Blueberry Product Test Hardware Testing Checklist CONCLUSION REFERENCES APPENDIX 1: Electrical Characteristics of the PL513 and TW i APPENDIX 2: List of Commercially Available JABWT Mobile Phones...ii APPENDIX 3: Glossary...ii Blueberry i

3 EXECUTIVE SUMMARY 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. Blueberry 1

4 1. INTRODUCTION 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. Blueberry 2

5 2. SOFTWARE DEVELOPMENT 2.1 Introduction 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 J2ME and JABWT 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. Blueberry 3

6 2.1.2 Development Tools and Resources 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 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 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) Blueberry 4

7 2.2 Top-Level Design Flow Diagram 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. t 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. w 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. Blueberry 5

8 Start program Is Bluetooth enabled? Refresh (from Figure 4) Are there any predefined devices stored in memory? Search for Bluetooth-enabled devices Any discovered devices? List predefined devices List discovered devices and store in memory User select device User select device Is selected device in range? Is selected device a Bluetooth transceiver? Is selected device a Bluetooth transceiver? Try again? Try again? Store address of switching module connected to transceiver Name switching module (numbering) Is address already saved in memory? Store in memory Name switching module with saved name Does user want to continue? Any more switching modules? Go to Main Menu window (Figure 4) End program Figure 3: Flow chart of Blueberry software (Part I - Initialisation) Blueberry 6

9 Main Menu window (from Figure 3) Profiles Instructions List of lights Refresh Exit Display instructions User select light Search for Bluetoothenabled devices (go to Figure 3) End program Change name? Change status? Store in memory Send data to transceiver Create new profile Open existing profile Name profile Select light Edit profile View profile Delete profile Select status Apply profile Store in memory Done? Save profile? Store in memory Apply profile? Send data to transceiver Figure 4: Flow chart of Blueberry software (Part II Main Menu) Blueberry 7

10 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 View View profile Apply Apply profile Edit Edit profile 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 2.3 Module Design 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 Stack Initialisation Module 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. Blueberry 8

11 2.3.2 Device Discovery Module 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 Simple Device Discovery via retrievedevices() Method 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 Display the list 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 Device Discovery via startinquiry() Method 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: Blueberry 9

12 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 Service Discovery Module 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 Communication Module 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 Blueberry 10

13 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 Record Management Module 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. Blueberry 11

14 2.3.6 Graphical User Interface (GUI) Module 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 2.4 Test Specifications Testing on Emulator 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. Blueberry 12

15 2.4.2 Testing on Mobile Phone 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 Testing the Real Bluetooth Networking 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 Software Testing Checklist 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.. 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). 1.3 Retrieve pre-known and cached devices by using retrievedevices() method. 1.4 Clear all pre-known and cached devices in memory. Perform device discovery when remote device is within reachable area. 1.5 Remote device information is already stored in memory. Perform device discovery when remote device is within reachable area. 1.6 Perform device discovery when remote device is not reachable. Bluetooth address, friendly name, discoverable mode, class of device, device properties. List of pre-known and cached device. Blueberry transceiver detected. Blueberry transceiver detected. Alert message. Blueberry 13

16 1.7 Once device discovery process is completed, select Blueberry transceiver from the device list (First time). 1.8 Once device discovery process is completed, select Blueberry transceiver from the device list (Pairing process has been completed). 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. Service discovery and serial port connection is done in the background. Main Menu is displayed. Alert message. 1.9 Select a non-blueberry transceiver device from the device list. 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 t allowed. application is sending them. 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. 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. problem when setting lights status. 3.6 Open profile and delete profile. Alert message asking user to 3.7 Turn off mobile phone. Turn on mobile phone and open Blueberry application. Check saved lights and profiles. Table 2: Software Testing Checklist confirm deletion. Saved lights and profiles remain in memory. Blueberry 14

17 3. HARDWARE DEVELOPMENT 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 nonradio-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. 3.1 Top-Level and Module Design 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 List of Components and Modules 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 BlueSMiRF Figure 8: BlueSMiRF Bluetooth Receiver [8] Blueberry 15

18 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 PIC Microcontroller 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. Figure 9: Microchip PIC16F688 [9] 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. Blueberry 16

19 Figure 10: Prototyping board [10] RJ-11 Connector 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. Figure 11: 6-pin RJ-11 Connector [11] XM10 Two-Way Interface Module 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 Blueberry 17

20 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] LM12U Controller Module 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. Blueberry 18

21 Serial Cable RS-232 DB9 Male/Female Connector 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 The Analogue Circuitry 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 Blueberry 19

22 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 PCB Design 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 Blueberry 20

23 3.2 Risk Evaluation 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. t 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. 3.3 Test Specifications For every stage of building the hardware, we will run a number of tests to ensure that it is operational DC Bias Test of the Circuit 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 Timing Requirement Test There is a strict timing requirement as specified in the X10 Technical te. [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. Blueberry 21

24 Figure 17: Timing Diagram taken from X10 Technical te [15] Blueberry Product Test 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. Blueberry 22

25 3.4.4 Hardware Testing Checklist 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 DC voltage level at the voltage regulator output in prototype board DC voltage supplied to PIC microcontroller DC voltage at the PWR pin of BlueSMiRF DC voltage supplied to interface between microprocessor and XM10 X10 envelope voltage level representing bit 1 X10 envelope voltage level representing bit 0 Table 4: DC Bias Test Expected 5 V 5 V 3.3 V < V < 10 V 5 V > 4 V < 0.8 V Test Expected Width of X10 envelope 1 ms - 50 µs µs Delay between X10 Maximum 50 µs envelope at XM10 input and trigger signal rising edge Table 5: X10 Timing Requirements 4. CONCLUSION 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. Blueberry 23

26 5. REFERENCES [1] The Java ME Platform - the Most Ubiquitous Application Platform for Mobile Devices, [2] JSR 82: Java TM APIs for Bluetooth, [3] NetBeans IDE Products, [4] JSR-82 Devices, [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 [5.3] pp [6] The Java APIs for Bluetooth Wireless Technology, Qusay H. Mahmoud, April 2003, [7] Sams Teach Yourself Wireless Java with J2ME in 21 Days, Micheal Morrison, Sams Publishing, 2001 [7.1] pp [8] Bluetooth Modem - BlueSMiRF, [9] [10] 14 Pin PIC Development Board, [11] RJ11 6-Pin Connector, [12] Two-way PLC Interface, [13] LM12U - UK 3-pin Lamp Module, [14] Serial Cable DB9 M/F - 6 Foot, [15] X10 Technical te, Powerhouse, ftp://ftp.x10.com/pub/manuals/technicalnote.pdf [16] Bluetooth: Connect Without Cables, Jennifer Bray, Charles F Struman, Prentice Hall PTR, 2001 te that all the websites above were available when accessed on 21 February Blueberry 24

27 APPENDIX 1 Electrical Characteristics of the PL513 and TW523 [15] Blueberry i

28 APPENDIX 2 List of Commercially Available JABWT Mobile Phones [4] 1. BenQ P30 2. Motorola A kia kia kia kia kia kia kia kia kia kia Sendo X 14. Siemens S Siemens S Siemens SK Sony Ericsson P900 and P Sony Ericsson P910a, P910c and P910i APPENDIX 3 Glossary TERM API CLDC GUI IDE J2ME J2SE JABWT DEFINITION Application Programming Interface. A set of routines, protocols and tools for building software applications. Connected Limited Device Configuration. The J2ME configuration for small handheld devices that are usually battery operated, low in memory and with limited processing power. 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. 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. 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. Java 2 Platform, Standard Edition. A collection of Java programming language APIs useful to many Java platform programs. Java APIs for Bluetooth Wireless Technology. A standardisation of Java APIs to incorporate Bluetooth technology with Java MIDlets. Blueberry ii