DESIGN REPORT BLUETOOTH AUTOMATION

machinebrainySoftware and s/w Development

Jun 8, 2012 (5 years and 1 month ago)

694 views


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

C
C
O
O
N
N
T
T
E
E
N
N
T
T
S
S
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_



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

E
E
X
X
E
E
C
C
U
U
T
T
I
I
V
V
E
E


S
S
U
U
M
M
M
M
A
A
R
R
Y
Y
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_



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
3

2
2
.
.


S
S
O
O
F
F
T
T
W
W
A
A
R
R
E
E


D
D
E
E
V
V
E
E
L
L
O
O
P
P
M
M
E
E
N
N
T
T
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_



2
2
.
.
1
1


I
I
n
n
t
t
r
r
o
o
d
d
u
u
c
c
t
t
i
i
o
o
n
n



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.

2
2
.
.
1
1
.
.
1
1


J
J
2
2
M
M
E
E


a
a
n
n
d
d


J
J
A
A
B
B
W
W
T
T



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

2
2
.
.
1
1
.
.
2
2


D
D
e
e
v
v
e
e
l
l
o
o
p
p
m
m
e
e
n
n
t
t


T
T
o
o
o
o
l
l
s
s


a
a
n
n
d
d


R
R
e
e
s
s
o
o
u
u
r
r
c
c
e
e
s
s



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

2
2
.
.
2
2
T
T
o
o
p
p
-
-
L
L
e
e
v
v
e
e
l
l


D
D
e
e
s
s
i
i
g
g
n
n






F
F
l
l
o
o
w
w


D
D
i
i
a
a
g
g
r
r
a
a
m
m



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
Refresh
Profiles
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

2
2
.
.
3
3


M
M
o
o
d
d
u
u
l
l
e
e


D
D
e
e
s
s
i
i
g
g
n
n



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.

2
2
.
.
3
3
.
.
1
1


S
S
t
t
a
a
c
c
k
k


I
I
n
n
i
i
t
t
i
i
a
a
l
l
i
i
s
s
a
a
t
t
i
i
o
o
n
n


M
M
o
o
d
d
u
u
l
l
e
e



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

2
2
.
.
3
3
.
.
2
2


D
D
e
e
v
v
i
i
c
c
e
e


D
D
i
i
s
s
c
c
o
o
v
v
e
e
r
r
y
y


M
M
o
o
d
d
u
u
l
l
e
e



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.

2
2
.
.
3
3
.
.
2
2
.
.
1
1


S
S
i
i
m
m
p
p
l
l
e
e


D
D
e
e
v
v
i
i
c
c
e
e


D
D
i
i
s
s
c
c
o
o
v
v
e
e
r
r
y
y


v
v
i
i
a
a


r
r
e
e
t
t
r
r
i
i
e
e
v
v
e
e
D
D
e
e
v
v
i
i
c
c
e
e
s
s
(
(
)
)


M
M
e
e
t
t
h
h
o
o
d
d



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


2
2
.
.
3
3
.
.
2
2
.
.
2
2


D
D
e
e
v
v
i
i
c
c
e
e


D
D
i
i
s
s
c
c
o
o
v
v
e
e
r
r
y
y


v
v
i
i
a
a


s
s
t
t
a
a
r
r
t
t
I
I
n
n
q
q
u
u
i
i
r
r
y
y
(
(
)
)


M
M
e
e
t
t
h
h
o
o
d
d



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


2
2
.
.
3
3
.
.
3
3


S
S
e
e
r
r
v
v
i
i
c
c
e
e


D
D
i
i
s
s
c
c
o
o
v
v
e
e
r
r
y
y


M
M
o
o
d
d
u
u
l
l
e
e



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.
2
2
.
.
3
3
.
.
4
4


C
C
o
o
m
m
m
m
u
u
n
n
i
i
c
c
a
a
t
t
i
i
o
o
n
n


M
M
o
o
d
d
u
u
l
l
e
e



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.

2
2
.
.
3
3
.
.
5
5


R
R
e
e
c
c
o
o
r
r
d
d


M
M
a
a
n
n
a
a
g
g
e
e
m
m
e
e
n
n
t
t


M
M
o
o
d
d
u
u
l
l
e
e



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

2
2
.
.
3
3
.
.
6
6


G
G
r
r
a
a
p
p
h
h
i
i
c
c
a
a
l
l


U
U
s
s
e
e
r
r


I
I
n
n
t
t
e
e
r
r
f
f
a
a
c
c
e
e


(
(
G
G
U
U
I
I
)
)


M
M
o
o
d
d
u
u
l
l
e
e



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
2
.
.
4
4


T
T
e
e
s
s
t
t


S
S
p
p
e
e
c
c
i
i
f
f
i
i
c
c
a
a
t
t
i
i
o
o
n
n
s
s



2
2
.
.
4
4
.
.
1
1


T
T
e
e
s
s
t
t
i
i
n
n
g
g


o
o
n
n


E
E
m
m
u
u
l
l
a
a
t
t
o
o
r
r



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

2
2
.
.
4
4
.
.
2
2


T
T
e
e
s
s
t
t
i
i
n
n
g
g


o
o
n
n


M
M
o
o
b
b
i
i
l
l
e
e


P
P
h
h
o
o
n
n
e
e



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.
2
2
.
.
4
4
.
.
3
3


T
T
e
e
s
s
t
t
i
i
n
n
g
g


t
t
h
h
e
e


R
R
e
e
a
a
l
l


B
B
l
l
u
u
e
e
t
t
o
o
o
o
t
t
h
h


N
N
e
e
t
t
w
w
o
o
r
r
k
k
i
i
n
n
g
g



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.

2
2
.
.
4
4
.
.
4
4


S
S
o
o
f
f
t
t
w
w
a
a
r
r
e
e


T
T
e
e
s
s
t
t
i
i
n
n
g
g


C
C
h
h
e
e
c
c
k
k
l
l
i
i
s
s
t
t



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

3
3
.
.


H
H
A
A
R
R
D
D
W
W
A
A
R
R
E
E


D
D
E
E
V
V
E
E
L
L
O
O
P
P
M
M
E
E
N
N
T
T
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_



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.
3
3
.
.
1
1


T
T
o
o
p
p
-
-
L
L
e
e
v
v
e
e
l
l


a
a
n
n
d
d


M
M
o
o
d
d
u
u
l
l
e
e


D
D
e
e
s
s
i
i
g
g
n
n




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.
3
3
.
.
1
1
.
.
1
1


L
L
i
i
s
s
t
t


o
o
f
f


C
C
o
o
m
m
p
p
o
o
n
n
e
e
n
n
t
t
s
s


a
a
n
n
d
d


M
M
o
o
d
d
u
u
l
l
e
e
s
s



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.
3
3
.
.
1
1
.
.
1
1
.
.
1
1


B
B
l
l
u
u
e
e
S
S
M
M
i
i
R
R
F
F




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.
3
3
.
.
1
1
.
.
1
1
.
.
2
2


P
P
I
I
C
C


M
M
i
i
c
c
r
r
o
o
c
c
o
o
n
n
t
t
r
r
o
o
l
l
l
l
e
e
r
r



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]


3
3
.
.
1
1
.
.
1
1
.
.
3
3


R
R
J
J
-
-
1
1
1
1


C
C
o
o
n
n
n
n
e
e
c
c
t
t
o
o
r
r




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.

3
3
.
.
1
1
.
.
1
1
.
.
4
4


X
X
M
M
1
1
0
0


T
T
w
w
o
o
-
-
W
W
a
a
y
y


I
I
n
n
t
t
e
e
r
r
f
f
a
a
c
c
e
e


M
M
o
o
d
d
u
u
l
l
e
e




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]


3
3
.
.
1
1
.
.
1
1
.
.
5
5


L
L
M
M
1
1
2
2
U
U


C
C
o
o
n
n
t
t
r
r
o
o
l
l
l
l
e
e
r
r


M
M
o
o
d
d
u
u
l
l
e
e






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

3
3
.
.
1
1
.
.
1
1
.
.
6
6


S
S
e
e
r
r
i
i
a
a
l
l


C
C
a
a
b
b
l
l
e
e


R
R
S
S
-
-
2
2
3
3
2
2


D
D
B
B
9
9


M
M
a
a
l
l
e
e
/
/
F
F
e
e
m
m
a
a
l
l
e
e


C
C
o
o
n
n
n
n
e
e
c
c
t
t
o
o
r
r




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.
3
3
.
.
1
1
.
.
2
2


T
T
h
h
e
e


A
A
n
n
a
a
l
l
o
o
g
g
u
u
e
e


C
C
i
i
r
r
c
c
u
u
i
i
t
t
r
r
y
y



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.
3
3
.
.
1
1
.
.
3
3


P
P
C
C
B
B


D
D
e
e
s
s
i
i
g
g
n
n



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

3
3
.
.
2
2


R
R
i
i
s
s
k
k


E
E
v
v
a
a
l
l
u
u
a
a
t
t
i
i
o
o
n
n



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


T
T
e
e
s
s
t
t


S
S
p
p
e
e
c
c
i
i
f
f
i
i
c
c
a
a
t
t
i
i
o
o
n
n
s
s



For every stage of building the hardware, we will run a number of tests to ensure that it is
operational.
3
3
.
.
4
4
.
.
1
1


D
D
C
C


B
B
i
i
a
a
s
s


T
T
e
e
s
s
t
t


o
o
f
f


t
t
h
h
e
e


C
C
i
i
r
r
c
c
u
u
i
i
t
t



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.

3
3
.
.
4
4
.
.
2
2


T
T
i
i
m
m
i
i
n
n
g
g


R
R
e
e
q
q
u
u
i
i
r
r
e
e
m
m
e
e
n
n
t
t


T
T
e
e
s
s
t
t



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]


3
3
.
.
4
4
.
.
3
3


B
B
l
l
u
u
e
e
b
b
e
e
r
r
r
r
y
y


P
P
r
r
o
o
d
d
u
u
c
c
t
t


T
T
e
e
s
s
t
t



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

3
3
.
.
4
4
.
.
4
4


H
H
a
a
r
r
d
d
w
w
a
a
r
r
e
e


T
T
e
e
s
s
t
t
i
i
n
n
g
g


C
C
h
h
e
e
c
c
k
k
l
l
i
i
s
s
t
t



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

4
4
.
.


C
C
O
O
N
N
C
C
L
L
U
U
S
S
I
I
O
O
N
N
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_




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

5
5
.
.


R
R
E
E
F
F
E
E
R
R
E
E
N
N
C
C
E
E
S
S
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_



[1] The Java ME Platform - the Most Ubiquitous Application Platform for Mobile Devices,
http://java.sun.com/javame/index.jsp

[2] JSR 82: Java
TM
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

A
A
P
P
P
P
E
E
N
N
D
D
I
I
X
X


1
1
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_




E
E
l
l
e
e
c
c
t
t
r
r
i
i
c
c
a
a
l
l


C
C
h
h
a
a
r
r
a
a
c
c
t
t
e
e
r
r
i
i
s
s
t
t
i
i
c
c
s
s


o
o
f
f


t
t
h
h
e
e


P
P
L
L
5
5
1
1
3
3


a
a
n
n
d
d


T
T
W
W
5
5
2
2
3
3


[15]




Bluetooth Automation Design Report

Blueberry
ii

A
A
P
P
P
P
E
E
N
N
D
D
I
I
X
X


2
2
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_




L
L
i
i
s
s
t
t


o
o
f
f


C
C
o
o
m
m
m
m
e
e
r
r
c
c
i
i
a
a
l
l
l
l
y
y


A
A
v
v
a
a
i
i
l
l
a
a
b
b
l
l
e
e


J
J
A
A
B
B
W
W
T
T


M
M
o
o
b
b
i
i
l
l
e
e


P
P
h
h
o
o
n
n
e
e
s
s


[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

A
A
P
P
P
P
E
E
N
N
D
D
I
I
X
X


3
3
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_




G
G
l
l
o
o
s
s
s
s
a
a
r
r
y
y





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.