Sign up for our monthly newsletter so you never miss the latest from InDepth!
by Jakub Šimánek
Photos courtesy of Divesoft unless otherwise noted. Illustrations by Aleš Procháska. Header photo by Martin Strmiska.
Full Disclosure: Divesoft is a sponsor of InDepth.
With open circuit diving, there is a general consensus that what is simple is safer and more functional, and the community has adopted simple, yet sufficiently redundant configurations. However, as rebreathers have come to the fore, it is time to ask what is necessary and simplest, and what can no longer be simplified.
The simplest way is not always the best way
The simplest, functionally ingenious, and—in principle—trouble-free rebreather is undoubtedly the oxygen rebreather. Simplicity itself. Breathing bag, CO2 absorber, oxygen bottle, oxygen regulator, breathing hose, and directional mouthpiece is all you need. I wish this was the final solution! Unfortunately, as we know, with only oxygen we can not safely dive very deep and it is necessary to complicate the device quite a bit to do so.
Rebreathers have been developed through semi-closed, electronic closed circuit (eCCR), manual closed circuit (mCCR, and passive semi-closed (PSCR). We already know that if we want a safe device that allows us to dive deep, we cannot do without electronics, because all mechanical solutions have their limitations. SCR wastes too much gas, PSCR is much more economical, but decompression is not ideal. Manual CCR is as powerful as electronically controlled closed circuit in terms of gas savings and decompression efficiency, but has depth limitations due to the blocked reference ports in the first stage regulator, which sense ambient pressure. As a result the intermediate and ultimately the low pressure delivered by the regulator does not increase with depth.
While an open circuit regulator valve delivers a fixed pressure of gas above ambient pressure, a mCCR constant flow valve, aka a leaky or trickle valve or fixed orifice, delivers a fixed pressure of gas, in this case oxygen, independent of depth. Accordingly, the valve will deliver oxygen until the ambient pressure is equal to the pressure of gas exiting of the flow valve. So, for example, if the flow valve delivers a pressure of 10 bar, the depth will be limited to 90 m/294 ft or 10 bar of pressure ATA.
This is not the only thing that is problematic on mCCR. mCCRs have been designed with maximum simplicity and with the elimination of “dangerous” electronics—excluding oxygen sensors—in mind. This moves the most critical part, i.e., the control of the partial pressure of oxygen, to the constant flow nozzle with manual addition by the diver. However, the diver is a human who can suffer from bad moods and bad concentration. They can underestimate the situation, have limited ability to concentrate on multiple things at once, especially in ‘critical’ situations and are impacted by limited visibility, cramped space, inert gas effects and great depths etc.
We want to avoid electronics and take control, but we must acknowledge that the weakest link in the whole chain is ourselves. How does our human error rate compare with electronics? How accurate are our oxygen injection calculations vs the machines? Aren’t human factors the hottest topic of recent times in the diving world? The answers are obvious when we consider that one makes three to six mistakes per hour.1
Personally, not counting the testing of pre-production prototypes, I have not had a dive computer fail underwater since 1996. There are no statistics on underwater electronics failure, but I would argue that the ratio of human error rate vs. the error rate of electronic dive computers is quite high. And what is the difference between a dive computer and a rebreather control electronics? Only that the control electronics of the rebreather processes information from multiple sources and has a software algorithm for controlling the solenoid.
Yet some people choose mCCR anyway. Research2 has even shown that people are more willing to trust other people and forgive inevitable human mistakes rather than trusting computers.
Machines can’t think, and we can’t do that for them. We have to think for ourselves, but we can entrust straight forward calculations to computers. They are much better at it than we are.
Important Things Must Be Redundant
Electronic devices have become an integral part of our lives. We wake up with them, we move with them on the ground, in the air, in space, and underwater. We spend the whole day with them, and we fall asleep again with them in the night. Some electronic devices work 24 hours a day, 7 days a week.
Electronics help us in critical situations. When we are driving a car (ABS and other electronic systems), we let it navigate us from point A to point B. We entrust our lives to it when we travel by airliners, which today cannot function without electronics at all. The development of electronics is constantly advancing, but we must admit that electronics, like any other part of the device, can fail. If it is a mobile phone or a television, it is not usually a tragedy, but if it is a hard drive on which you have your family photos, or the results of your many years of work, for example, or a device on which human life depends, the data or device must have a reliable back up.
We all know it from both diving and everyday life, that those who do not back up their data will be sorry when they lose it. Those who do not have a backup plan in diving, a backup source of gas, can lose their lives. We are talking about redundancy.
Redundancy when diving with open circuit means having two first and two second stages, a buddy team, enough gas for the diver and their partner to surface, a buoyancy compensator that is backed up by a dry suit and any measuring device, such as a computer, sufficiently backed up by a second measuring device. So there is partly a kind of team backup. CCR failures cannot neccesarily be solved by team backup; a complete OC bailout ascent should be the last solution when there is no other option left. CCR cannot be backed up by a team member; CCR cannot be shared by two divers. The rebreather must contain its own back up.
What is a Fault Tolerant System?
A fault tolerant system is a feature that allows a system (often a computer system) to continue to work properly even if one of its components fails. Fault tolerance is desirable for systems with high availability or providing vital functions such as a space shuttle or an aircraft, so why not a rebreather? Life depends on it just as much.
As already mentioned, a rebreather is a complex system. What does such a system consist of? The electronic control unit receives information from several sensors, evaluates the data, and calculates the appropriate next action such as firing the injector, adjusting the decompression calculation, etc. The input systems are as follows: a pressure sensor, oxygen sensor, RTC (real time counter), and possibly additional helium or CO2 sensors. We also need a power source, i.e., a battery, and a user interface in the form of a handset or a simple display of PO2 values. Those are the basics.
Therefore, in order to appreciate what a fault tolerant rebreather is, let’s first look at a standard eCCR as shown in Fig. 1. The system is very vulnerable. A single error can cause us to either execute special skills or go straight to bailout. Try to imagine a failure of a battery, a single sensor, a solenoid, or a control unit.
The next diagram illustrates a fault tolerant rebreather schema—namely the Divesoft Liberty CCR (Fig.2)
We start the dive with a fully functional rebreather. The loop is not very different from a conventional rebreather, except that all elements are doubled (a manual add valve (MAV) and automatic diluent valve (ADV), an oxygen MAV and two solenoids). In addition, the electronics are doubled: two control units, two main displays, two secondary displays (HUD and buddy display (BD), solenoids, batteries, and all sensors are doubled. These are actually two self-sufficient systems that are interconnected and can communicate with each other.
Let’s phase out the individual components and observe how robust and resilient the fault tolerant system is. Let’s say I just cut off the handset cable in the wreck. Nothing is happening, I still have a second handset that shows me all the data and I am able to control the whole device. In addition, water does not leak into the device, because the cables are protected by watertight partitions on all inputs and outputs.
Oops, I broke the second handset against a rock. Still, nothing is happening. All the sensors work and I am able to read the ppO2 from the HUD. One of the batteries is exhausted/failed. This means the loss of one CU. But, I still have two oxygen sensors and therefore two O2 sensors, depth sensors, a solenoid. I can still continue on the unit and return safely to the surface without any need to intervene.
How To Make A System Fault Tolerant
The fault tolerant rebreather design consists of three basic parts:
1. A robust software solution
2. Hardware redundancy
3. A fault detection system
Complex software for modern CCRs consists of individual software modules. The software modules (tasks) are: ppO2 measurement, ambient pressure measurement, ppO2 regulation, decompression calculation, and the user interface. Which of these components probably experiences the most errors? Of course, every software engineer sees it right away; it’s the user interface—the most complex part of almost any software. What’s with that?
The solution is simple. We separate the user interface into another hardware-separated unit, i.e., a handset. It communicates with the rest of the system, i.e., with the control unit via the bus, in a fixed, formal, precisely defined manner. In the event of a fault, it only stops working, but the vital core of the system goes on (Fig.4).
Because the control unit (CU) does not include a user interface, it can be programmatically divided into small, simple modules that are easier to verify.
The second principle is hardware redundancy. For hardware redundancy to really work as fault tolerant, it requires a sophisticated system.
Figure 5 shows a primitive rebreather without redundancy. One mistake is enough and it is inoperative (Fig.5).
We improve the system by placing three oxygen sensors. In addition to these, we connect a backup monitoring system, and the battery is doubled (Fig.6).
Figure 7 shows another improvement: a separate oxygen sensor for backup. As in the previous case, the backup is short-circuit-proof on the measuring bus (Fig.7), all of which combine to form a fail-safe system. If any one element fails, it may not necessarily remain functional, but we will immediately learn about the problem and go to the bailout.
Further improvements: everything is completely doubled. In case of any one fault, the system remains functional (Fig.8). In this case, we can already talk about a fault tolerant system.
Third principle: a fault detection system? If I only have two oxygen sensors (Fig. 9) in each part of the system, it is not possible to automatically evaluate which one is defective (but a diver can decide manually because he or she sees all four sensors). How do we solve the problem?
Add three plus three sensors. This will, of course, double the cost of sensors. (Fig.10)
Alternatively, enable each system to see all four sensors. The problem is that it is not at all easy to prevent a short circuit on one system (ex: flooding with salt water) not to short the other system at the same time (Fig.11).
Or, simply connect both systems via a bus, through which they can send the measured values from the sensors to each other. The bus is much easier to disable in the event of a short circuit thanks to analog measurement.
And, other sensors (depth, temperature, etc.) are treated in the same way, effectively doubling them.
Internal complexity does not mean complexity for the user.
If we look at the fault tolerant rebreather scheme, one may think that the system is too complex, but that’s just on the inside. We have already shown that an increased number of components does not lead to a greater risk; on the contrary, in the case of a completely redundant system, it leads to greater safety.
Externally, on the other hand, the control of such a system is very simple and the user does not feel the internal complexity at all. It’s like driving a modern car full of the latest cutting-edge technology, and all we need to do is step on the gas and turn the steering wheel and enjoy the d(r)ive.
- Edkins G., Human Factors, Human Error and the role of bad luck in Incident Investigations, May 23th 2016
- Andrew Prahl and Lyn M. Van Swol; “The Computer Said I Should: How Does Receiving Advice From a Computer Differ From Receiving Advice From a Human,” presented at the 66th Annual International Communication Association Conference, Fukuoka, Japan, 9-13 June 2016.
- Procháska Aleš; Principles of Fault tolerant rebreather“ 2016, powerpoint presentation
aquaCORPS #12 Survivors: Designing a Redundant Life -Support System by William C. Stone (1995)
Jakub Šimánek graduated as a biology and physical education teacher from Charles University in Prague. Thanks to his father, he has been diving since childhood. He transferred his experience from teaching, biology, diving and sports to his instructor activities. Since 2012, he has been working in Divesoft, where he participates in the analysis and development of diving equipment, mainly rebreathers. He has been working as a Factory Instructor Trainer since 2014 and is an author of training procedures for this device. He is currently actively involved in developing and diving with bailout rebreathers.
They Helped Foment a Dive Computing Revolution: RIP Cochran Undersea Technology (1986-2020)
Latin American distributor for Cochran Undersea Technology and certifiable dive geek Carlos Lander recounts the many firsts and innovations in dive computing created by microprocessor pioneer Mike J. Cochran (1941-2018). These included the first wireless air-integrated dive computer, automated sensors, hands free gas switching, tap interface, compartment-level conservation factors, what-if software, and the “Cochran Navy”—used to by the US Navy, to run their proprietary VVAL 18 algorithm.
By Carlos E. Lander
Header image courtesy of C. Lander
Carlos Lander was the distributor for Latin America for Cochran Undersea Technology.
Michael James Cochran, genius and founder of Cochran Undersea Technology, revolutionized the design of dive computers (DCs) with the company’s state of the art US Navy Computer that impacted the entire DC industry. But before exploring the accomplishments of Cochran Undersea Technology, let’s answer an integral question: “Who was Michael James Cochran?”
Mike was born in Daytona Beach, Florida, on May 21, 1941. He worked on a missile tracking ship as a young adult but also had an illustrious career in electronics, receiving 57 patents, including ones for the microprocessor and microcomputer chip.1 The microcomputer chip patent was assigned to Texas Instruments (TI)—where Mike worked for many years—and issued to Gary Boon and Michael J. Cochran in July 1971.
For his work on that microcomputer chip, Mike won an IR-100 Award from Industrial Research Magazine (now known as R&D World Magazine). After he left TI, he worked with NASA and invented a DC for their astronaut training program. He founded Cochran Undersea Technology in 1986, and began designing and manufacturing DCs for recreational, sport, commercial, and military diving applications.
In 2016, he was awarded the honorary position of Admiral in the Texas Navy, an accolade commending exceptional community service. In that same year, he won the New Orleans Grand Isle (NOGI) Award—frequently known as the Academy Award of Diving—which recognizes pioneers of the underwater world.
Sadly, Mike passed away on December 2, 2018, at the age of 77, leaving behind a lasting legacy of studies and research in electronics. Mike was always driven by passion—so much so that he worked until the end of his life, having never created a plan for Cochran Undersea Technology to continue without him.
The Cochran Undersea Technology employed brilliant and gifted people such as Martin Heerschap, designer and engineer for the Cochran closed circuit rebreather (CCR) and liaison to the US Navy throughout the Navy DC’s development. Sales manager and tech instructor Larry Elsevier was another who worked closely with Cochran clients including the US Navy and NATO. He passed away in 2014. There was also Jeff Loudan, physicist, mathematician, and software engineer; Stuart McNair, engineer; and John Corso, talented diver and the face of the company before Mike’s passing.
Creating An Advanced Dive Computer
Everything started in 1991 when Cochran Consulting Inc—the parent company to Cochran Undersea Technology—filed a patent for an “advanced dive computer,” which was intended to become an Oceanic air integrated DC.2 While that specific product was never patented, Cochran’s DC led to a huge advancement in the field. First, Mike made a DC from a Single Board Computer (SBC), and then he programmed everything in an “assembly language,” securing very high-speed, real-time calculations on a reliable DC.
An SBC refers to any computer that contains all of its components in one circuit board. This configuration is perfect for devices with limited hardware space, such as a DC. SBCs are self-contained and energy-efficient, important elements under diving conditions.
An assembly language is an architecture-specific, low-level programming language, and Mike used one to efficiently compile a very complex algorithm including a set of variables that, at the time, did not exist in a DC (breathing parameters being one).
The final product included a microprocessor, a depth and pressure transducer, an electrically conductive metal clasp, and other components that worked efficiently in a small package within a very low power consumption unit.
Consequently, Mike decided to produce his own line of DCs, dubbed Nemesis in the United States, and Aquanaut in the EU. Although the company worked with different brands, in the end they decided to concentrate on their own, the Cochran Dive Computer. No other manufacturer at the time designed and built every component of their DC in-house.
Cochran was the first company to produce a hoseless DC with the following design features:
- Mike’s design allows the main computer to be attached to the tank, so all the information gathered by the pressure transducer is transmitted to a diver’s wrist monitor (a second computer) in real time3, including the diver’s breathing parameters and workload. The wrist unit could be used independently as a DC in the event of a tank unit failure. Other brands used a transmitter attached to the tank, limiting the amount of information that could be sent to the main unit in short data bursts.
- As determined by Cochran, the cases on both units were air-filled (at 1 atm), ensuring that the cases were manufactured with material that was capable of withstanding extreme depths. Taking this approach required fewer case penetrations—such as buttons—and ensured an effective, long-term seal. In addition, the battery compartment was sealed from the electronics and built with materials that wouldn’t corrode. In an extremely rare case of flooding, the only damage would be to the battery compartment and not the electronics.
- The case was equipped with three electrically conductive metal clasps instead of pushbuttons. Those stainless contacts, in conjunction with the electronics, could detect the difference between saltwater and freshwater and thus refine the depth calculation. They could also distinguish metallic objects and fingers via electroconductivity.
- Another cool patented feature was the implementation of a vibration detector inside the unit which allowed the user to perform quick functions, like tapping the unit for five seconds to turn it on, or tapping it once to turn on the back light.
- The Cochran computer accurately measured and recorded the altitude (pressure) every minute whether it was on or off, accounting for minute changes of nitrogen levels in tissue.4
- Other contemporary DCs accounted for changes in decompression conservatism, and while some commercially available computers offered conservatism customizations, they didn’t provide adjustment calculation guidance. The majority of DCs based the conservatism factor in changing altitude; instead, Cochran used gas-loading to add conservatism in proportional increments so that divers both understood and controlled their conservatism.
- Cochran’s DC’s tandem PC software featured two capabilities not offered by any other manufacturer at the time. First, the PC software ran the same algorithm as the DC, behaving exactly as the DC did on a dive. Divers could perform a trial run on the PC graphically or review an existing profile. Secondly, divers could transfer gas loading and altitude characteristics from one DC unit into another DC unit. For example, if one computer malfunctioned, information would transfer from one unit to another. Therefore, divers could continue to dive with the new computer without noticing any difference.
- Perhaps most importantly, the Cochran DC never locked a diver out; most DCs would block access for 24 hours if the diver violated a stop. Cochran’s DC allowed them to continue their dive, and the DC would continue off-gassing at their current depth.
The Proprietary Cochran algorithm
Mike exchanged ideas with dive experts while developing Cochran’s proprietary algorithm, including Dr. Bill Stone, Dr. RW Bill Hamilton, and Capt. Edward Thalmann of the US Navy. He designed the circuit board with the algorithm in mind. During this period, Capt. Thalmann was developing the Navy’s proprietary VVAL18 algorithm with the intention of using it in a forthcoming Navy DC. His plan was to be able to test the DC on the manned test-dive data to evaluate its performance against the algorithm.
Once Cochran Undersea Technology was awarded the contract to build the Navy DC, they had access to all the scientific studies, probabilistic software, and anecdotal data on the installation of VVAL18 into a DC, which was pivotal to the development of Cochran’s own decompression algorithm. Cochran’s algorithm for the Nemesis included compensation for a bubble formation, and the Gemini—based on the Nemesis prototype—added variables for ascent rate and breathing parameters. The algorithm is based on a modification of Haldane’s decompression model, with compartments between five and 480 minutes.
There were several versions of the Cochran algorithm: 14, 16, and 20 compartment models. In the case of the 20 compartment version, the algorithm included fast compartments to compensate for helium gas and added a compensation for microbubbles related to ascent rate velocity. The model also used the same linear off-gassing from the Thalmann algorithm but included more than the fast compartment and ascent velocity to compensate for the aforementioned microbubble formations.
DC algorithm evaluation has been the subject of some research. For example, Dr. Carl Edmonds compared DC responses to a series of bounce dives. Dr. Karl E. Huggins used the same technique to evaluate DC algorithms by testing them on profiles that had known human subject results.
In his article published in 2004, Huggins notes that DC manufacturers did not validate their algorithms with human subject tests, so running a DC against a battery of previously tested dive profiles provided some rudimentary level of validation. So, when it came to validating their algorithm for use in both the Nemesis and Navy DCs, Cochran had the advantage of accessing the Navy’s database of man-tested dives.
Along with validation against the Navy’s database, the Cochran DC was validated against NOAA’s custom tables on the wreck of the USS Monitor, and the tables and DC were said to have matched well throughout the project.
In a 1989 Undersea and Hyperbaric Medical Society (UHMS) Workshop on Validation of Decompression Tables, UHMS determined that decompression algorithm validity could only be proven using primary data, such as results derived from controlled laboratory conditions. However, secondary data such as anecdotal performance reports could be cited as an operational evaluation but wouldn’t be considered proof of validity.
Cochran’s Navy DC and what made it so special
In 1996, there were no commercial DCs running the VVAL18 decompression algorithm. The US Navy Experimental Diving Unit (NEDU) sought a manufacturer to install the VVAL18 on a DC following their specifications, which were far from simple.
Cochran won the bid (being the only DC designer and manufacturer entirely in-house likely had much to do with it) and delivered five modified Commander DCs with the VVAL18 algorithm, which they called “Cochran Navy.” After a few modifications, Cochran developed additions to the Single Board Computer (SBC) that allowed for massive dive profiling memory and a one-second sample diving profile (the Navy required a maximum of two seconds). The finished product was a DC that handled large amounts of data and self-test diagnostics.
Due to the breathing parameters, the DC would operate with air if the depths were shallower than 23 m/75 ft, or at PPO2 = 0.7 (MK16 MOD 0 UBA) at further depths. Additionally, hands-free Gas Switching was implemented to eliminate the need for buttons5. Part of the computational power was required for this, as the switch function would depend on depth and time. Also, the DC was programmable on the surface or via PC.
The device computed decompression properly whether the diver was below or above the stipulated stop. The residual gas was based on the diver’s depth: a real-time-calculator, without gimmicks. Therefore, the DC never shut down or left the diver hanging. Other advances were handling of the magnetic signature, EMF emissions, and visible light emissions (red light) required for Explosive Ordnance Disposal (EOD) work, and for stealth. The DC could be programmed for the needs of the mission with the Navy’s Analyst computer software.
According to probabilistic decompression models for the profiles tested on the Cochran Navy DC, the average risk predicted of decompression sickness occurrence was low: less than 1%, as expected. Therefore, the DCs were validated by faithful replication of the decompression schedules when exposed to simulated manned tested-dives.
The computers made by Cochran Undersea Technology, while advanced for their time, were misunderstood and misused by many. Still, I consider Cochran’s Gemini DC the best ever made. If you’re not breathing from the back-gas and can reach certain pre-programmed depths, the computer automatically knows that you’re breathing from the deco bottle. If you start breathing from the back-gas again, automatically switching back without needing to push any buttons is an astounding characteristic unmatched by any other DC.
Unfortunately, the absence of a marketing division in the company gave Cochran the reputation of producing a military-only DC. The EMC-20H, a later DC, was also very advanced for its time, so it was sad to see Cochran vanish. I am comforted by the fact that I still have a few Cochran DCs I can use, and that they will serve me for many years to come.
I want to thank Martin and John for our conversations, and for their help in getting the facts straight.
- Patent No. 4074351
- Patent Nos. US4949072, 4999606
- Transmitting information every second reduces noise; the power transmitter and a 250 kilohertz frequency results in a strong communication between units and protection from interference with other devices such as camera strobes and scooter motors.
- When a diver changes from a lower altitude to a higher one, the computer detects this change and adds nitrogen to the tissue compartments. The differential pressure between the nitrogen in the body and the higher altitude must be equalized (outgassed). Conversely, when a diver changes from a higher altitude to a lower one, the computer detects this change and removes nitrogen from the tissue. The computer automatically reacts to long-term stays at a constant altitude. If a dive is made while at altitude (whether the computer has already automatically reacted or not), the nitrogen algorithm within the Dive Computer is adjusted depending on the exact depth.
- Patent No. 5794616
Cochran Undersea Technology Technical Papers:
Carlos Lander—I’m a father, a husband, and a diver. I’m a self-taught amateur archaeologist, programmer, and statistician. I think that the amateur has a different mind set than the professional and that this mindset can provide an advantage in the field. I studied economics at university. My website is Dive Immersion. You can sign up for my newsletter here.
Thank You to Our Sponsors
Why Do Divers Run Out Of Gas?
Not surprising, the answer is more complicated than simply, they neglected to look at their gauges. Here Aussie diving medical...