Applications for the PDA
Project Final Report
Dec 02-06
December 18, 2002
Client:
National Instruments
Faculty Advisor:
Dr. Steve Russell
Team Members:
Rick Cordaro
Romeo Denghel
Shawn Rouse
Holly Denghel
i
TABLE OF CONTENTS
LIST OF FIGURES ...................................................................................................................... ii
LIST OF TABLES ....................................................................................................................... iii
EXECUTIVE SUMMARY ........................................................................................................ 1
ACKNOWLEDGEMENT ............................................................................................................ 2
DEFINITION OF TERMS........................................................................................................... 3
INTRODUCTION......................................................................................................................... 4
General Background ................................................................................................................... 4
Technical Problem ...................................................................................................................... 4
Operating Environment ............................................................................................................... 5
Intended User(s) and Use(s)........................................................................................................ 5
Assumptions................................................................................................................................ 5
Limitations .................................................................................................................................. 6
DESIGN REQUIREMENTS ....................................................................................................... 7
Design Objectives ....................................................................................................................... 7
Functional Requirements ............................................................................................................ 7
Design Constraints ...................................................................................................................... 8
Measurable Milestones ............................................................................................................... 8
END PRODUCT DESCRIPTION............................................................................................. 10
APPROACH AND DESIGN ...................................................................................................... 11
Technical Approach .................................................................................................................. 11
Technical Design ...................................................................................................................... 11
Testing Approach ...................................................................................................................... 20
Risks.......................................................................................................................................... 22
Recommendation for Follow-On Work .................................................................................... 24
PERSONAL EFFORT BUDGET .............................................................................................. 26
PROJECT SCHEDULE ............................................................................................................. 27
EVALUATION OF PROJECT SUCCESS .............................................................................. 29
COMMERCIALIZATION ........................................................................................................ 31
RECOMMENDATIONS FOR ADDITIONAL WORK ......................................................... 32
LESSONS LEARNED ................................................................................................................ 33
PROJECT TEAM INFORMATION ........................................................................................ 34
Client ......................................................................................................................................... 34
Faculty Advisor ......................................................................................................................... 34
Team Members ......................................................................................................................... 34
SUMMARY ................................................................................................................................. 35
REFERENCES ............................................................................................................................ 36
APPENDICES ............................................................................................................................. 37
Appendix 2: Module Testing Form.......................................................................................... 37
Appendix 3: Application Testing Form ................................................................................... 38
i
LIST OF FIGURES
Figure 1: Voltmeter User Interface .............................................................................................. 11
Figure 2: Voltmeter Code ............................................................................................................ 12
Figure 3: Continuous Read Voltmeter Code ................................................................................ 13
Figure 4: PDA-to-PDA Chat User Interface ................................................................................ 14
Figure 5: PDA-to-PDA Chat - Send Message Code .................................................................... 14
Figure 6: PDA-to-PDA Chat - Receive Message Code ............................................................... 15
Figure 7: Automobile Diagnostic Main User Interface ............................................................... 16
Figure 8: Automobile Diagnostic Connector Diagram ................................................................ 16
Figure 9: Finished automobile diagnostic connector ................................................................... 17
Figure 10: ALDL Communications Data Format ........................................................................ 18
Figure 11: Sample Data Stream ................................................................................................... 18
Figure 12: Automobile Diagnostic Decision Tree User Interface ............................................... 19
Figure 13: Automobile Diagnostic Interface - Decision Tree Code ............................................ 20
Figure 14: Original/Revised/Final Gantt chart for EE 491 (First Semester) ............................... 27
Figure 15: Original Gantt chart for EE 492 (Second Semester) .................................................. 28
Figure 16: Final Gantt chart for EE 492 (Second Semester) ....................................................... 28
ii
LIST OF TABLES
Table 1 – Testing Summary .......................................................................................................... 22
Table 2 – Estimated Financial Budget for the Project .................................................................. 25
Table 3 – Original Estimated Personnel Effort Budget for the Project ........................................ 26
Table 4 – Revised Personnel Effort Budget for the Project .......................................................... 26
Table 5 – Summary of Estimated and Actual Personnel Effort for the Project ............................ 26
iii
EXECUTIVE SUMMARY
National Instruments is in the process of developing a programming language that runs on PDAs
(personal digital assistant) running the PalmOS operating system. As with any new product, the
hardware and software requires testing by both the development team and beta users. The
development team often catches many bugs in the software and hardware but cannot find all of
them. Some bugs show up on some systems and not others. Some bugs appear when using
certain operating systems, or when putting modules together in a certain way, or many other
possibilities. That is why beta user testing is so important. It simulates how the product will be
used in real life and can assist in catching bugs before the product is released to the public.
National Instruments has asked this senior design team to be a beta test group. The objective of
this team is to design applications using this software that run on a PDA. These applications will
fulfill two purposes. One, the design and implementation of these applications will assist in
flushing out any bugs that may remain in the software or hardware. Two, these applications will
belong to National Instruments upon completion and may potentially be used as product
demonstrations.
The project consists of three applications. The first application is a basic voltmeter. It takes
measurements in the range of ±10 Volts. The second application is a two-PDA chat program. It
allows two users each with their own PDA and a copy of the application to communicate with
each other by writing messages and transmitting them over a short distance. The third
application is an automobile diagnostic computer interface. Using a connector built by the team,
a person could connect to an automobile’s diagnostic computer, download the available data, and
determine what system(s) on the automobile have a problem, and follow a flowchart to better
pinpoint the problem.
The project is currently in a partially finished state. The team has been successful in their first
objective, finding software or hardware bugs. All three projects are currently being examined to
better determine the source of the errors that are occurring. Due to the problems currently being
explored, the team has not been successful in their second objective, creating applications that
National Instruments could use as demos. However, the team anticipates that these bugs will be
fixed and the projects completed by the date of the industrial review panel presentation.
1
ACKNOWLEDGEMENT
The team would like to thank National Instruments for providing the equipment and software
used in the development of this project.
The team is also grateful for the help of David Gardner, Andrew Dove, Stephanie Rowland, and
Marius Ghercioiu, the company representatives and engineers who have provided helpful
information and technical assistance.
Finally, the team would like to thank Dr. Lamont for his help in getting an additional computer
added to the senior design lab for use in testing our projects.
2
DEFINITION OF TERMS
ALDL – Assembly line diagnostic link
DAQ – Data acquisition
DMM – Digital multimeter
GM – General Motors
GUI – Graphical user interface; the part of the program that the user interfaces with.
IR – Infrared
IrDA – Infrared data acquisition
Palm – A handheld computer developed by the Palm Company (http://www.palm.com/)
PalmOS – The operating system that runs on the Palm handheld computer
PDA – Personal digital assistant, a handheld computer
Software – The programming language being used to develop the applications is still under
development and is considered confidential. For this reason, we cannot disclose the
name of the software in public documents and will instead simply refer to it as
software.
TV – Television
3
INTRODUCTION
GENERAL BACKGROUND
The purpose of the Applications for the PDA project is to design and develop useful applications
for a handheld computer (the PDA). National Instruments is in the process of developing a
programming language that operates on a PDA running the PalmOS. The development team has
asked this project team to create some applications that will help beta test their new software.
Three applications will be developed to meet this need.
1. Voltmeter (previously multimeter) – The task is to produce a fully functional voltmeter
with the appropriate display.
Producing the voltmeter requires only software
implementation, as the hardware already exists.
2. PDA-to-PDA chat – The task is to create an application that allows two PDAs to
communicate via the wireless (infrared) port. Text from one PDA appears on the screen
of the second PDA and vice versa.
3. Automobile diagnostic computer interface – The task is to design a connector and
software to communicate with GM vehicles and their onboard computers. Modern cars
have complex diagnostic systems that are helpful for skilled mechanics but prohibit the
weekend warrior from tinkering with many of the advanced systems. This product allows
anyone the chance to interface with his or her car and read the available diagnostic
information in the same way a mechanic would.
4. Television remote control (obsolete) – Our original project plan included plans for
creating a television remote control that used of the infrared interface. Due to infrared
interface specifications, this project has been cancelled and replaced with the chat
program specified above. The reasons for discontinuing this application are explained in
more detail in the encountered risks section.
TECHNICAL PROBLEM
The preliminary technical approaches are as follows:
1. Voltmeter – A data acquisition (DAQ) card that can connect to the PDA will be the
hardware portion of the application. Two electrical probes attached to the card serve as
the probes for the meter. Finally, software has been written to read from the DAQ card
and display the measurement.
2. PDA-to-PDA chat – The PDA is equipped with an infrared interface that is utilized by
this application. Software has been written to enable the users to send and receive instant
messages by writing to and reading from the PDA’s infrared interface.
4
3. Automobile diagnostic computer interface – The team designed a cable that connects the
automobile’s onboard diagnostic computer to a DAQ card. Development for this project
was twofold. First, a connector was designed to allow the data to be read from the
automobile. Second, software has been written to interpret the diagnostic data and
display it to the user.
OPERATING ENVIRONMENT
The operating environments for these products are varied. For instance, a voltmeter is often used
in a laboratory setting but is also commonly found wherever there is an electrical measurement
to be made. A chat program may be used almost anywhere. The automotive diagnostic tool
could be found in hazardous and dirty conditions. According to the Palm Users Guide, the
handheld computer should not be exposed to rain or moisture, strong impacts, or extreme
temperatures (outside of 32 – 100 F). The environment in which any of these tools may be
used is varied, and the tools will be designed so that the constraints of the PDA are the limiting
factors.
INTENDED USER(S) AND USE(S)
The intended user(s) and use(s) follow:
1. Voltmeter – Electronics workers and engineers measuring small voltages within the ±10
Volts range.
2. PDA-to-PDA chat – People who want to send instant messages at close distance without
using the Internet.
3. Automobile diagnostic computer interface – The home-based mechanic who needs to
quickly and accurately diagnose his or her vehicle.
ASSUMPTIONS
The following assumptions were made about the user.



The user is assumed to know how to turn on a Palm PDA and operate a touch screen
interface.
The user is assumed to be familiar with their particular application (for instance, a typical
voltmeter user is an electrical engineer and the auto diagnostic tool is used by a trained
mechanic).
Users wishing to use the chat program have the software installed on both PDAs that will
be used to chat.
5
LIMITATIONS
The following limitations were made when developing the applications.












The auto diagnostic tool may only be used for GM vehicles using the same connector
cable and data specifications as the 1988 Pontiac Grand Prix. This is due to the fact that
cable and data specifications vary widely between models and years.
Design implementation was limited to total cost of all chosen parts.
Any parts selection will be limited to availability.
Design complexity will be limited to a two-semester turn-around time.
All external devices are constrained by the input and output ports of the DAQ card and
voltage requirements of the PDA, which is why the change from multimeter to voltmeter
was made.
The size and weight of external devices should be no larger than the PDA and DAQ card.
Power consumption while the applications are in use is limited to what the PDA can
provide.
Infrared transmissions are valid for distances of less than five feet.
Infrared transmissions are limited to line-of-sight.
All other physical requirements are limited to the PDA or DAQ card’s specifications.
Cost may not exceed a budget of $150, which is provided by the team members.
Voltmeter accuracy is limited to the accuracy of the DAQ card, which is approximately 1
millivolt.
6
DESIGN REQUIREMENTS
DESIGN OBJECTIVES
Each application has its own design objectives.
1. Voltmeter – This design objective has changed since the writing of the Project Plan
document. Due to the electrical constraints of the chosen DAQ card, only a digital
voltmeter will be designed and implemented. The small range and limited accuracy of
the DAQ card make creating an entire multimeter impractical and possibly hazardous to
the DAQ card. The voltmeter will use the PDA for displaying output and the DAQ card
as input source.
2. PDA-to-PDA chat – The objective is to design and implement a tool for the PDA that
will be used to send and receive instant messages using the PDA’s infrared capabilities
3. Automobile diagnostic computer interface – The objective is to design and implement a
diagnostic tool for the PDA that will interface with the on-board computer on a 1988
Pontiac Grand Prix and vehicles with similar systems through the DAQ card.
FUNCTIONAL REQUIREMENTS
1. Voltmeter
 Measure and display voltage from the DAQ card
 Provide both an analog as well as a digital display of the measured voltage
2. Chat program
 Send instant messages
 Receive instant messages
3. Automobile diagnostic computer interface
 Adaptable to all GM cars that use the same physical connector and data specifications
as the 1988 Pontiac Grand Prix.
 Display an error code being signaled by the automobile’s on-board computer
 Interpret the error code and display the affected system to the user
 Provide an interactive decision tree (yes/no questions) for pinpointing the faulty
component in the system producing the error
 Assist the user in finding additional information in the appropriate reference manual
7
DESIGN CONSTRAINTS
1. Voltmeter
 Input levels and accuracy limited to the DAQ card’s capabilities. The DAQ card can
handle ±10 Volts and has an accuracy of 1 millivolt.
 Operation under interference limited to PDA capabilities
2. Chat program
 PDAs must be within five feet of each other due to infrared limitations
 PDA infrared ports must be within the line-of-sight of each other due to infrared
limitations
3. Automobile diagnostic computer interface
 Diagnostic capabilities and accuracy limited to on-board computer capabilities
 Access to on-board computer
 Interpretation of data is limited to what General Motors or other suppliers have made
publicly available
4. The following design constraints are applicable to all three applications
 User-friendly
 Power consumption limited to PDA capabilities
 Operating environment limited to PDA capabilities
 Display capabilities limited to PDA capabilities
MEASURABLE MILESTONES
The following eight items are the major milestones accompanied with bulleted lists of items that
constitute the tasks that must be accomplished to successfully complete the milestone. A
milestone is considered successful if all of the accompanying tasks are finished. The percentage
in parentheses is what weight each milestone has relative to the entire project.
1. Project definition (5%)
 Define applications to be developed
2. Project design (10%)
 Define functionality of each application
 Develop prototype user interfaces for each application
 Outline program flow
3. Research (10%)
 Research on-board computers of GM automobiles and determine what data is
produced and how the system may obtain this data
 Research infrared capabilities of the Palm as well as infrared requirements of
televisions and television remote controls
8
4. Implement voltmeter (10%)
 Set up DAQ card to receive voltage information
 Create software application to receive, interpret, and display data provided by DAQ
card.
5. Implement automobile diagnostic computer interface (15%)
 Create hardware connector for connecting to the automobile’s on-board computer.
 Create software application to receive, interpret, and display data from the on-board
computer.
 Create decision charts for each of the possible systems in which an error could occur.
6. Implement chat program (15%)
 Create software to send instant messages
 Create software to receive instant messages
7. Testing (30%)
 Test each application for software bugs
 Test each application for accuracy
 Conduct user testing when possible.
8. Documentation (5%)
 Document final results
 Prepare final report
 Present results
9
END PRODUCT DESCRIPTION
The end product is a collection of three software applications that run on most PDAs that use the
PalmOS and have an infrared interface. The first application adapts a PDA to work as a digital
and analog voltmeter. The second application allows two users each with their own PDA to
communicate using a chat program that utilizes the PDAs’ wireless ports. The third application
allows the user to communicate with the onboard diagnostic computer of GM vehicles that use
the same connector and data standard as the 1988 Pontiac Grand Prix. This allows the user to
diagnose internal mechanical problems in much the same way as certified mechanics. The
voltmeter and automobile computer diagnostic interface applications require the use of
specialized hardware to interface between the PDA and the incoming electrical signals.
10
APPROACH AND DESIGN
TECHNICAL APPROACH
The client has specified the technical approach. This project is to be done using two PDAs
supplied by the client and two DAQ cards purchased by the client. The software applications are
to be programmed using a beta version of software that is currently being tested for the PalmOS
environment.
TECHNICAL DESIGN
The project has three parts, each corresponding to one of the three applications. Each part has its
own design specifications and considerations.
1. Voltmeter

User interface
The first task for this application is to design a user-friendly voltmeter display
(Figure 1). The interface should be designed so that anyone familiar with a
conventional voltmeter should be able to use it without instruction.
The interface will have both a digital LCD display and an analog dial display.
The user can set the data range and the DAQ channel that will be used to obtain
the reading.
Figure 1: Voltmeter User Interface
11

Data acquisition
The programming language has pre-written data acquisition functions that work
with the DAQ cards of other manufacturers. One of these is used to obtain the
data from the DAQ card.

Processing data
The main voltmeter module initially sets up the connection to the DAQ card.
After that, readings are taken continually until an error occurs or the user clicks
“EXIT”. The meter and digital monitor on the front panel are updated after each
reading to show the latest data. The code for the voltmeter is shown in Figure 2
below.
Figure 2: Voltmeter Code

Continuous read voltmeter
To test more than one DAQ card function, a second voltmeter was written that
takes 1500 samples an averages them before providing the result to the user. The
code for this second version is shown in Figure 3.
12
Figure 3: Continuous Read Voltmeter Code

Current status of this application: Completed (100%)
Both versions of this application are functional and have been tested to the team’s
satisfaction.
2. PDA-to-PDA chat

User interface
The first task for this application is to design a user-friendly interface that is easy
to use and resembles a classic chat program (Figure 4). It needs to have a field for
entering text, a button to send the entered text to the chat partner, and a field for
reading text received from the chat partner.
13
Figure 4: PDA-to-PDA Chat User Interface

Send instant message
This code is responsible for sending an instant message to the receiving PDA.
When the user is ready to send a message, they click the “SEND” button. The
send message module then transmits the message. It must first set up an IrDA
connection. It then transmits the message and finally closes the connection. The
code is shown below in Figure 5.
Figure 5: PDA-to-PDA Chat - Send Message Code
14

Receive instant message
This code is responsible for receiving an instant message from the emitting PDA.
A listener is set up to listen for an IrDA connection. When one is detected, the
message is received and displayed to the user. Then the connection is closed and
the program waits for the next IrDA connection. The code for this module is
shown below in Figure 6.
Figure 6: PDA-to-PDA Chat - Receive Message Code

Current status of this application: Mostly completed (75%)
Both the send message and receive message modules have been thought out,
designed, and written. However, there currently are problems with receiving
messages. The team has experimented with several different algorithms and
worked with National Instruments to resolve this issues, but was unsuccessful.
National Instruments is aware of the issues that the team has had and the steps
that were taken to try to resolve the issue.
3. Automobile diagnostic computer interface

User interface
The first task for this application is to design a user-friendly interface to display
error codes as well as the system to which the error refers (Figure 7).
15
Figure 7: Automobile Diagnostic Main User Interface

Hardware connector
Commercially made connectors are available for purchase. However, these are
very expensive and can range from $50.00 and higher. The team decided it was
more practical to create a homemade connector than to purchase one. A diagram
of the automobile socket pin out is shown in Figure 8. The connector on the
automobile is in the shape of a normal 25-pin D-sub connector with four slots.
Top View
Ground (Black)
160 Baud Data (Red)
5 Volts (Black w/ Stripe)
8192 Baud Data (Green)
Side View
Figure 8: Automobile Diagnostic Connector Diagram
16
The connector was made with a normal 25-pin D-sub female connector. Pins
from a male connector were inserted into the appropriate slots and wires were
soldered onto the pins. The wires are colored coded as noted in Figure 8. The
remaining holes were then covered. The finished cable is shown in Figure 9.
Figure 9: Finished automobile diagnostic connector

Data acquisition and interpretation
To obtain the data from the automobile’s diagnostic computer, a module that
reads continuously from the DAQ card will be used. This DAQ module is a
standard software module that comes as part of the programming language
package. Thus, no actual code needs to be written to accomplish this task. The
data is interpreted by a processing module, which is discussed in the next section.
The connector, called an ALDL (Assembly Line Diagnostic Link), has a specific
output scheme. The communications data format is shown below in Figure 10.
This is how the data will be interpreted to determine the error code that the
automobile’s computer is transmitting.
17
Figure 10: ALDL Communications Data Format
The easiest way to determine if a 0 or 1 bit is being transmitted is to measure the
time interval between negative going transitions (i.e. the end of the start time) and
then the next positive going transitions (i.e. the start of the stop time).
Data bytes (8 bits) are transmitted with the most significant bit first. A leading 0
logic level start bit (indicated as bit S in Figure 11) is added to delimit successive
bytes. This gives a total of 9 bits per transmitted byte. The screen shot here shows
3 groupings of 9 data bits (the waving signal is due to the measurement technique.
The first character is a SYNC character followed by the character 20H
(000100000) and 0FH (000001111).
Figure 11: Sample Data Stream

Diagnostic chain
This code will be displayed when the user presses the “View Diagnostic Chain”
button on the main user interface. This code will execute a “yes/no”-based
decision tree. There are several possible decision trees; the one shown will be
based on the error code received from the automobile’s on-board computer. The
purpose of the decision tree is to pinpoint the exact error in the automobile
18
system. The user interface of the “View Diagnostic Chain” code is shown below
in Figure 12.
Figure 12: Automobile Diagnostic Decision Tree User Interface
The actual code of the decision tree is a basic state machine. Initially, the Yes and
No buttons are enabled and the Exit button is disabled and grayed out. The
problem system and initial question are displayed on the screen. The user clicks
either yes or no in answer to the question and the next question is displayed.
Once the user has reached the bottom of the tree, the Yes and No buttons are
disabled and the Exit button is enabled. The code for one of the decision trees is
shown below in Figure 13.
19
Figure 13: Automobile Diagnostic Interface - Decision Tree Code

Current status of this application: Mostly completed (75%)
The connector has been completed and the research on the data format is
complete. The team was able to download data from the automobile’s diagnostic
computer. However, the data received was not at the expected 160-baud rate and
data format. The data received was at the 8192-baud rate and format. This is a
data format considered proprietary by GM and cannot be interpreted based on the
data the team has found. Although the data interpretation code cannot be
completed, the auto diagnostic chains are complete. So although the user would
have to purchase a commercial scan tool, they would at least be able to use the
application to narrow down the problem after receiving the error code from the
scan tool.
TESTING APPROACH
Two types of testing shall be used to verify the validity of all of the code for each of the three
applications.
1. Module testing
As each individual piece of code is developed, it shall be tested to insure that it meets all
of its particular specifications. The developer as a part of the code-writing process shall
do this testing. This testing shall mainly consist of boundary and statements tests,
verifying that each piece of code performs as it is supposed to within and outside of its
normal operating constraints. This testing is vital for ensuring that all data, both valid
and invalid, is handled properly. For a module of code to pass this test, it must have all
inputs tested satisfactorily over a sufficient range of values inside, near the boundaries of,
and outside of its normal operations range. These tests shall be recorded on the “Module
Test Form”, located in Appendix 1.
20
2. Application testing
Once the individual functions or modules of code are written and tested, they will be
integrated into an application and tested as a unit. The developers will also handle
application testing. Each module should have been thoroughly tested by the module
testing so that any errors uncovered in this portion of the testing should be errors in the
handing of data from one area of the program to another. The team will use a top-down
approach by testing the overall functionality of the integrated portions and then, if
necessary, move down into the functionality to uncover what portions of data exchange
are not functioning properly. For a clump of integrated modules to pass the integration
test, all functions of the inputs should be successfully tested over a range of valid and
invalid inputs. These tests shall be recorded on the “Application Test Form”, located in
Appendix 2.
Voltmeter testing:
Inputs of –10, -7.5, -5, -2.5, 0, 2.5, 5, 7.5, and 10 Volts will be tested. Measurements will
be compared with the readings from a standard laboratory multimeter and a standard
handheld multimeter. If the reading from the PDA is within one standard deviation of the
readings of the two multimeters, the voltmeter will pass the test.
PDA-to-PDA chat testing:
Several messages will be sent between the two PDAs over varying distances to verify that
the chat program works within the specified physical distances and line-of-sight
requirements. Also, the program will be tested to be sure that data buffers will not
overflow.
Automobile diagnostic interface testing:
Several errors will be simulated on a 1988 Pontiac Grand Prix by removing parts and
testing to verify that the application interprets the error code correctly. The decision trees
will be followed along all paths to verify that all branches are correctly implemented.
A summary of testing appears below in Table 1. All of the tests are module tests.
21
Table 1 – Testing Summary
Module
Tested
Voltmeter
Voltmeter
Automobile
Diagnostic
Tested By
Status
Comments
10/4/02
10/26/02
# Times
Tested
6
3
R. Cordaro
R. Cordaro
Failed
Failed
11/4/02
4
R. Cordaro
Failed
Chat Program
11/9/02
8
R. Denghel
Failed
Chat Program
11/10/02
3
R. Denghel
Failed
Offset Problem
Offset Problem
Continuous DAQ
acquisition not working
IrDA ports not
connecting
IrDA ports not
connecting
5
H. Denghel
Success
5
4
8
R. Cordaro
R. Denghel
H. Denghel
Success
Failed IrDA read/write timeout
Failed IrDA read/write timeout
1
R. Cordaro
Failed
Unexpected data format
15
R. Cordaro
Failed
IrDA timeouts
Date
Auto Decision
11/10/02
Tree
Voltmeter
11/20/02
Chat Program 12/1/02
Chat Program 12/2/02
Auto
12/03/02
Diagnostic
Chat Program 12/7/02
RISKS
Encountered risks:
1. Client misses promised delivery deadline(s)
This risk occurred during the design process. Originally, the team was scheduled to
receive the PDAs, DAQ cards, and a beta version of the software on March 15. Actually
delivery of the equipment occurred during the first week of August. Most of the
development time that was lost was during the summer months, which did not have too
much of an impact. The major impact was that the team did not have time to become
more familiar with the equipment prior to starting actual application development. The
team managed this risk by compressing the schedule, but its impact is still being felt.
2. Bugs in client’s prototype hardware or software
The software and hardware that are being provided by the client are still in the
development phase. As beta testers, one of the team’s objectives is to find and report any
bugs that are found. This risk has impacted the team, but the extent is not known.
Currently, there are problems with all three applications. However, the team cannot be
certain in any of the three cases if the problems encountered are due to problems with our
designs or if there is a bug in the hardware or software. This uncertainty has lengthened
the amount of time it is taking to develop each of the three applications. The team
managed this risk by communicating with the National Instruments developers frequently
and keeping them advised of the problems since they can better determine if the problems
the team is experiencing are possible bugs.
22
3. Inability to find documentation for the automobile onboard computer
This risk prevented the team from completed the automobile diagnostic tool. The
publicly available data formats were not the ones used by the vehicle that was chosen.
The team managed this risk by completing all of the decision trees and by making an
extra voltmeter that used the modules that should have been used by the automobile
diagnostic tool. This ensured that at least all of the DAQ modules were tested.
4. Inability to complete a proposed application
This is a risk that the team did not originally anticipate but had to compensate for. The
team had originally intended to create a television remote control to test the infrared
capabilities of the PDA and the IrDA modules. However, upon researching the infrared
signals that television infrared ports require versus the infrared signals that the PDA’s
infrared interface can produce, the team discovered that the two were incompatible. The
team discussed possible ways of coding the specifications using C DLLs that could be
incorporated into the modules. However, this was rejected for two reasons. One, it was
quite possible that the C DLLs would make the modules too large for the PDA’s limited
memory space. And two, although this would have made use of the PDA’s infrared
interface, it would not have tested the programming language’s IrDA functions. Since
testing the programming language is one of the main objectives of this project, that was
the major reason for abandoning the television remote control project. To replace this
project, the team proposed writing a PDA-to-PDA chat program that would send instant
messages between two PDAs using the infrared interface and the IrDA functions.
National Instruments approved this substitute project. The major impact of this risk was
loss of time due to researching a project that was not implemented.
Risks that were not encountered:
1. Loss of a team member
This is a risk that is possible in any project and was planned for to minimize its impact
were it to occur. The team kept all members up-to-date on what each member was
working on and did its best to document code and research so that other members could
pick it up and continue working if necessary. If this risk had occurred, its biggest impact
would have been the redistribution of work among the remaining members.
2. Client cancels the project
As the end of the second semester of development drew near, the likelihood of this risk
became smaller and smaller because the client was growing closer and closer to their
anticipated release date. Now that the team has the software, hardware, and PDAs, the
only impact this risk could have had was in losing the technical support of National
Instruments.
23
RECOMMENDATION FOR FOLLOW-ON WORK
National Instruments intends to release this product sometime in the early part of 2003. One of
the major objectives of this project was for the team to act as beta testers for National
Instruments. Since they will not need beta testers after the product has been released, there is no
work that could be done by a future senior design team.
24
FINANCIAL BUDGET
The client provided the following hardware and software that includes, but is not limited to, two
Palm m505 series PDAs, two DAQ cards, two signal cables, two signal connector blocks, and
two copies the development software package. The team provided the hardware for the
automobile connector, telephone and postage, and the poster. Original estimates neglected to
take the connector cost into account. Table 2 below shows the costs.
Table 2 – Estimated Financial Budget for the Project
Item
Hardware
Palm PDA (2)
DAQ Card (2)
Software
Automobile Connector
25-position D-sub metalized hood
8’ of insulated wire
Epoxy
22-18 gauge crimp-on spade terminal (4)
4-pin male interlocking power connector
Electrical tape
1’ x 1’ cardboard
Telephone and Postage
Poster
Total
Original
Estimated
Cost
$ 1060.00
$ 600.00
$ 460.00
$ 4000.00
$
0.00
$
0.00
$
0.00
$
0.00
$
0.00
$
0.00
$
0.00
$
0.00
$
40.00
$
50.00
$ 5150.00
25
Revised
Estimated
Cost
$ 1060.00
$ 600.00
$ 460.00
$ 4000.00
$
0.00
$
0.00
$
0.00
$
0.00
$
0.00
$
0.00
$
0.00
$
0.00
$
40.00
$
50.00
$ 5150.00
Final Cost
$ 0 (client provided)
$ 0 (client provided)
$ 0 (client provided)
$ 0 (client provided)
$ 16.13
$ 2.19
$ 4.98
$ 2.99
$ 1.69
$ 3.19
$ 0.99
$ 0.10
$
36
$
80
$ 132.13
PERSONAL EFFORT BUDGET
Table 3 is an estimate of the time each individual is expected to contribute to the project. Table
4 is a revised version of Table 3 based on actual data and more accurate predictions. Table 5
shows our total hours to date. The final hours are less than the estimated hours due to
unexpected stalls in development when the team conferred with the client about possible bugs.
Table 3 – Original Estimated Personnel Effort Budget for the Project
Task
Research
Documentation
Poster
Meetings
Design
Programming
Assembly
Testing
Presentation
Total Effort
Rick
Cordaro
5
14
4
64
15
10
4
15
8
139
Shawn
Rouse
10
12
6
64
15
10
4
15
6
142
Romeo
Denghel
1
15
2
64
15
40
2
4
4
147
Holly
Denghel
1
12
3
64
15
40
0
4
4
143
Total
Hours
17
53
15
256
60
100
10
38
22
571
Table 4 – Revised Personnel Effort Budget for the Project
Task
Research
Documentation
Poster
Meetings
Design
Programming
Assembly
Testing
Presentation
Total Effort
Rick
Cordaro
5
8
8
50
12
30
0
12
4
129
Shawn
Rouse
10
5
6
50
12
10
4
6
4
107
Romeo
Denghel
0
8
2
50
12
30
0
12
4
118
Holly
Denghel
0
15
3
50
12
20
0
6
8
114
Total
Hours
15
36
19
200
48
90
4
36
20
468
Table 5 – Summary of Estimated and Actual Personnel Effort for the Project
Task
Rick Cordaro
Shawn Rouse
Romeo Denghel
Holly Denghel
Total Effort
Original
Estimated Effort
139
142
147
143
571
Revised
Estimated Effort
129
107
118
114
468
26
Actual Effort
To Date
115
80
90
105
390
PROJECT SCHEDULE
Figure 14 is the Gantt chart for EE 491. The original, revised, and final chart for EE 491 are the
same; no changes have been made since the design report. It is shown below.
January February
March
April
14 21 28 4 11 18 25 4 11 18 25 1 8 15 22 29
Develop Project Plan
Define Project Scope
Define General Functions Required
Draft Project Plan
Review and Update Project Plan
Develop Project Poster
Define Poster Content
Develop Poster Content
Layout Poster
Create Poster
Revise and Finalize Poster
Develop Project Design
Define Operating Environment
Define Intended User(s) and Use(s)
Define Initial Assumptions and Limitations
Define Schedule and Budget
Create Project Design
Review and Update Project Design
Draft Project Design Report
Revise and Update Design Report
Research
Research Voltmeter
Research IR protocol and TV interface
Research ALDL protocol and connector
Figure 14: Original/Revised/Final Gantt chart for EE 491 (First Semester)
Figure 15 is the original/revised Gantt chart for EE 492. This chart shows all implementation
and code revision being finished before November, with November dedicated to extensive
application and user testing as well as preparing the final report and the presentation.
Figure 16 is the current, up-to-date Gantt chart for EE 492. Due to all of the problems the team
has had in implementing the applications, implementation and module testing is being pushed
out to almost the end of November. Application testing time has been shortened and intensified,
with most of the application testing being done in just a couple of weeks. This is unfortunate,
but it is difficult to test a product that does not work! Due to the team giving their practice
presentation early in September, the dates for the gathering of information for the final report and
designing the presentation are much earlier than intended. These dates are split, showing that the
drafting began in September, was halted to allow implementation to proceed, and will be finished
up in November and early December. Also, the change from implementing a television remote
control to implementing a chat program should be noted.
27
August September
October
November December
12 19 26 2 9 16 23 1 7 14 21 28 4 11 18 25 2 9 16 23
Implement Voltmeter
Gather Parts
Implement Code
Module Testing
Integration Testing
Revise Code
Retest Code
Testing Phase 1
Application Testing for Voltmeter
Implement Auto Diagnostic Interface
Gather Parts
Implement Code
Module Testing
Integration Testing
Revise Code
Retest Code
Implement TV Remote Control
Implement Code
Module Testing
Integration Testing
Revise Code
Retest Code
Testing Phase 2
Application Testing for Auto Diagnostic
Application Testing for TV Remote
Develop Final Report and Presentation
Define Final Report Contents
Develop Presentation
Draft Final Report
Figure 15: Original Gantt chart for EE 492 (Second Semester)
August September
October
November December
12 19 26 2 9 16 23 1 7 14 21 28 4 11 18 25 2 9
Research
Research Voltmeter
Research IR protocol and TV interface
Research ALDL protocol and connector
Implement Voltmeter
Gather Parts
Implement LabVIEW Vis
Module Testing
Integration Testing
Revise Code
Retest Code
Testing Phase 1
Application Testing for Voltmeter
Implement Auto Diagnostic Interface
Gather Parts
Implement LabVIEW Vis
Module Testing
Integration Testing
Revise Code
Retest Code
Implement PDA to PDA Chat
Implement LabVIEW Vis
Module Testing
Integration Testing
Revise Code
Retest Code
Testing Phase 2
Application Testing for Auto Diagnostic
Application Testing for PDA to PDA Chat
Develop Final Report and Presentation
Define Final Report Contents
Develop Presentation
Draft Final Report
Figure 16: Final Gantt chart for EE 492 (Second Semester)
28
EVALUATION OF PROJECT SUCCESS
At this point in time, the evaluation of project success is mixed. This project has two objectives:
assist in beta testing of the software package, and create demonstration applications that National
Instruments could use in the future. As far as the first objective is concerned, the team has been
very successful. The team has found several issues while working with the products and has
made these issues known to the development team at National Instruments. In our second
objective, the creation of demo applications, the team has been less than successful. Each of our
applications has a problem that is currently being worked out. Pending the successful resolution
of these issues, the team is optimistic that the second objective will be met prior to the industrial
review panel presentation.
As far as the milestones themselves, here is a breakdown of the relative success of each
milestone: To measure the success of the milestones, the following scale has been used. The
percent given is how much work has been done on that particular milestone, not on the entire
project.






Not attempted
Started
Partially completed
Mostly completed
Completed
Completed above and beyond
0%
25%
50%
75%
100%
>100%
1. Project definition – Completed
This milestone has been fully met. The project was defined in the project plan and
redefined in the design plan. The National Instruments development team approved the
proposed applications.
2. Project design – Completed
This milestone has been fully met. Our project has been completely defined and is in the
implementation and testing phase.
3. Research – Completed
This milestone has been fully met. The research is complete and the team has all of the
information required to implement each application, pending the resolution of
outstanding issues.
4. Implement voltmeter – Completed
Two versions of the voltmeter have been implemented and are fully functional.
29
5. Implement automobile diagnostic computer interface – Mostly completed
This milestone has been partially met. The hardware connector and the diagnostic
decision tree are both complete. However, the team was unable to interpret the data
received from the automobile due to the proprietary information of the data scheme
utilized by GM.
6. Implement chat program – Partially completed
This milestone has been partially met. The design of both the send message and receive
message modules has been written. However, the issue regarding the send/receive
timeouts was not resolved prior to the end of the semester.
7. Testing – Completed
All functional modules have been tested completely and to the team’s satisfaction.
8. Documentation – Mostly completed
Upon the completion of this document, this milestone will be completely met.
As a whole, the project is mostly completed. Although the team was not able to complete all of
the intended applications, they did fulfill their intended function as beta testers.
30
COMMERCIALIZATION
Commercialization does not apply to this project. The purpose of this project is to assist
National Instruments with their beta testing and provide them with demo applications. The demo
applications may possibly be used as examples, but National Instruments provides examples free
of charge.
31
RECOMMENDATIONS FOR ADDITIONAL WORK
National Instruments intends to release this product sometime in the early part of 2003. One of
the major objectives of this project was for the team to act as beta testers for National
Instruments. Since they will not need beta testers after the product has been released, there is no
work that could be done by a future senior design team.
32
LESSONS LEARNED
What went well:
 Brainstorming application ideas
 Defining application ideas and having them approved by National Instruments
 Dividing the work among the group members
What did not go well:
 Understanding the document requirements
 Getting the client demos to work on the team’s systems
 Meeting deadlines
 Scheduling
Technical lessons learned:
 Different infrared protocols (TV remote control modulation scheme vs. IRDA data
transfer scheme)
 Datalog functions in the software: a proprietary scheme for saving data
 The file system (or lack thereof) on PDA and how to deal with this issue
 Interpreting data specification schemes (such as the ALDL used in the automobile
diagnostic interface)
Non-technical lessons learned:
 Creation of project timelines and estimating work needed to complete a task
 Stay in regular contact with the client
 Communicate confidentiality requirements early in the relationship with the client
 Pay attention to details
 Understand and conform to documentation standards
33
PROJECT TEAM INFORMATION
CLIENT
David Gardner
National Instruments
11500 N Mopac Expwy
Austin, TX 78759-3504
512-683-5458 (Phone)
512-683-6837 (Fax)
david.gardner@ni.com
FACULTY ADVISOR
Steve F. Russell, Ph.D., P.E.
3108 Coover, Iowa State University
Ames, IA 50011
515-294-0442
sfr@iastate.edu
TEAM MEMBERS
Rick Cordaro (EE)
300 Stanton Ave. #308
Ames, IA 50014
515-292-9616
rcordaro@iastate.edu
Romeo Denghel (CprE)
4112 Westbrook #17
Ames, IA 50014
515-292-0313
romster@iastate.edu
Shawn Rouse (EE)
3219 Roy Key Ave. #204
Ames, IA 50010
515-233-4347
srouse@iastate.edu
Holly Denghel (CprE)
4112 Westbrook #17
Ames, IA 50014
515-292-0313
hstilwel@iastate.edu
34
SUMMARY
All PDAs are light and portable. Combining a PDA with software creates a powerful tool. With
the weight and size of a PDA, using a PDA to control and monitor a voltmeter makes working
out in the field easier and less cumbersome. Utilizing PDAs to send instant messages is a great
way to converse without making it obvious. What better way to get across essential information
during a business meeting without letting your clients know? For the home auto mechanic, the
automobile diagnostic computer interface helps them diagnose problems with their vehicles
faster and more efficient than old conventional ways.
35
REFERENCES
Palm m500 Series Users Guide. Palm Company. 2001.
General Motors Systems manual for the 1988 Grand Prix
36
APPENDICES
APPENDIX 2: MODULE TESTING FORM
Module Testing Results
Group: Dec 02-06
Project: Applications for the PDA
Name of Module Tested:
Start Time:
Results of Test:
Finish Time:
Passed:
Elapsed Time:
Failed:
Reason for Failure:
Inputs and Values Tested:
Inputs or Values Not Tested:
Comments:
Tested By:
Date:
37
APPENDIX 3: APPLICATION TESTING FORM
Application Testing Results
Group: Dec 02-06
Project: Applications for the PDA
Name of Module Tested:
Start Time:
Results of Test:
Finish Time:
Passed:
Elapsed Time:
Failed:
Reason for Failure:
Inputs and Values Tested:
Inputs or Values Not Tested:
Comments:
Tested By:
Date:
38