O2 sensor voting strategies

[shapeshifter]

Looking for details on O2 sensor voting strategies.

I've heard that the actual implementations are scary simple, but it seems like there's scope for a fair bit of theory.

[nigel hewitt]

Nearest two vote out the outlier then you use the midpoint of them.
If anything deviates more than a certain amount make a fuss so the user knows about it.
That's how it was with autopilots when I worked on them and they probably spent piles of money deciding on that.

Actually I think I have an Inspiration log of dive from back in the bad days of the sensor problems where first one sensor drifted off and was ignored and then a second one followed it and the system moved to them.
It was never more than a few decimals but I knew which was the new style sensor I had jut fitted so I was watching it but they were all reading a mix I was prepared to breath so I continued the dive.

[shapeshifter]

Are implementations really as simple minded as take the average of all readings, good bad or unknown, and eliminate anything too far from that" ? No markov chains or fuzzy logic?

I'll certainly bow to experience on this, but has anything more subtle ever been tried, or are we just doing it that way because we've always done it that way and not too many people have died?

Nearest two vote out the outlier then you use the midpoint of them.
If anything deviates more than a certain amount make a fuss so the user knows about it.
That's how it was with autopilots when I worked on them and they probably spent piles of money deciding on that.

Actually I think I have an Inspiration log of dive from back in the bad days of the sensor problems where first one sensor drifted off and was ignored and then a second one followed it and the system moved to them.
It was never more than a few decimals but I knew which was the new style sensor I had jut fuitted so I was watching it but they were all reading a mix I was prepared to breath so I continued the dive.

[NWdiver]

They don't take the average of all and discount any that are too far out...
They ALWAYS discount one cell. Then take the average of the closest two.

Voting logic and the human factors behind it are certainly not my area of expertise. Fuzzy Markovs mean little to me!

However, I would suspect that by trying to make the logic smarter (and probably more complex) you're increasing the risk that the user fucks something up or misunderstands the information he's being given.


Many would argue for a mCCR without any voting logic as it (arguably) increases awareness of the cell readings.

The average of two and alert if the third creeps away from that average is a compromise which for the most part works. When it doesn't it's usually realtively easy to notice and correct with the information displayed to you. I'd be concerned taht more complex logic might increase the percentage of time where it looks after itself but then makes correcting any issues much harder.

Edit: I believe the Poseidon uses just 2 cells?? So there must be another method in place there.

[Swifty]

They don't take the average of all and discount any that are too far out...
They ALWAYS discount one cell. Then take the average of the closest two.

Voting logic and the human factors behind it are certainly not my area of expertise. Fuzzy Markovs mean little to me!

However, I would suspect that by trying to make the logic smarter (and probably more complex) you're increasing the risk that the user fucks something up or misunderstands the information he's being given.


Many would argue for a mCCR without any voting logic as it (arguably) increases awareness of the cell readings.

The average of two and alert if the third creeps away from that average is a compromise which for the most part works. When it doesn't it's usually realtively easy to notice and correct with the information displayed to you. I'd be concerned taht more complex logic might increase the percentage of time where it looks after itself but then makes correcting any issues much harder.

Edit: I believe the Poseidon uses just 2 cells?? So there must be another method in place there.

From the Poseidon user manual
"The first truly auto-calibrating and auto-validating rebreather. The MkVI uses a patented automated method to verify that the oxygen sensors are working properly at all times – both before and during a dive"

From a very quick skim of the "A New Approach to Closed☺Circuit Rebreather Gas Monitoring: Why Two Oxygen Sensors can be Better than Three white paper." They inject a know gas over the cell faces and checks that it registers the correct PPO2.

[shapeshifter]

Are you *sure* about that algorithm ? I mean, it certainly could work that way but, in the (common enough) failure mode where two cells have faulty connections giving two zero readings and one good, wouldn't that result in throwing out the good reading and permanently injecting oxygen irrespective of the depth?

They don't take the average of all and discount any that are too far out...
They ALWAYS discount one cell. Then take the average of the closest two.

Voting logic and the human factors behind it are certainly not my area of expertise. Fuzzy Markovs mean little to me!

However, I would suspect that by trying to make the logic smarter (and probably more complex) you're increasing the risk that the user fucks something up or misunderstands the information he's being given.


Many would argue for a mCCR without any voting logic as it (arguably) increases awareness of the cell readings.

The average of two and alert if the third creeps away from that average is a compromise which for the most part works. When it doesn't it's usually realtively easy to notice and correct with the information displayed to you. I'd be concerned taht more complex logic might increase the percentage of time where it looks after itself but then makes correcting any issues much harder.

Edit: I believe the Poseidon uses just 2 cells?? So there must be another method in place there.

[NWdiver]

Are you *sure* about that algorithm ? I mean, it certainly could work that way but, in the (common enough) failure mode where two cells have faulty connections giving two zero readings and one good, wouldn't that result in throwing out the good reading and permanently injecting oxygen irrespective of the depth?

Yes.

Possibly, although I've never heard of anyone getting two 0mv readings. It might recognise that as an issue...

It certainly would happen though if two cells (maybe of the same age / batch) fail / become current limited at the same time. The solenoid will continue to inject oxygen into the loop and the "good" cell would continue to be ignored.

This is something that should be relatively easy to spot and then resolve.

If you're solenoid is continually firing and your cell readings are 1.45 / 1.28 / 1.26 (cell one would be increasing whilst cells 2/3 hold steady). Switching to low set point stops the solenoid and a dill flush will show that cell 1 comes down, "meets 2 & 3" just below 1.3 and then they all fall together. By doing that, you diagnose cells 2/3 as faulty and can act accordingly.


I don't think there's an ideal system yet. But simple logic makes it easy to deal with when said logic shits the bed.

[shapeshifter]

Ok. Your position is well defended and duly noted.

However. It seems to me that some failure modes are really very easy detect (a sensor reading zero when less than a second before it was at 1.4 has surely failed and can be ignored) and some can be detected with a lesser or greater degree of confidence (a cell known to be old reading lower than the others is likely current limited, a cell who's reading doesn't change after injecting oxygen is likely covered in humidity. In both cases, the reading can be treated with caution).

Is a more subtle voting strategy an inherently bad thing? The diver can switch to manual or bail out just as easily as he can with a simpler algorithm.

Yes.

and yes, it would. This also happens if two cells (maybe of the same age / batch) fail / become current limited at the same time. The solenoid will continue to inject oxygen into the loop and the "good" cell would continue to be ignored.

This is something that should be relatively easy to spot and then resolve.

If you're solenoid is continually firing and your cell readings are 1.45 / 1.28 / 1.26 (cell one would be increasing whilst cells 2/3 hold steady). Switching to low set point stops the solenoid and a dill flush will show that cell 1 comes down, "meets 2 & 3" just below 1.3 and then they all fall together.


I don't think there's an ideal system yet. But simple logic makes it easy to deal with when said logic shits the bed.

[NWdiver]

You clearly know more than me about the subject of voting logic so I'm open to listening. I'll see what happens if I unplug two cells on the surface.

But for me... throughout the dive, I'm making decisions and part of my mind is thinking about what those decisions will do to my PO2 and in turn, my rebreather.

By using a system which is simple (albeit flawed in some cases), I can work through it in my head. I know what it will do. I know what it will think my PO2 is. I know the cell it will disregard and I know when the solenoid will fire. Because I know those things, I can spot when something unexpected happens.

For me the key driver is not to have a system that works 100% of the time. It's to have a system that gives me the best chance of surviving. The more complicated the voting logic is, the less I understand it. It's not the 99% of dives I worry about, it's the 1% where the issues crop up.

With the many permutations of out voting cells in your idea, how do I know what has happened? Why has that cell been ignored? Is it clear to me which cells are now running the unit? Confusion in the time I need it least.

[shapeshifter]

What I'm imagining is a system where all cells are displayed along with a confidence rating, anything from "ignoring, presumed broken" to "total confidence even if the other cells disagree" and a fourth, effective, value derived from the cells and actually used to calculate deco and fire the solenoid. The diver can override the computer's opinion of any cell at any time. The clever bits of how the computer assigns confidence are almost secondary.

Is that a stupid idea? Or perhaps how controller already all work anyway?

The reason I ask all this is because so many people have asked me about adding o2 monitoring to my computer and whilst the math seems simple enough I don't really have the concrete experience required to make some of the usability value calls.

You clearly know more than me about the subject of voting logic so I'm open to listening. I'll see what happens if I unplug two cells on the surface.

But for me... throughout the dive, I'm making decisions and part of my mind is thinking about what those decisions will do to my PO2 and in turn, my rebreather.

By using a system which is simple (albeit flawed in some cases), I can work through it in my head. I know what it will do. I know what it will think my PO2 is. I know the cell it will disregard and I know when the solenoid will fire. Because I know those things, I can spot when something unexpected happens.

For me the key driver is not to have a system that works 100% of the time. It's to have a system that gives me the best chance of surviving. The more complicated the voting logic is, the less I understand it. It's not the 99% of dives I worry about, it's the 1% where the issues crop up.

With the many permutations of out voting cells in your idea, how do I know what has happened? Why has that cell been ignored? Is it clear to me which cells are now running the unit? Confusion in the time I need it least.