Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Dive computer
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Safety and reliability == The ease of use of dive computers can allow divers to perform complex dives with little planning. Divers may rely on the computer instead of dive planning and monitoring. Dive computers are intended to reduce risk of decompression sickness, and allow easier monitoring of the dive profile. Where present, breathing gas integration allows easier monitoring of remaining gas supply, and warnings can alert the diver to some high risk situations, but the diver remains responsible for planning and safe execution of the dive plan. The computer cannot guarantee safety, and only monitors a fraction of the situation. The diver must remain aware of the rest by personal observation and attention to the ongoing situation. A dive computer can also fail during a dive, due to malfunction or misuse.<ref name="DANSA" /> === Failure modes and probability of failure === It is possible for a dive computer to malfunction during a dive. Manufacturers are not obliged to publish reliability statistics, and generally only include a warning in the user manual that they are used at the diver's own risk. Reliability has markedly improved over time, particularly for the hardware.<ref name="Seveke" /> ==== Hardware failures ==== Mechanical and electrical failures: * Leaks allowing ingress of water to the electronic components, may be caused by: ** Cracked faceplate, which is more likely with hard, scratch-resistant glass and sapphire used on watch format units. They are strong, but brittle, and can shatter under impact with a sufficiently hard point contact. ** Seal failures can occur at joints, probably most often at the battery closure, as it is usually the most often disturbed. Computers with user serviceable batteries often use a double O-ring barrel seal to provide a more reliable seal. * Button failures are one of the more frequent problems, some models are particularly susceptible. Occasionally the failure is in the form of leaks, but more often the switch fails open, which is sometimes a fatigue problem. Pressure sensitive switches with no moving parts are sometimes used to avoid this problem. * Circuitry failures, other than switch failures, often due to water or battery leaks causing internal corrosion. * Battery failure, such as running down unexpectedly, leaking, or failing to charge properly. Internal rechargeable batteries exchange a lower risk of water leaks for a higher risk of battery degradation over time. * Non-rechargeable lithium batteries can explode if incorrectly used in a dive computer with charging facilities.<ref name="Deeperblue HW" /> {{expand section|date=June 2021}} ==== Software failures and reliability issues==== There have been several instances where dive computers have been recalled due to significant safety issues in the software or factory calibration.<ref name="recall notices" /> Earlier dive computers had to have software upgrades at the factory or an approved agent. This has changed and as of 2024, it is common to be able to update firmware over the internet, via [[bluetooth]] or a similar procedure.<ref name="Perdix manual" /> A series of Uwatec Aladin Air X NitrOx dive computers made in 1995 was recalled in 2003 due to faulty software which miscalculated desaturation time, leading to at least seven cases of DCS attributed to their use.<ref name="Air X Recall" /> This is not the only recall for faulty software or calibration, Suunto D6 and D9s were recalled in 2006, Oceanic Versa Pro 2A in 2006, and Dacor Darwin computers in 2005, but no injuries were reported, and the units were recalled relatively soon after the problems were reported.<ref name="Dacor recall" /><ref name="Oceanic recall" /><ref name="Suunto recall" /> The Uwatec Aladin Air X Nitrox recall occurred during a class action suit and after several related lawsuits against the company and several alleged cover-ups, starting as early as 1996.<ref name="Etzel 2003" /><ref name="Undercurrent" /><ref name="recall" /><ref name="class action" /> The case was settled on the eve of trial.<ref name="Concannon and Charles" /> === Inherent risk === The main problem in establishing decompression algorithms for both dive computers and production of decompression tables, is that the gas absorption and release under pressure in the human body is still not completely understood. Furthermore, the risk of decompression sickness also depends on the [[physiology]], fitness, condition and health of the individual diver. The safety record of most dive computers indicates that when used according to the manufacturer's instructions, and within the recommended depth range, the risk of decompression sickness is low.<ref name="Validation workshop" /> Personal settings to adjust conservatism of the algorithm are available for most dive compters. They may be input as undisclosed personal factors, as reductions to M-values by a fixed ratio, by [[gradient factor]], or by selecting a bubble size limit in VPM and RGBM models. The personal settings for recreational computers tend to be additional to the conservatism factors programmed into the algorithm by the manufacturer. Technical diving computers tend to allow a wider range of choice at the user's discretion, and provide warnings that the diver should ensure that they understand what they are doing and the associated risk before adjusting from the moderately conservative factory settings.<ref name="Perdix manual" /><ref name="HSE Manual" /> === Human error === [[File:Confirmation message on Ratio iX3M dive computer P8220433.jpg|thumb|Confirmation message for gas change on Ratio iX3M dive computer]] Many dive computers have menus, various selectable options and various display modes, which are controlled by a small number of buttons. Control of the computer display differs between manufacturers and in some cases between models by the same manufacturer.<ref name="aaus" /><ref name="iX3M" /><ref name="Perdix manual" /> The diver may need information not displayed on the default screen during a dive, and the button sequence to access the information may not be immediately obvious. If the diver becomes familiar with the control of the computer on dives where the information is not critical before relying on it for more challenging dives there is less risk of confusion which may lead to an accident. Most dive computers are supplied with default factory settings for algorithm conservatism, and maximum oxygen partial pressure, which are acceptably safe in the opinion of the manufacturer's legal advisors. Some of these may be changed to user preferences, which will affect risk. The user manual will generally provide instructions for adjusting and resetting to factory default, with some information on how to choose appropriate user settings. Responsibility for appropriate use of user settings lies with the user who makes or authorises the settings. There is a risk of the user making inappropriate choices due to lack of understanding or input error.<ref name="iX3M" /><ref name="Perdix manual" /><ref name="aaus" /> In some cases it can be easy to select the wrong setting by accidentally double pressing the same button with cold fingers encased in thick gloves. The process of correcting the setting can be unfamiliar and take a considerably greater number of buttons pressed at a time when there are other important matters to attend to. An example of this type of error would be accidentally selecting oxygen as the breathing gas instead of a travel gas because oxygen is at the top of the gas options list. This is an error that must be corrected as soon as possible as it will set off alarms and cause unsafe decompression calculation errors.<!--This specific error is easily possible on at least one model of tech dive computer. It is a good example of what should not be possible with good interface design--> Confirmation messages during gas switches can reduce the risk of user error at the cost of an extra button press.<ref name="iX3M" /> === Management and mitigation strategies === If the diver has been monitoring decompression status and is within the no-decompression limits, a computer failure can be acceptably managed by simply surfacing at the recommended ascent rate, and if possible, doing a short safety stop near the surface. If, however the computer could fail while the diver has a decompression obligation, or cannot make a direct ascent, some form of backup is prudent. The dive computer can be considered [[safety-critical]] equipment when there is a significant decompression obligation, as failure without some form of backup system can expose the diver to a risk of severe injury or death. The diver may carry a backup dive computer. The probability of both failing at the same time is orders of magnitude lower. Use of a backup which is the same model as the primary simplifies use and reduces the probability of user error, particularly under stress, but makes the equipment [[Redundancy (engineering)|redundancy]] less [[statistically independent]]. Statistics for failure rates of dive computers do not appear to be publicly available. If diving to a well regulated [[Buddy diving|buddy system]] where both divers follow closely matched dive profiles, using the same gases, the buddy's dive computer may be sufficient backup.<ref name="aaus" /> A dive profile can be planned before the dive, and followed closely to allow reversion to the planned schedule if the computer fails. This implies the availability of a backup timer and depth gauge, or the schedule will be useless. It also requires the diver to follow the planned profile conservatively.<ref name="CMASISA TxManual 2006" /><ref name="aaus" /> Some organisations such as the [[American Academy of Underwater Sciences]] have recommended that a dive plan should be established before the dive and then followed throughout the dive unless the dive is aborted. This dive plan should be ''within the limits of the [[decompression tables]]''{{clarify|What is meant by within the limits of decompression tables? No stop limit, exceptional exposure limit, dives completely off the tables?|date=May 2013}} to increase the margin of safety, and to provide a backup decompression schedule based on the dive tables in case the computer fails underwater.<ref name=aaus/><ref name="McGough et at 1990" /><ref name="McGough et al 1990b" /> The disadvantage of this extremely conservative use of dive computers is that when used this way, the dive computer is merely used as a [[#Bottom timer|bottom timer]], and the advantages of real time computation of decompression status β the original purpose of dive computers β are sacrificed.<ref name="Validation workshop" /> This recommendation is not in the 2018 version of the ''AAUS Standards for Scientific diving: Manual''.<ref name="AAUS Standards" /> A diver wishing to further reduce the risk of decompression sickness can take additional precautionary measures, such as one or more of: * Use a dive computer with a relatively conservative decompression model. * Induce additional conservatism in the algorithm by selecting a more conservative personal setting or using a higher altitude setting than the actual dive altitude indicates.<ref name="CMASISA TxManual 2006"/> * Add additional deep safety stops during a deep dive (the efficacy of this approach has not been supported by experiment)<ref name="CMASISA TxManual 2006" /> * Make a slow ascent. This will reduce decompression stress in the earlier parts of the ascent, but will make the total time to surface longer if the decompression stress later in the ascent is not to be increased. * Add additional shallow safety stops, or stay longer at the stops than required by the computer * Have a long surface interval between dives. This will decrease risk provided the outgassing calculations of the algorithm are accurate or conservative. * If using a backup computer, run one on a low conservatism setting as an indication of fastest acceptable risk ascent for an emergency, and the other at the diver's preferred conservatism for personally acceptable risk when there is no contingency and no rush to surface. The diver can always elect to do more decompression than indicated as necessary by the computer for a lower risk of decompression sickness without incurring a penalty for later dives. Some dive computers can be set to a different gradient factor during a dive, which has the same effect if the diver can remember under stress how to make the adjustment, and some computers can be set to display the maximum tissue supersaturation value for an immediate ascent.<ref name="Perdix manual" /><ref name="Pollock 2015" /> * Continue to breathe oxygen enriched gas after surfacing, either in the water while waiting for the boat, after exiting the water, or both. === Management of violations === <!-- target for redirect [[Dive computer lockout]] --> Violations of the safety limits as indicated by the computer display may occur during a dive for various reasons, including user error and circumstances beyond the diver's control. How this is handled depends on the decompression model, how the algorithm implements the model, and how the manufacturer chooses to interpret and apply the violation criteria. Many computers go into a "lockout mode" for 24 to 48 hours if the diver violates the safety limits set by the manufacturer, to discourage continued diving after what the manufacturer deems an unsafe dive. Once in lockout mode, these computers will not function until the lockout period has ended.<ref name="Apeks" /> This is usually a reasonable response if lockout is initiated after the dive, as the algorithm will have been used out of scope and the manufacturer will reasonably prefer to avoid further responsibility for its use until tissues can be considered desaturated. When lockout happens underwater it will leave the diver without any decompression information at the time when it is most needed. For example, the Apeks Quantum will stop displaying the depth if the 100 m depth limit is exceeded, but will lock out 5 minutes after surfacing for a missed decompression stop. The Scubapro/Uwatec Galileo technical trimix computer will switch to gauge mode at 155 m after a warning, after which the diver will get no decompression information.<ref name="Galileo" /> Other computers, for example Delta P's VR3, Cochran NAVY, and the [[Shearwater Research|Shearwater]] range will continue to function, providing 'best guess' functionality while warning the diver that a stop has been missed, or a ceiling violated.<ref name="Perdix manual" /><ref name="InDepth" /> Some dive computers are extremely sensitive to violations of indicated decompression stop depth. The HS Explorer is programmed to credit time spent even slightly (0.1 metre) above the indicated stop depth at only 1/60 of the nominal rate. There is no theoretical or experimental basis claimed as justification for this hard limit. Others, such as the Shearwater Perdix, will fully credit any decompression done below the calculated decompression ceiling, which may be displayed as a user selectable option, and is always equal to or shallower than the indicated stop depth. This strategy is supported by the mathematics of the model, but little experimental evidence is available on the practical consequences, so a warning is provided. A violation of the computed decompression ceiling elicits an alarm, which self cancels if the diver immediately descends below the ceiling. The Ratio iX3M will provide a warning if the indicated stop depth is violated by 0.1 m or more, but it is not clear how the algorithm is affected. In many cases the user manual does not provide information on how sensitive the algorithm is to precise depth, what penalties may be incurred by minor discrepancies, or what theoretical basis justifies the penalty.<ref name="Perdix manual" /><ref name="HSE Manual" /><ref name="Apeks" /> Over-reaction to stop depth violation puts the diver at an unnecessary disadvantage if there is an urgent need to surface, and no computer can guarantee freedom from decompression sickness even if the displayed surfacing profile is followed exactly. More complex functionality is accompanied by more complex code, which is more likely to include undiscovered errors, particularly in non-critical functions, where testing may not be so rigorous. The trend is to be able to download [[firmware]] updates online to eliminate bugs as they are found and corrected.<ref name="Perdix manual" /> In earlier computers, some errors required factory recall.<ref name="recall" /> There are circumstances in which a lockout on surfacing is not an appropriate, helpful, safe or reasonable response. If a cave diver surfaces inside a cave, and the computer locks out following a violation, the diver may be in a position where they have no option but to make the return dive without the information the computer could reasonably be expected to provide, putting the diver at considerably more severe risk than strictly necessary. This is a very rare occurrence, but it is a failure that a backup computer with similar functionality cannot mitigate. Depending on circumstances and the specific computer, it may be possible to set it to gauge mode, which would at least provide depth and time data.<ref name="Liberty" /> === Redundancy === A single computer shared between divers cannot accurately record the dive profile of the second diver, and therefore their decompression status will be unreliable and probably inaccurate. In the event of computer malfunction during a dive, the buddy's computer record may be the best available estimate of decompression status, and has been used as a guide for decompression in emergencies. Further diving after an ascent in these conditions exposes the diver to an unknown additional risk. Some divers carry a backup computer to allow for this possibility. The backup computer will carry the full recent pressure exposure history, and continued diving after a malfunction of one computer will not affect risk provided that the second computer continues to function correctly. It is also possible to set the conservatism on the backup computer to allow for the fastest acceptable ascent in case of an emergency, with the primary computer set for the diver's preferred risk level if this feature is not available on the computer. Under normal circumstances the primary computer will be used to control the ascent.<ref name="Tek lite 1" /> <ref name="Davis redundant computers" /> ===Ethical questions=== Some questions have been raised in the diving community regarding the ethics of certain practices by dive computer manufacturers. In the continued absence of normative standards for the design and testing of dive computers, these have remained open, and the choice must be made by the user based on the information made available by the manufacturer, which may not be much. *Is it ethical for the computer manufacturer to not divulge the details of the decompression model used in a dive computer? How does this affect the ability of the diver to make an informed acceptance of risk? What are the criteria for effectiveness and risk acceptability?<ref name="Lang and Angelini 2009" /> *What is an acceptable level of risk? It is generally recognised that with the current technology and understanding of decompression physiology, a zero risk algorithm is not reasonably practicable. Different sectors of the diving community accept different levels of decompression risk, and within the recreational sector, different divers accept different levels of risk.<ref name="Lang and Angelini 2009" /> *What would be an acceptable validation protocol? Should dive computers be validated on human subjects using Doppler monitoring? If so, what types of profile should be used, and how would meaningful rejection criteria be chosen? <ref name="Lang and Angelini 2009" /> *Should validation be done by an independent agency?<ref name="Lang and Angelini 2009" /> *Is it acceptable to lock out decompression monitoring functionality during a dive in the event of a profile violation, leaving the diver without any indication of a reasonable safe ascent profile at a time when it is most needed?
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)