Thoughts on voting algorythms.....

dantheman

Genesis,

You are an opinionated fellow, with some acumen to back it up.
You've put out lots of detail in both objections to and improvements
on current practice. I'm interested in what you have to say, and
I like quite a bit of it.

Perhaps now would be a good time to ask you to give the same
attention to stating what your goals are for your unit. What kind
of philosophy are you proceeding from?

I ask partly because of Phi's observation and one of your remarks.
Your method#3 is, by your own admission less safe, "but you're the pilot".
Phi's observation about a simple warning vs disabling the SP controller
speaks from that same perspective, IMO.

Where are you coming from?

--dan

Genesis

I am not attempting to make an idiot-proof unit. That's not possible, so there's no reason to design towards that goal, as it cannot be achieved.

My study over the last few years appears to validate what became a basic belief of mine some time ago - that complacency kills most people who die while diving, if we exclude medical incidents (which are not fair to count as "diving deaths" in the first place.) The counter-argument over time has always been that (more) training is the fix for the deaths that occur.

Well, we've had a few years of ever-tightening restrictions and ever-increasing training requirements. What we haven't had is a decrease in deaths. Indeed, there have been a number of people with unimpeachable credentials who have died on these things, and while diving in general.

Clearly, the prescription that all the doctors have been writing isn't saving any patients. Its like writing a 'script for aspirin when the patient has a brain tumor. It makes 'ya $50 but it doesn't cure the disease.

Since I am building something to actually use, my goal has nothing to do with being politic. It has to do with addressing what I believe are some of the causes of people getting in trouble.

Thus, the validation requirement.

That particular aspect of the controller firmware addresses one specific threat to your life, which is the fact that you cannot calibrate the unit at the PO2 you actually intend to use with any degree of accuracy. Its not possible because the PO2 you wish to reach can't be achieved in free air.

(As an aside, there is a tangental part of this which is why I have it calibrating in free air rather than tank O2, but that's for another thread - or at least after this issue is beaten to death )

The #3 procedure is less safe than either #1 or #2 but more safe than not having any validation at all. While #3 does not prove that the instruments read what is in the bag it does prove that the reading can be achieved.

The current paradigm in controllers is to take your word for it that the sensors can read hyperbaric PO2s - with no evidence that they really can! IMHO that's fundamentally unsound from an engineering point of view and violates what I keep hearing as the fundamental premise of Rebreather diving - "always know your loop PO2."

Ever wonder why there aren't a bunch of dead bodies on the KISS? IMHO a big part of the reason is that the only setpoint controller is between your ears, and everyone who dives one knows that if they don't use it, they will die. Therefore, complacency tends to be kept at bay because you can't "set it and forget it."

Phi's argument originally was that a "cold" dive-bomb drop (where the unit had not been used in a week) would lead to the unit refusing to allow a setpoint over 0.9, since you can't stop at 20' to do the validate. That's not true - you can validate at depth if you want. I do "dive bomb" drops all the time on OC in the gulf and often on scooter - the unit's ability to handle this IS important to me.

What you can't do is validate the unit with a voted-out sensor - which means if you have current limited sensor(s) you are forced to fly at the lower setpoint or fly manually with the controller as a parachute.

What's Phi's alternative? Do a dive on a unit with sensor(s) that are unproven, get to depth and find out that they aren't linear at the expected range? Now you have to notice that the solenoid is firing "too much" and turn the tank off (or stop it in the controller) - by which time you have a hyperoxic loop to deal with on top of the rest, and assuming you do deal with it, you're still flying manually at that point, because the controller has lost its mind. In the common "two beats one" voting logic paradigm this looks to be potentially quite dangerous, as the only GOOD sensor could be telling you the truth - and be voted out. The code in this controller has defensive measures against this as well, but that's a debate for either later in this thread (once we've disposed of this issue) or in another one.

I do not understand Phi's argument that his scenario is superior to the unit refusing to take control at the desired setpoint. In both cases you're flying manually, but in one you had the unit try to kill you first - with validation you just got a non-optimum decompression profile out of the experience. If he's able to provide more illumination that clarifies the reason for his view, I'd love to hear it..... its just that so far what I've heard doesn't appear (to me anyway) to make sense.

__________________
"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

dantheman

I'm sure Phi can speak for himself (I don't think he was going as far as you suggest..), so I'll just say that I wasn't trying to compare his idea to yours. Just the philosophy.

You both postulated a scenario where the pilot was in control, with information flowing to them from the unit. The difference of whether or not the unit still tries to do anything is beyond my current interest, which is your design philosphy. I.e. is there a thread connecting all those design points where you simply inform and let the pilot do their thing?

You're obviously putting a ton of work into this, and I'm genuinely curious.
--dan

Underwaterbear

My humble two cents worth on this issue is that I would rather not have my hand held. The less complicated the better. As things stand for me at the moment I do not fully understand how the prism voting algo works..and it is something I'm attempting to follow up privately with SMI. Anyway, that's a different issue.

I can see your point about limiting the scope for complacency. I agree this is a major source of pilot error (sources of screw-up's are the only parallel between flying and Rebreather diving in my mind - but that too is another beef).

Back on track, aren't we going the long way home here? Sounds like you're developing a complex and potentially limiting (and annoying for some) software solution to the problem of testing the capacity of your cells to respond to a full range of PO2 correctly. Why not just take a leaf from Joe's book and test your cells under pressure...on dry land - the safest and most convenient place for such checks.

Cheers

AB

Genesis

Actually, its a different side of the same issue.

I think this stuff should be published. If its not, then how do you know what the fool thing is doing?! That sucks. That won't happen here - if this thing ever becomes more than a "one off" for me, the algorythm WILL be published in the manual. I don't believe in obfuscating stuff like this.

The Parallax code is going to go up on Sourceforge soon, along with the ExpressPCB files to have the boards cut. The only reason I haven't done it yet is that I've made a couple of minor revisions to the boards and want to turn another set of them (and verify they're ok!) before I cut the code loose.

The ZX code I do not intend to publish - the ZX turns out to be so much "more machine" in terms of being a processor that this is the way I'm going to go for the actual unit I will dive, but the Parallax code serves as quite a useful demonstration and, although it is somewhat less-accurate and less-capable, may be of use to other folks.

I will likely dive the Parallax version of the code just to prove it works... all the bench testing shows that its fine, but the lack of multitasking is somewhat of an issue for me, as is the lack of floating point math. The latter, and lack of support for more than 16-bit integer math, makes the granularity of computation more coarse than I'd like.

(This is a particularly cool design because it will actually accept multiple processors from different companies - I am aware of at least three lines of product that are pin-compatable and will work - the Parallax BS2 line - multiple chips - the BX product from Netmedia and the ZX from the Zbasic folks.)

If you want to test the cells under pressure you can. If you came up with a wiring harness for them that would allow penetration of the pot wall you could actually do so and validate the controller this way....

What I'm trying to achieve with cell validation is control for one failure mode that appears to have been at least a contributor to one recent fatality. Its a relatively easy fix and doesn't get significantly in the way of using the controller - but it does force you to think about the possibility of this particular fault happening, and in some cases will prevent you from overriding it (e.g. if you have a sensor voted out at depth when you try to validate, it will refuse)

__________________
"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

LS_DK

Perhaps 0.02 is a bit aggressive. I would use a slightly higher value..
If you use 0.02, then you will probably need to filter the Cell alarms. I.e the error state needs to be stable for more than a couple of seconds before it is a real alarm. My cells are often out by 0.05. Especially during step changes in Po2 (Ascent, Decent and setpoint change) (Cold water diving in nordic waters..).. Would love to try out your warm Florida waters..

I am using 0.2, but that is mainly because I only monitor (not control) Po2 and try to follow the classic Inspiration setpoint controller.. (If I didnt the predicted deco time would fly up and down, as the voted mean Po2 point
would disagree with the Inspiration controller)


Cheers,
Kasse

Genesis

I've gone to a percentage-based computation for the ZX-based code (since it can easily do the math.)

The tolerance can be user-adjusted in the range of 1-7% off the settings menu, all plus-or-minus (so a 7% tolerance allows a difference of 1.49 to 1.71 against a 1.6 "correct" setpoint.) As PO2 falls so does the allowed error in terms of actual amount, but not in terms of percentage. The PO2 display is only 2 digits but the internal computations and storage are all floating-point single-precision numbers with FAR more resolution than is displayed.

If I don't like how that performs underwater, I'll go back to a fixed-deviation instead.....

__________________
"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

UWSojourner

Is this what you are doing Genesis?

Hypoxic Range
Any sensor is under Preference Range

Preference Range
All sensors within 0.3 - 1.4 Indicated PPO2 (example)

Hyperoxic Range
Any sensor is over Preference Range

State 1 : All sensors indicate within preference range

Allow diver set options: a) Assume high sensor is correct b) Assume middle sensor is correct c) Use average of sensors d) Use two closest sensors e) Use lowest sensor, etc.

State 2 : At least 1 sensor reads in Hyperoxic Range;
Others are in Preference Range

Set off non-critical alarm
No injection until high indicator comes into Preference Range

State 3 : At least 1 sensor reads in Hypoxic Range;
Others are in Preference Range

Set off non-critical alarm
Inject to bring low sensor into Preference Range

State 4 : At least 1 sensor reads in Hypoxic Range;
At least 1 sensor reads in Hyperoxic Range

Set off critical alarm
Vote sensor furthest from others out


In all cases,

1) Integrated DECO software uses low sensor (conservative with regard to tissue loading)

2) CNS clock uses high sensor (conservative on ox tox calcs)

Genesis

I'm distinctly uncomfortable with the scenario in State 3, for example, as IMHO the odds are that this is wrong. (It might be right, but I bet its not more often than it is)

What I've got implemented right now works like this:

Consensus defined:

1. If all three sensors are within diver-selected tolerance (percentage difference from 1-7% of each side of one another) we average all three.
2. If one sensor reads low but the other two are within tolerance of each other, we vote out the low-reading sensor and average the remaining two.
3. If one sensor reads high and is not on the rail, we vote out the two low sensors and read the high one. If the high one is on the rail, we vote it out. The reason for this decision is that this scenario appears to be most likely associated with current-limited sensors except in the case where a supply voltage leakage is occurring into a channel. Since the normal operating range of these sensors should never exceed ~150mv or thereabouts, leakage (into the 10kohm load) of quite-small current levels (as little as one milliamp) will lead to a pinned input. A pinned input is thus ignored.

I currently recognize the following alarms:

1. PO2 high - injection disabled, critical. Consensus value over 1.6
2. PO2 low - injection should have already corrected this before it got there; critical fault. Consensus value under 0.21 Unless the solenoid is locked out due to a previous fault, it has already fired, so the assumption is that something very serious is wrong (e.g. O2 supply tank empty!)
3. System fault - Displayed for either a shorted solenoid detected (excessive current draw) or communications failure (check values from the head board are out-of-range.) This is a critical fault as the system cannot operate normally with either of these conditions present.
4. Low battery. V+ is within 0.25V of loss-of-regulation. Unit has approximately 2 hours of operating time remaining with solenoid enabled under normal conditions. Warning only.
5. Injection fault. Solenoid was commanded to inject, and appeared to - but no rise was detected in the PO2 in the loop. Critical fault; likely that either the solenoid has failed, the O2 supply valve is closed, or the O2 tank is empty.
6. One Sensor Only. Only one believed-good sensor exists. This is critical and locks out the solenoid.

Faults 1, 2, 3(communications) and 6 are non-latching - they will clear if the condition goes away. 4 is non-latching as well but isn't going to go away once it appears until you change/charge the batteries. 5 can be cleared from the menus, as you might have closed the O2 valve either accidentially or intentionally for some reason. Shorted solenoid detection cannot be cleared from the menu, only by a powerdown.

Critical faults disable the solenoid so long as they are present.

For all faults except low battery, the backlight flashes and annunication occurs until acknowledged. For low battery annunciation takes place and the backlight flashes for 5 seconds, then both cease - since both require LOTS of battery power and its in short supply. In all cases there are indicators on the LCD showing composite alarm status (e.g. O2% for PO2 high or low) and a status screen can be accessed off the dive page which shows all alarm conditions that are active at that given moment in time.

There is another fault which I am not yet covering but will - watchdog reset occurred. This is most likely to happen during a low-battery event if there is some other problem with the unit (e.g. a shorted solenoid while in low battery) with the unit able to respond quickly enough to the excessive current drain to avoid tripping the on-chip brownout detector. The code can detect a restart caused by this, but currently does not.

__________________
"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

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.

For worst case senario avoidance, the only time you would be taking a chance is if 1) all senarios are bad, or 2) at least 1 sensor is reading in the hypoxic range and at least 1 is in the hyperoxic range. In this scenario, the diver should be allowed to override a sensor, but until they do, you place your bets on which sensors are right.