Senior Design Project
Advisor: Dr. Ronald Hoelzeman
Christopher M. Keller
Gregory M. Nehus
Matthew D. Odille
P a g e
I. Project Summary
In a recent study, it has been determined that roughly
80% of all motor vehicle accidents are a result of
distractions. Cell phone usage has been labeled as one of these distractions (NHTSA). Usage includes
real time voice conversations as well as text messaging. Voice conversations are typically conducted
by the driver with one hand holding the cellular device to a particular ear depending on the driver’s
preference. This is detrimental to the safety of the passengers and driver of the vehicle for two reasons;
the driver's attention is split between his or
her conversation and driving and also one of the drivers
hands is being consumed and thus not on the steering wheel. While there are a plethora of in
navigational/entertainment units that will pair with a cell phone, allowing hands
unication, there are no such units that allow for dictation of text messages.
Text messaging while driving is potentially more dangerous than normal phone conversations. The
difference between writing a text message and talking on the phone is that text
messaging requires the
user to look at the screen of the cell phone exclusively, completely drawing attention away from the
road ahead. It is estimated that 20% of all drivers either receive texts or send text messages while
driving and the figure increas
es to 66% when the statistics are limited to drivers between the ages of 18
and 24 (U.S. News). The scale of the problem and the severity of the danger that it causes has led
several states to pass 'anti
messaging' laws to prohibit drivers from text
messaging while driving a
We propose an in car unit capable of not only streaming phone conversation audio using Bluetooth
communication, but also capable of dictating text messages and reading incoming text messages to the
driver. This unit wil
l allow for much safer communication with the driver and the outside world.
While text messaging should not be done while driving, it is impossible to enforce laws such as a text
messaging ban. Such a unit will allow a driver to receive and respond to te
xt messages without taking
their eyes off of the road or their hands off of the steering wheel.
Initially, we intended to build the computer system as well as program the software required for such a
device, but our advisor, Professor Ronald Hoelzeman, ur
ged us to narrow our project. Professor
Hoelzeman felt that our project was too broad and that we should remove the irrelevant hardware
assembly. Our project will consist of designing and implementing a graphical user interface with back
end software cap
able of interfacing with cellular devices via Bluetooth communication.
This project will require extensive research covering several new topics for the group. First, we will
need to find how to get Java to interact with a Bluetooth dongle. Next, we ha
ve to find how to initiate
the Bluetooth dongle and have it search for all nearby devices. The most important part of our research
is discovering the types of services on a cellular device and how to utilize each of these services. We
anticipate that the
most difficult and technically challenging aspect of this project will be creating an
audio stream from the cellular device to the computer and vice versa via Bluetooth.
This project was chosen for several reasons. For one, all members of our group
are intrigued by
Bluetooth communications and have yet to delve into its protocol. Our main goal is to gain knowledge
in the area of the Bluetooth communication, the Bluetooth communication protocol in cellular devices,
and to further develop our skills i
n the Java programming language. In addition to our quest for
knowledge, we feel that it is important to develop something that we feel would better our world by
increasing public safety.
P a g e
II. Specific Aims
This design project will accomplish four overa
ll goals. First, each of the individual group members
will gain comprehensive knowledge on how Bluetooth technology works. This will require performing
extensive research into the Bluetooth protocol and learning how software developers write applications
in programming languages such as Java to communicate over Bluetooth. Specifically, each participant
will learn how to write code for implementing the various portions of the Bluetooth anatomy. This
includes stack initialization, device management, devic
e discovery, service discovery, and
communication protocols (Qusay Mahmoud). Upon the completion of this project, each member of the
group will understand on a software level how Bluetooth
enabled devices are paired with each other
and how they listen and
communicate back and forth. Also, as a result of writing the code in Java, this
project will further strengthen each of the group members' programming skills with the object
language of Java.
Secondly, our group will discover how Bluetooth tech
nology is currently being used in automotive
environments. Specifically, our project will involve the investigation of the current uses for Bluetooth
with regards to pairing a cell phone to the interface of an automobile. This aim will mostly be
shed by performing general searches via web search engines such as Google. These web
searches will let our group quickly determine all of the various specific services and functionality cell
phone and car manufacturers alike are already providing. Determ
ining these existing features will
enable our group to see what is already being done with Bluetooth technology and subsequently allow
us to use all of our knowledge gained from the previous goal to write software from the ground up that
will have the abil
ity to mimic the same functionalities currently available with cell phones and
automobiles. Thus, each group member will gain an intimate knowledge on both
applications for Bluetooth are able to do, and
exactly they are coded.
re, after determining what various features are already available and how our group can
implement those existing features ourselves, our third specific aim will be to
the status quo. In
order to do this, our project group will develop an additiona
l set of features ourselves which are not
currently available. Our main focus with this part of the project will be on implementing a hands
dictation feature and a text
speech feature. Using these two aforementioned functions, our project
able drivers to send and receive text messages hands
free. Thus, our project will aim to
contribute something more to the current market.
Ultimately, all of the above goals will contribute to accomplishing a much broader and more important
By adding improvements to the way we can communicate with cell phones while
driving, we will help reduce the number of automobile accidents and deaths which occur due to cell
related driving distractions. As cell phones become owned by more and more
potential distractions they present while driving affect more and more people. Current implementations
of the Bluetooth technology help reduce these distractions by enabling hands
free calls. But this
project's additional feature of hands
ee text messaging will aim to even further reduce such
distractions, especially with the emerging popularity of text
messaging among younger drivers.
III. Background and Motivation
All three senior design group members are currently enrolled in the Unive
rsity of Pittsburgh Computer
Engineering program. This program is a combination of both electrical engineering and computer
science coursework, therefore exposing students to both the hardware and software aspects of computer
engineering. Towards the end
of the curriculum, a student can choose to specialize in either hardware
P a g e
or software. All three members of our group have taken a special interest in software and thus wanted
to take on a project that is heavy on computer programming.
All being seniors
in the Computer Engineering program, we have been exposed to enough
programming in the required coursework to provide the necessary background to succeed in a project
such as this. In the COE 401 course, Intermediate Programming Using Java, the fundamenta
techniques of computer programming are taught using the Java language; this course teaches the basics
of the Java language and the fundamentals of object oriented programming and design. In the next
software course, COE 445, Data Structures, the basic d
ata structures of computer programming (trees,
queues, stacks, and lists) are taught. COE 445 also introduces these structures by using the Java
programming language. In COE 1501, Algorithm Implementation, a broad range of the most
commonly used algorith
ms in computer science are introduced. These algorithms include sorting,
searching, encryption, and compression which are all taught in Java. Two group members have also
completed COE 1186, Software Engineering. The Software Engineering course is especi
in taking on a project such as this because it introduces topics such as software requirements,
oriented analysis, design, and implementation; again, this course is taught in the
Java language. Also, all group members h
ave all completed COE 1185, Computer Systems Interfacing;
this is not a software class, however it will help in the use of the Bluetooth protocol for
communications between systems.
As you can see, all members of our group have been programming in the J
ava language through several
courses. In these courses, we have completed many small Java applications which were geared for us
to learn whichever topic we were currently studying. Unfortunately, we have not had the chance to put
all of our Java programm
ing knowledge together to build a working real world design. Therefore, we
we’re motivated to choose a senior design project that would enable us to do this. In order to be
successful in this project, we will need to combine all of our knowledge from our
coursework with new
research on topics such as the Bluetooth Protocol and AT Commands to communicate with cellular
In addition to coursework experience, each member of our group has participated in the University of
Pittsburgh’s school of engine
ering cooperative education program. In this program, students get a total
of one year’s worth of work experience in the computer engineering industry. One of our group
members did their co
op at a company called Vocollect. The main component of Vocolle
product is voice recognition software (Vocollect). His experience working at Vocollect has inspired
him to learn more about how voice recognition is done in software. The other two members of our
group did their co
op’s at ANSYS Inc. ANSY
S develops engineering simulation software (ANSYS).
Even though all of our group members were able to get real world working experience, that experience
was limited mostly to light development and software testing. This project gives us a chance to be le
developers on our own design.
All members of our group have an interest in cell phone technology. Cell phones are currently one of
the fastest growing technologies, and we would like to learn more about how they work. Specifically,
we are interest
ed in learning how we can use our Java programming knowledge to get more from our
own cell phones. For our project, we will focus on what can be done with communication with a cell
phone using Java and the Bluetooth protocol.
Bluetooth technology provid
es a way for electronic devices to connect across short ranges. It is a
frequency technology that uses the 2.4 GHz Industrial
Medical (ISM) band (Sun
Microsystems). This enables Bluetooth to be much more than just a cable replacement tec
P a g e
is ideal for peripheral connectivity, file transfer, device synchronization, voice communication and
much more. We are motivated to explore this technology to learn how many of these feats are
Our group members also share interests in the technologies used in automobiles. Primarily, we are
interested in how Bluetooth can be used to facilitate communication between cell phones and computer
systems installed in cars. We have been inspired by som
e of the recent technologies like Ford Sync
which seamlessly integrates the driver’s cell phone and entertainment into one computer system that is
controlled by the touch of a button or by voice command. We would like to design something similar
t we have learned through our coursework.
Our experience with the Java language in our courses has driven us to want to see what more we can do
in the language. Also, our co
op experience in the computer engineering industry has inspired us to be
developers on our own project. Since our group members are all interested in cell phone and
automotive technology we wanted to somehow incorporate this into a project that uses our Java
knowledge. We feel that this project gives us a good opportunity to
combine all of this.
IV. Preliminary Work/Design Possibilities
The Java programming experience of the group described in the Background and Motivation section
proves that our group is capable of using Java to create working applications. By combining ne
written entirely by our group with technology that already exists, we will be able to successfully
complete our project. There are several pre
existing technologies that make this project possible: the
BlueCove Java library for Bluetooth, CloudGard
en’s TalkingJava SDK, and Broadcom’s Widcomm
The BlueCove Java library will allow us to write code in Java to control Bluetooth communications
between the computer and the cell phone. One of the primary purposes of the BlueCove librar
y is for
students to learn the Bluetooth protocol. Vlad Skarzhevskyy is the creator of the BlueCove library, and
when he was asked how he sees BlueCove being used he responded, “I expect that students are starting
to learn JSR
82 (the Java Bluetooth API)
using BlueCove. I'm answering all of the questions I'm
receiving by e
mail no matter how simple they are (Rococo).” This quote reveals that one of the main
motivations of the creators of the BlueCove library was for students to learn the standard Bluetoo
protocol through working on projects such as ours.
CloudGarden’s TalkingJava library provides a full development kit for Sun's Java Speech API for
Windows platforms, allowing Text
Speech and Speech
Recognition engines (in many different
o be programmed using the standard Java Speech API (CloudGarden). This software has
been used in similar applications by others, which proves that we can use it to accomplish our project.
For example, recent research was done that allowed a robot to be c
ontrolled remotely over Wi
voice commands. The speech recognition of the voice commands was done with the CloudGarden
software (Ayres and Nolan).
In the researchers’ report, they said “
We have established the
CloudGarden implementation of the
Java Speech API under the Windows operating system on the PC
and developed a simple Java/CloudGarden client which can recognize speech (Ayres and Nolan).”
This is exactly what needs to be done for the speech
recognition portion of our project, and since o
have accomplished and documented such work, our design, too, is attainable.
Broadcom's Widcomm software offers a proven Bluetooth software stack, featuring broad application
support with easy to use Bluetooth products (Broadcom). Broadcom not only
builds hardware such as
P a g e
radios for Bluetooth applications, they also write the software to allow other Bluetooth
to interact with that hardware. One of the features of Broadcom’s software includes the ability to
stream phone calls and ster
eo audio over Bluetooth from a cell phone. Even with access to a Broadcom
development kit this task is extremely difficult to implement, therefore Broadcom’s existing application
will enable our group to accomplish the task of passing audio from a phone ca
ll to the computer’s
V. Design Approach
Setting Up Development Environment
The first part of the overall design process will be to set up the development environment. The
programming language our group has decided upon is Sun Java
. Java is a general
oriented language (Sun Microsystems, Java Programming). Java is preferable due to our group's
previous experience with the language. Also, Java is easily expandable via packages which are readily
le. Additionally, Java is cross
platform, meaning it can run on a vast array of operating
systems (Sun Microsystems, Java Programming). This latter feature is important because although our
project will be developed on a laptop running the Windows Vista
operating system, if our project were
to eventually be utilized in a mobile environment it would most likely run on an embedded platform
using a different operating system.
A prerequisite for developing in Java is to install the Java Runtime Environment (
JRE) and the Java
Development Kit (JDK). The JRE and JDK are freely available from Sun's website. Installing the JRE
will give us the necessary components to execute Java applications, since it provides the various
libraries and the Java Virtual Machine
(Sun Microsystems, Java SE). The JDK contains the compilers
and debuggers necessary for developing and debugging our applications (Sun Microsystems, Java SE).
Uniformity in the aspect of development environments within our group is important i
n order to
maintain stability and code cohesion. This project will be written in Java utilizing NetBeans.
NetBeans is an Integrated Development Environment (IDE) which contains a plethora of features,
including an editor, version control integration and
development collaboration, syntax and error
highlighting, and code completion (NetBeans). Using NetBeans and its various features will cut down
on time costs. This extra time will certainly prove to be valuable in later stages of the project. Since
group member will be coding individually, it will be helpful in integrating our code if all group
members to use the same IDE.
Another way to facilitate the combining of our code is through the use of version control software.
control will be accomplished using Subversion, which NetBeans supports natively. Figure 1
below shows the basic concept of version control systems.
P a g e
Figure 1: Version control overview
multiple clients sharing a single code repository
Each developer wi
ll download source from a central location
the repository. Local copies are
available anytime and can be accessed without a connection to the server repository. Then, when any
of the developers make a change to their local copies of the source code and
commit it to the repository,
the new updates to the code then become available to each of the other developers. In the event that
conflicts arise in code that is being edited by multiple developers, Subversion has the capability of
determining that a con
flict has arisen and will prompt the developer to resolve the conflict in question
before the developer can commit their new change.
Java does not come packaged with any type of API which would enable interfacing
with a Bluetooth
stack. Therefore, a third
party library is necessary. BlueCove is a free Java library for Bluetooth JSR
82 implementation (BlueCove Team). This library provides necessary classes and functions to bridge
the gap between our software writ
ten in Java and the Bluetooth stack built into the computer's
operating system. The BlueCove software offers a fairly high
level interface with the Bluetooth stack.
This removes the necessity of dealing with low bit
level logic. Figure 2 below gives a h
of the various layers of the Bluetooth hierarchy, and the following five sections outline the more
specific aspects of Bluetooth communication in Java which our application will have to directly deal
Figure 2: High
level view of Bluet
ooth layer hierarchy
P a g e
Stack initialization must be done prior to any of the remaining four steps, since the Bluetooth stack is
responsible for controlling the Bluetooth device (Qusay Mahmoud). Initializing the Bluetooth stack
cific device configuration parameters such as port name, baud rate, connectable mode, and
discoverable mode (Qusay Mahmoud). The port name specifies the port through which signals will be
sent through the computer (e.g. COM1, COM2). The baud rate specif
ies the speed of which data is
transmitted between the computer and the Bluetooth
enabled cell phone. The connectable option
specifies whether the computer is available to respond to commands from a Bluetooth
Furthermore, the discoverable
option specifies whether the computer will or won't respond to any
incoming inquiries (Bluetooth SIG).
After the stack is initialized, the next step will be device discovery. Device discovery allows the
computer to get a list of availa
ble nearby Bluetooth
enabled devices (Qusay Mahmoud). This will be
implemented with the BlueCove API via the DiscoveryAgent class. The result of calling the
startInquiry() method of the DiscoveryAgent class is an array of RemoteDevice objects. A Bluetoo
enabled cell phone is an example of a remote device. The example below in Code 1 shows the basic
commands that will be utilized.
// retrieve the discovery agent
DiscoveryAgent agent = local.getDiscoveryAgent();
// place the device in inquiry mode
boolean complete = agent.startInquiry();
// retrieve the discovery agent
DiscoveryAgent agent = local.getDiscoveryAgent();
// return an array of pre
RemoteDevice devices =
ieve the discovery agent
DiscoveryAgent agent = local.getDiscoveryAgent();
// return an array of devices found in a previous inquiry
RemoteDevice devices =
Code 1: Device discovery implementation (
Next, the process of device management will allow the computer to access properties of any
RemoteDevice object obtained from the commands seen in Code 1 (Qusay Mahmoud). These
properties include, for example, the friendly
name of the cell phone (i.e. “Fred's BlackBerry8100”) and
the MAC address. The MAC address is essential for connecting the computer directly to the cell
phone. The example in Code 2 below demonstrates this functionality.
P a g e
// retrieve the device that
is at the other end of
// the Bluetooth Serial Port Profile connection,
// L2CAP connection, or OBEX over RFCOMM connection
RemoteDevice remote =
// retrieve the Bluetooth addr
ess of the remote device
String remoteAddress = remote.getBluetoothAddress();
// retrieve the name of the remote Bluetooth device
String remoteName = local.getFriendlyName(true);
Code 2: Retrieving MAC address and friendly name of a RemoteDevice (
Once the computer has received a RemoteDevice object, it can determine what services and protocols
are available, along with the connection strings required to establish connections with each service.
There are 25 various
Bluetooth services, also known as Bluetooth profiles, which operate on top of the
6 available Bluetooth protocols (Bluetooth SIG). One Bluetooth profile relevant to this design project
is the A2DP profile. The A2DP profile enables stereo
quality audio to
be streamed over a Bluetooth
connection, which is necessary to enable a cell phone to stream conversational audio to an external
source (Bluetooth SIG). The only protocol required for our project is the RFCOMM protocol. This
protocol allows for sending
AT commands, discussed in the next section, directly from the computer to
the cell phone.
Once the cell phone, along with its available services, has been discovered and the cell phone has been
paired with the computer, the line of communic
ation is now open. There is a predefined set of
commands which are used to control the cell phone. These commands, known as AT commands, are
very similar to the commands used in the 1990's to initialize a dial
up modem. AT commands can be
used for placi
ng calls, receiving incoming calls, hanging up, retrieving phone book contacts, and
obtaining text messages from the cell phone (Sony Ericsson). Code 3 below shows an example of the
dialog between the cell phone and the computer when a new text message (S
MS) arrives on the phone
and the computer requests the data of the message:
P a g e
// Cell phone saying, “New Text Arrived”
// this message is stored (either on phone or on
// memory card) and the <index>
field indicates the
// location of the new message in memory.
// This command requests the new text message from the cell
// phone. As above, the index refers to the location in
// memory at which the message is stored.
// This command is the cell phone returning the text message to the
// computer. The <stat> field indicates
// the status of this message i.e. unread, read, etc. The <length> field
// indicates the length of t
he encoded PDU message. <CR> is carriage return
// and <LF> is line feed. <pdu> refers to the encoded text message.
Code 3: Dialog between computer and cell phone for retrieving SMS message
The cell phone doesn't pass the original
plaintext of the message over Bluetooth to the computer.
Instead, it returns a PDU
encoded message which resembles the example in Code 4.
Code 4: A PDU
encoded SMS message
means nothing to the average person, our software will have to decode this message to recover
the original message and sender information. A breakdown of the decoding method of a PDU message
can be seen in Figure 3 below.
There are 23 octets in this mess
age. The first octet ("00") doesn't count; it is only an indicator of the
length of the SMSC information supplied, this always be 0 for us. The format of the PDU string can be
seen in Table 1 below.
Length of SMSC information. Here the length is 0, which
means that the SMSC stored in the phone should be used.
Note: This octet is optional.
First octet of the SMS
First octet of this SMS
Address Length. Length of the sender number (0x0B = 11)
Type of Address of the sender number. (91 indicates
international format )
The phone number in semi octets.
Data coding scheme (DCS). This message i
according to the 7
bit default alphabet. Having "04" instead
of "00" here would indicate that the User Data field of this
message should be interpreted as 8
bit characters rather
Validity Period. "AA" means 4 days.
User Data Length. Length of message. The DCS field
bit data, so the length here is the number of
septets (10). If the DCS field were set to 8
bit data or
Unicode, the length would be the number of octets.
User Data. T
hese octets represent the message "hellohello".
Table 1: The PDU format (
P a g e
Other Bluetooth communication tasks, such as answering phone calls and querying the cell phone for
its contact list, require similar processes to the procedure
described above for retrieving a text message
from the cell phone.
Text via CloudGarden SDK
Creating a safe interface with minimal distractions is one of the main goals of this project. In order to
minimize distractions such as typing a teleph
one number, typing text messages or scrolling through a
contact list we need a way to extract user input in a way other than with his or her hands. Through
research, our group determined that the least distracting method to extract user input is via his o
voice. This is where a Speech
Text engine comes in to play. As the title suggests, a Speech
engine is written to convert a human voice into a string that a computer can understand. Due to time
constraints, our group decided to use a pre
Text engine rather than implementing a
STT engine from scratch. As there are many algorithms, signal processing designs, etc., our group
would not be able to fully implement a TTS engine with the time allotted for this project. A searc
the Internet yielded several Java
based TTS engines and CloudGarden was selected.
The CloudGarden SDK implementation provides a relatively high
level approach to converting human
voice into a Java String (CloudGarden). It is important to utilize a J
ava SDK rather than any
text software such as Dragon Naturally Speaking, because it allows us to directly
handle the speech with our Java code. In addition to converting speech to text, we will also have to
create a function which th
e voice commands will call. This will include parsing the spoken text and
looking for key words which will then segue to functions for performing various specific tasks.
As an example, in the event that the user wishes to place a phone call to a person
in his or her contact
list, the user would say something such as “Call Robert”. The program will look at this string and
search for keywords, determining that “Call” is a keyword. We will have a function such as
sendCallCommand(), with a parameter speci
fying the telephone number that is the desired recipient.
The program will then look at the remainder of the string and determine that “Robert” is not a
telephone number and will thus query the contact list for “Robert.” There are several unique outcomes
for this query. The contact name “Robert” may have several telephone numbers saved in his
information (such as home, cell phone and work numbers), just one number or perhaps no information
at all. In the event that there are several numbers, we will hav
e to ask the user what number in
particular that they would like to reach “Robert” at and listen for the user to reply. The resulting
telephone number will be returned and this number will be passed into the sendCallCommand()
The speech comma
nds will also affect what the GUI displays to the user. In the event that the user
places a call, the screen will display the information of the current call. For instance, if the user places
a call to Robert, the screen will display “Calling Robert”, th
e call duration and several options such as
hang up or place on hold. The biggest challenge of this portion of the project will be dealing with the
infallibility of the speech
in other words, we will have to deal with misunderstood
eech and handle it in the most efficient and effective manner.
Speech via CloudGarden SDK
As the Speech
Text engine converts human voice to a string understandable to a computer,
conversely, a Text
Speech engine converts a computer string i
nto a computer generated audio
P a g e
rendition of a human voice speaking the string. This aspect of the project is essential as virtually all
driven user interaction with the computer will be responded to with a computer generated voice.
For example, if
the user said “Call Greg,” the computer would respond “Do you wish to call Greg?”
and would listen for a reply.
The most important feature that depends on the TTS engine is that of reading a new, incoming text
message to the user. After the text message
is read to the user, the user will be asked if he or she would
like to reply to the text message. If the user responds “Yes,” the Speech
Text engine will again be
used to dictate the text message.
Streaming calls via Broadcom
One of the Bluetooth pro
tocols, appropriately named “Headset Profile,” allows for streaming audio
over the Bluetooth connection. This protocol is taken advantage of in several preexisting technologies,
such as Bluetooth ear pieces which allow the user to handle conversations com
pletely in a hands (and
wire) free manner. This protocol allows for two distinct channels, which is needed for a two
conversation. In order to implement this functionality, an SDK provided by Broadcom will be used. In
contrast to all other programmi
ng in our project, this section will need to be completed using C++,
which will be designed and compiled using Microsoft Visual C++.
After having implemented all of the needed Bluetooth functionalities and speech recognition aspects of
, our group will then focus on designing a graphical user interface. The graphical user
interface acts as a bridge between the user and the core, back
end functions that are in place. It may be
said that the voice recognition also bridges the user to the
functions, but the GUI will allow more
detailed information to be displayed as well as allow the user to interface without his or her voice.
Our group plans to make use of NetBeans' built
in GUI designer. This designer allows the user to drag
items such as menu bars, buttons, text fields, drop down lists, etc. without having to code it
his or herself. Using this designer, our group will be able to create a more detailed, more user friendly
GUI in a much shorter time period.
The GUI will hav
e several unique screens: a main screen for standby, a screen representing a cell phone
keypad for calls, a contact list, which can be added to, and a screen for text messages, which will allow
the user to read all text messages on his or her device as wel
l as write new text messages. While the
user would be able to place calls (to a contact in list or to a unique 10 digit number) using just his or
her voice, it was decided that the user also be able to interface using another form of input. In addition
o responding to user input, the GUI will also have to respond to the input from the cellular device. For
instance, when an incoming call is occurring, the GUI will display the caller's information and will ask
the user if he or she wishes to accept the ca
VI. Milestones and Schedule
Below is a tentative schedule and list of milestones and subtasks for the project. Realizing that time is
a factor, the strategy is to initially focus on the most feasible tasks to ensure a basic working design.
hing basic Bluetooth communication between the cell phone and computer is the fundamental
milestone of the design. Accomplishing this core functionality by week three leaves sufficient time to
build on the design.
P a g e
Repository and IDE set up
Create use case diagrams
Progress report on non
(implement use cases)
stall and learn basics of
arden Java Voice Software
Test robustness of established
Progress report on technical issues
arden to begin
implementing voice commands
Begin design and coding of GUI
Finish implementation of voice
Begin incorporation of
WIDCOMM voice over Bluetooth
Test design at this stage
preparation for final report
Finish WIDCOMM incorporation
Finish final report
Prepare final presentation
VII. Management Plan
The Milestones and Schedule section below provides a timetable and
list of subtasks that must be
completed. To successfully realize the design, several separate tasks will need to be completed each
week. The strategy is to assign each group member a primary task or tasks for each week. However,
some tasks will require
more time than others and may require the entire group’s focus; thus, there is
P a g e
flexibility in the task assignments. Chris will be the initial group leader and will be responsible for
setting up meeting times with Dr. Li and Dr. Hoelzeman; this leader role
may change every few weeks.
Below is a list of each member’s primary task for each week.
Chris: Finish preliminary research and project proposal
Matt: Finish preliminary research and project proposal
Greg: Finish preliminary research and project
Chris: Progress report on non
Matt: Create use case diagrams
Greg: Begin rudimentary communication between computer and phone
Chris: Testing of established communication between computer and phone
Matt: Install an
d learn basics of CloudGarden voice software
Greg: Finish communication between computer and phone
Chris: Utilize CloudGarden to begin implementing voice commands, progress report technical issues
Matt: Begin GUI design and coding, progress report
Greg: Utilize CloudGarden to begin implementing voice commands, progress report technical issues
Chris: Finish implementation of voice commands
Matt: Finish GUI
Greg: Begin incorporation of Broadcom
Chris: Begin final re
Matt: Test design at this stage
Greg: Finish Broadcom incorporation
Chris: Finish final report
Matt: Any remaining technical tasks
Greg: Begin final presentation
Chris: Final Presentation
Matt: Final Presentation
VIII. Expected Problems and Solutions
In performing the initial planning stages of the project, a few potential and expected problems stand
out. The successful completion of this project will depend on coming up with solutions to these
lems. The aspects of the project that we expect to have problems with are handling issues with
P a g e
inaccuracy of voice dictations when accepting voice commands using CloudGarden, being able to
seamlessly incorporate the Broadcom software into our project, and
software compatibility issues with
respect to CloudGarden.
Voice Recognition Accuracy
When running, the software will be completely under the control of voice commands from the user.
The speech dictations done by the CloudGarden software are not always
completely accurate. In fact,
it is expected that the dictations will be slightly erroneous in most cases. This brings on the problem of
how to recognize what the command was intended to be from a string of text that is slightly dissimilar.
n to this problem comes through the use of the Levenshtein distance algorithm. By
incorporating this algorithm into our software, we will be able to search through the text of commands
that were read in by CloudGarden to test if they are “close” to what t
hey are supposed to be. Code 5
below demonstrates how the Levenshtein Distance algorithm can be called and used to determine the
accuracy of a recognized string with an expected string.
String s1 = "Once upon a time"; String s2 = "once up on a
int lev_distance = LD(s1, s2);
float accuracy = 100 * ( 1
((float) lev_distance ) /
System.out.println("Expected = " +s1+ "
nRecognized = "
System.out.println("Levenshtein distance = " + lev_distance);
ccuracy score = " + (int) accuracy +
* Expected = Once upon a time
* Recognized = once up on a times
* Levenshtein distance = 2
* Accuracy score = 87%
Code 5: Calculating string similarity using the Levenshtein distance
Incorporating Broadcom Software
way audio over Bluetooth has been determined to be the most difficult aspect as no
members of our group are familiar with handling streaming audio in C++ or Java. As this functionality
is not the
core of our project, a preexisting implementation of a Bluetooth headset by Broadcom may be
used for sake of time and completeness in the event that our group is unable to implement a working
model of streaming audio.
Software Compatibility Issues with Cl
The TalkingJava SDK from CloudGarden is essential in enabling us to write the software for speech
recognition and text
speech conversion. However, the problem with the TalkingJava SDK is that it
requires a specific outdated version of the Ja
va Runtime Environment (JRE) in order for it to install
P a g e
properly. Our solution to this problem will be to uninstall any previous versions of Java currently on
any of the machines we’ll be working on and then temporarily installing the 1.4.2 version of the
which is compatible with the TalkingJava SDK installer.
IX. Estimated Costs
The Java development kit required to program our project comes free of charge from Sun
Microsystems. The NetBeans GUI also comes packaged with the development kit
for no additional
cost. However, academic licenses for the TalkingJava software development kit by CloudGarden are
also required and cost $14 per license. Thus, three licenses, one for each group member, will require a
total of $42.
ated costs associated with obtaining the necessary hardware components required to complete
our design project will include:
Computer for developing and testing
enabled cell phone
Our group w
ill be providing the computer and the cell phone, therefore both hardware and software
estimated costs come to a total of $64.
P a g e
ANSYS. ANSYS Products Portfolio. ANSYS.
June 1, 2009).
Ayers, Tony and Nolan, Bryan. 2004.
Voice activated command and control with Java
recognition over Wi
. Institute of Technology Blanchardstown.
BlueCove Team. BlueCove. BlueCove Team. http://www.bluecove.org/ (accessed J
une 1, 2009).
Bluetooth Software Solutions
(accessed June 8, 2009).
Bluetooth SIG. Bluetooth Glossary. Bluetooth SIG.
http://www.bluetooth.com/Bluetooth/Technology/Glossary/ (accessed June
CloudGarden. TalkingJava SDK with Java Speech API implementation. CloudGarden.
http://www.cloudgarden.com/ (accessed June 5, 2009).
SMS and the PDU format. Dreamfabric.
June 5, 2009).
NetBeans. NetBeans IDE 6.5 Features. NetBeans.
(accessed June 1, 2009).
NHTSA. The 100 Car Naturalistic Driving Study. National Highway Traffic Safety Administration
002/100CarPhase1Report.pdf (accessed June 1, 2009)
Qusay Mahmoud. The Java APIs for Wireless Bluetooth Technology. Sun Microsystems.
http://developers.sun.com/mobility/midp/articles/bluetooth2/ (accessed June 5,
Rococo. Cool Projects Using JSR82. Rococo.
(accessed June 5, 2009).
Sony Ericsson. AT Commands for Sony Ericsson Phones. Sony Ericsson.
sonyericsson.com/getDocument.do?docId=65054 (accessed June 5, 2009).
Sun Microsystems. Java Programming Language. Sun Microsystems.
http://java.sun.com/j2se/1.5.0/docs/guide/language/ (accessed June 1, 2009).
Sun Microsystems. Java SE Technologies at a G
lance. Sun Microsystems.
http://java.sun.com/javase/technologies/ (accessed June 1, 2009).
Outlawing Text Messaging While Driving
(accessed June 5, 2009)
P a g e
Vocollect. About Vocollect. Vocollect.
(accessed June 1, 2009).