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 (https://zenodo.org/record/17661/files/MK6_White_Paper_v2.pdf)." 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.

[NWdiver]

Cell 1 (Confidence = 90%)
Cell 2 (Confidence = 5%)
Cell 2 (Confidence = 5%)

Leaving alone the debate about how you come to those confidence values, human nature will go with cell 1 everytime. They'll ignore anything with a low % and not give it a moments thought. The user see's 90% and goes with it. They don't read "you die 1 in 10 times".

If all three cell values are displayed then all the confidence rating is doing is distracting you from the correct diagnosis. The system has done it's job by this point. It's alerted you to a discrepency and you're now looking at the cell values. Those three PO2 values are all you need to diagnose, correct the issue and get out.

The voting logic does it's job when all is working well. When it's not, you don't want a computer deciding whether you live or die. The user needs to step in.

[Vanny]

No keep the assessment of the cells health in the hands of the diver. From an AP inspo point of view , I can’t speak for other units , all cell readings are displayed. From monitoring those values the diver can see which cells are being used for voting logic , this could be changing throughout the dive. Ccr Diving skills equip the diver with the ability to interrogate those cell readings to assess cell health. Keep the diver in charge of the unit and voting logic simple to interrogate.

[shapeshifter]

Definitely not arguing, just looking for clarification here. You guys reckon it would be a bad idea to have a little indicator next to each cell reading showing "probably broken; ignoring", "seems reasonable, but trusting the others", "trusting this one" (so basically just providing some extra info about the computer's reasoning) with the option to immediately override any and all of these?

[NWdiver]

If the computer trusts it, I trust it.... human laziness

The only way to know if you should be trusting a cell is to check them youself. You'd have to be doing that anyway. So what does the extra infomation add?

There is currently only one reason that a CCR ignores (and it always does ignore) one cell. It doesn't need explanation to the user and it almost never requires overiding. If it does, the SP can be changed, or the unit can be manually controlled in various ways.

I'm sure things can be improved. But making the voting logic enough to keep trying to work through failures worries me. The logic is not the weak link. The vulnerable component is the cell.

If the overall aim of this is to improve the consistency and accuracy of po2 measurement then I think you're looking in the wrong place

[shapeshifter]

Where should I be looking? At the end of the day, I just get cell readings work out a ppo2, derive ppHe and ppN2, update the tissue loading and possibly also tell the solenoid to fire.


If the overall aim of this is to improve the consistency and accuracy of po2 measurement then I think you're looking in the wrong place

[NWdiver]

The voting logic is there to compensate for the fact that the cells aren't 100% reliable.

Fix that and you'll be sorted... :nod:

[M-J-J]

The voting logic is there to compensate for the fact that the cells aren't 100% reliable.

Fix that and you'll be sorted... :nod:

Solid state cells! Where are we with them? Haha

[diverjoe]

You can get solid state cells now a bit expensive as you have to get the computer to read them plus a C-POD and cable (https://www.poseidon-uk.co.uk/webshop/computer-and-accessories/cpod-incl-solid-state-sensor-and-cable/) the M28 computer is about £1300

[NWdiver]

Remind me in 15 years when they've worked out the kinks

[diverjoe]

If your on Facebook have a look here https://www.facebook.com/BSACtec/videos/563590297367081/

[NWdiver]

A video of some BSAC bods on a jolly talking to a salesman?... I think this thread is about to get interesting

[rossh]

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.


Back in the days when the X1 and X-Link where available, our code was more complex than simple averaging. The usual problem is a cell that under reads, and often we could see in the dive records a lazy cell that slowly drifted lower than it other two, and finish up some distance apart at the end of the dive. So the code needed to aware of these two typical conditions, and not have any lazy signals dragging the displayed average lower. More importantly, when the system decides to drop out a cell, it should not cause a jump in the displayed value. It takes different logic to handle a dropped cell condition. As well it has to deal with spotty or sensor data on loose wire connections and do its best to see through the noise.

So we have some clever formula to address all that.

[Moleshome]

If your on Facebook have a look here https://www.facebook.com/BSACtec/videos/563590297367081/

Is that the Richard Pyle of Pyle Stops fame?

[diverjoe]

Yes its Richard Pyle and no he's not a salesman he's a test diver and fish collector who often dives a Poseidon se7en to 150mts

[shapeshifter]

Thank you, that's very interesting.

It seems to me that some failure modes should be detectable by analysing a sensor signal in total isolation (lock low, lock high or stuttering), some should be detectable within the context of the machine's closed loop transfer function (a sensor that doesn't read higher after oxygen injection is likely current limited or covered with humidity) and others only within the context of the other cell readings ("lazy cells" as you describe them).

Did your software perform these types of analyses?


Back in the days when the X1 and X-Link where available, our code was more complex than simple averaging. The usual problem is a cell that under reads, and often we could see in the dive records a lazy cell that slowly drifted lower than it other two, and finish up some distance apart at the end of the dive. So the code needed to aware of these two typical conditions, and not have any lazy signals dragging the displayed average lower. More importantly, when the system decides to drop out a cell, it should not cause a jump in the displayed value. It takes different logic to handle a dropped cell condition. As well it has to deal with spotty or sensor data on loose wire connections and do its best to see through the noise.

So we have some clever formula to address all that.