Computer vs Algorithm

Please register or login

Welcome to ScubaBoard, the world's largest scuba diving community. Registration is not required to read the forums, but we encourage you to join. Joining has its benefits and enables you to participate in the discussions.

Benefits of registering include

  • Ability to post and comment on topics and discussions.
  • A Free photo gallery to share your dive photos with the world.
  • You can make this box go away

Joining is quick and easy. Log in or Register now!

John,

I went to your site as I had never heard of your computer before. Very interesting.

My question is what makes your algorithms better?

Also I am curious about your sample population for the research behind your algorithms. Was it predominantly Navy SEALS, extremely physically fit divers performing strenuous activities? How does this relate to your typical non-commercial civilian diver?

Not bashing just curious... :)

The Thalmann algorithm is well documented and has been researched. IIRC rates of DCS when left to float the dive time were very low but at the cost of a lot of decompression time. I know Dr. Doolette did some work on it in the mid 2000's and from the one report I can remember reading the conclusions were that given sufficiently severe dives the DCS risk became, in the words of the research team, "unacceptable". If I remember correctly it was even higher than BVM(3) which was the model used for the more recent study done by NEDU on deep stops. For technical diving that's a red-flag to me.

The other algorithm Cochran uses is unknown to me but in the article I posted it would appear -- if you squint and read between the lines -- that it is a bubble wrapped Bulhmann, perhaps similar in design to what Suunto implemented. As far as I know Cochran don't communicate the details of their algorithm, so as a matter of principle as a technical diver, I would personally avoid it for the same reason I would avoid Suunto, Mares and others. I'm sure John is MUCH better informed about this than I am so I will defer to his expertise when he responds.

Let me be perfectly clear about what I said above. I am NOT saying that the Cochran algorithm is unsafe nor am I passing judgment on its suitability for the purpose with the level of information I have. I simply don't have enough information to draw that conclusion. I am, however, personally uncomfortable using any computer for technical diving when I'm not absolutely sure how it's working. YYMV

R..
 
I bought my first computer (Suunto Gekko) based on my perception of price/features. I bought my second computer (Suunto Cobra 2) based on features (hose AI and USB computer interface) and algorithm to match my first computer. I bought my third dive computer (Shearwater Perdix) based on algorithm [having learned enough to want Buhlmann with GF over SuuntoRGBM], User Interface, reputation.
 
I bought my first computer (Suunto Gekko) based on my perception of price/features. I bought my second computer (Suunto Cobra 2) based on features (hose AI and USB computer interface) and algorithm to match my first computer. I bought my third dive computer (Shearwater Perdix) based on algorithm [having learned enough to want Buhlmann with GF over SuuntoRGBM], User Interface, reputation.
I did pretty much the same thing...

Mine were:
1st DC an Aeris Epic - was a small watch style and AI (which the salesman said would be great for me just going into OW)

2nd DC an Atomic Cobalt - I hated the Aeris Epic, much to complicated to operate (179 pg manual in small print) where the Cobalt was so easy. My other half now uses it.

3rd DC a Shearwater Petrel - Once I started down the Tec Road this was the DC of choice based on ease of operations and algorithm.

4th DC a Shearwater Perdix - Just because :)
 
John,

I went to your site as I had never heard of your computer before. Very interesting.

My question is what makes your algorithms better?

Also I am curious about your sample population for the research behind your algorithms. Was it predominantly Navy SEALS, extremely physically fit divers performing strenuous activities? How does this relate to your typical non-commercial civilian diver?

Not bashing just curious... :)
Hello Michael,
Either myself or Jeff Loudan (Software Engineer at CCI) will answer your questions on Monday 04/09. I'm currently on holiday with my family in Madrid, España.
Again have a great weekend
Safe Diving
John
 
Hello Michael,
Either myself or Jeff Loudan (Software Engineer at CCI) will answer your questions on Monday 04/09. I'm currently on holiday with my family in Madrid, España.
Again have a great weekend
Safe Diving
John
No worries John...Happy Holidays. :)
 
Grasping the basics- dive computers PART 1
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.

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.

completed article here
 
Last edited:
PART 2
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 PART 3
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).
 
https://www.shearwater.com/products/perdix-ai/

Back
Top Bottom