Wreck diver killed by leaking computer - UK

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!

Sorry to call you out here... But this exact mentality is killing people like this UK man.

THE DEFAULT is to bailout. #1 choice, just do it, don't di*k around. Stop thinking "I got this" like this man did.

Only is rare or unusual cases is there any need to try something else. SB and other forums like this are a terrible influence talking on and on about all the ways you can limp home on a broken CCR.

I have thought about this over the past few days, and I agree with you now.

While I still think that flying manually remains an option if you have a MAV and a way of monitoring PO2, the lack of a CMF orifice on an eCCR means that you are much more dependent on hitting that MAV, and even more so in shallow water. And even an experienced diver might fall behind on that task enough to fall off the cliff.

So all things considered, a task loaded diver with no working solenoid is probably better off bailing out. The proponents of staying on the loop if at all possible are often the same divers who run team bailout or cut their OC gas supply close in other ways.

Thanks for promoting safe diving practices!
 
So all things considered, a task loaded diver with no working solenoid is probably better off bailing out. The proponents of staying on the loop if at all possible are often the same divers who run team bailout or cut their OC gas supply close in other ways.

Bailing off the loop ticks the box for quite a few of the known rebreather failure modes.

Comprehensive Database of Top Down Rebreather Failure Modes http://www.deeplife.co.uk/or_files/FMECA_OR_V6_190910.pdf
 
I don’t understand how this applies to controllers.

I understand the concept of a backup controller if your primary fails. But with sensors, you have three that are each giving you their own measurement of loop PO2, and then you can apply voting logic. The operator can override that vote by doing a dil flush to see if two sensors have failed.

But how would that work with controllers, which simply take the voted on PO2 from the three sensors and decide whether or not to open the solenoid. And don’t you need a minimum of three for a vote?
Just pointing out that there are different types of redundancy used in engineering. Sometimes you have a fully redundant backup, so if the primary system fails you can switch over to the backup (e.g. amplifiers used in some types of satellite transponder). Another common system is triple redundancy, used where a computer processes a stream of data in real time and makes decisions. There, three identical computers operating simultaneously are used and, if they don't agree, a majority vote is used. This type of system was AFAIK used by the Apollo missions.
 
I don’t understand how this applies to controllers.

I understand the concept of a backup controller if your primary fails. But with sensors, you have three that are each giving you their own measurement of loop PO2, and then you can apply voting logic. The operator can override that vote by doing a dil flush to see if two sensors have failed.

But how would that work with controllers, which simply take the voted on PO2 from the three sensors and decide whether or not to open the solenoid. And don’t you need a minimum of three for a vote ?
You could do this with three sensors:
  1. No failures: 3 sensors give the same reading
  2. 1 failure: 2 sensors give the same reading and you are still fine and possibly indicate the failure
  3. 2 failures: if the two failures give no reading you just take the only reading and report 1/3 units possibly working. If the at least one of the two failures units give a reading, you cannot give a single value
3 units can guarantee only against 1 failure
5 against 2 failures maximum ?
 
You could do this with three sensors:
  1. No failures: 3 sensors give the same reading
  2. 1 failure: 2 sensors give the same reading and you are still fine and possibly indicate the failure
  3. 2 failures: if the two failures give no reading you just take the only reading and report 1/3 units possibly working. If the at least one of the two failures units give a reading, you cannot give a single value
3 units can guarantee only against 1 failure
5 against 2 failures maximum ?

Yeah, I know how voting logic and other human override strategies work for dealing with redundant sensors. My question was how the previous poster wanted to make this work with controllers.
 
Yeah, I know how voting logic and other human override strategies work for dealing with redundant sensors. My question was how the previous poster wanted to make this work with controllers.
You’ll have to have some kind of way for the controller to check its own integrity (or for the backup controller to check the first controller’s integrity) so it can perform a handover.
 
...........
 
You don't need any controllers to dive a rebreather. Adding more is not the solution. Next thing you know there will be a rebreather with 3 controllers. But what if a controller gives feedback into the sensors? Easy, make all the sensors separate, so 9 sensors. No this is wrong. If you have a decent rebreather instructor you know how to dive without any functional controller. Just need a reliable method of monitioring PPO2. If don't know the PPO2, now you really need to consider getting off the loop. Adaquate bailout, do it.

Need to get away from the failed handset/controller being the cause. It was a problem, but not the only problem. Should have been completely safe and nothing more than a nuisance. There are other factors in this fatality. Either more equipment failure, poor training, or the failure to revert to the training. (poor planning is also possible but that goes back to the poor training or failure to revert to the training).
 
You don't need any controllers to dive a rebreather. Adding more is not the solution. Next thing you know there will be a rebreather with 3 controllers. But what if a controller gives feedback into the sensors? Easy, make all the sensors separate, so 9 sensors. No this is wrong. If you have a decent rebreather instructor you know how to dive without any functional controller. Just need a reliable method of monitioring PPO2. If don't know the PPO2, now you really need to consider getting off the loop. Adaquate bailout, do it.

Need to get away from the failed handset/controller being the cause. It was a problem, but not the only problem. Should have been completely safe and nothing more than a nuisance. There are other factors in this fatality. Either more equipment failure, poor training, or the failure to revert to the training. (poor planning is also possible but that goes back to the poor training or failure to revert to the training).
I don’t have a strong opinion on your second point, but you don’t need 3 sensors per controllers in your first example, each of them would be linked to the same sensors, isn’t it ?
 
3 units can guarantee only against 1 failure
5 against 2 failures maximum ?

One kind of failure is when the device is dead. Another kind is when it gives you bad numbers. 5 can work against 4 failures of the former kind; with the latter all bets are off, generally speaking. Consensus vote only works if the majority agrees on the number.

The problem is slightly different with multiple controllers wrestling over one solenoid.
 
https://www.shearwater.com/products/teric/

Back
Top Bottom