SOAP: SCUBA Oxygen Analysis Project
Final Report
Team
May 07-17
Client
Dan Stieler
Faculty Advisor
Dr. Gary Tuttle
Team Members
Michael Beckman
Adam Petty
Rory Lonergan
Jeffrey Schmidt
DISCLAIMER NOTICE
This document was developed as a part of the requirements of an electrical and computer
engineering course at Iowa State University, Ames, Iowa. This document does not constitute a
professional engineering design or a professional land-surveying document. Although the
information is intended to be accurate, the associated students, faculty, and Iowa State University
make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy
of the information. The user of this document shall ensure that any such use does not violate any
laws with regard to professional licensing and certification requirements. This use includes any
work resulting from this student prepared document that is required to be under the responsible
charge of a licensed engineer or surveyor. This document is copyrighted by the students who
produced this document and the associated faculty advisors. No part may be reproduced without
the written permission of the senior design course coordinator.
Date Submitted
03/30/2007
Table of Contents
Table of Contents ........................................................................................................................... i
List of figures ................................................................................................................................ iii
List of tables.................................................................................................................................. iii
List of definitions.......................................................................................................................... iii
1. Introductory material ............................................................................................................... 1
1.1 Executive summary................................................................................................... 1
1.1.1 Need for the project ....................................................................................................... 1
1.1.2 Project activities ............................................................................................................. 1
1.1.3 Final results .................................................................................................................... 2
1.1.4 Recommendations for follow-on work .......................................................................... 2
1.2 Acknowledgment ...................................................................................................... 2
1.3 Problem statement and solution ................................................................................ 2
1.3.1 Problem statement .......................................................................................................... 2
1.3.2 Problem solution ............................................................................................................ 2
1.4 Operational environment .......................................................................................... 3
1.5 Intended users and uses ............................................................................................. 3
1.5.1 Intended users ................................................................................................................ 3
1.5.2 Intended uses .................................................................................................................. 3
1.6 Assumptions and limitations ..................................................................................... 3
1.6.1 Assumptions................................................................................................................... 3
1.6.2 Limitations ..................................................................................................................... 3
1.7 End-product and other deliverables .......................................................................... 4
2. Project approach and results ................................................................................................... 4
2.1 Approach used .......................................................................................................... 5
2.1.1 End-product functional requirements ............................................................................ 5
2.1.2 Design requirements (including constraints) ................................................................. 5
2.1.4 Approaches considered and the ones selected ............................................................... 6
2.2. Detailed Design ........................................................................................................ 9
2.2.1 Overview of the system design ...................................................................................... 9
2.2.2 Flow restrictor and oxygen sensor ................................................................................. 9
2.2.3 Amplifier ...................................................................................................................... 12
2.2.4 ADC ............................................................................................................................. 13
2.2.5 Microcontroller ............................................................................................................ 14
2.2.5.1 Development environment .................................................................................... 14
2.2.5.1 Pseudo code .......................................................................................................... 15
2.2.5.3 Serial enabled LCD backpack ............................................................................... 15
2.2.5.4 LCD....................................................................................................................... 16
2.2.6 Power supply and voltage regulators ........................................................................... 16
i
2.2.7 Low battery detection .................................................................................................. 17
2.2.8 Protoboard .................................................................................................................... 17
2.2.9 End product design ...................................................................................................... 18
2.3. Implementation Process Description ..................................................................... 20
2.4. Testing of the end product and its results .............................................................. 21
3. Estimated Resources and Schedules ..................................................................................... 22
3.1 Resource requirements ............................................................................................ 22
3.1.1 Personal effort requirements ........................................................................................ 22
3.1.2 Other resource requirements ........................................................................................ 24
3.1.3 Financial requirements ................................................................................................. 24
3.2 Schedules ................................................................................................................ 25
3.2.1 Project schedule ........................................................................................................... 25
3.2.2 Deliverable schedule .................................................................................................... 26
4. Closure Materials .................................................................................................................... 27
4.1 Project evaluation.................................................................................................... 27
4.2 Commercialization .................................................................................................. 29
4.3 Recommendations regarding project continuation and modifications.................... 29
4.4 Lessons learned ....................................................................................................... 30
4.4.1 What went well ............................................................................................................ 30
4.4.2 What did not go well .................................................................................................... 30
4.4.3 What technical knowledge was gained ........................................................................ 31
4.4.4 What non-technical knowledge was gained ................................................................. 31
4.4.5 What would you do differently if you had project to do over again ............................ 31
4.5 Risk and risk management ...................................................................................... 31
4.5.1 Anticipated potential risks and planned management ................................................. 31
4.5.2 Anticipated risks encountered and success in management ........................................ 32
4.5.3 Unanticipated risks encountered, attempts to manage, and success ............................ 33
4.5.4 Resultant changes in risk management made because of encountered unanticipated
risks ....................................................................................................................................... 33
4.6 Project Team Information ....................................................................................... 33
4.6.1 Client Information ........................................................................................................ 33
4.6.2 Faculty Advisor Information........................................................................................ 33
4.6.3 Team Members’ Information ....................................................................................... 34
4.7 Closing Summary.................................................................................................... 34
4.8 References ............................................................................................................... 34
4.9 Appendices .............................................................................................................. 35
4.9.1 Appendix A – Microcontroller block diagram............................................................. 35
4.9.2 Appendix B – Oxygen sensor specifications ............................................................... 35
4.9.3 Appendix C – Serial enabled LCD backpack schematic ............................................. 37
4.9.4 Appendix D – Testing document ................................................................................. 38
ii
List of figures
Figure 1: Overall system design………………………………………………………….... 9
Figure 2: Low pressure inflator connection………………………………………………... 10
Figure 3: Oxycheq flow restrictor and sensor cap................................................................. 11
Figure 4: Flow restrictor diagram………………………………………………………….. 12
Figure 5: Oxygen sensors………………………………………………………………….. 12
Figure 6: The amplifier…………………………………………………………………….. 13
Figure 7: The PIC18F4520 microcontroller……………………………………………...... 14
Figure 8: The PICDEM 2 PLUS development board……………………………………… 14
Figure 9: Serial enabled LCD backpack…………………………………………………… 15
Figure 10: Formatted output on the LCD screen……………………………………….….. 16
Figure 11: TL780 Voltage regulator………………………………………….……………. 17
Figure 12: The MAX667………………………………………….……………………….. 17
Figure 13: Initial end-product design…………………………………………………….... 19
Figure 14: Design phase end-product design….…………………………………………… 19
Figure 15: Current end-product design……………………………………………………. 19
Figure 16: Project schedule……………………………………………………………....... 26
Figure 17: Deliverable schedule………………………………………………………….. 27
List of tables
Table 1: Original labor totals……………………………………………………………...
Table 2: Modified labor totals…………………………………………………………..…
Table 3: Final labor totals…………………………………………………………..……..
Table 4: Labor costs……………………………………………………………………….
Table 5: Other resource requirements……………………………………………………..
Table 6: Financial requirements…………………………………………………………...
Table 7: Component costs in bulk…………………………………………………………
24
24
24
24
24
25
29
List of definitions
ADC - Acronym for analog to digital converter. Converts an analog signal to a digital one for
use in digital processing.
DC – Acronym for direct current. In a direct current circuit, current always flows in the same
direction.
Decompression sickness (DCS) - This occurs when a diver returns to the surface too rapidly and
nitrogen bubbles form in her or his bloodstream. Depending on the severity, these bubbles can
cause joint pain, strokes, and even heart failure.
LED - Acronym for light emitting diode. This is an electrical component that lights up when
current passes through it.
iii
LCD - Acronym for liquid crystal display. This is a screen for output that is comprised of
multiple monochrome pixels with a backlight.
Maximum operating depth (MOD) - A SCUBA diving term referring to the maximum safe
depth based on the partial pressure of oxygen. While opinions vary, the accepted safe maximum
PO2 is 1.4, with an absolute limit of 1.6.
Nitrox - A gas mixture comprised of nitrogen, oxygen and other trace gases. In SCUBA diving,
Nitrox is commonly mixed to contain a higher than normal percent of oxygen (greater than
20.9%).
O2 (or O2) - Short for oxygen.
Oxygen analyzer - An instrument that uses an oxygen sensor to determine the fractional
percentage of oxygen contained in a gas.
Oxygen sensor - A device that measures the percent of oxygen in a gaseous medium.
PO2 - Partial pressure of oxygen, more accurately termed ppO2. PO2 is used in the diving
community for simplicity.
Polling - A computer programming technique where software constantly checks a device to see
what the device’s data value is.
SCUBA - Acronym for self contained underwater breathing apparatus.
SOAP - Acronym for “SCUBA Oxygen Analysis Project” – the name of the project.
Voltage – A voltage is the difference of electrical potential between two points of an electrical
network. The unit for voltage is volts (V), and this document refers to voltages when discussing
power requirements and ADC input.
iv
1. Introductory material
Included in the introductory materials are the executive summary, acknowledgments, the problem
statement and solution, the operating environment, the intended users and uses, assumptions and
limitations, and the expected end-product (and other deliverables).
1.1 Executive summary
This section provides a summary of the project.
1.1.1 Need for the project
SCUBA diving has become a popular hobby and has steadily grown since its inception. The amount of
time divers have traditionally been able to spend underwater has been limited by both the amount of air
they can bring with them and the buildup of nitrogen in their bloodstream. This buildup occurs as
increased pressure forces nitrogen to dissolve into the bloodstream when a diver descends. Likewise,
when a diver surfaces, the pressure decreases and the nitrogen will come out of the diver’s blood
solution and need to be released. The excess nitrogen is removed from the body by respiration, and there
is a fixed rate at which this can occur. If a diver ascends too quickly, bubbles will form in the
bloodstream. These bubbles can lead to decompression sickness, which is a debilitating and possibly life
threatening condition. Divers can avoid these problems by making long stops at slowly and steadily
decreasing depths to properly remove the nitrogen. However, this requires carrying more breathing gas
and warmer exposure suits. The other solution to the problem would be to simply breathe less nitrogen.
To accomplish this, some of the nitrogen in the breathing mixture is replaced with oxygen. This mixture
is called Enriched Air Nitrox, or simply Nitrox.
When a person goes SCUBA diving, a Nitrox tank must first be analyzed to determine the fractional
percent oxygen content of the tank. Typically divers use expensive off-the-shelf analyzers to determine
the oxygen percentage and then look at a series of tables to determine the MOD of their dive. While this
may seem trivial, many divers come from non-technical backgrounds and have difficulties using the
tables to safely plan a dive.
The goal of this project was to create a low-cost device that could analyze and output the oxygen
percentage of a Nitrox tank and the MOD for a dive. Such a device could help to remove human error
from SCUBA diving by providing one simple interface by which divers could see their tank’s oxygen
percentage and MOD. This would not only make it easier for divers to determine their MOD, but it
could also save lives by removing one source of human error. Also, since the device was intended to be
low-cost, it could motivate people to take up SCUBA diving as a hobby.
1.1.2 Project activities
There were four major activities (phases) of this project: planning, designing, implementing, and testing.
In the planning phase, the team came up with the requirements for the device, the specifications for the
device, the basic component architecture for the device, and a plan for getting the project built by the
team’s deadline. A “project plan” was written to show the results of the planning phase.
The design phase focused on creating a detained architecture for the end-product. Specific components
were considered, tested for usability, and decided upon for use in the project. Component-level diagrams
were also drawn to demonstrate how the components would interface with each other. Also, pseudo1
code was written for the microcontroller. A “design report” was written to show the results of the design
phase.
The implementation phase started immediately after the design phase ended. In this phase, project
components were ordered (the ones that weren’t ordered in the design phase) and the end-product was
built out of them. Also, the project’s design was updated during this phase.
The final phase, product testing, was done both during and after the implementation phase. As the
device’s components were built, coded, etc, they were tested to ensure that they performed as expected.
Also, after the end-product was completed, testing was done on it ensure that it met all the design
specifications and that it worked as the client expected it to.
This document is the “final report” for the project, which was written to show the changes made from
the design phase and the results of the implementation and testing phases.
1.1.3 Final results
The final result of the project was that an end-product was created that successfully met all of the team’s
specifications and requirements. The end product is described in detail in later sections of this document,
but to summarize, the end product is a mobile oxygen analyzer that can calculate and output the MOD of
a dive. It is battery powered, small, reliable, accurate, and has a simple user interface.
1.1.4 Recommendations for follow-on work
The team successfully completed this project, on time, to the full specifications outlined by the client.
There is no need for follow-on work with the purpose of completing the project as it was originally
described. However, the end-product could be modified to include additional functionality. Suggestions
for improvements to the end-product can be found in section 4.3 of this document.
1.2 Acknowledgment
The team would like to thank their client, Dan Stieler, for proposing this project. He provided a great
deal of insight into oxygen sensors and analyzers and gave the team some great ideas about how to
design the device. The team would also like to thank Dr. Tuttle for his insight on the design and the
SSOL lab for allowing the team to use their equipment
1.3 Problem statement and solution
This section summarizes the general problem as well as the proposed solution.
1.3.1 Problem statement
Current commercial oxygen analyzers for SCUBA diving are expensive and contain minimal features to
aide divers when they are analyzing the oxygen content of their tanks. This can dissuade people from
taking up SCUBA diving as a hobby, so the team’s client proposed that a handheld device be built with
an LCD display that can accurately analyze the contents of a SCUBA tank. This device needs to be able
to display the percentage of oxygen and the MOD of an oxygen enriched mixture. It also needs to be
reasonably cheap to create and very reliable.
1.3.2 Problem solution
The team’s solution was to build a mobile oxygen analyzer using an oxygen sensor connected to a
device of the team’s design. This device takes the oxygen content of a SCUBA tank as input and outputs
that percentage onto an LCD screen, along with the MOD for the mixture. The team ensured that the
2
oxygen sensor is taking measurements within 1% of the correct amount of oxygen by outputting very
accurate information to the LCD (proven with testing) and by providing a calibration knob on the
device. Also, the device is handheld and battery powered. Finally, the cost of the components for the
device was $169.55, which is well below the cost of commercial oxygen analyzers.
1.4 Operational environment
Since the device is used to analyze tanks both indoors and outdoors, it was made to be water resistant
and relatively immune to temperature changes. However, this device is not water proof and should not
be used under wet conditions. Also, it isn’t guaranteed to operate in temperatures above 120 degrees
Fahrenheit or below 32 degrees Fahrenheit. Finally, though it was designed to be durable, it was not
designed to be able to survive extreme physical trauma.
1.5 Intended users and uses
This section defines the intended users and uses of the device.
1.5.1 Intended users
This device is intended to be used by SCUBA divers and people that refill SCUBA tanks. This will
typically be a fully certified adult who has a reasonably high amount of experience with SCUBA diving.
However, there are no physical requirements preventing people from using the device, so anyone who
can connect the oxygen sensor, turn the device on, and read the LCD should be able to use the device.
1.5.2 Intended uses
Users can use the device to determine two things: the percentage of oxygen content in a SCUBA tank
and the MOD of a SCUBA dive. Those users that aren’t interested in the MOD can use the device like
any other conventional oxygen analyzer.
1.6 Assumptions and limitations
The following section defines the assumptions and limitations for the team, the design process, and the
end-product.
1.6.1 Assumptions








The parts required are affordable and are commercially available.
The device’s user understands English and understands exactly what the output of the device
means.
The complexity of this device is within the scope of the knowledge and time that is at the
disposal of the team.
The team has access to a SCUBA tank for testing.
All of the purchased components operate at or above their specifications.
The components needed to make the device are capable of being powered by a battery.
No one on the team will drop the class or get severely injured.
The user will follow the device’s instructions and not use the device in a manner in a way that
was unintended by the team.
1.6.2 Limitations


The project must completed by the deadline in spring 2007.
The oxygen sensor must be capable of reading in oxygen content of a SCUBA tank within 1% of
the actual value for the full range of oxygen input.
3












The MOD must be accurate for the full range of the possible oxygen input.
The device needs to be mobile.
The device cannot weigh more than 5 pounds.
The device needs to be powered by a battery.
The device needs indicate low battery status.
The device needs to be able to correct inaccurate input.
The device needs to be reliable and consistent.
The device needs a way of being easily powered on and off by the user.
The device’s LCD needs to be large enough to display all of the device’s output.
The device needs to display the oxygen percentage and the MOD on the LCD.
There must be a publicly available development board to program the microcontroller.
The cost of the device’s parts should not greatly exceed $150.
1.7 End-product and other deliverables
The end product is a mobile device that weighs about 1 pound.
The device’s enclosure is made of aluminum and is 8” x 4” x 1.5” large. The enclosure can be opened by
removing the screws that hold the top half and the bottom half together. This allows access to the battery
and other internal components. There are sections of the device that are not covered by the aluminum
enclosure. The LCD screen is covered by a piece of Plexiglas, which protects it from water and other
harmful elements. The power switch, low-power LED, calibration knob, and oxygen sensor input port
rise out from the enclosure and are not protected.
To convey information to the diver, the device uses a 4 line x 20 character LCD screen. The LCD screen
is backlit to make the text easily readable. When the device is turned on, the screen displays the
percentage of oxygen in the oxygen tank and the MOD at a PO2 of 1.4 and 1.6.
The device operates off of a 9V battery and is turned on/off via a switch. The battery (located inside the
enclosure) is easy to replace. There is also an LED that indicates when the device’s battery is low on
power. As the device’s battery gets weaker, the device’s readings become increasingly inaccurate, so the
battery should be replaced as quickly as possible when the low battery LED is lit up.
There is a port on the device for the oxygen sensor to connect to. The oxygen sensor need only be
plugged into this port for the device to start taking oxygen sample readings. When the oxygen sensor is
not plugged into the device, the device outputs an error message to the user. The sensor reading can be
calibrated via a knob on the case.
The completed device, the design schematics, and the programming source code are to be turned over to
the client upon the completion of the project.
2. Project approach and results
The following section provides a detailed description of the team’s approach to the design and the endresults of the project.
4
2.1 Approach used
The following section contains the end-product functional requirements, design requirements (including
constraints), and technical approaches considered (and the ones selected).
2.1.1 End-product functional requirements
The following section describes the functional requirements of the end product:

Calibration: The device can be calibrated via a knob on the device’s case. Calibration is done
by taking an oxygen tank with a known percentage of oxygen and turning the calibration knob
until it the device displays the correct oxygen value.

LCD screen: The LCD screen is used to convey the device’s output to the user. It displays the
fractional percentage of oxygen in the oxygen tank and the MOD at a PO2 of 1.4 and 1.6. It also
displays an error message when invalid input is detected.

Low-battery LED: An LED lights up when the device’s battery drops below 7V. The device
requires 7V to operate properly, and when this LED lights up, the battery should be replaced.

Oxygen sensor: The oxygen sensor reads in the oxygen content of the SCUBA tank and sends
that information to the device. Its samples are accurate within 1%.

Power (on/off) switch: The device has an on/off that powers up and powers down the device.
2.1.2 Design requirements (including constraints)
The following section describes the design requirements and constraints that the team worked under
while building the end product:

Budget: The team had a design budget of $150. While spending more than $150 was an option,
it was not preferable as the team would have had to provide the additional funding themselves.

Input interface: The device needed to have a simple interface for connecting the oxygen sensor.

Input-correction (calibration): The device needed a way to correct the input from the oxygen
sensor if the sensor is giving non-ideal input. Also, the accuracy of oxygen sensors decays over
time, so some form of calibration was needed to make the device work with non-new sensors.

Low power detection: The device needed to be able to inform the user when power is low.

Microcontroller: The microcontroller had to be low power (be able to operate with a 5.5V input
or less). It also needed to have an ADC and be able to transmit serial data at 9600bps. A
microcontroller with an internal clock was preferred.

Mobility: The device needed to be mobile because users are expected to bring the device to their
tanks – not their tanks to the device. To make the device mobile, the device needed to meet
certain size, weight, and power requirements. Those constraints are listed separately in this
section.
5

Oxygen Sensor: The team needed to make one oxygen sensor compatible with the end-product.
This sensor had to be high performance, high accuracy (within 1%), full range (be able to detect
0% - 100% oxygen content), have a long shelf life, and have a long active life.

Operating environment: The device was expected to be water resistant and relatively immune
to temperature changes. However, it was not expected to be water proof or to operate in
temperatures above 120 degrees Fahrenheit or below 32 degrees Fahrenheit. Also, though it was
expected to be durable, it was not expected to be able to survive extreme physical trauma.

Output: The team needed to be able to output all the relevant information on one screen. It was
preferable that buttons not be needed for scrolling. Also, the screen had to fit within the
enclosure.

Power: The device needed to be powered by a battery – preferably only one. Also, the device
needed to be capable of being turned on and off by the user.

Size: The device needed to be small enough to be considered mobile. The team took this to mean
that the device shouldn’t be more than 10" x 6" x 3" large.

Weight: The device is designed to be handheld, so it shouldn’t be heavy. 5 pounds or lower was
the maximum weight that the team believed the device should be to maintain “mobile” status.
2.1.4 Approaches considered and the ones selected
The following section presents several of the possible technological alternatives that were analyzed
during the design of this product, along with their respective advantages and disadvantages. In addition,
this section presents the technology selected for the final design.

Amplifier: The oxygen sensor inputs a voltage into the ADC of the microcontroller so that the
microcontroller can analyze the oxygen levels in the tank. To read this voltage, an amplifier
needed to be implemented so that the low voltage levels outputted by the sensor could be read by
the ADC at levels that the microcontroller can readily use. The team originally decided to build
the amplifier themselves out of commonly available components, but after some consideration,
the team decided to use an instrumentation amplifier from Texas Instruments - the INA128. This
particular amplifier had a very low offset voltage (50uV maximum), low power usage, could be
implemented in a design with low voltage rails, could be used in a design that uses battery, and
had a gain that could be easily modified. For these reasons, the team went with this amplifier.

Calibration: The team decided that a knob would be the best way to correct the input (calibrate)
of the oxygen sensor. Since calibration is done internally via a potentiometer, the team only
considered round knobs that would rise out of the exterior of the enclosure. Such a knob served
the dual-purpose of making calibration easy to implement and creating an interface that is easy
for the user to understand. Other ways of correcting the oxygen sensor input would have been
too hard to implement, so nothing other than knobs was seriously considered.

Document and code repository: Since the team needed an effective way to collaborate on the
project, “Subversion” was chosen to provide a stable and reliable repository for all of the
electronic media created. This includes all documents prepared for the client, images used, and
code. There were many advantages to using Subversion over a simple remote storage setup.
6
Subversion kept a complete revision history of every file contained in the repository. At any
time, the team could look back at a previous version and compare the differences. This helped a
great deal when a member accidentally overwrote someone's changes. In addition to allowing the
team to review and change past revisions, the Subversion software emailed the entire team with
the details of any change, plus a message left by the team member who made the changes. This
eliminated the need for one member to notify the team when a change was made. It also
reinforced the need for members to document the changes made. The last feature the team relied
heavily upon was the integration of Subversion with a web server to create an easily accessible
web interface for the code. While the team considered similar software packages, such as the
Concurrent Versions System or CVS, they lacked the features of Subversion, so they were not
ultimately used.

LCD screen: Various LCD screens were considered, but all of the potential candidates had to
meet the following criteria: it had to be HD44780 compliant, it had to be backlit, and it had to be
20 characters wide (or more). Both red and green tinted LCDs were considered, but in the end,
price was a heavier consideration than color. The LCD screen that the team chose was a basic
Hitachi 4 line x 20 character LCD that was green-tinted and backlit. It was chose because it was
cheap and could output all of the information on one screen without the need for buttons.

LCD serial backpack: The team decided to use a serial backpack to simplify the process of
sending data from the microcontroller to the LCD. Only one serial backpack was considered for
use in this device. This was because serial backpacks are uncommon components, and few
companies make them. On the recommendation of someone who had used a serial backpack
before, the team chose to use the backpack offered from SparkFun.com.

Low power detection: Initially, the team thought that the microcontroller could be programmed
to determine when the device was low on power. However, further research into the issue
showed that the microcontroller’s capabilities would be insufficient to implement this feature, so
a special integrated circuit was ordered to serve as a trip for when the battery is low. Specifically,
when the battery’s voltage falls below 7V, an LED lights up to indicate that the power is low.
The integrated circuit was researched and purchased after the discovery that the microcontroller
couldn’t do the job, and the team purchased the first integrated circuit they found that met the
needs of the project.

Microcontroller: During the approach to designing the analyzer, the team decided that a
microcontroller would be used to read in all of the inputs and output the calculated information
to the user via the LCD screen. Texas Instruments provided the team with some free samples of
some of their microcontrollers, but the team had difficulties finding a board to program the
microcontroller on. Also, Texas Instruments’ microcontrollers were surface mount. After some
discussion, the team decided to use a PIC microcontroller from Microchip instead. Multiple
boards to program these microcontrollers were readily available on campus, which helped keep
the project within its budget. After initially planning to use the PIC18F452, the team decided to
use the PIC18F4520. While both had an ADC, a serial connection, were low power, and were
sufficiently fast, the PIC18F4520 had internal clock and an easier to use ADC. Also, the
PIC18F4520 was more commercially available and Microchip offered free samples of them, so
choosing the PIC18F4520 helped the team stay under budget.

Oxygen Sensor: Many different oxygen sensors were evaluated during the initial planning
stages of this project. After some research was completed, the team decided to obtain a sensor
7
manufactured by Teledyne Analytical Instruments. This decision was made because the company
is well known amongst the diving community and manufactures accurate sensors that are well
documented. After the team chose a vendor for purchasing the sensor, a specific model needed to
be decided upon that would be well suited for the design. The sensor that the team decided on
using for the project is the Teledyne R22D. This is a high performance and high accuracy
oxygen sensor. It has a both a long shelf life and a long active life. The sensor has an output of
9mV and 12mV in air at 25۫ ۫C at sea level.

Power: The final product is powered by a 9V battery. This battery was chosen because it was
readily available and because of its size. To get a high enough voltage from AA batteries,
multiple batteries would be needed, which would have added a significant amount of weight to
this device. Since this device was not intended to be turned on for more than a few seconds at a
time, a low amp-hour rating wasn’t as important of a consideration as size or weight.

Power on/off: Buttons and switches were both considered to power on/off the device, but a
switch was eventually chosen because it was easier to implement and equally easy to understand.
Various switches were considered for the device, but all of them were two-state switches. The
team thought that a switch with more than two states would confuse the user.

Programming language: The software that analyzes and outputs the oxygen percentage and
MOD to the LCD screen was written in C. C was chosen because it is the most common highlevel language of the chosen microcontroller, and because programming in pure assembly would
have been too time consuming. Also, there were many good examples of code on the Internet for
the microcontroller that was written in C.
8
2.2. Detailed Design
The detailed design section of this report features a thorough description of the design of the device.
2.2.1 Overview of the system design
The design of the oxygen analyzer device was divided into several subsections. These subsections
consist of the oxygen sensor, an amplifier, the power supply and voltage regulators, the microcontroller
(including its internal clock and ADC), the low power detection unit (and attached LED), and the LCD
display (including serial backpack). The interconnection of these components is shown in Figure 1.
Figure 1: Overall system design
2.2.2 Flow restrictor and oxygen sensor
The flow restrictor is the part of the device attaches directly to the user's SCUBA gear to reduce the flow
rate over the oxygen sensor. While a SCUBA tank may contain gas at over 3000 pounds per square inch
(psi), the flow rate over the sensor should be approximately 1 liter per minute to properly analyze the
gas. To simplify the design and help reduce possible damage to the oxygen sensor, the team chose to
attach the device to the low pressure inflator line of a SCUBA regulator. A picture of this connection is
shown in Figure 2.
9
Figure 2: Low pressure inflator connection
The output of this line is reduced from the tank pressure to 150psi above the ambient pressure. This
greatly simplified the design of the flow restrictor, and since this used a quick disconnect, the design is
improved from a usability standpoint as well. To design this flow restrictor, Bernoulli's Continuity
Equation was used to derive the proper dimensions of the restricting orifice. Converting the integral
form of the equation into a quasi-one-dimensional form yields the following equation:
1 A1V1   2 A2V2
Equation 1: Bernoulli's continuity equation
In equation 1, ρ is the density of the fluid (air), A is the area of the orifice, and V is the velocity of the
fluid. In this case, the velocity is not an important factor as long as it remains below Mach 0.3. Below
that velocity, air can be very accurately modeled as an incompressible fluid. Knowing the relation
between area, velocity, density of the gas, and pressure differences, the equation can be rewritten into
the following form:
1
1
  V22  V12
2
2
Equation 2: Relation between pressure difference and fluid velocity
Combining the two previous equations and relating velocity to volumetric flow rate and area, an
equation describing the flow rate (Q) can be found.
Q
2p
A2

2
A 
1   2 
 A1 
Equation 3: Idealized flow rate
The above equation can be further modified to account for real world effects such as turbulence and
viscosity. This yields the final equation used in the calculations, shown in equation 4.
10
Q  C f Ao 2
p

Equation 4: Flow rate versus area of the orifice
In the above equation, several assumptions have been made. First, it is possible to replace A1 and A2 (the
areas of the pipe inlet and the restricting orifice) with Ao and Cf. Since modeling the flow through A2 is
very complex, a flow coefficient Cf is introduced. However, this is only valid if the distance along the
tube leading to the orifice is approximately four times the diameter of the orifice. The tubing used to
connect to the orifice is approximately 1cm in diameter, so a distance of 4cm was required. Second, the
value of Cf is also assumed. Typically the value of Cf for an orifice is between 0.6 and 0.9. For theses
calculations, a value of 0.6 was chosen (representing the high turbulence created by the sharp edges of
the orifice when it is drilled). Finally, using a diameter of 1cm for the tube leading to the orifice and a
flow rate of 1 liter per minute, a value of 170 µm was calculated to be the correct size of the orifice.
During the design process it became clear that manufacturing a block of aluminum with a hole only 170
µm in diameter was beyond the capability of the resources at hand. The team decided to find an off the
shelf solution that fit the above requirements. Shown below is an image of the flow restrictor as
purchased from OxyCheq. It features a quick disconnect fitting and includes a cap with threads to screw
directly onto the oxygen sensor. The oxygen sensor also has an O-ring on the threaded connector so this
provided the team with a reasonably closed loop while gas is flowing over the sensor. This should
further enhance the accuracy and reliability of the device.
Figure 3: OxyCheq flow restrictor and sensor cap1
As a summary of the flow restrictor design, a quick disconnect fitting attaches to the low pressure
inflator line and then directly to the flow restrictor. Since the low pressure inflator line is typically 27
inches long, this guarantees a minimum length of 4cm before the flow restrictor. The restrictor has a
barbed fitting on the low pressure side. The barbed fitting is attached to the oxygen sensor cap with a
flexible plastic hose. The screw on cap attaches securely to the oxygen sensor and provides a low leak
system to analyze the gas. The diagram below illustrates this design.
1
Graphic from http://www.oxycheq.com/Oxycheq/analyzeracc/F44575EB-4D44-4712-8053-4C574CA2D409.html
11
Figure 4: Flow restrictor diagram
The oxygen sensor used in this design, the R22D from Teledyne, is more accurately termed an electrogalvanic fuel cell. Inside the sensor there is a lead anode and a gold-plated cathode. Potassium hydroxide
(the “fuel”) reacts with oxygen and produces a current flowing through an attached load. For the R22D
sensor, the load should be 10K Ohms. Figure 5 shows the case style of the sensor the team used.
Figure 5: Oxygen sensors2
The team chose this sensor based on the reliability and experience of the company that produces them. It
will nominally produce a DC signal between 9 mV and 12 mV in air (20.9% O2). Its output changes
linearly depending on the fractional percentage of oxygen. As the percentage of O2 increases, so does
the output voltage from the sensor. The output of the sensor is connected to the amplifier stage and then
fed to the ADC to be interpreted by the microcontroller.
2.2.3 Amplifier
The amplifier takes the weak signal that is outputted from the oxygen analyzer and amplifies it to a
voltage that the ADC can accurately read. Since the gain needed to be large to properly amplify the
signal and offsets needed to be kept to a minimum, an instrumentation amplifier was chosen.
Instrumentation amplifiers are designed to amplify small voltages with a very small offset. The specific
instrumentation amplifier implemented in the design is an INA128, manufactured by Texas Instruments.
The INA128 is a precise, low power instrumentation amplifier with a very low offset voltage significantly lower than the voltage the oxygen sensor creates. The design of the amplifier circuit is
fairly simple, and is shown in Figure 6. The instrumentation amplifier comes in a package with eight
2
Graphic from http://en.wikipedia.org/wiki/Image:Electrogalvanic_fuel_cell_x_3.JPG
12
terminals for input and output. These terminals are labeled one through eight in the schematic. The gain
of the amplifier circuit can be easily changed by modifying the resistor combination between two
terminals. The team used a potentiometer to modify the gain, as doing so allowed the stage to be
calibrated to the changing output voltage of the oxygen analyzer. This calibration helps to compensate
for the variances in the sensor output that can be a result of the sensor’s ago and/or the ambient
temperature. The gain can be calculated from the resistance of the feedback portion by the following
equation:
G 1
50,000
R R
RS  Pot P
RPot  RP
where RS is the value of the series resistor, RPot is the value of the potentiometer, and
RP is the value of the resistor in parallel with RPot.
Figure 6: The amplifier3
2.2.4 ADC
The analog to digital converter, which is built into the microcontroller, converts the DC signal from the
amplifier (0V to 5V range) into a digital signal for use by the microcontroller. The microcontroller uses
a 5V reference voltage to determine the value of the input signal, and turns that value into a digital
number. The ADC has 10 bits of digital output, which means that there are 210 - 1 (1023) possible digital
outputs. To illustrate this, if the amplifier is inputting 3V (with a 5V reference voltage), the
corresponding digital output would be (3/5 * 1023) = 613 (aka, 60% oxygen).
With this setup, the ADC will have a resolution of around 5mV, as given by the following equation:
Vmin 
3
5V
5V

 4.8875mV
2  1 1023
10
Graphic from http://focus.ti.com/lit/ds/symlink/ina128.pdf
13
As a result, the ADC has the ability to be accurate to within .1%, assuming the oxygen sensor is giving
accurate input.
2.2.5 Microcontroller
The microcontroller the team chose for this project is the PIC18F4520, manufactured by Microchip. Its
clock generated by an 8MHz internal crystal. Its purpose is to get the oxygen data, as reported by its
ADC, and use that data to output the percentage of oxygen and MOD to the LCD screen.
Figure 7: The PIC18F4520 microcontroller4
2.2.5.1 Development environment
The development board that was used to program the microcontroller was a “PICDEM 2 PLUS” multichip programming board. It was capable of directly flashing program code to the microcontroller, and
had inputs and outputs that the team could connect all the external components the microcontroller used
to. This board was compatible with the MPLAB integrated development environment (IDE). MPLAB,
in conjunction with the Microchip’s C compiler suite (called C18), was used to program and test the
microcontroller. A picture of the development board is shown in Figure 8.
Figure 8: The PICDEM 2 PLUS development board
4
Graphic from http://www.sparkfun.com/commerce/product_info.php?products_id=232
14
2.2.5.1 Pseudo code
The microcontroller essentially works by constantly checking and updating the oxygen value from the
ADC and recalculating the oxygen percent and MOD. This technique is known as polling. At each
cycle, the oxygen percentage and the MOD values are recalculated and written to the LCD screen. The
pseudo code for these operations is given below.
main() { // Program Entry Point
initialize adc, serialport, lcd;
variables percent_o2, mod_14, mod_16;
while (forever) {
percent_o2 = get_percent_o2();
mod_14 = compute_mod(percent_o2, 1.4); // For PO2 of 1.4
mod_16 = compute_mod(percent_o2, 1.6); // For PO2 of 1.6
output_to_lcd(percent_o2, mod_14, mod_16);
}
}
get_percent_o2() {
return percentage o2 from adc manipulated to be range 0 – 1.0;
}
compute_mod(percent_o2, max_ppo2) {
return 33*(max_ppo2/percent_o2 - 1); // Computes & returns the MOD
}
output_to_lcd(percent_o2, mod_14, mod_16) {
if (percent _o2 input is good) print percent_o2, mod_14, and mod_16 to the LCD;
else print error message;
return;
}
2.2.5.3 Serial enabled LCD backpack
To simplify the process of outputting data to the LCD screen, the team purchased a serial enabled LCD
backpack. This device bridged the gap from the microcontroller to the LCD by having the
microcontroller transmit the oxygen percentage characters and MOD characters to the LCD backpack
via the microcontroller’s serial data output pin. Upon receiving data, the LCD backpack sends the data
to the LCD in a form that the LCD can understand (HD44780 standard format). This allows the
microcontroller code to use C-style printf and putchar statements to send data to the LCD, rather than
sending that information though the microcontroller’s LCD-out pins. A picture of the serial enabled
LCD backpack is shown in Figure 9.
Figure 9: Serial enabled LCD backpack5
5
Graphic modified from http://www.sparkfun.com/commerce/product_info.php?products_id=258#
15
2.2.5.4 LCD
The LCD screen that the team chose to use was a 4 line x 20 character screen from Hitachi that is
HD44780 compliant and backlit (product ID: GDM2004D). The LCD is connected to the serial enabled
LCD backpack, which is what it receives data from (the backpack receives data from the
microcontroller). Figure 10 shows the LCD screen that the team used. Displayed on the LCD screen is
an example of the (properly formatted) output that the device conveys to the user. The values being
displayed are the percentage of oxygen in the SCUBA tank and the MOD at partial pressures of oxygen
of 1.4 and 1.6
Figure 10: Formatted output on the LCD screen
2.2.6 Power supply and voltage regulators
The end-product needed to run off a battery. Using a battery presented certain problems that needed to
be addressed. The largest problem was voltage consistency. Batteries decay in power at an exponential
rate. This decay causes the output voltage to fall. If the ADC’s supply voltage is inconsistent, the
accuracy of the measurements would be severely compromised. Also, the voltage that is need for circuit
components in the device is 5V. Ensuring that the voltage is exactly 5V was important to ensure that the
amplifier and ADC were able to provide accurate values. The answer to both of these problems lied in
the implementation of the voltage regulators. The batteries that were used in this design are of the 9V
form factor family. Given that the batteries with the lowest nominal voltage in this family supply a
nominal voltage of 7.2V, there is a voltage margin of 2.2V that allows for a loss in supply voltage while
still allowing the device to fully function. The battery that provided the lowest nominal voltage was the
Energizer® Rechargeable 9V form factor Nickel Metal Hydride (NiHM). This battery had 6 cells, and
due to the chemical composition of the cells, each cell only produces 1.2 volts. These 6 cells combined
for a total voltage of 7.2V.
To implement voltage regulation, an integrated circuit TL780 (shown in figure 11) was used. This
circuit, which was manufactured by Texas Instruments, regulated the power supply voltage down to 5V.
The battery is connected to the input of the regulation integrated circuit and a regulated 5V is supplied
from the output pin.
16
Figure 11: TL780 Voltage regulator
2.2.7 Low battery detection
If the ADC’s reference voltage is inconsistent, the accuracy of the oxygen content analysis would be
severely compromised. Since the end-product was designed to run off a battery, low battery detection
was implemented to increase the safety of the device. The low voltage circuitry is designed to detect
when the voltage of the battery falls below 7V. This ensures that there is enough power in the battery to
operate the device safely. 7V was chosen as the trip point because the voltage regulator needs 7V to
properly maintain a 5V output. When a voltage lower than 7V is detected, a LED lights up on the case
letting the user know that it is time to change the battery and that the oxygen analysis may not be
accurate.
To implement the low battery detection circuitry, the team used an integrated circuit from Maxim - the
MAX667. The layout of this circuit can be seen in figure 12.
Figure 12: The MAX6676
2.2.8 Protoboard
The oxygen analyzer utilizes different circuits that needed to be tied together on a single printed circuit
board. To accomplish this, the team decided to use a protoboard. The different components were
soldered onto the protoboard in the final implementation, and the board was installed inside the oxygen
analyzer’s enclosure.
6
Graphic from http://datasheets.maxim-ic.com/en/ds/MAX667.pdf
17
2.2.9 End product design
The end product is a mobile device that weighs about 1 pound.
The device’s enclosure is made of aluminum and is 8” x 4” x 1.5” large. The enclosure can be opened by
removing the screws that hold the top half and the bottom half together. This allows access to the battery
and other internal components. There are sections of the device that are not covered by the aluminum
enclosure. The LCD screen is covered by a piece Plexiglas, which protects it from water and other
harmful elements. The power switch, low-power LED, calibration knob, and oxygen sensor input port
rise out from the enclosure and are not protected.
To convey information to the diver, the device uses a 4 line x 20 character LCD screen. The LCD screen
is backlit to make the text easily readable. When the device is turned on, the screen displays the
percentage of oxygen in the oxygen tank and the MOD at a PO2 of 1.4 and 1.6.
The device operates off of a 9V battery and is turned on/off via a switch. The battery (located inside the
enclosure) is easy to replace. There is also an LED that indicates when the device’s battery is low on
power. As the device’s battery gets weaker, the device’s readings become increasingly inaccurate, so the
battery should be replaced as quickly as possible when the low battery LED is lit up.
There is a port on the device for the oxygen sensor to connect to. The oxygen sensor need only be
plugged into this port for the device to start taking oxygen sample readings. When the oxygen sensor is
not plugged into the device, the device outputs an error message to the user. The sensor reading can be
calibrated via a knob on the case.
The initial design the team had is shown in Figure 13 and a picture of the design-phase end product is
shown in Figure 14. The current end-product is show in figure 15.
18
Figure 13: Initial end-product design
Figure 14: Design phase end-product design
Figure 15: Current end product
19
2.3. Implementation Process Description
The implementation process and materials used shall be described in this section.

External case design: The enclosure chosen by the team was made from aluminum and had
some small blemishes on the outside. The team used a grinding wheel with a metal brush to
remove these blemishes, and also to give the case a more professional look. The Plexiglas cover
for the screen was chosen to protect the delicate LCD surface from impacts and water damage. It
was sealed with clear RTV silicone to increase the device’s resistance to water. In addition, the
case has rubber seals along the outside edge, and rubber grommets in the screw holes. These
features further protect the device from any accidental exposure to water.

Circuit board layout: The team used a protoboard as a base for the circuits. This had the
advantage of being easy to work with since it is similar in functionality to a breadboard, while
also allowing the components to be soldered in place. The initial layout was chosen based off the
design used on the breadboard. The layout was clean and manageable, but the team later decided
to add additional circuitry to enhance the low power detection feature. This did add a small
amount of clutter to the design, and in future revisions it should be changed. This highlights the
advantage of using the protoboard over a fabricated printed circuit board - the team could
quickly redesign the circuit to add functionality.

Software implementation: The code for the microcontroller was written in C and programmed
using the MPLAB integrated development environment provided by Microchip. This provided
an easy to use environment using a familiar language. The main difficulty was loading the code
onto the microcontroller, as this required removing the chip from the breadboard and placing it in
the development board. On several occasions the development board malfunctioned, leaving the
team with the impression that it had failed completely. While in all occurrences the board did
resume normal operations, it was frustrating for the team members. Fortunately, any future
versions of the device will require far fewer reprogramming cycles since there is a solid
foundation to work with, and should eliminate some of the problems encountered.

Sensor mounting: The oxygen sensor has been mounted externally to allow for easy storage of
the sensor while not in use, and for faster replacement of the sensor. The user simply needs to
unplug the three pin connector from on end of the sensor, and unscrew it from the flow restrictor
on the other. The physical connection to the case was done using a ¼” mono audio jack. This
gave sturdy mounting and a strong electrical connection, and it is much more durable than most
standard three pin Molex connectors. The team has no complaints with the attachment of the
sensor, and would suggest that future revisions keep this feature.

Final assembly: This part has been planned, but not fully implemented to date. For the latest
testing phase, and for demonstrating the device to the client, the team has temporarily attached
the circuit board, LCD, and battery to the device. Eventually, all of the parts will be attached to
the device in a more permanent fashion. The circuit board will be mounted to the case using
stand offs, the batter holder will be adhered to the case using metallic epoxy, and the LCD will
be attached to the outer cover of the device. Since the assembly is not yet complete, the team has
only one recommendation for future revisions. That is, to attach all components to the top cover
of the enclosure to allow for easy changing of the battery. Hopefully the team will have time to
complete this design change before the final deadline. If not, it will be left for future revisions.
20
2.4. Testing of the end product and its results
Each component of the end product was tested thoroughly and was evaluated based on each subsystem’s
design requirements. The subsystems tested are their testing results are listed below:

Circuitry testing: Initially, circuitry testing was performed without the use of the oxygen sensor
in the laboratory. This means that there were two phases in the circuitry testing: the first phase
was without the oxygen sensor and the second phase will use oxygen sensor as a voltage source.
The first phase used a source that generates a voltage between 0V and 5V. The analog to digital
converter was tested using these values because they are what it would receive under the actual
operating conditions of the device. Before the test began, the team determined the correct
voltages at different locations of the circuit and verified that they were at the correct values. The
testing ensured that the components are behaving linearly and that the ADC is correctly
determining the voltage level. This test was completed using an oscilloscope and multi-meter.
The first phase of tests passed successfully. In phase two, the circuitry was tested while using
the oxygen sensor. This was done in the same manner as the previous tests, testing the same
aspects. The most important part of this test was to ensure the amplifier was working properly.
Since this was the case, the test passed.

LCD testing: The LCD has been tested to make sure that it can display the characters that need
to be displayed. Testing on the LCD was done in conjunction with the microcontroller and
software testing, as it is difficult to test the LCD’s functionality alone. The testing has been done
in the laboratory, working at the computer so that the test can be run using a test program. This
program has tested all the capabilities of the LCD that are required by the team. This included
outputting all required characters, displaying on all four lines of the LCD, making sure that the
data transmission from the microcontroller was error free, getting the delay between character
writes correct, changing the brightness level, and ensuring that it worked properly at
microcontroller startup. The LCD passed all tests performed by the team.

Microcontroller testing: Microcontroller testing was done in conjunction with programming the
software for the device. This took place in the SSOL lab with the microcontroller plugged into
the development board and involved the team writing small programs designed to test the basic
its basic functionality. These tests were aimed at ensuring there is no defect in the
microcontroller, and tested the ADC, LCD output, and logic functionality. These tests showed
that the microcontroller performed as expected, and even pointed out several problems with the
team’s code.

Power testing: The ability for the device to perform at low voltage was important because it was
powered by a source that is not capable of providing a constant voltage (the battery). This means
that the circuit testing needed to include the corner conditions of the power rails to the devices
used. A level of ~6.8V was found to be the lowest amount of power required to operate the
device. Based on this, the team adjusted the low power warning light to come on slightly above
this level (7V).

Sensor testing: Testing the oxygen sensor was done by the team in the SSOL lab and at the
Applied Sciences Complex (ASC). The first tests were done using only room air and exhaled air.
Air contains ~20.9% oxygen, and exhaled air contains between 15% and 17% oxygen. While the
exact percentage of oxygen in the exhaled air was not known, it did show that the sensor
responded to different levels of oxygen. Next, the sensor was tested at the ASC during the final
21
product test phase using tanks of oxygen and nitrogen that could be mixed together in different
ratios. The mixing was controlled by the mass flow rate of the gas. The team measured the
results from the device and compared them to the calculated ratio of the mix. The results of this
test can be found in Appendix D. The voltages outputted by the sensor stabilized using a filter
capacitor to provide a more accurate analysis. The sensor provided very stable readings and was
determined to be functional.

Software testing: After writing the software for the device, the team ran the software through a
series of tests to ensure that there are no bugs in the code. These tests were performed in the
SSOL lab with the microcontroller plugged into the development board. Manual testing was
done on each of the functions in the microcontroller – all of which tested within the boundaries
of the expected input, at the edges of the expected input, and outside the boundaries of the
expected input. The tests included MOD and oxygen percentage testing, as well as ADC
conversion testing. LCD output was also tested both while in the development board and while
connected to the team’s board. The values of MOD at certain percentages of oxygen were
compared against a known value for accuracy. This testing was very important because should a
bug be missed, it could have severe consequences as divers will depend on this device for their
safety. The process of software testing will continue until the device has been delivered to the
client, to ensure there are no hidden bugs.

Final product testing: The final product will need to be tested multiple times; so far it has only
been tested once. The product was tested by the team members and the client, Dan Stieler, at the
Applied Sciences Complex. As described above in the sensor testing section, the team used tanks
of oxygen and nitrogen and mixed them in different ratios to obtain results at different
percentages of oxygen. The tests showed that there is room for improvement on the design; only
two of the tests showed the device reading within the required ±1%. The team plans to make
modifications to achieve the required accuracy, and to make the device easier to calibrate.
Additionally, the device will later need to be tested by the faculty advisor for the team, Gary
Tuttle, and other outside resources to ensure that the device is operating correctly and as planned.
Among the outside resources, divers should be used to test the device. The divers should focus
their evaluation on the usability of the device and accuracy of the information provided. Divers
were more apt to spot errors in the information provided. The outside resources will ensure that
people unfamiliar with the device can properly operate the oxygen analyzer. The team also plans
on testing the final product against similar commercially available products to ensure the
accuracy of the device’s output.
3. Estimated Resources and Schedules
The following section contains the resource requirements for the project and schedules for the project.
3.1 Resource requirements
This section contains personal effort requirements, other resource requirements, and financial
requirements.
3.1.1 Personal effort requirements
The personal effort requirements are divided into subsections that organize the flow of the project design
and progression. These subsections are as follows:
1. Problem definition
22
2.
3.
4.
5.
6.
7.
8.
a. Problem definition
b. End user(s) and end use(s) considerations
c. Constraint identification
Technical considerations and selection
a. Identification of possible technologies
End-product design
a. Identification or design requirements
b. Design process
c. Documentation of design
End-product prototype implementation
a. Identification of prototype limitations and substitutions
b. Implementation of prototype and end-product
End-product testing
a. Test planning
b. Test development
c. Test execution and evaluation
d. Documentation of testing
End-product documentation
a. Development of end-user documentation
b. Development of maintenance and support documentation
End product demonstration
a. Demonstration planning
b. Faculty advisor demonstration
c. Client demonstration
d. Industrial review panel demonstration
Project Reporting
a. Project plan
b. Project poster
c. Design report
d. Final report
e. Weekly email report
Table 1: Original labor totals (in hours)
Task
Michael
Rory
Jeff
Adam
Total
1
15
20
25
15
2
30
27
30
28
3
50
48
45
46
4
26
27
24
28
5
20
23
17
15
6
19
18
15
19
7
14
13
11
13
8
21
22
20
32
195
198
187
196
776
Table 2: Design-phase labor totals (in hours)
Task
Michael
Rory
Jeff
Adam
Total
1
10
13
12
12
2
12
15
10
11
3
41
40
44
45
3
30
24
36
34
4
26
27
24
28
23
5
20
23
17
15
6
19
18
15
19
7 8 9
14 10 11 192
13 9 13 195
11 11 9 189
13 12 20 210
785
Table 3: Final labor totals (in hours)
Member Advisor Mtg Group Mtg Other
Total
Jeff
20
47.1
94
161.1
Rory
17
48.1
76.5
141.6
Michael
21
48.1
82.25
151.35
Adam
21
46.1
92.5
159.6
Total
79
189.4
345.25
613.65
Table 4: Labor costs
Task
Michael
Rory
Jeff
Adam
Total
Rate
$11.00
$11.00
$11.00
$11.00
$11.00
Original Hours
195
198
187
196
776
Totals
$2,145.00
$2,178.00
$2,057.00
$2,156.00
$8,536.00
Modified Hours
181
175
193
190
739
Totals
$1,991.00
$1,925.00
$2,123.00
$2,090.00
$8,129.00
Final Hours
161.1
141.6
151.35
159.6
613.65
Totals
$1,772.00
$1,557.00
$1,665.00
$1,756.00
$6,750.00
3.1.2 Other resource requirements
Resources that are needed to help refine the product are relevant enough to be mentioned in the design
analysis. These items may not necessarily be required to produce a final product, but they are required
for a polished and presentable end product. Such items are listed in table 5.
Table 5: Other resource requirements
Requirement
DC Power Supply
Microcontroller Programmer
Soldering Iron
Multi-meter or Oscilloscope
Computer
Pspice
Microcontroller programming suite
Poster
Miscellaneous
Status
Provided
Provided
Provided
Provided
Provided
Provided
Provided
Purchased
Purchased
Price
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$15.00
$5.00
3.1.3 Financial requirements
The initial and revised project cost estimates can be found in table 6. These calculations assume that the
team members’ hourly wage is $11.00.
Table 6: Financial requirements
24
Parts
Wires, Cables, Connectors
ADC and Microcontroller
Pspice Simulation Software
DC Power Supply
Soldering Iron
Multi-meter or Oscilloscope
Computer
Microcontroller Programmer
Microcontroller Programming Software
Resistors, Capacitors, Op-Amps
Prototyping Boards
LCD Screen
Oxygen Sensor
Enclosure
Knobs and Buttons
Batteries
Poster
Miscellaneous (RTV Silicone)
Total
Labor
Total With Labor
Status
Provided
Purchased
Provided
Provided
Provided
Provided
Provided
Provided
Provided
Provided
Provided
Purchased
Purchased
Purchased
Purchased
Provided
Provided
Purchased
Original Price Prediction
$10.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$5.00
$10.00
$15.00
$70.00
$20.00
$15.00
$0.00
$40.00
$40.00
$225.00
$8,536.00
$8,761.00
Modified
$0.00
$11.65
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$32.90
$70.00
$20.00
$15.00
$0.00
$15.00
$5.00
$169.55
$8,129.00
$8,298.55
The majority of the project design and assembly occurred within the SSOL lab at Iowa State. The lab
provided the use of the microcontroller programmer free of charge. It also provided the use of soldering
irons, oscilloscopes, wires, and the microcontroller headers. Other parts that were anticipated to cost
significant amounts of money were also available free of charge online via the “free sample” option that
most companies offer for electrical components. The poster was printed free of charge by the Computer
Support Group (CSG). The only cost involved with the poster was the lamination. Miscellaneous
charges were very minimal as well. The only significant charge concerning miscellaneous items was the
RTV silicone that was used to seal portions of the enclosure. This large deviation from the original cost
estimate was not expected, but worked to the team’s benefit.
3.2 Schedules
The following section contains the project schedule and the deliverable schedule.
3.2.1 Project schedule
The primary changes to the project schedule from the schedule that was predicted in the Design Report
were the extension of the prototyping section, the testing section, and the time frame for miscellaneous
purchases. These extensions are the result of several unforeseen obstacles that were encountered
throughout the two semesters. Also, the redesign section has been omitted due to the method of
prototyping that is being used, and testing was done during the time that prototyping was scheduled for.
25
Figure 16: Project schedule
3.2.2 Deliverable schedule
The deliverables Gantt chart displays the parts of the project that are not related to research, design, and
implementation. The portions that have been finished are shown with a check-mark on the Gantt chart.
26
Figure 17: Deliverable schedule
4. Closure Materials
This section contains the project evaluation, commercialization considerations, recommendations
regarding project continuation and modification, lessons learned, risks and risk management, the team’s
information, and the closing summary.
4.1 Project evaluation
Evaluating a project’s success depends heavily on the goals originally outlined for the project. The
success or failure of each of the goals is a good indicator of the project’s overall success. Each of the
27
goals outlined early in this project are discussed in this section, with a summary of the goal’s success or
failure. Afterwards, the project’s overall success or failure is discussed.
Device powers on with battery:
One of the most important goals for the project was the ability to power the device on. In the final
implementation, the power on/off capability is completely intuitive and simple to understand. It requires
no external input from the user other that simply throwing a switch. Given the simple “it just turns on”
nature of the on/off switch, it is safe to say that the “power on” goal was fully met and was an important
milestone in making the device usable. Likewise, the end-product successfully runs off a 9V battery, so
that goal is also considered to be fully met.
Device displays percentage of oxygen and MOD:
To have a successful project, the end-product must be able to do what its specifications say it should be
able to do. In the case of this project, if the percentage of oxygen and the MOD weren’t shown on the
LCD display, then the project would be considered a failure. Fortunately, that wasn’t the case. The endproduct of this project successfully displays both the percentage of oxygen and the MOD on the LCD
screen. This display is refreshed roughly once per second and is easily readable on the LCD’s high
contrast, backlit, screen. Furthermore, in the case that the sensor feeds bad information into the
microcontroller, or that the sensor is disconnected, the LCD displays a message informing the user to
“Check the Sensor”. As a result, this milestone is considered to have exceeded expectations, as the LCD
screen displays all the data it should, plus some extra data when bad input is detected.
Safe for use within an oxygen environment:
Testing was done on the device to ensure that it would not combust, and the components were laid out
inside the device to ensure that oxygen would be a non-factor in the device’s internal operation. As a
result, this goal, while not the most important, is considered to be fully met.
Accurate within 1%:
While the accuracy of the oxygen analysis is largely a function of the oxygen sensor, it also depends on
the health of the battery and any offsets present in the amplifier. When the battery voltage is above 7V
and a test voltage is given to the ADC (as opposed to the oxygen sensor), the circuit performs very
consistently and reliably - well within 1% accuracy. However, the input from the oxygen sensor isn’t as
stable as the test inputs, so to overcome problems involved with sensor instability, a calibrating
potentiometer was implemented on the front of the device. This allows users to remove most of the error
that comes from the sensor, but it alone isn’t sufficient to address the accuracy issues that can occur
when the battery voltage is low. To counteract this problem, the low battery warning LED was
implemented. While this doesn’t solve the problem of the device outputting potentially incorrect data to
the LCD screen when the battery is low, it does let users know that the accuracy of the device could be
compromised. Given the testing results at the time this document was written, this milestone can be
considered partially met. Of the tests performed, two were accurate with 1% and three were accurate
within 1.8%. The team theorizes that the results will be improved when the restrictor plate arrives.
Considering how important the accuracy of the output is to the success of the project, this milestone is
extremely important.
Small and manageable enclosure:
The device needed to be mobile, and as such, it needed to be reasonably small and lightweight. The endproduct weighs approximately 1 pound, and the device is only 8” x 4” x 1.5” large, so this goal can also
be considered to be fully met.
28
Given that most of the project’s goals were either fully met or exceeded expectations, the team believes
that the project can be considered a success. The only goal that isn’t fully met yet is that the device isn’t
always accurate within 1%, but it is accurate within 2%, and changes are planned to make it accurate
within 1% by the time it is turned over to the client.
4.2 Commercialization
Though the device was not specifically designed with commercialization in mind, the possibility of
commercialization will be considered in this section. Take note that in these commercialization
considerations, it is assumed that the prototype design will not be altered. Oxygen analyzers on the
market that doesn’t calculate the MOD currently sell for over $300, and the market pool is fairly small.
Taking this into consideration, the team’s end-product would probably be sold for between $200 and
$270. This price would allow the device to be sold at a lower price than its competitors while still
making a reasonable profit. Table 7 shows a breakdown of the estimated costs to produce 100, 250, 500,
and 1000 units. These estimated prices were provided by various vendors that sell components in mass
quantities. The potential for profit is between $32 and $112 per unit if the device is sold at the price
listed above.
Table 7: Component costs in bulk
9V Battery
Voltage Regulator
Microcontroller
Sensor
Inst. Amplifer
LCD
LCD Backpack
Power Switch
Wiring
Potentiometer
Battery Holder
Battery Clip
PCB
Enclosure
Production
Total
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
100
1.60
0.54
6.37
70.00
6.35
17.95
14.95
1.93
0.25
9.98
0.18
0.28
10.00
18.33
10.00
168.71
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
250
1.51
0.41
6.37
69.50
6.11
17.95
14.95
1.93
0.24
9.70
0.18
0.28
9.49
18.33
9.50
166.45
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
500
1.51
0.36
6.37
68.90
6.01
17.95
14.95
1.75
0.24
9.70
0.15
0.24
9.04
18.33
9.25
164.75
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
1000
1.51
0.35
6.37
68.05
5.89
17.95
14.95
1.56
0.23
9.70
0.15
0.21
8.89
18.33
9.00
163.14
4.3 Recommendations regarding project continuation and modifications
In the future, some or all of the modifications listed below could be added to the project.

Alternative oxygen sensors: The end product is only compatible with one oxygen sensor. A
good enhancement would be to make it compatible with multiple different oxygen sensors.

Direct connection with dive computers: One future enhancement would be to allow the oxygen
analyzer to connect to the user's dive computer. This would allow the analyzer to program the
29
computer for the correct percentage of oxygen and eliminate another possible source of human
error.

Helium sensor: The addition of a helium sensor would allow the device to be used in the highly
technical parts of the diving community, and also for commercial operations. For very long and
deep dives, the breathing gas may be a mixture of helium, oxygen and nitrogen. The fractional
percentage of helium is just as important to know as the percentage of oxygen, and this device
would then be able to safely and accurately measure both gases.

Metric units: In the current design, the device only displayed the MOD in feet. A switch could
be added in the future to switch the analyzer to meter mode so that it can output the MOD in
meters.

Size reduction: While not overly large, the current design is still somewhat bulky. The
dimensions and weight could be reduced in the future.

Wireless connectivity: Currently, the device is directly connected to the SCUBA tank. A future
enhancement would be to design a small oxygen analyzer and wireless transmitter that would
allow that information to be sent to a base unit half the size of the current design. That would
allow the user to quickly move the sensor unit without risking harm to the base unit.
4.4 Lessons learned
This section describes the lessons the team learned over the duration of the project.
4.4.1 What went well
This section details what went well during the development of the end-product.

The team worked extremely well together and had a common goal in mind. Each person bought
their unique skills to the project, all of which complemented everyone else’s abilities. The team
was also very good about consistently meeting and staying on task.

The SSOL lab was great asset for the project. This lab provided an excellent environment to
work on the project from start to finish. It contained all of the hardware modification tools, such
as the drill press, the wire brush polisher, and the soldering irons, and it also contained the
development board used to program the microcontroller. Finally, some of the components used
in the device were taken from the SSOL lab, such as wires and the microcontroller header.

The project advisor, Dan Stieler, was extremely helpful in providing insight into problems that
occurred intermittently. Dan also provided the equipment needed for testing at the
Microelectronics Research Center. It was clear that Dan was benevolent and sincerely wanted to
see the project completed successfully.
4.4.2 What did not go well
This section details what did not go well during the development of the end-product.

The schedule that was originally created for the project was not followed very closely. The
majority of the device’s production occurred during the second semester of the project, while the
first semester was spent on design and the acquisition of parts. While the project was still
30
completed, there could have been a problem that delayed the project to the point of incompletion.
The team should have started building the product sooner with that notion in mind.

The difficulty that was encountered during the development of the device was that many of the
components were difficult to find information about. Furthermore, it was difficult to find anyone
who had experience with microcontrollers that could help to when it was not operating properly.
It usually took several hours of reading documentation and trying different things to eradicate a
bug in microcontroller code. Also, two microcontrollers were destroyed during the development
process.

There were numerous problems involved in getting the LCD screen to display what it should.
Until very late in the project, the LCD screen would intermittently output junk characters,
making it very hard to figure out what was wrong with the setup. This was frustrating because it
raised doubts about whether some of the team’s components were working as they were
supposed to.
4.4.3 What technical knowledge was gained
Several technical skills had to be learned to complete this project and were refined through the process
of the development of the project. The microcontroller used basic C syntax, but had a specific learning
curve to understand how to use the ADC, the internal clock, and the serial pins. The operation of ADC
was something that all members of the team became familiar with. Also, the use of application specific
chips like voltage regulators, detectors, and instrumentation amps was new to some of the team
members, making them useful to learn from.
4.4.4 What non-technical knowledge was gained
Aside from gaining better teamwork and time management skills, the team learned and refined a few
non-technical skills. For example, one important skill that every team member refined was the ability to
identify, research, and find appropriate solutions to problems as they arose. Another skill that the team
learned was how to identify and set realistic goals and how to place limitations on the design so that the
project could get finished on time. This skill of setting goals, meeting them, and presenting the results is
important in all projects, and it was definitely improved in all of the team members as a result of
working on this project.
4.4.5 What would you do differently if you had project to do over again
The main change that the team would make if given the chance to do the project again would be to
spend more time on the project during the first semester. This could be accomplished by creating a
design earlier, and then purchasing parts immediately. Spending more time implementing the design in
the first semester would have allowed the team more time for testing and refining the design in the
second semester.
4.5 Risk and risk management
This section describes the risks and the risk management that the team encountered and dealt with for
the duration of the project.
4.5.1 Anticipated potential risks and planned management
Below is a list of anticipated potential risks:
31

Loss of a teammate: To deal with the loss of a teammate, the team chose to set goals that would
still be possible for three people to manage. While the current workload is sufficient for four
people, three could still have managed the project.

Difficulty obtaining parts: In the event that obtaining parts became difficult, a combination of
finding part alternatives and/or delaying a portion of the development would be required. A
delay in one aspect of the development would be substituted for increased development on
another aspect of the project until the part in question could be obtained.

Lack of time: Since the project was under the constraints of a deadline, the team scheduled
intermediate deadlines to help ensure that the project was on track. The team also agreed to be
assertive on responding to problems and to work on weekends.

Over budget: Given the high cost of the oxygen sensor, there was a concern that the device
could go over the team’s budget of $150. Should this happen, the team would have no choice but
to fund the remainder of the project themselves.

Unfamiliarity with parts: Several parts of the design called for the use of devices that none of
the team members had used prior to the project. Learning how to use these devices given only a
datasheet was expected to be difficult, so should the team get stuck on something, the team
agreed to seek help from the team’s client, the team’s advisor, or any other expert that could
help. If none of those outlets worked, company support lines and online forums were always a
backup option.
4.5.2 Anticipated risks encountered and success in management
Below is a list of anticipated risks that were encountered:

Difficulty obtaining parts: Problems did occur during the acquisition of two parts. The oxygen
sensor that was originally planned for purchase became unavailable upon request. The required
several design modifications to accommodate an alternative sensor. Also, obtaining the restrictor
plate was difficult. The company supplying the plate was extremely slow in shipping their part.
To work around this problem, in the absence of the plate, careful manual flow regulation was
performed on the tanks for testing purposes.

Unfamiliarity with parts: The microcontroller used C as its primary programming language,
but understanding how to use the features of the microcontroller proved to be quite hard. A few
of the microcontroller difficulties encountered were figuring out how to utilize the internal clock,
implement the ADC, and send data to the display. In order to manage these problems, a book
was purchased that focused on how the microcontroller’s. Another serious issue with the
microcontroller was that sometimes problems occurred with the operation of the microcontroller
when it was off the development board that didn’t occur when it was on the development board.
In these cases, research was done to figure out the underlying cause of the problems that were
occurring. Eventually, all the problems were identified and solved. Also, parts such as the
voltage regulator, detector, and instrumentation amplifier required reading the documentation on
the parts so that their operation could be fully understood.

Lack of time: The amount of time that was provided for the project became a serious concern
near the beginning of the second semester. To address this problem, the team agreed to meet for
32
around 5 hours every Saturday in the SSOL lab to work towards completing the project. This
agreement was the main reason that the project was completed on time.

Over Budget: The components used to make and test the device went over budget by about $20,
and a few other items that weren’t used to build the device (such as the programming book) were
also purchased. These costs were not great enough to prohibit the team from paying for the
additional costs themselves, so the team funded all costs that went over $150 themselves.
4.5.3 Unanticipated risks encountered, attempts to manage, and success
Below is a list of unanticipated risks that were encountered:

Part failure: Accidentally destroying a part due to misuse is, at times, and avoidable
consequence of development. One part that was damaged was the on/off switch’s LED, which
burned out from excess current. The burned out LED did not affect the operation of the switch
itself, so the switch was still used. Two separate microcontrollers were destroyed. One was
ruined after improper wiring on a prototyping board, and another was ruined when pulling it
from a socket. Fortunately the team was provided with nine microcontrollers free of charge that
served as excellent replacements. Purchasing and requesting excess parts made these problems
insignificant in the overall scheme of the project.

Incorrect part order: When purchasing parts at the beginning of a project, it was sometimes
difficult to foresee problems with a specific part chosen for an application. As a result, the team
ordered some parts that didn’t work out. These parts included the first microcontroller
(PIC18F492) and the 10k Ohm potentiometer. The problem with the potentiometer was that it
was a one turn potentiometer. This made it very difficult to calibrate the device because a minor
touch to the potentiometer made a large difference in the calibrated value. To overcome this
problem, a 10 turn potentiometer was purchased to make the calibration mechanism less
sensitive.
4.5.4 Resultant changes in risk management made because of encountered unanticipated
risks
As electrical components were damaged and destroyed, the team was more careful when hooking up
power supplies to the various components. Also, the team became more aware of how fragile the
electrical components were and treated them with more respect. As for the incorrect part order issue,
there was really nothing that the team could have done differently, so no risk management adjustments
were made with regards to part ordering.
4.6 Project Team Information
This section includes the project team, client, and faculty advisor contact information.
4.6.1 Client Information
Dan Stieler - ISU graduate student and avid diver
Phone: 515-451-1518
Email: dstieler@iastate.edu
Address: 4815 Hutchison #17 Ames, IA 50014
4.6.2 Faculty Advisor Information
Dr. Gary Tuttle - Professor in Electrical Engineering at Iowa State University
33
Phone: 515-294-1814
Email: gtuttle@iastate.edu
Address: 247 ASC I Ames, IA 50011-3025
4.6.3 Team Members’ Information
Michael Beckman - Team Leader
Major: Electrical Engineering
Phone: 515-710-4792
Email: beckmanm@iastate.edu
Address: 225 N Hyland Apt. #20 Ames, IA 50014
Adam Petty - Communications Coordinator
Major: Electrical Engineering
Phone: 515-351-9860
Email: apetty@iastate.edu
Address: 225 N Hyland Apt #20 Ames, IA 50014
Rory Lonergan
Major: Electrical Engineering
Phone: 515-231-5391
Email: wowy@iastate.edu
Address: 217 Welch Ave, Apt. #411 Ames, IA 50014
Jeffrey Schmidt
Major: Computer Engineering
Phone: 515-232-2940
Email: jeffreys@iastate.edu
Address: 1108 S 4th St. - Apt. #10 Ames, IA 50010
4.7 Closing Summary
This project exists primarily to make life easier and safer for SCUBA divers. This noble goal was
motivation for the team to successfully complete this project. The team is confident that the final
prototype is a successful realization of the project that was originally assigned. The flow of design
through several steps of design simulation, prototyping, and testing allowed the project design to be both
manageable and logical, and as such, allowed the delegation of work to be done in a manner that
allowed all the team members to feel challenged, but not alone in their efforts. The team is very pleased
with the outcome of this project and hopes that the client is satisfied with it as well.
4.8 References






http://seniord.ece.iastate.edu
http://www.sparkfun.com
http://www.microchip.com
http://www.OxyCheq.com
http://en.wikipedia.org/wiki/Electro-galvanic_fuel_cell
Basic Diving Physics and Applications by Bruce Wienke
34
4.9 Appendices
This section contains all the appendices for the project. This includes datasheets, technical
specifications, and large designs.
4.9.1 Appendix A – Microcontroller block diagram
4.9.2 Appendix B – Oxygen sensor specifications
35
36
4.9.3 Appendix C – Serial enabled LCD backpack schematic
37
4.9.4 Appendix D – Testing document
38