[Genesis]

Quote: (Originally Posted by AD_ward9)

The tracking inside the board is not for ESD: it is to prevent the power supply being coupled to the sensor tracks anywhere. Tracks are covered by solder resist, but if the power supply does get to them through heavy condensation or worse, a flood, then the sensors are stuffed.

Alex

Which was, in ther context of my original contribution, the point.

You're diving, look at your handset, and its blank - and full of water.

All the rest of the esoteric "what got blown up" stuff goes out the window right there. You cannot trust anything connected with a physical wire to that handset, no matter what it is, from that point forward.

Why? Because you have no way to know if a voltage rail got shunted where it does not belong. It is not possible to divine this in the water; ergo, you must assume that it DID.

This requirement means that you must treat the sensors as being stuffed until PROVEN otherwise, which requires that you return to land for a full inspection, teardown and functional test.

The only truly valid exception to this is if there is a PURE optical (no wire) link between the head and handset - but then of course a fault in the head is the same as a fault in the handset (you must again assume the sensors are stuffed) because once again you can't see inside the head while you're diving to analyze the failure!

Likewise, if I am diving on the K1 and get a systemic alarm indicating that communications errors are being taken between the head and handset, I must assume the sensors are stuffed, even if they appear to be ok. Why? Because a fault in the head board means that it may have had its watertight integrity compromised (yes, even though its potted!) and if that has happened then once again the sensors may be stuffed.

My approach to operating a device like this is that if you have evidence suggesting that something might be broken you must declare it broken until proven otherwise. That appears to be one of the keys to remaining alive - and when one looks at the accidents for which we have any data at all what keeps coming up again and again is that people have decided - incorrectly - that some part of the unit was "ok" when they had evidence available to them (whether they looked or not!) to the contrary.

[AD_ward9]

Quote: (Originally Posted by Genesis)

This requirement means that you must treat the sensors as being stuffed until PROVEN otherwise, which requires that you return to land for a full inspection, teardown and functional test.

The only truly valid exception to this is if there is a PURE optical (no wire) link between the head and handset - but then of course a fault in the head is the same as a fault in the handset (you must again assume the sensors are stuffed) because once again you can't see inside the head while you're diving to analyze the failure!

Couple of issues:
1. The purpose of guarding the O2 sensor tracks is not to keep the unit working during a flood, it is to stop the sensors being destroyed, so they can be used afterwards. If rinsed in clean water, sensors themselves survive a flood if no reverse voltage is applied to them. Very simple solution avoids wrecking the sensors.
2. On the handset/base issue, it does not matter if wires or optical is used, if the connector or penetrator is properly designed. If water gets into the handset, the handset is cooked. It should not do that through the penetrator just because the base is flooded. The connectors and cables below are some examples of how to prevent that.

Cheers,

Alex

[Genesis]

Alex, we keep talking past each other and I'm not sure why.

Yes, I understand that connectors should be waterblocked and that's not the issue (unless you're looking at the Inspiration's design as the "holy grail", which I think we both agree it is not!)

My point is simply that any time you have a failure of an electrically-powered part of the unit any portion of the unit which could be damaged by exposure to the unregulated voltage rail must be assumed to be compromised until proven otherwise.

You keep coming back to sensors getting wet like this is the whole story. I'm not sure why, because its NOT. Your design (and everyone else's) has at least some 1 ATA enclosured components or hard encapsulation (and usually both.) You cannot assume that these enclosures have retained their integrity after a failure in the circuitry has been detected, nor that anything "behind" that circuit (which does not have multi-point validation) remains intact.

My specific concern in this context is the sensors when there are two or more devices connected to one set - e.g. two handsets which share a set of three sensors for O2 content determination. My argument is that IF the first handset fails then you cannot assume the components connected to it are ok unless none of them would be damaged by imposing the unregulated rail across any part of them. For O2 cells this is never true, so if the first controlling/display device fails you must assume that all of the O2 cells are now invalid - rendering the "secondary" or "backup" control/display device irrelavent.

The exception is where you KNOW why the first one failed (e.g. out of battery power.) The majority of the time you DO NOT know why it failed while you're underwater. You may SUSPECT a cause but most of the time you cannot be certain.

Good engineering and safety practice says that if in doubt you call it broken until you know otherwise.

(Yes, I know this is getting into design philosophy - but that's what ALL unit designers adopt FIRST - right?)

[AD_ward9]

Quote: (Originally Posted by Genesis)

Alex, we keep talking past each other and I'm not sure why.

Because there are a number of separate but interconnected issues and we are not being clear enough with each other in separating them. In fact, they are not separable, as a CCR is so tight a system, a decision on one matter when considered from many different angles, usually affects other parts of the system. If I break your post up into neuron sized elements, perhaps we can overcome this communications barrier (at least it will make it easier to point out where my neurons may be miswired):

Quote: (Originally Posted by Genesis)

Yes, I understand that connectors should be waterblocked and that's not the issue (unless you're looking at the Inspiration's design as the "holy grail", which I think we both agree it is not!)

My point is simply that any time you have a failure of an electrically-powered part of the unit any portion of the unit which could be damaged by exposure to the unregulated voltage rail must be assumed to be compromised until proven otherwise.

I take a different view. That is, ensure the design does not allow one failure to spread to other sections.

For example, water in the handset should not affect the base. It should continue functioning completely normally.

Quote: (Originally Posted by Genesis)

You keep coming back to sensors getting wet like this is the whole story. I'm not sure why, because its NOT. Your design (and everyone else's) has at least some 1 ATA enclosured components or hard encapsulation (and usually both.) You cannot assume that these enclosures have retained their integrity after a failure in the circuitry has been detected, nor that anything "behind" that circuit (which does not have multi-point validation) remains intact.

Sensors are not the whole story, but an important element (and the theme of this thread).
The only things we keep at 1 ATM are batteries and the rear face of pressure sensors: we keep both of them outside the rebreather in thick stainless steel tubes. They can fail in any way they like, they are not going to affect any other electronics, other than reducing battery life. We are opposed to hard encapuslation (it causes failures).

It is this approach that gives us fundamental differences in the way we look at a problem. It affects trivial things like how to route the O2 sensors, how much ESD protection to provide, what failure modes to cover (i.e. all). We would both agree there is a lot of nonsense posted about the cost of these things: most cost very little - a resistor here, a buried track somewhere else. Added up, it is not a lot but together they implement a certain philosophy or method in approaching the design.

Quote: (Originally Posted by Genesis)

My specific concern in this context is the sensors when there are two or more devices connected to one set - e.g. two handsets which share a set of three sensors for O2 content determination.

A good case in point. We do not connect multiple devices to one sensor, except through high valued resistors. This prevents one failure in one set of electronics from affecting anything else.

Quote: (Originally Posted by Genesis)

My argument is that IF the first handset fails then you cannot assume the components connected to it are ok unless none of them would be damaged by imposing the unregulated rail across any part of them.

I believe we meet the latter condition, and the latter condition is the correct design objective for safety critical systems. At the sensor end, we prevent the situation where any rail can ever be across any of them, by taking proper ESD precautions, protecting the sensor from the electronics using a series resistor, and the electronics from a new sensor plugged in with an open load using the same resistor/diodes, burying the track and guarding it with ground so a conductive electrolyte (e.g. water from a flooded scrubber, or sea water), cannot put a potential onto the sensor wires. Safe design means the design should be resiliant, not just tell you that it has failed. When underwater you may not have another bail out option left: you want the rebreather to just work - tell you to bail out by all means, but keep you alive until you can.

Quote: (Originally Posted by Genesis)

situation For O2 cells this is never true,

Please tell me the situation where it is not true for the system I just described, and we have published right down to circuit level. We try to design such that the assertion you are making is not true.

Quote: (Originally Posted by Genesis)

so if the first controlling/display device fails you must assume that all of the O2 cells are now invalid - rendering the "secondary" or "backup" control/display device irrelavent.

A deduction based on a false assumption.

Quote: (Originally Posted by Genesis)

The exception is where you KNOW why the first one failed (e.g. out of battery power.) The majority of the time you DO NOT know why it failed while you're underwater. You may SUSPECT a cause but most of the time you cannot be certain.

You do not have to know why a failure has occured, or what failure, at all. One just needs containment of the failure and enough true redundancy so that when the failure happens, the system can operate as normal. For example, our using two batteries on the base and one in the handset, all packaged separately, and wired such that any one battery can power the whole system, and we monitor power supplies and shut them down when a failure occurs: all this is published in circuit diagrams and circuit review in our Open Revolution submission.

Quote: (Originally Posted by Genesis)

Good engineering and safety practice says that if in doubt you call it broken until you know otherwise.

On the surface during pre-dive checks, I could not agree with you more. But underwater, I disagree. In a recent fatal accident review we did, the fatality occurred because the software would not let the unit perform its life critical function when it was powered up underwater with a fault condition present.

Quote: (Originally Posted by Genesis)

(Yes, I know this is getting into design philosophy - but that's what ALL unit designers adopt FIRST - right?)

100% right, which is why this debate is worthwhile. It is also part of the concept behind the Open Revolution initiative: that each company, not just Deep Life, publish sufficient data to prove the safety of their products, that way the whole community designing rebreather controls can adopt the best practices and best design philosophies. I saw another post that made the good point that a rebreather controller should either demand everything from the user, or nothing. Where do you stand on this?

Cheers,

Alex

[Genesis]

Quote: (Originally Posted by AD_ward9)

I take a different view. That is, ensure the design does not allow one failure to spread to other sections.

I don't believe you CAN insure this when the failure possibilities include water intrusion into places where it does not belong.

Quote:

For example, water in the handset should not affect the base. It should continue functioning completely normally.

If the CPU is in the handset, then the base is a dumb brick without it. If the handset is just a display device then losing it costs you the ability to see what the CPU is doing, which IMHO is a critical failure (inability of the "big brain" to see what the "little brain" is doing means you have lost redundant thinking.)

If the CPU is in the head and fails then the handset is a brick also, since it displays either nonsense or nothing.

It IS possible (and not terribly hard) to design a display that will not blow up the controller if it is shorted randomly by water intrusion. There are trade-offs that come iwth the CPU in the head however, so there's no "free lunch".

Quote:

Sensors are not the whole story, but an important element (and the theme of this thread).
The only things we keep at 1 ATM are batteries and the rear face of pressure sensors: we keep both of them outside the rebreather in thick stainless steel tubes. They can fail in any way they like, they are not going to affect any other electronics, other than reducing battery life. We are opposed to hard encapuslation (it causes failures).

So your electronics pod is allowed to float at loop pressure? That is certainly different! If you conformal coat the board(s) then you're still hard encapsulated, its just thinner than a "full potting".

Quote:

A good case in point. We do not connect multiple devices to one sensor, except through high valued resistors. This prevents one failure in one set of electronics from affecting anything else.

That's simply not true. The resistor can be shorted across in which case its protective value is lost. This is like saying "well the input resistance on the ADC is 500Mohms, so its isolated". Uh, only until the ADC fails! While discretes certainly have less failure risk than ICs, neither are generally considered likely to fail unless something "bad" happens to them externally (e.g. ESD, exposure to moisture, etc)

Quote:

I believe we meet the latter condition, and the latter condition is the correct design objective for safety critical systems. At the sensor end, we prevent the situation where any rail can ever be across any of them, by taking proper ESD precautions, protecting the sensor from the electronics using a series resistor, and the electronics from a new sensor plugged in with an open load using the same resistor/diodes, burying the track and guarding it with ground so a conductive electrolyte (e.g. water from a flooded scrubber, or sea water), cannot put a potential onto the sensor wires.

But you CAN'T completely bury the trace. You can run it down an internal plane and place guards around it, BUT it has to surface to be connected to the sensor! And there's a potential place for the conduction you're trying to avoid.

Yes, I understand the concept of guarding signal channels that cannot withstand V+ excursions and all - however, I argue that there is no such thing as a guarantee if that circuitry is exposed to seawater and it penetrates either the housing or the encapsulation. At some point you have to bring the trace out of the inside of the board.

THEORETICALLY it is impossible for there to be a V+ short to the K1's sensors. I say theoretically because the head amplifier/ADC board is encapsulated in a solid potting compound, and therefore, in order for water to get to the traces and cause the short it has to get inside the potting compound and yet miss the guards, while bridging the connections. Impossible, right? I don't believe in impossible when you're talking about electronics flooded in an electrolyte, and believe the safe course of action is to consider the sensors buggered in that instance.

Quote:

Safe design means the design should be resiliant, not just tell you that it has failed. When underwater you may not have another bail out option left: you want the rebreather to just work - tell you to bail out by all means, but keep you alive until you can.

I do not believe you can get there from here. You can be damn defensive but I'm not sold on the concept that you can be COMPLETELY certain.

One of the tests I did with the K1's head unit was to submerge the WHOLE THING, sensors and all, in seawater, with the power on, after potting and all (that is, "as assembled".) It continued to work, and when I rinsed off the sensors with fresh water they returned to normal too. No visible harm.

That doesn't mean that I consider this "safe". Its not. Well, ok, it was that time. But I don't call the design "proof against flooding", not that in that particular case I'd care - if the head floods like that you're stuffed anyway as the loop is full of water!

Quote:

But underwater, I disagree. In a recent fatal accident review we did, the fatality occurred because the software would not let the unit perform its life critical function when it was powered up underwater with a fault condition present.

Well yeah, that's a clear problem. The K1's designed to take its "best guess" if you force it underwater when you shouldn't, although it'll bitch about it. I find it terribly offensive when you've got a system that if powered up in an "unexpected" state does bad (evil) things.....

Quote:

100% right, which is why this debate is worthwhile. It is also part of the concept behind the Open Revolution initiative: that each company, not just Deep Life, publish sufficient data to prove the safety of their products, that way the whole community designing rebreather controls can adopt the best practices and best design philosophies. I saw another post that made the good point that a rebreather controller should either demand everything from the user, or nothing. Where do you stand on this?

Cheers,

Alex

I tend to agree.

My view is that the controller should never display data it is not reasonably confident in. For example, it is not possible to discern if all three sensors go tits up at the same time in the same way. If they ALL tell you the PO2 is 1.0 when it really is 1.3, yet when you inject O2 and expect to see a .2 rise you do, well, that's kinda tough to detect.

But, for example, if you get a cell alarm on the K1, it will still act BUT the unit will alert - it doesn't just shut up and go along, it sound an audible along with the visual (flashing of the backlight.) If you CHOOSE to silence that you can - but if a SECOND cell goes out then you get an alarm you CAN'T silence. To ignore that you have to intentionally sit there while it beeps at you, yet do nothing.

It has proven in testing to be extraordinarily sensitive. When you start to see a "slow" cell show up you'll get a momentary alarm on injection that goes away a few seconds later. Not a critical thing - you can dive with that happening - but its damn hard to miss the fact that its doing it! You hear click-hiss-beep-pause-beep-pause-beep (silence).... if you look down while its beeping you see the asterisk next to the slow cell's reading. Of course normally all you hear is "cick-hiss" - pretty hard to miss.

Even with NORMAL cells big PO2 changes (e.g. from shallow to deep setpoints) that are done at the controller tend to result in transient alarms, simply because even well-responding sensors don't respond instantly together, and there's enough lag to get them out-of-band on the error rate. The K1's philosophy is not to filter display values unless necessary for some reason, so you can see the response of the sensors. As a result the update rate for the PO2 displays can be as often as every 200ms (depending on what the controller is up to at the time; the protocol to the actual LCD is serial, so if there's a lot to change it can be a bit slower to get back around to it, and it intentionally sits 100ms between "looks" for changes in the display), which gives you a very good idea of exactly how the cells are behaving.

In general I like having the big brain with true control. If the unit is making decisions I want it to still "expose" the data its using, rather than filtering it for display purposes, and I also want it to raise hell if it has any reason to be uncertain of what its doing (e.g. two cells read 1.4, one reads 0.15 - which one's right? If its the 0.15 and you don't inject, the user dies! If the 1.4 ones are right and you inject enough to bring the 0.15 up, you may kill the user with a tox event!) You CAN'T let that sort of situation occur without alerting the user that the "best guess" may be wrong, and he better use the big computer between the ears.

I look at the electronics as a guide, not a God. The nature of electronics around seawater, along with O2 sensors that have known failure modes which do not meet the reliability requirements to be truly trusted, IMHO make this approach almost mandatory.

In addition, I do not believe that it is possible to build a system that cannot be compromised. A physical failure of the loop is ALWAYS possible. For this reason I find the idea of a "safe" unit (e.g. one that can be dove safely without bailout) to be wishful thinking. Once you've accepted the need to be able to bail, and equipped yourself accordingly, then why is it important to try to prevent someone from doing so, when the act of bailing brings you to breathing a known-safe mixture?

[AD_ward9]

Quote: (Originally Posted by Genesis)

If the CPU is in the handset, then the base is a dumb brick without it.

Not in our designs. The DL Open Revolution submission has a full controller in the base (in fact two independent controllers, one in FPGA and one in microcontroller), and two in the handset.

Quote: (Originally Posted by Genesis)

If the handset is just a display device then losing it costs you the ability to see what the CPU is doing, which IMHO is a critical failure (inability of the "big brain" to see what the "little brain" is doing means you have lost redundant thinking.)

Which is why there is a HUD, which is not driven from the handset, and it is why the HUD has voice annunciation.

You make a series of assertions based on contemporary designs which fall into an uncomfortable middle ground: a system that neither demand the user does everything (e.g. KISS style CCRs), nor do they protect the user under all conditions (Open Revolution compliant eCCRs). As another user on this forum wisely pointed out, either end is OK and safe, anywhere in the middle is not. It is worth stepping back and looking at what EN61508 demands, and one thing it does demand is a change in design philosophy. With all due respect, you are adopting the middle ground and if you do that, I or anyone a coroner picks, will be able to find lots of errors. If you take either of the extremes, there should be no errors to find. For a KISS that is easy, for a unit that does things for the diver then it must meet EN61508 (in Europe), and if it does that none of the assertions you make are true (Assertion in the maths sense, i.e. an hypothesis).

Quote: (Originally Posted by Genesis)

IS possible (and not terribly hard) to design a display that will not blow up the controller if it is shorted randomly by water intrusion. There are trade-offs that come iwth the CPU in the head however, so there's no "free lunch".

Very few handsets actually explode. The Open Revolution handset cannot explode, it just can fail (not work), and the base then does the appropriate thing instead.

Quote: (Originally Posted by Genesis)

Your electronics pod is allowed to float at loop pressure? That is certainly different! If you conformal coat the board(s) then you're still hard encapsulated, its just thinner than a "full potting".

There is a conformal coat, but you cannot say it is full potting. We keep electronics in silicone oil.

Quote: (Originally Posted by Genesis)

That's simply not true. The resistor can be shorted across in which case its protective value is lost. This is like saying "well the input resistance on the ADC is 500Mohms, so its isolated". Uh, only until the ADC fails!

To get a voltage on the cell, the resistor would have to fail short. 100K SMD resistors do not fail short, they fail open.

Even if by some new physical phenomena, it were to fail short, that is OK. If the ADC failed as well, then a voltage could appear across the sensor taking out one sensor. The sensor is out of range for the depth, therefore is ignored. There are 4 sensors fitted to the O.R. submission. Only one needs to work. There are two ADCs to achieve the billion hours (based on MTBF of the ADCs in military conditions).

Quote: (Originally Posted by Genesis)

While discretes certainly have less failure risk than ICs, neither are generally considered likely to fail unless something "bad" happens to them externally (e.g. ESD, exposure to moisture, etc)

No guesswork needed. We published the full calculation of the MTBF and MTBCF and how we calculated it in our Open Revolution submission. It achieves 2.9 billion hours. Please point out where the error is.

Quote: (Originally Posted by Genesis)

But you CAN'T completely bury the trace. You can run it down an internal plane and place guards around it, BUT it has to surface to be connected to the sensor!

It is connected to the centre pin of an SMB connector, which itself has 4 ground guard pins. You can flood it and there is no potential on the pin.

Quote: (Originally Posted by Genesis)

Yes, I understand the concept of guarding signal channels that cannot withstand V+ excursions and all - however, I argue that there is no such thing as a guarantee if that circuitry is exposed to seawater and it penetrates either the housing or the encapsulation.

Yes, there is. One simply designs it properly and then tests it for exactly those conditions.

Quote: (Originally Posted by Genesis)

At some point you have to bring the trace out of the inside of the board.

See above. It comes out on the centre pin of an SMB connector, with the 4 ground guard pins.

Quote: (Originally Posted by Genesis)

THEORETICALLY it is impossible for there to be a V+ short to the K1's sensors.

If you say the trace is fully guarded with ground, and you have a big enough series resistor, then that is probably true. If either of those assumptions are false, then your statement is not true.

Quote: (Originally Posted by Genesis)

I say theoretically because the head amplifier/ADC board is encapsulated in a solid potting compound, and therefore, in order for water to get to the traces and cause the short it has to get inside the potting compound and yet miss the guards, while bridging the connections. Impossible, right?

Not quite. It depends on your ESD arrangements. You said you use shunts, which have not been tested for ESD, and in that case, if the chip fails from ESD you may well find +ve on your sensor.

Quote: (Originally Posted by Genesis)

You can be damn defensive but I'm not sold on the concept that you can be COMPLETELY certain.

So please, tell me the mechanism by which +ve gets onto the Open Revolution sensors, and its probability. The latter is easy to calculate if you can identify the former (I will do it for you). By reducing things to basic principles and maths, one can be certain. Maths is the only true science, with black and whites.

Quote: (Originally Posted by Genesis)

One of the tests I did with the K1's head unit was to submerge the WHOLE THING, sensors and all, in seawater, with the power on, after potting and all (that is, "as assembled".) It continued to work, and when I rinsed off the sensors with fresh water they returned to normal too. No visible harm.

Good. Glad you tested that. Now try testing the ESD structure.

Quote: (Originally Posted by Genesis)

My view is that the controller should never display data it is not reasonably confident in. For example, it is not possible to discern if all three sensors go tits up at the same time in the same way.

Yes it is, you have 4. Or, you check they work every minute using the PPO2 controller.

Quote: (Originally Posted by Genesis)

If they ALL tell you the PO2 is 1.0 when it really is 1.3, yet when you inject O2 and expect to see a .2 rise you do, well, that's kinda tough to detect.

It is not hard at all, and is just what the O.R. unit from DL does. Sensors and injectors are part of the same checking system.

Quote: (Originally Posted by Genesis)

The K1's philosophy is not to filter display values unless necessary for some reason, so you can see the response of the sensors.

So you sit in the middle ground, passing some things to the user and some things you handle in the K1. Uncomfortable place. We simply pass the right result to the user. Much more work in doing that, but that is the only way of sticking to the principle.

Quote: (Originally Posted by Genesis)

In general I like having the big brain with true control. If the unit is making decisions I want it to still "expose" the data its using, rather than filtering it for display purposes, and I also want it to raise hell if it has any reason to be uncertain of what its doing (e.g. two cells read 1.4, one reads 0.15 - which one's right? If its the 0.15 and you don't inject, the user dies! If the 1.4 ones are right and you inject enough to bring the 0.15 up, you may kill the user with a tox event!) You CAN'T let that sort of situation occur without alerting the user that the "best guess" may be wrong, and he better use the big computer between the ears.

If the unit is designed properly, it should have many orders of magnitude better performance in determining when the sensors are working and what is the answer than a user looking and second guessing. The controller should detect immediately when sensors fail. The first step is using sensors that do not fail in either high or low states.

Quote: (Originally Posted by Genesis)

I look at the electronics as a guide, not a God. The nature of electronics around seawater, along with O2 sensors that have known failure modes which do not meet the reliability requirements to be truly trusted, IMHO make this approach almost mandatory.

It makes your approach dangerous: it puts the unit in the middle ground. MTBFs, HAZOPs, proper FMECAs are a process that allows engineers to pin hard numbers for probability on what they design. Without these, it is a complete guess what the safety is, and the Second Law of Thermodynamics (most universal law in the universe) dictates the guess falls against you more often than in your advantage. Do publish everything (as K1 is I thought), but do the sums and publish them too!

Quote: (Originally Posted by Genesis)

In addition, I do not believe that it is possible to build a system that cannot be compromised.

Agree, but safety engineering is all about putting a probability on the frequency of compromise.

Quote: (Originally Posted by Genesis)

A physical failure of the loop is ALWAYS possible. For this reason I find the idea of a "safe" unit (e.g. one that can be dove safely without bailout) to be wishful thinking. ?

One always needs bail out. Each of our design philosophies embody that, but some do not, and some take different views on forcing the user to use the bail out ...

Alex

[Genesis]

FMECA can only model that which is in it.

Murphy - and basic entropy theory - says you missed something.

You claim you can meet the 1 billion hour MTBCF. I believe your claim is impossible to meet, because the system's MTBCF as a whole is not limited to the failures modelled in your FMECA.

If you truly believe in your number, then you should be willing to advocate diving it alpine, since by definition the risk of death is less than 1 in 100,000 for users who put 10,000 hours on the unit.

After all, the basic OC diver runs "alpine" - he has no bailout, leaving him with only a CESA as his "last resort". This is considered acceptable literally millions of times every year, and while people do die, the statistics say that you're more likely to have a coronary underwater than you are to die from adopting this philosophy.

With reliability that surpasses the basic OC diver's rig, under your definition you should be willing and able to advocate diving alpine on it.

But - you don't:

Quote:

One always needs bail out. Each of our design philosophies embody that, but some do not, and some take different views on forcing the user to use the bail out .

Not true, if you're certain your system as a system meets the 1 billion hour goal you've set.

If you fail to meet the goal in any part of the system then the part that fails to get there is not relavent - whether its electronic or mechanical does not matter.

Your claim is that:

Quote:

It makes your approach dangerous: it puts the unit in the middle ground. MTBFs, HAZOPs, proper FMECAs are a process that allows engineers to pin hard numbers for probability on what they design. Without these, it is a complete guess what the safety is, and the Second Law of Thermodynamics (most universal law in the universe) dictates the guess falls against you more often than in your advantage. Do publish everything (as K1 is I thought), but do the sums and publish them too!

Nonsense.

MTBFs and FMECAs only model that which is included in them. By definition humans are fallible beings, and therefore, so is their analysis.

Mathematics is indeed the only true science but in order to apply it without error one must insure that all terms to the computation are included. This is an impossibility for all but the simplest systems.

Your EN specs may refer only to the electronics but IMHO that's a fallacious approach, as the system is not limited to electronics - and it is the system as a whole that matters here.

My viewpoint is that there is no such thing as a "safe" rebreather. They are all Homicidal Spawn of Satan, just as all OC gear is, and that only through attention to their operation can you make them reasonably safe to use.

My approach is that God gave us lungs instead of gills, and that by replacing the gills of sea-dwelling creatures with artificial devices we are inherently going somewhere we do not belong.

So long as one has adequate bailout and can detect a failure before it kills them, the option always exists to depart from the system you are using.

[rdmmdr]

Alex

the whole talk about protecting the boards during a flood seems mute because after a flood only an idiot would try to wash the board and reuse. it is a paper weight at that point, i understand the isolation you are trying to accomplish for the hand set comms it would make a repair cheaper after the flood. i would think however if the unit did flood, you would want the board to burn out so it could not be used by someone trying to get cheap.

i really like the idea of the flow control valve due to fact that loss of power/ control gives a fixed oraface, but how are handling a runaway of the valve controller. it seems that you have added multiple modes of failure here not subtracted them and increased the complexity of the part way beyond what it needs to be. the basic problem with the solenoids is corrosion of the plunger. a redesign of the plunger seems to be the best solution to this issue and the simplest. life threating issue with the solenoids are stuck open or failure to open, failure to open is a problem that you have time to deal with. stuck open, while a more critical problem time wise, can be mediate with a properly design flow limiter,a pneumatic fuse and proper training.

you are placing the batteries in the loop, a battery short in a high humidity high o2 environment is a failure i would not be comfortable with, how are you dealing with this issue.

encapsulating, you say that this causes more problems then it solves. i agree that there are problems with encapsulating the electronics, thermal stress and mechanical stress imposed upon the board, but don,t the benefits outweigh the a limited number of damaged boards during manufacture. and since the industry has been doing it for years these problems have been solved.

having talked to both ai and teledyne about the molex connector, what shitty idea those where for a rebreather, any decent molded connector will give you better results. i personally am using the the r-17d for that reason and have asked both manufacturers to look in to gold plating their connectors. i will take the risk of corrosion on the cell side rather then having to replace the harness. i question the protection of the input Chanel does not the load resister handle this and if the load resister is bad then is not the board already shot.

since you have installed a pressure sensor in the unit i assume that you will be including some deco software, what will be the mandatory re-cal requirement for the sensor. since even using two sensors here will not give you redundancy since both sensors are subjected to the same mechanical and thermal stresses. we annually service our regs but how many throw their deco computer in the pot to check the sensor.
rick

[Faceless]

Lithium batteries are placed in separate containers, placed outside of the loop, it can be seen on photos.
Also check the document named "safe PPO2 control", it wil give you a glue
In short: basically O.R. rebreather is calibrating O2 sensors all the time, i.e. first known amount of gas is injected into the loop, next we're checking O2 sensors for that happened:
http://www.deeplife.co.uk/files/Safe...rol_public.pdf

Variable orifice valve position is being controlled by two Hall sensors.

[AD_ward9]

Quote: (Originally Posted by rdmmdr)

the whole talk about protecting the boards during a flood seems mute because after a flood only an idiot would try to wash the board and reuse.

We are talking about a handset flood destroying not just the handset but the entire system. If the handset floo