Grasping the basics- dive computers

What is underneath?

Schematics of a Dive Computer

Sensors/Clock → Storage Unit ↔ [Control Unit / Arithmetic and Logical Unit]CPU → Output [Display]

A dive computer is a device that operated upon collected data, it is an electronic board which does arithmetic and logical operations accordingly with the programmed decompression algorithm and provides with the actual (real time) ascent profile information.

This device supposed to guide the diver from depth back to the surface with some degree of confidence that the user will get out of the water without symptoms of DCS and if they are present, should be easily managed.1

The computer contains sensors that reads depth/altitude (barometric pressure), temperature and a clock. With the collected data performs real time-depth calculations base on the programmed algorithm, stored detailed dive statistics and profiles.

Some computers include a  high pressure transducer assembly that records and track gas supply and it is able to predict the remmaning dive time in conjunction with the “No Decompression Limits (NDL/ NoD/ NDC).  Also this computers takes biological data (i.e., breathing frequency, breathing volume and heart rate) to show the level of exertion of the diver which is used as parameters in the calculations of the ascent profile.

Remember that algorithm used by the computer is a model predictor 

The computer interface is how the diver introduce data and reads the display. This feature represent how the user engaged with the computer itself.

Aslo it is important that the computer can be interface with a PC2  for dive planning function, print backups tables, review past profiles,  and make parametric computer cloning.

List of regular futures and displays

  • Easy-to-read display (sometimes in color) that provides the following information:
  • No stop limits,
  • Depth,
  • Time,
  • No stop time remaining,
  • Ascent rate,
  • Decompression status,
  • Previous dive information/ Log Book,
  • Low battery warning,
  • EAN, HELIOX, TRIMIX compatible,
  • Automatic adjustment for altitude diving,
  • Replaceable or rechargeable batteries,
  • CCR (Closed-Circuit Rebreather) mode,
  • Interface with your laptop/regular computer so you can download your dive data,
  • Electronic compass,
  • built-in thermometer.

The Major benefits of  a dive computer is the flexibility that allows the diver to do multilevel profiles without the limitations of the maximum depth for the entire time as it is prescribe by the tables. Most tables use only one compartment to calculate repetitive dive allowances; dive computers have accurate depth reading (± 0.5 msw) and provide the diver with information continuously through the dive.

Within the scope of a multilevel recreational profile within the Haldane’s model, the 5 min. compartment control the bottom time at for example 30 meters maximum depth profile; when you ascend above 20 meters, this compartment no longer restrict the NoD since it can no longer reach the allowed loading limit. Other lower compartments control each depth as you ascend and because these slower compartments haven’t reached their loading limits, additional dive time is permitted without enter decompression status.

How do I choose?

There’s still some discussion about the validation procedure of a dive computer, up until now no other computer has been validated except for Cochran Dive Computer, which is what the NAVY use. Outside the military environment, the EMC-20H has been used and evaluated by Hamilton on the Archeological research of the Monitor, which also was used to elaborated and validated his DCAP program, especially for mixes like TMX 18/50.

Remember that we are talking about computers validation and not algorithm’s validations, both concepts are different and not related to each other.

For example, Dive Freedom computer use a well know validated algorithm!

Regarding the validation, Dr. Doolette defined it as a process that measures whether your product meets its “requirements”, and “verification” evaluates whether it works or functions. In other words, Validation confirms that a decompression algorithm performs to the level you
want in terms of risk. Verification determines that the dive computer does the proper calculations to perform that validated algorithm.
Another concept to have in consideration is the function of the computer, Dr. Hamilton recommended in its own word “never use the word ‘safe’ in relation to decompression, it just does not apply and is misunderstood by people. Use ‘acceptable risk’, which gives a different perspective although it really is the same thing.“

Although considered that the primary function of the computer is to get the diver to the surface without any residual or long-term effects of DCS.

One more point before you read the next section of this lesson is what Dr. W. Gerth alleged about the process of acceptable risks on decompression models: “In the U.S. Navy in the ‘noise’ of our risk of DCS estimates we include factors such as what the diver ate for breakfast, body temperature, etc. Then we assert that the model that we use prescribes schedules that are within an acceptable risk of DCS and we say that anybody can dive that profile – that will be your mean risk of DCS with such and such an error. We are not going to live long enough to get enough data to parameterize a model to incorporate all of the different factors that have been posited as controlling DCS risk.”

So before you choose a computer, you should ask yourself:

1-With which decompression model am I comfortable accepting the risks of DCS and,

2-With which computer works as it was intended for or function as it was designed for.

In the next section (title) you will read about the procedure took by the NAVY on validating and verifying their dive computer (NAVY), having a glimpse on it will give you an understanding on the effort implied on developing such endeavor. This is the main reason why commercially over the counter dive computer doesn’t publish their algorithm implementation nor validation or verification of their computers. Just change the circuit model board of a dive computer will require a new verification. I invited you to read along to understand such complexity.

Conclusion

One interesting conclusion on the workshop were made by S. Lesley Blogg from SLB Consulting and Andreas Møllerløkken the Norwegian University of Science and Technology, in which they described the need of test each computer separately in relation on how many bubbles can be detected using VGE measurements. Such method could easily be employ without taking to much effort in man-power (man-tested) nor money investment.

Once the target population has identified their need for a dive computer, then ideally their most commonly used dive profiles could be used to test different models against one another to find the optimal DC for the populations’ use. It is necessary to test individual DC models, because each is driven by a specific, but usually unidentifiable, algorithm. Although this might not be ideal, it is a cost-effective approach and with objective endpoints, an eminently testable approach to take. This method obviously could not be employed if using DCS as an endpoint. Using VGE measurement, the algorithms in each DC for each specific profile can be rated for decompression stress, then paired comparisons can be made and the optimal DC (producing the lowest amount of VGE across the test population over selected profiles)
chosen for use in that specific population.

U.S Navy Dive Computer Validation (NDC)

David J. Doolette
Keith A. Gault
Wayne A. Gerth
F. Greg Murphy
U.S. Navy Experimental Diving Unit
321 Bullfinch Road
Panama City, FLORIDA 32407-7015 U.S.A

The U.S. Navy Dive Computer (NDC) is a typical diver-carried dive computer
that uses a simple decompression algorithm to provide decompression
schedules updated in real time. However, unlike many dive computers, the
NDC is based on a well-documented decompression algorithm that is the
result of extensive manned test-diving and for which the risk of decompression
sickness is well defined. Since this Thalmann Algorithm is itself validated,
validation of the NDC involved the relatively simple task of verifying a faithful
implementation of the Thalmann Algorithm. The U.S. Navy experience in dive
computer validation provides a useful framework for validating a commercial
off-the-shelf dive computer, but challenges exist for dive computers that do not
implement a well-documented decompression algorithm.

INTRODUCTION

Breathing a gas mixture at elevated ambient pressure (pamb), such as during underwater
compressed gas diving, results in tissue uptake of dissolved respired gases. During ascent (or
“decompression”) to sea level, pamb may decrease to a level less than the sum of the partial
pressures of all gases dissolved in tissue, and in this state of gas supersaturation, bubbles can
form and potentially cause decompression sickness (DCS). To manage the risk of DCS, dives
are conducted according to depth/time/breathing gas decompression schedules derived with
decompression algorithms that implicitly or explicitly limit bubble formation by slowing
decompression, typically by interrupting ascent with “decompression stops” to allow time for
tissue inert gas washout.

Although decompression without tissue gas supersaturation and, therefore, without bubble
formation or risk of DCS is possible, such decompression strategies yield schedules that are
impractically long. Instead, practical decompression algorithms balance the probability of
DCS (PDCS) against the costs of time spent decompressing. Modern, diver-carried dive
computers sample pamb at frequent intervals and use this as input to simple decompression
algorithms that provide decompression schedules updated in real time.

The principal requirement for a dive computer is that dives following its decompression guidance will have a target (typically low) incidence of DCS. A corollary to this requirement for dive computers used in occupational (military or commercial) diving – the focus of this workshop – is that the decompressions are efficient, because time spent decompressing is unproductive (costs money) and prolongs exposure to a hostile environment. Requirements will be specific to some range of diving practices and to particular populations of divers because no decompression algorithm is suitable for all types of diving and different diving communities have different risk tolerances. Validation of a system such as a dive computer is simply a demonstration that it matches its requirements. Validation of a dive computer entails measurement of the incidence of DCS, or estimation of PDCS by some other method, associated with its decompression guidance.

Validation could be accomplished by subjecting a dive computer to many different depth/time dive profiles and evaluating the PDCS of resulting decompression guidance. Such validation could be done without knowledge of the underlying decompression algorithm.

Alternatively, the decompression algorithm can be validated separately from the dive
computer, by measuring PDCS associated with another implementation of the algorithm. The
latter would then be the “gold standard” implementation. In this case, validation of the dive
computer would follow from verification that it is a faithful implementation of the decompression algorithm by comparison of the dive computer behavior to the gold standard implementation. In this approach, understanding of the decompression algorithm can guide the validation process. It is this latter approach that is used by the U.S. Navy.

U.S. NAVY DIVE COMPUTER (NDC)

U.S. Navy Dive Computers (NDCs) are built by Cochran Undersea Technologies (Richardson, TX) but implement the Thalmann Algorithm, a decompression algorithmdeveloped at the U.S. Navy Experimental Diving Unit (NEDU). There are now several configurations of the NDC tailored to the requirements of different diving communities within the U.S. Navy and different diving operations breathing open-circuit air or constant pO2 from the MK 16 MOD 0 or MK 16 MOD 1 closed-circuit, mixed gas underwater breathing apparatus (UBA). In support of different combinations of these UBAs, the various configurations of the NDC for air and N2-O diving calculate decompression assuming inspired inert gas partial pressures associated with constant FO= 0.21, constant pO2= 0.7 atm, and constant pO2= 1.25 atm, and make depth-dependent changes between these modes.

VALIDATION OF THE NDC

1. Development and Validation of the VVal-18 Thalmann Algorithm
The Thalmann Algorithm is a neo-Haldanean decompression algorithm similar to those implemente in many dive computers. Inert gas uptake and washout is modeled for a set of parallel tissu compartments and decompression stops are required to keep the partial pressure of a single inert ga (pi) in k modeled tissue compartments less than or equal to a depth-dependent maximum permissible value, pi,k≤ Mk= akD+ M0k., where D is pamb at each decompression stop expressed in depth of water, M and M0 are the maximum permissible tissue pressures (M-values) at D and at the surface, respectively, and a and M0 are determined experimentally.

The Thalmann Algorithm differs from earlier such algorithms in several ways. The principal difference is that compartmental inert gas washout can switch from the normal exponential approach to arterial inert gas partial pressure to a much slower linear approach when a compartment is gas supersaturated (Exponential Linear or EL kinetics). This linear rather than exponential gas washout gives appropriately lengthened decompression times, particularly for repetitive dives, without negatively impacting no-stop limits.

Another novelty is that the Thalmann Algorithm was developed specifically with a view to implementation in a dive computer, and was originally called the EL-RTA (real-time algorithm). The EL-RTA running on a minicomputer was used to control most man-dives conducted during the development and testing of the algorithm. The version used to calculate decompression tables, (originally the EL-DCM) calculates gas uptake and washout for finite ascent and descent rates, and therefore printed tables exactly match the EL-RTA if the same travel rates are used. Thalmann published the FORTRAN source code of the original EL-DCM (Thalmann, 1983; 1985), and this original code has been further developed at NEDU to support other diving applications. The structure of this enhanced version of the FORTRAN EL-DCM, renamed the Thalmann Algorithm Decompression Table Generation Software, is documented in detail (Gerth, 2010). This implementation was used to calculate the air and MK 16 decompression tables in the U.S. Navy Diving Manual, Revision 6 (Naval Sea Systems Command, 2008a). A Visual Basic implementation of the Thalmann Algorithm developed at NEDU and called the Navy Dive Planner is also documented in detail (Gerth et al., 2011). Users interact with Navy Dive Planner via a graphical user interface to plan dives or to follow dives in real-time and it is intended primarily as a tool for planning multilevel dives that will be conducted using a NDC. Decompression prescriptions generated by the Navy Dive Planner match those of the table generation software (Gerth et al., 2011).

The Thalmann Algorithm is initialized with a parameter set that includes a table of M-values and different parameter sets exist for different applications. The NDCs for air and N2-O2 diving use a parameter set called VVal-18, which is the same parameter set used to calculate the constant 0.7 atm pO2-in-nitrogen (MK 16 MOD 0; Thalmann, 1984) decompression tables and MK 16 MOD 1 N2-O2 decompression tables in the U.S. Navy Diving Manual (Johnson et al., 2000). The Air Decompression Tables in the U.S. Navy Diving Manual, Revision 6 (Naval Sea Systems Command, 2008a) are calculated using a modified parameter set proposed by Flynn and designated VVal-18M which results in shorter air decompression times than VVal-18 (Gerth and Doolette, 2007; 2009). The development and testing that lead to the VVal-18 parameter set was simultaneous with development of the Thalmann Algorithm, and was initially in support of constant 0.7 atm pO2-in-nitrogen diving with the MK 15 and MK 16 UBAs. This initial development included 1505 air and constant 0.7 atm pO2-in-nitrogen man-dives (84 cases of DCS) with the algorithm and parameters beingadjusted in response to schedules with high incidences of DCS (Thalmann et al., 1980; Thalmann 1984; 1986). In a recent test of VVal-18 Thalmann Algorithm air decompression,  192 dives to 170 feet sea water (fsw) for 30 minutes bottom time resulted in only three casesof DCS (Doolette et al., 2011). The MK 16 MOD 1 N2-O2 VVal-18 Thalmann Algorithm decompression tables were validated with 515 man dives that resulted in seven cases of DCS (Johnson et al., 2000; Southerland, 1998). All these man dives were conducted in the wet pot of the Ocean Simulation Facility at NEDU under conditions relevant to occupational divers: divers worked on the bottom and were at rest and cold during decompression – conditions shown to increase the risk of DCS (Van der Aue et al., 1945; Gerth et al., 2007). There has not been extensive manned-testing of air decompression tables calculated using the VVal-18M parameterization of the Thalmann Algorithm, but the PDCS of the each schedule in both VVal-18 and VVal-18M air decompression tables have been estimated using NMRI98 (Parker et al., 1998) and BVM(3) (Gerth and Vann, 1997) probabilistic decompression models (Gerth and Doolette, 2007; 2009).

2. Verification of the NDC and configuration control

As outlined in the preceding paragraphs, the VVal-18 Thalmann Algorithm was already validated with manned diving trials under operationally relevant conditions that demonstrated acceptable PDCS. Testing of the NDC was therefore simply to verify that it was a faithful implementation of the Thalmann Algorithm. This could be done by functional testing of NDCs comparing their behavior to “gold standard” decompression schedules and these gold standards exist in two forms. The gold standard printed VVal-18 Thalmann Algorithm decompression tables are the constant 0.7 atm pO2-in-nitrogen (MK 16 MOD 0) (Thalmann, 1984) decompression tables and MK 16 Mod 1 N2-O2 decompression tables (Johnson et al.,2000) that have appeared in several revisions of the U.S. Navy Diving Manual. The gold standard software implementations are the Thalmann Algorithm Decompression Table Generation Software and the Navy Dive Planner. The latter software package is designed specifically to complement the NDCs and is convenient for generating multilevel dives and decompression schedules of any complexity against which to test the NDC. A sample of 10 to 30 of each configuration of the NDC has been functionally tested by exposing them to simulated dive profiles in a small, flooded test chamber and comparing NDC prescription to gold standard Navy Dive Planner decompression schedules (Southerland, 2000; Gault and Southerland, 2005; Gault, 2006; Southerland et al., 2010). Schedules differ by no more than can be accounted for by the specified pressure sensor tolerance (maximum ±2 fsw (0.61 msw) deviation at maximum operating depth). This type of functional testing is called “black box” testing because the tester has no access to internal data structures and computer code to guide testing. The agreement between the Cochran Undersea Technologies and the U.S. Navy does not extend to sharing such proprietary
information. The outcome of dive computer testing only remains valid while the system remains unchanged and by agreement with the manufacturer, no hardware or software changes are made to any configuration of the NDC after it has passed validation testing at
NEDU. Every NDC unit undergoes a simple functional test of pressure sensor accuracy at purchase and subsequently every 18 months.

Outline of validation of the U.S. Navy Dive Computer

Development, validation, and documentation of the Navy VVal-18 Thalmann Algorithm was a large effort. Consequently, verification of the NDC implementation of the algorithm can be a substantially smaller effort.

The principal requirement of the NDC is implementation of the U.S. Navy-approved VVal18 Thalmann Algorithm. The U.S. Navy maintains gold standard software implementations of the Thalmann Algorithm. VVal-18 Thalmann Algorithm decompression schedules produced by these gold standard implementations have acceptable PDCS as demonstrated in
manned dive trials and estimation of PDCS using probabilistic models. The NDCs are
validated by faithful replication of gold standard decompression schedules when exposed to simulated dives.3

What are the difference between Thalmann and Bühlmann?

Regarding the Cochran VVal-18 computer, one of the things that distinguishes the Thalmann algorithm from the Bühlmann algorithm is that it does not assume that the gas uptake kinetics are the same as the gas elimination kinetics; it is called the EL algorithm. You uptake a gas exponentially and if you are offgasing, you have a sufficient supersaturation that triggers a so-called linear offgasing. You turn from exponential to linear rates and wash out slower.

Does it really matter which computer I use?

Well, yes and no. It’s a matter of preference. There is no right or wrong decompression schedule. What is important is the implementation of the model, the model fundamental in relation of the profile calculations. Because it is possible to fit the wrong model fundamental to a set of data and, so produce the wrong dive schedule , as C. Gutvik describe on the workshop1.

Take a look inside a simulated Cochran Computer dive using Analyst in a technical-recreational dive

 


1 Dive Computer Validation Procedures workshop, R.W. Bill Hamilton. Hamilton Research Ltd.

2 Today’s PC means personal computer which included mobile phones, tablets, laptops, etc.

3 Read the full report in our online repository

Questions