Thoughts on voting algorythms.....

Genesis · 30th January 2006, 05:23

Quote: (Originally Posted by UWSojourner)

I'll take a look at the rest of your comments when I have time, but the idea of State 3 is simply to avoid making the bet you describe above.

Suppose the sensors read 0.19, 1.2, 1.2. State 3 would say inject until State 3 no longer exists. Case 1 - if the sensor is bad, then you would likely inject until sensors 2 & 3 go out of preference range. This would result in running the loop at the high end of the Preference range and likely shoot you into State 4. Case 2 - sensor 1 is not bad, then you don't go hypoxic and you end up running the loop at the low end of the Preference range.

In the situation above, the odds of two sensors pinned at 1.2 both being wrong while the third at 0.19 is correct is something I'd have to give thought to - how does that circumstance arise? Water on the cell faces makes them read low. Current leakage that pins two of three sensors at the same reading but not at the rail on a potted board is quite a stretch - even very small differences in the path current takes to get to one input pin or another will result in different (but both wrong) readings. Failed discretes on one of the input channels would not cause an adjacent channel to change values - there is no common path in the input chain. A failed op-amp that passes either rail through is going to lead to a pinned output, either at 0 or at the maximum possible PO2 given the stored calibration value, and again, there would be no crosstalk. A failed ADC pollutes all three channels (plus the depth and V+ sensor channels as well) along with the internal "sanity check" channels, which posts an immediate system critical alarm because the sanity checks fail. In any event what the code does right now is post a (non-critical) alarm - that may not be strong enough in this instance. It would be easy to strengthen this to post the alarm as critical if any sensor reads either hyperoxic or hypoxic, but otherwise leave the matrix alone.

I see a potential issue where 0.19, 0.19, 1.2 is being returned. This one is a much tougher nut to crack. Or is it? In this case right now the code declares the controller broken and posts a critical alarm, because it has only one sensor that it "thinks" is right (the high-reading one.) Thus you have to take action as the diver to figure out what's up. Odds are the two 0.19s are right, but I want the human to make his own decision - my first corrective action (at depth) is likely to be to add some DIL first, on the premise that if you're really hypoxic that'll fix it but if you're not you won't push the loop over the hyperoxic limit. If you inject DIL and see both low cells come up equally while the other one sits, you have confirmation that in all probability they're right. However, if the low ones sit at 0.19 and the high one moves......

My basic design philosophy is that if the code determines that it doesn't trust what its seeing it calls for help from the human. Defining a preference range and the states above appears to allow you to dive on "automaitc" with cells that are all over the place, so long as they remain within your defined preference range.

That violates the concept of using multiple sensors as a check on each other based on them having a linear output across the measurement range.

IMHO if you detect non-linearity in the sensors you have to assume what you're getting back is trash.

Consider the algo you defined with the following readings, with a preference range defined as 0.5 - 1.4:

0.5, 1.0, 1.2

This generates no alarm under your posted state table.

But what's the loop PO2? I'd argue that you have no idea. Without congruence between two of the sensors you have no clue whether you have any sensors that are linear. You know you don't have more than one - but that's all you can deduce from the above - you can't tell (without manual intervention) which one is correct or indeed if any of them are.

**UWSojourner** · 30th January 2006, 05:50

Quote: (Originally Posted by Genesis)

Consider the algo you defined with the following readings, with a preference range defined as 0.5 - 1.4:

0.5, 1.0, 1.2

This generates no alarm under your posted state table.

Ok. Sound the alarm if a certain sensor deviation occurs. That's ok with me.

What those three sensors tell me is that if ANY are correct, then I won't die over it if I load the deco model assuming 0.5 PPO2 and the perform OxTox calcs using PPO2=1.2. The diver SHOULD BE ALERTED to the high deviations because it would have an impact on deco/oxtox calcs.

In the scenario I described, the readings above would be subject to diver preference settings until at least one goes outside the Preference range. I'm not sure its more dangerous because only 1 need be right for me not to die (I think).

Genesis · 30th January 2006, 06:02

I'd argue you can't be reasonably sure that any of them are right unless you have two that agree and show linearity - at least not sure enough to bet your life on it.

In that circumstance you're going to have to figure out which one (if any) are right - if you're at depth then a DIL flush at a given depth should tell you if any of the three are reading close enough to correct (assuming you can do the math in your head) This of course assumes that the depth sensor is correct

Now there's an idea for a data screen - ask for the DIL O2 percentage and then the controller can then know what a DIL flush should result in for any given depth.... that might be quite useful and its trivial to do.

**UWSojourner** · 30th January 2006, 17:23

Quote: (Originally Posted by Genesis)

IMHO if you detect non-linearity in the sensors you have to assume what you're getting back is trash.

Consider the algo you defined with the following readings, with a preference range defined as 0.5 - 1.4:

0.5, 1.0, 1.2

This generates no alarm under your posted state table.

But what's the loop PO2?

I guess I don't disagree with you on this. The way I was trying to look at this was more from a game theory perspective. What's the game?

Suppose the two players are the Rebreather and you. In this game (the way I would define it), the diver wins if he/she surfaces unbent and alive. The RB wins if you don't surface or surface bent. You control the sensor algorithm.

All I was pointing out was that if at least 1 sensor is OK and all sensors can be kept withing the preference range, my algorithm wins ... I surface unbent (except for statistical probability on the bends).

In your algorithm, there exists a small chance that two sensors are wrong, but you use them and the Rebreather wins. Most RBs I think (including the one I dive) use this method, but I'm not sure it maximizes the chance of winning the game as I define it.

Genesis · 30th January 2006, 21:35

Quote: (Originally Posted by UWSojourner)

I guess I don't disagree with you on this. The way I was trying to look at this was more from a game theory perspective. What's the game?

Suppose the two players are the Rebreather and you. In this game (the way I would define it), the diver wins if he/she surfaces unbent and alive. The RB wins if you don't surface or surface bent. You control the sensor algorithm.

I like that viewpoint... its pretty close to my own.

Quote:

All I was pointing out was that if at least 1 sensor is OK and all sensors can be kept withing the preference range, my algorithm wins ... I surface unbent (except for statistical probability on the bends).

If at least one sensor is ok. What are the odds like though in this scenario? You went in the water with all three sensors showing ok readings. Now all three are WILDLY different? I'll bet that the odds favor something being radically wrong and all three sensors are producing garbage.

Quote:

In your algorithm, there exists a small chance that two sensors are wrong, but you use them and the Rebreather wins. Most RBs I think (including the one I dive) use this method, but I'm not sure it maximizes the chance of winning the game as I define it.

Not really.

I define any time an alarm has been raised to be a termination of the game.

What I do not want is the second-order game to get going - complacency. That's where my analysis says the REAL risks are.

Its interesting to note that as far I as know nobody has managed to cack themselves on a KISS yet. There are plenty of them out there. How come nobody's lost the bet? I argue that a big part of - if not THE answer - lies with the fact that the KISS is a mCCR - you MUST pay attention or you WILL die. There is no "trust the computer" because there isn't one.... that seems to be a protective feature rather than a bug, if one examines just the statistics.....

That has driven much of my design philosophy. If the computer doesn't like what it sees, it raises hell and lets the diver decide. By doing that you're basically forced to act....

**UWSojourner** · 30th January 2006, 22:02

Quote: (Originally Posted by Genesis)

I like that viewpoint... its pretty close to my own

Was this supposed to be comforting?

Quote: (Originally Posted by Genesis)

I'll bet that the odds favor something being radically wrong and all three sensors are producing garbage.

I completely agree. But, until more information is available, the CCR still has to do something. What is the best action? Unless sensors are in the hypoxic AND hyperoxic regions, I think the best course is to assume at least 1 is ok. (Some troubleshooting of the CCR could probably be programmed if space was available).

Quote: (Originally Posted by Genesis)

I define any time an alarm has been raised to be a termination of the game.

We completely disagree here (and so does my wife

). The game ends when I surface safely or have no chance of doing so (death). Until then, actions toward survival still need to be taken.

Quote: (Originally Posted by Genesis)

If the computer doesn't like what it sees, it raises hell and lets the diver decide. By doing that you're basically forced to act....

We probably disagree here too. Raise hell all you want, but you can't force a diver to act and until the diver actually acts, the CCR should perform its best actions to cause the diver to win the game. The CCR should not just stop trying. It must act until more information is provided by the diver.

I would think that a CCR's best action is rarely to 1) sound an alarm, 2) wash its hands with regard to your safety (i.e. stop the injection cycle), and 3)start you down the path toward hypoxia while waiting for diver input. There are other decision paths that keep the game going longer over a wider set of scenarios.

Genesis · 30th January 2006, 23:01

Quote: (Originally Posted by UWSojourner)

I completely agree. But, until more information is available, the CCR still has to do something. What is the best action? Unless sensors are in the hypoxic AND hyperoxic regions, I think the best course is to assume at least 1 is ok. (Some troubleshooting of the CCR could probably be programmed if space was available)

I disagree but only due to the second-level analysis - which I argue you have to do. A triple failure is one of those "can't happen" deals - or it should be. Unfortunately some current designs seem to have them happen way too often.

There would be no need for 3 sensors if you could trust 1.... IMHO if you don't have two that agree then you're in serious trouble no matter how you slice it.

Quote:

The game ends when I surface safely or have no chance of doing so (death). Until then, actions toward survival still need to be taken.

Yes, but who or what takes the action?

Problem is, my controller cannot control diluent. If it could AND if it had control over buoyancy then it could do a diluent flush and figure out what's up - and whether it can trust anything. Given an entered FO2 it is easy to compute what the PO2 should be for a given gas at a given depth.

But - that option is not available. So at the point you have wildly different readings you have no clue if any of them are worth anything at all.

Quote:

We probably disagree here too. Raise hell all you want, but you can't force a diver to act and until the diver actually acts, the CCR should perform its best actions to cause the diver to win the game. The CCR should not just stop trying. It must act until more information is provided by the diver.

Ah, but the first rule should be "don't kill the guy by an act of commission!"

If all three sensors are whacked (for real) and presenting garbage then there is a very real risk that you're right up against the high alarm PO2 limit, or even beyond it. There's no way to know. Injecting O2 could potentially kill you. Not injecting O2 could kill you. Its a coin toss absent more information at that point, and the only way to get the information is for the diver to provide it, since the controller lacks access to the diluent injection controls.

Quote:

I would think that a CCR's best action is rarely to 1) sound an alarm, 2) wash its hands with regard to your safety (i.e. stop the injection cycle), and 3)start you down the path toward hypoxia while waiting for diver input. There are other decision paths that keep the game going longer over a wider set of scenarios.

Unfortunately some of those decisions paths actively kill.

I don't want a controller that might kill me on its own. I accept that I may kill myself by ignoring its wanrings.

Now if the controller had a second solenoid with diluent behind it, with the output "spray" from it aimed at the sensor faces, I might change my tune. Then, in the fact of a "nothing makes sense" it could inject some DIL and look at the sensors to see which one(s) read at or close to what it KNOWS must be correct. If it finds one or more sensors which can read at that PO2, then it can change the setpoint to that value and hold it there.

That sort of response to your scenario I like - but it requires a second solenoid.....

**UWSojourner** · 31st January 2006, 01:10

Quote: (Originally Posted by Genesis)

I don't want a controller that might kill me on its own. I accept that I may kill myself by ignoring its wanrings.

Your algorithm would sound the alarm and, if the diver did not respond with more information or actions, simply do nothing as the diver breathed the loop to hypoxic levels?

So you sound an alarm because the sensors read 0.8, 1.05, 1.5. Then you stop working and watch (through your algorithm) the sensors go to 0.08, 0.10, 0.15? Now that's tough love

!

Genesis · 31st January 2006, 01:25

The obvious question is why would the diver not respond to very-insistent notice that something's wrong - and it needs his/her attention?

And how does this differ from the unit running out of 'sorb capacity, or O2 supply?

I can see the argument for, if you have no agreement, one (or more) sensors are hypoxic, AND the remainders are close enough that there is little risk of them being current-limited (even if out of tolerance) to inject.

What I'm distinctly uncomforatable with is injecting into a potentially current-limited sensor - which is the only one that's working at all.

**UWSojourner** · 31st January 2006, 03:28

Quote: (Originally Posted by Genesis)

The obvious question is why would the diver not respond to very-insistent notice that something's wrong - and it needs his/her attention?

The question isn't why? The question is "Now what?"

Quote: (Originally Posted by Genesis)

And how does this differ from the unit running out of 'sorb capacity, or O2 supply?

It differs because you do have Sorb, O2, a functioning solenoid ... you aren't out of anything

Why can't a test be done just with O2 rather than Dil? If you know the loop volume (roughly), you should be able to inject some O2 and see what happens to the sensors. See which respond in the way you would expect.

30th January 2006, 05:23	#21 (permalink)
Genesis Bubbless Box of Death Current Rebreather/s: Home Build Other Rebreather/s: Home Build Join Date: Oct 2005 Location: Sunny Florida Posts: 1,453	Re: Thoughts on voting algorythms..... Quote: (Originally Posted by UWSojourner) I'll take a look at the rest of your comments when I have time, but the idea of State 3 is simply to avoid making the bet you describe above. Suppose the sensors read 0.19, 1.2, 1.2. State 3 would say inject until State 3 no longer exists. Case 1 - if the sensor is bad, then you would likely inject until sensors 2 & 3 go out of preference range. This would result in running the loop at the high end of the Preference range and likely shoot you into State 4. Case 2 - sensor 1 is not bad, then you don't go hypoxic and you end up running the loop at the low end of the Preference range. In the situation above, the odds of two sensors pinned at 1.2 both being wrong while the third at 0.19 is correct is something I'd have to give thought to - how does that circumstance arise? Water on the cell faces makes them read low. Current leakage that pins two of three sensors at the same reading but not at the rail on a potted board is quite a stretch - even very small differences in the path current takes to get to one input pin or another will result in different (but both wrong) readings. Failed discretes on one of the input channels would not cause an adjacent channel to change values - there is no common path in the input chain. A failed op-amp that passes either rail through is going to lead to a pinned output, either at 0 or at the maximum possible PO2 given the stored calibration value, and again, there would be no crosstalk. A failed ADC pollutes all three channels (plus the depth and V+ sensor channels as well) along with the internal "sanity check" channels, which posts an immediate system critical alarm because the sanity checks fail. In any event what the code does right now is post a (non-critical) alarm - that may not be strong enough in this instance. It would be easy to strengthen this to post the alarm as critical if any sensor reads either hyperoxic or hypoxic, but otherwise leave the matrix alone. I see a potential issue where 0.19, 0.19, 1.2 is being returned. This one is a much tougher nut to crack. Or is it? In this case right now the code declares the controller broken and posts a critical alarm, because it has only one sensor that it "thinks" is right (the high-reading one.) Thus you have to take action as the diver to figure out what's up. Odds are the two 0.19s are right, but I want the human to make his own decision - my first corrective action (at depth) is likely to be to add some DIL first, on the premise that if you're really hypoxic that'll fix it but if you're not you won't push the loop over the hyperoxic limit. If you inject DIL and see both low cells come up equally while the other one sits, you have confirmation that in all probability they're right. However, if the low ones sit at 0.19 and the high one moves...... My basic design philosophy is that if the code determines that it doesn't trust what its seeing it calls for help from the human. Defining a preference range and the states above appears to allow you to dive on "automaitc" with cells that are all over the place, so long as they remain within your defined preference range. That violates the concept of using multiple sensors as a check on each other based on them having a linear output across the measurement range. IMHO if you detect non-linearity in the sensors you have to assume what you're getting back is trash. Consider the algo you defined with the following readings, with a preference range defined as 0.5 - 1.4: 0.5, 1.0, 1.2 This generates no alarm under your posted state table. But what's the loop PO2? I'd argue that you have no idea. Without congruence between two of the sensors you have no clue whether you have any sensors that are linear. You know you don't have more than one - but that's all you can deduce from the above - you can't tell (without manual intervention) which one is correct or indeed if any of them are. __________________ "A venturesome minority will always be eager to get off on their own, and no obstacles should be placed in their path; let them take risks for Godsake, let them get lost, sunburnt, stranded, drowned, eaten by bears, buried alive under avalanches - that is the right and privilege of any free American." http://www.denninger.net http://www.diversunion.org/liability.htm - Fix the Diving Cert racket
(Offline)

30th January 2006, 05:50	#22 (permalink)
UWSojourner Pacific Northwest Current Rebreather/s: Megalodon Other Rebreather/s: Join Date: Feb 2005 Location: Portland Oregon Posts: 558	Re: Thoughts on voting algorythms..... Quote: (Originally Posted by Genesis) Consider the algo you defined with the following readings, with a preference range defined as 0.5 - 1.4: 0.5, 1.0, 1.2 This generates no alarm under your posted state table. Ok. Sound the alarm if a certain sensor deviation occurs. That's ok with me. What those three sensors tell me is that if ANY are correct, then I won't die over it if I load the deco model assuming 0.5 PPO2 and the perform OxTox calcs using PPO2=1.2. The diver SHOULD BE ALERTED to the high deviations because it would have an impact on deco/oxtox calcs. In the scenario I described, the readings above would be subject to diver preference settings until at least one goes outside the Preference range. I'm not sure its more dangerous because only 1 need be right for me not to die (I think).
(Offline)

30th January 2006, 06:02	#23 (permalink)
Genesis Bubbless Box of Death Current Rebreather/s: Home Build Other Rebreather/s: Home Build Join Date: Oct 2005 Location: Sunny Florida Posts: 1,453	Re: Thoughts on voting algorythms..... I'd argue you can't be reasonably sure that any of them are right unless you have two that agree and show linearity - at least not sure enough to bet your life on it. In that circumstance you're going to have to figure out which one (if any) are right - if you're at depth then a DIL flush at a given depth should tell you if any of the three are reading close enough to correct (assuming you can do the math in your head) This of course assumes that the depth sensor is correct Now there's an idea for a data screen - ask for the DIL O2 percentage and then the controller can then know what a DIL flush should result in for any given depth.... that might be quite useful and its trivial to do. __________________ "A venturesome minority will always be eager to get off on their own, and no obstacles should be placed in their path; let them take risks for Godsake, let them get lost, sunburnt, stranded, drowned, eaten by bears, buried alive under avalanches - that is the right and privilege of any free American." http://www.denninger.net http://www.diversunion.org/liability.htm - Fix the Diving Cert racket
(Offline)

30th January 2006, 17:23	#24 (permalink)
UWSojourner Pacific Northwest Current Rebreather/s: Megalodon Other Rebreather/s: Join Date: Feb 2005 Location: Portland Oregon Posts: 558	Re: Thoughts on voting algorythms..... Quote: (Originally Posted by Genesis) IMHO if you detect non-linearity in the sensors you have to assume what you're getting back is trash. Consider the algo you defined with the following readings, with a preference range defined as 0.5 - 1.4: 0.5, 1.0, 1.2 This generates no alarm under your posted state table. But what's the loop PO2? I guess I don't disagree with you on this. The way I was trying to look at this was more from a game theory perspective. What's the game? Suppose the two players are the Rebreather and you. In this game (the way I would define it), the diver wins if he/she surfaces unbent and alive. The RB wins if you don't surface or surface bent. You control the sensor algorithm. All I was pointing out was that if at least 1 sensor is OK and all sensors can be kept withing the preference range, my algorithm wins ... I surface unbent (except for statistical probability on the bends). In your algorithm, there exists a small chance that two sensors are wrong, but you use them and the Rebreather wins. Most RBs I think (including the one I dive) use this method, but I'm not sure it maximizes the chance of winning the game as I define it. Last edited by UWSojourner : 30th January 2006 at 20:11.
(Offline)

30th January 2006, 21:35	#25 (permalink)
Genesis Bubbless Box of Death Current Rebreather/s: Home Build Other Rebreather/s: Home Build Join Date: Oct 2005 Location: Sunny Florida Posts: 1,453	Re: Thoughts on voting algorythms..... Quote: (Originally Posted by UWSojourner) I guess I don't disagree with you on this. The way I was trying to look at this was more from a game theory perspective. What's the game? Suppose the two players are the Rebreather and you. In this game (the way I would define it), the diver wins if he/she surfaces unbent and alive. The RB wins if you don't surface or surface bent. You control the sensor algorithm. I like that viewpoint... its pretty close to my own. Quote: All I was pointing out was that if at least 1 sensor is OK and all sensors can be kept withing the preference range, my algorithm wins ... I surface unbent (except for statistical probability on the bends). If at least one sensor is ok. What are the odds like though in this scenario? You went in the water with all three sensors showing ok readings. Now all three are WILDLY different? I'll bet that the odds favor something being radically wrong and all three sensors are producing garbage. Quote: In your algorithm, there exists a small chance that two sensors are wrong, but you use them and the Rebreather wins. Most RBs I think (including the one I dive) use this method, but I'm not sure it maximizes the chance of winning the game as I define it. Not really. I define any time an alarm has been raised to be a termination of the game. What I do not want is the second-order game to get going - complacency. That's where my analysis says the REAL risks are. Its interesting to note that as far I as know nobody has managed to cack themselves on a KISS yet. There are plenty of them out there. How come nobody's lost the bet? I argue that a big part of - if not THE answer - lies with the fact that the KISS is a mCCR - you MUST pay attention or you WILL die. There is no "trust the computer" because there isn't one.... that seems to be a protective feature rather than a bug, if one examines just the statistics..... That has driven much of my design philosophy. If the computer doesn't like what it sees, it raises hell and lets the diver decide. By doing that you're basically forced to act.... __________________ "A venturesome minority will always be eager to get off on their own, and no obstacles should be placed in their path; let them take risks for Godsake, let them get lost, sunburnt, stranded, drowned, eaten by bears, buried alive under avalanches - that is the right and privilege of any free American." http://www.denninger.net http://www.diversunion.org/liability.htm - Fix the Diving Cert racket
(Offline)

30th January 2006, 22:02	#26 (permalink)
UWSojourner Pacific Northwest Current Rebreather/s: Megalodon Other Rebreather/s: Join Date: Feb 2005 Location: Portland Oregon Posts: 558	Re: Thoughts on voting algorythms..... Quote: (Originally Posted by Genesis) I like that viewpoint... its pretty close to my own Was this supposed to be comforting? Quote: (Originally Posted by Genesis) I'll bet that the odds favor something being radically wrong and all three sensors are producing garbage. I completely agree. But, until more information is available, the CCR still has to do something. What is the best action? Unless sensors are in the hypoxic AND hyperoxic regions, I think the best course is to assume at least 1 is ok. (Some troubleshooting of the CCR could probably be programmed if space was available). Quote: (Originally Posted by Genesis) I define any time an alarm has been raised to be a termination of the game. We completely disagree here (and so does my wife ). The game ends when I surface safely or have no chance of doing so (death). Until then, actions toward survival still need to be taken. Quote: (Originally Posted by Genesis) If the computer doesn't like what it sees, it raises hell and lets the diver decide. By doing that you're basically forced to act.... We probably disagree here too. Raise hell all you want, but you can't force a diver to act and until the diver actually acts, the CCR should perform its best actions to cause the diver to win the game. The CCR should not just stop trying. It must act until more information is provided by the diver. I would think that a CCR's best action is rarely to 1) sound an alarm, 2) wash its hands with regard to your safety (i.e. stop the injection cycle), and 3)start you down the path toward hypoxia while waiting for diver input. There are other decision paths that keep the game going longer over a wider set of scenarios.
(Offline)

30th January 2006, 23:01	#27 (permalink)
Genesis Bubbless Box of Death Current Rebreather/s: Home Build Other Rebreather/s: Home Build Join Date: Oct 2005 Location: Sunny Florida Posts: 1,453	Re: Thoughts on voting algorythms..... Quote: (Originally Posted by UWSojourner) I completely agree. But, until more information is available, the CCR still has to do something. What is the best action? Unless sensors are in the hypoxic AND hyperoxic regions, I think the best course is to assume at least 1 is ok. (Some troubleshooting of the CCR could probably be programmed if space was available) I disagree but only due to the second-level analysis - which I argue you have to do. A triple failure is one of those "can't happen" deals - or it should be. Unfortunately some current designs seem to have them happen way too often. There would be no need for 3 sensors if you could trust 1.... IMHO if you don't have two that agree then you're in serious trouble no matter how you slice it. Quote: The game ends when I surface safely or have no chance of doing so (death). Until then, actions toward survival still need to be taken. Yes, but who or what takes the action? Problem is, my controller cannot control diluent. If it could AND if it had control over buoyancy then it could do a diluent flush and figure out what's up - and whether it can trust anything. Given an entered FO2 it is easy to compute what the PO2 should be for a given gas at a given depth. But - that option is not available. So at the point you have wildly different readings you have no clue if any of them are worth anything at all. Quote: We probably disagree here too. Raise hell all you want, but you can't force a diver to act and until the diver actually acts, the CCR should perform its best actions to cause the diver to win the game. The CCR should not just stop trying. It must act until more information is provided by the diver. Ah, but the first rule should be "don't kill the guy by an act of commission!" If all three sensors are whacked (for real) and presenting garbage then there is a very real risk that you're right up against the high alarm PO2 limit, or even beyond it. There's no way to know. Injecting O2 could potentially kill you. Not injecting O2 could kill you. Its a coin toss absent more information at that point, and the only way to get the information is for the diver to provide it, since the controller lacks access to the diluent injection controls. Quote: I would think that a CCR's best action is rarely to 1) sound an alarm, 2) wash its hands with regard to your safety (i.e. stop the injection cycle), and 3)start you down the path toward hypoxia while waiting for diver input. There are other decision paths that keep the game going longer over a wider set of scenarios. Unfortunately some of those decisions paths actively kill. I don't want a controller that might kill me on its own. I accept that I may kill myself by ignoring its wanrings. Now if the controller had a second solenoid with diluent behind it, with the output "spray" from it aimed at the sensor faces, I might change my tune. Then, in the fact of a "nothing makes sense" it could inject some DIL and look at the sensors to see which one(s) read at or close to what it KNOWS must be correct. If it finds one or more sensors which can read at that PO2, then it can change the setpoint to that value and hold it there. That sort of response to your scenario I like - but it requires a second solenoid..... __________________ "A venturesome minority will always be eager to get off on their own, and no obstacles should be placed in their path; let them take risks for Godsake, let them get lost, sunburnt, stranded, drowned, eaten by bears, buried alive under avalanches - that is the right and privilege of any free American." http://www.denninger.net http://www.diversunion.org/liability.htm - Fix the Diving Cert racket
(Offline)

31st January 2006, 01:10	#28 (permalink)
UWSojourner Pacific Northwest Current Rebreather/s: Megalodon Other Rebreather/s: Join Date: Feb 2005 Location: Portland Oregon Posts: 558	Re: Thoughts on voting algorythms..... Quote: (Originally Posted by Genesis) I don't want a controller that might kill me on its own. I accept that I may kill myself by ignoring its wanrings. Your algorithm would sound the alarm and, if the diver did not respond with more information or actions, simply do nothing as the diver breathed the loop to hypoxic levels? So you sound an alarm because the sensors read 0.8, 1.05, 1.5. Then you stop working and watch (through your algorithm) the sensors go to 0.08, 0.10, 0.15? Now that's tough love !
(Offline)

31st January 2006, 01:25	#29 (permalink)
Genesis Bubbless Box of Death Current Rebreather/s: Home Build Other Rebreather/s: Home Build Join Date: Oct 2005 Location: Sunny Florida Posts: 1,453	Re: Thoughts on voting algorythms..... The obvious question is why would the diver not respond to very-insistent notice that something's wrong - and it needs his/her attention? And how does this differ from the unit running out of 'sorb capacity, or O2 supply? I can see the argument for, if you have no agreement, one (or more) sensors are hypoxic, AND the remainders are close enough that there is little risk of them being current-limited (even if out of tolerance) to inject. What I'm distinctly uncomforatable with is injecting into a potentially current-limited sensor - which is the only one that's working at all. __________________ "A venturesome minority will always be eager to get off on their own, and no obstacles should be placed in their path; let them take risks for Godsake, let them get lost, sunburnt, stranded, drowned, eaten by bears, buried alive under avalanches - that is the right and privilege of any free American." http://www.denninger.net http://www.diversunion.org/liability.htm - Fix the Diving Cert racket
(Offline)

31st January 2006, 03:28	#30 (permalink)
UWSojourner Pacific Northwest Current Rebreather/s: Megalodon Other Rebreather/s: Join Date: Feb 2005 Location: Portland Oregon Posts: 558	Re: Thoughts on voting algorythms..... Quote: (Originally Posted by Genesis) The obvious question is why would the diver not respond to very-insistent notice that something's wrong - and it needs his/her attention? The question isn't why? The question is "Now what?" Quote: (Originally Posted by Genesis) And how does this differ from the unit running out of 'sorb capacity, or O2 supply? It differs because you do have Sorb, O2, a functioning solenoid ... you aren't out of anything Why can't a test be done just with O2 rather than Dil? If you know the loop volume (roughly), you should be able to inject some O2 and see what happens to the sensors. See which respond in the way you would expect.
(Offline)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode