Validation of Dive Computers

Dive computers have evolved rapidly since the first modern, diver-carried electronic dive computer (ORCA Industries’ EDGE) became commercially available in 1983. The emergence of dive computers prompted questions about their safety, evaluation procedures and guidelines for use. Because little data existed on repetitive diving, there were concerns about computers’ ability to manage multiple deep dives.

Today, dive computers’ ability to monitor decompression status and ascent rate in real time is well established. And computers allow increased flexibility: They permit dives of unlimited complexity while providing guidelines for limiting decompression stress. Because of this improved flexibility, dive-computer guidance is generally expected to present a greater risk of decompression sickness (DCS) than the use of a dive table based on the same decompression algorithm.

The computer’s calculations use the actual depth of the dive rather than being rounded to the next deeper depth, and repetitive dives are based on the entirety of the underlying decompression model (i.e., all tissue compartments are considered). Most dive tables use only one of the decompression model’s tissue compartments to calculate repetitive dive allowances, which adds a margin of safety. With dive computers, there is also the potential for electrical or mechanical failure and user error. However, based on reviews of the available databases of dive injuries, dive computers appear to have acceptable safety records regardless of the algorithm they use.


Dive-computer validation consists of several steps, which include: 1) verification of a clear and unambiguous information interface, consideration of ergonomics and rigorous leak testing; 2) a procedure for testing the decompression model and algorithms (as in decompression-table testing); 3) confirmation of the computer’s function in simulations; and 4) field testing.

The testing of dive computers using human subjects has been very limited; that means most of the support for computers’ use has resulted from their operational success. But operational safety does not translate to decompression-algorithm safety since most real-world dives do not push the algorithms to their limits. The simplest way to understand the operational benefits a particular dive computer truly offers is to simulate dives using the computer’s software and then analyze the generated profiles using validated dive tables. If the results are very similar, the risk of DCS should be roughly equivalent.

There is a lack of information on how different models compute decompression, and this is sometimes perceived as a lack of verifiable safety. The problem is an absence of standards specific to dive computers that allow assessment of their functional safety. Applied to a dive computer as a safety-critical system, such standards would mean the device performs according to requirements and that in case of failure, no harm would occur. There is a need for a consolidated dive-computer safety standard that uses the essential safety and health requirements of CE Marking Directives (a set of widely accepted European product conformity standards).

Applicability of Dive Computer Algorithms

Dive-computer models employ more conservative versions of dive tables; they achieve this primarily by reducing the tolerated levels of supersaturation. While it’s obvious that using a decompression model outside of its validated range carries risk, even using one within its validated range does not guarantee safety. A multilevel dive computed as an extension of the multicompartment theory (which was validated using square dives) cannot be assumed to follow the same rules.

Digital facing of a dive computer
Clarity of information and comfort are important aspects of dive-computer validation.

There is little agreement among various computers with regard to repetitive dives with short surface intervals (one hour or less). While a relatively standard Haldanean implementation is at the core of most dive computers, different mathematical manipulations are employed to account for residual nitrogen. This indicates that the true impact of residual nitrogen is not fully understood.

To manage the risk of DCS, dives are conducted according to decompression schedules that have parameters that account for depth, time and breathing gas. These schedules are derived from algorithms that aim to limit bubble formation by slowing decompression, typically by interrupting ascent with decompression stops to allow time for washout of inert gas from tissues. Many decompression models use DCS as a measurable endpoint, but it’s not generally practical to commit time and money to the large number of dives necessary for this type of validation, nor is it particularly ethical to provoke DCS.

Venous gas emboli (VGE) nearly always accompany DCS, although their presence does not have a direct relationship with clinical symptoms. However, VGE are an accepted indicator of the level of decompression stress that a diver has been subjected to and can thus be used as a tool to help in the validation process.


Twenty-nine years of operational experience with dive computers has demonstrated that their advantages over tables outweigh their disadvantages. The primary issue with computers remains their mechanism of accounting for repetitive dives. The significant variability among dive computers means selection criteria should be established to meet the specific needs of particular dive communities. An important element of this approach is the creation of a community-specific universe of “safe” dive profiles for which the computer is effective. This can be accomplished through the use of a dive-computer monitoring program. Traditionally, the limits of decompression models were established using trials with human subjects, but this is not likely to occur in dive-computer validation because of the time and expense involved as well as the infinite combination of dive computers and settings.

At present, DCS is the measurable negative outcome. There is a need to specify an acceptable level of DCS risk and a method for measuring that risk. A defined window of applicability for each computer is also needed. A dive computer should have the support of a dive planner, and the computer’s functionality and safety must be verified and documented. To understand “what’s in the box,” documentation of designers’ logic and equations is needed.

There is no evidence that multilevel dives with dive computers are more risky than square dives when they follow the same algorithm. The risk of DCS in no-decompression recreational and scientific diving is no greater now than when tables were prevalent. This is largely because dive computers are not pushed to the limits of their decompression models or algorithms.

Dive-computer validation should include specification of training standards for divers who use the computer, thorough assessment to ensure the computer meets all requirements for validation and monitoring of the computer’s operational performance.

© Alert Diver — Q1 Winter 2013