Split sensors or not (rEvo, 5 cells)?

[Wibble]

If my controller dies, I want my ascent plan (from my NERD) to be based on live cell monitoring that includes voting logic. I.e. not just based on 2 cells.

Pardon my asking, I'm not sure what you mean by this. The Nerd (in standard Revo config) is a backup device and doesn't connect to the solenoid. Thus there's no voting logic which is only applicable to a controller?

Another (subtle) point about using a splitter is the Nerd will display three cells/PPO2 readings. The stock config shows two cells. IMHO, as a result of having two readings only on the Nerd, it 'forces' me to periodically validate the three cells/PPO2 readings on the Petrel controller. If there's three readings on the Nerd, there's less impetus to compare with the Petrel.

This, plus full monitoring redundancy, was the reason I rejected the idea of using a splitter (also the 'third' cell position can be used for the mini AI pressure values).

"Extreme" diving aside, the general principle of one major failure applies. Should the controller fail during a dive, that's an abort condition as you've effectively lost your monitoring should you need to bail out (it's not easy to read the Nerd when on bailout -- need to unclip the Nerd from the loop and hold it in front of your eye to read it). One reason why some people dive with a third computer on their wrist, as a backup to the Petrel to run a bailout.

 

[stuartv]

Pardon my asking, I'm not sure what you mean by this. The Nerd (in standard Revo config) is a backup device and doesn't connect to the solenoid. Thus there's no voting logic which is only applicable to a controller?

Another (subtle) point about using a splitter is the Nerd will display three cells/PPO2 readings. The stock config shows two cells. IMHO, as a result of having two readings only on the Nerd, it 'forces' me to periodically validate the three cells/PPO2 readings on the Petrel controller. If there's three readings on the Nerd, there's less impetus to compare with the Petrel.

This, plus full monitoring redundancy, was the reason I rejected the idea of using a splitter (also the 'third' cell position can be used for the mini AI pressure values).

"Extreme" diving aside, the general principle of one major failure applies. Should the controller fail during a dive, that's an abort condition as you've effectively lost your monitoring should you need to bail out (it's not easy to read the Nerd when on bailout -- need to unclip the Nerd from the loop and hold it in front of your eye to read it). One reason why some people dive with a third computer on their wrist, as a backup to the Petrel to run a bailout.

I think that is not correct. Even though it's a monitor, not a controller, it still calculates your deco obligation based on what it understands you to be breathing. If one of the O2 sensors is reading 3.0 and the other 2 are reading 1.3, it's going to vote out the one that says 3.0 and calculate your deco based on being at 1.3.

Also, if I have 3 cells shown on the NERD (monitor) and they are all good, then why do I need to look at the controller? What problem could be happening on the controller that won't soon be reflected in the ppO2 readings I'm seeing on the NERD?

Don't get me wrong. I'm not advocating a 3-cell NERD and never looking at your controller. I'm just asking the question: If my NERD is monitoring 3 cells, what do you envision that could ever go wrong on the controller that I wouldn't know about (possibly with a short delay - the same delay I might experience in between times that I was looking at the controller anyway) by watching the NERD? The thing that prompts me to actually look at my controller is to check what the rMS is telling me. Confirming the ppO2 readings is secondary.

Lastly, I'm not clear on what point you were trying to make in your last paragraph. If the one major failure principle applies, then you would not be planning for your controller to fail AND something happens to your loop that requires you to bail. You mention the one failure principle and then immediately go on to "if my controller fails and I also over breathe my loop or have breakthrough or flood my loop or tear a loop hose" or something like that. I would call that 2 major failures. So, like I said, I'm not really sure where you were trying to go with that whole paragraph.

On a serious technical dive, I would dive with controller, NERD2, and Teric, with the Teric being along primarily for the extremely unlikely case that I flood my unit and the flood somehow lets the water in there short circuit wires that are connected to my controller and take it out. I feel like it is EXTREMELY unlikely that a flood in the unit could kill the controller. I think the rEvo design is simply better than that. But, it's water and electricity, so.... Slapping a Teric on my wrist to use, so I don't have to do as your described with looking at my NERD after bailing, doesn't seem too onerous (or risky).

 

[stuartv]

Pardon my asking, I'm not sure what you mean by this. The Nerd (in standard Revo config) is a backup device and doesn't connect to the solenoid. Thus there's no voting logic which is only applicable to a controller?

Another (subtle) point about using a splitter is the Nerd will display three cells/PPO2 readings. The stock config shows two cells. IMHO, as a result of having two readings only on the Nerd, it 'forces' me to periodically validate the three cells/PPO2 readings on the Petrel controller. If there's three readings on the Nerd, there's less impetus to compare with the Petrel.

This, plus full monitoring redundancy, was the reason I rejected the idea of using a splitter (also the 'third' cell position can be used for the mini AI pressure values).

"Extreme" diving aside, the general principle of one major failure applies. Should the controller fail during a dive, that's an abort condition as you've effectively lost your monitoring should you need to bail out (it's not easy to read the Nerd when on bailout -- need to unclip the Nerd from the loop and hold it in front of your eye to read it). One reason why some people dive with a third computer on their wrist, as a backup to the Petrel to run a bailout.

Further, if your controller dies and your NERD is only reading 2 sensors, what happens if one sensor is reading 3.0 and the other is 1.3? I mean, you can do a dil flush to figure out which one is correct, hopefully. But, what ppO2 value is the NERD going to use to calculate your ascent? Will you trust what it’s telling you? What if it just averages the 2, so it’s giving you deco stops based on being at a ppO2 of 2.1 when you really are actually at 1.3?

 

[Wibble]

I think that is not correct. Even though it's a monitor, not a controller, it still calculates your deco obligation based on what it understands you to be breathing. If one of the O2 sensors is reading 3.0 and the other 2 are reading 1.3, it's going to vote out the one that says 3.0 and calculate your deco based on being at 1.3.

Good point about the PPO2 value used by the 'standalone' backup being used to calculate deco obligations.

Regarding checking the controller periodically, it's to ensure that it's not running incorrect values which could mean the solenoid's fired. It is more a general principle of knowing what's going on with your kit as you dive.

The 'one failure' planning principle's a bit loose! You're absolutely right that my example was showing two failures -- the controller and needing to bail out. On a deeper dive, say 75m/230ft plus, even if you've turned the dive you've still got hours on deco, so maybe "plan for one failure" is too simplistic. On that sort of dive you want to say on the loop as long as you can, thus you're looking out for a second failure and having three cells monitored would mean more information to base your decisions upon. Under the 'one failure' principle, two cells would be enough.

My reasoning for not splitting was simply not 'joining' two independent systems to effectively become one system. Literally accepting Paul Raemaker's arguments.

(This thread is really useful to be able to think through these scenarios when not diving)

 

[rjack321]

On a deeper dive, say 75m/230ft plus, even if you've turned the dive you've still got hours on deco, so maybe "plan for one failure" is too simplistic. On that sort of dive you want to say on the loop as long as you can, thus you're looking out for a second failure and having three cells monitored would mean more information to base your decisions upon.

At 75m+ with a major failure, bail out. You'll have a shorter TTS and not run the risk of something else sneaking up and killing you. The number of divers staying on the loop as long as possible and dying is actually quite high compared to the number of fatalities due to a BO ascent.

 

[beldridg]

Further, if your controller dies and your NERD is only reading 2 sensors, what happens if one sensor is reading 3.0 and the other is 1.3? I mean, you can do a dil flush to figure out which one is correct, hopefully. But, what ppO2 value is the NERD going to use to calculate your ascent? Will you trust what it’s telling you? What if it just averages the 2, so it’s giving you deco stops based on being at a ppO2 of 2.1 when you really are actually at 1.3?

I replied somewhere else about this recently as I have two cells connected to my NERD2 and had one of them fail on a dive and I noticed my deco obligation rising quickly.

Essentially, in this case, the Shearwater will use the lower PO2 for deco obligation and the higher PO2 for CNS calculations. It will not average them if there are only two and they aren't within acceptable tolerances of each other.

- brett

 

[beldridg]

I'm not clear on what you're saying here about keeping the NERD1. Are you saying that if your controller totally died on Day 1, you would dive the rest of the trip with 2 NERDs on your rEvo?

Yes with both monitoring cells.

And that is so that you will be prepared in case your Petrel dies and then your NERD2 ALSO dies on the same trip?

And you want to be diving with 2 NERDs (presuming your Petrel is dead) so that if the NERD2 dies, the NERD1 will be there giving you an ascent plan based on live monitoring?

Yes. Under "normal" dive conditions, I like to always have two computers calculating deco obligation based on actual PO2 of the cells.

To give an example, if I was in Bikini and my Petrel controller died on dive 1, I wouldn't want to do the rest of the trip with only the NERD2 monitoring cells. Would I still dive? Yes. I would also have my off board Teric.

My logic was partially based on the fact that I replaced my NERD with a NERD2 and had two choices for what to do with the original NERD: keep it or try to sell it.

I think for your expedition planning, I would be satisfied to be starting my diving with a working controller, NERD2, and a Teric running on a fixed setpoint. If the Petrel died, then continue my remaining dives with just the NERD2 and Teric, flying it manually. If the NERD2 then died, get out using the Teric, unplug the NERD2, plug the NERD1 into that cable, and keep diving with it and the Teric.

Perfectly sound logic. I just like the ability to dive with two computers monitoring PO2. On a long trip in a remote location with some reasonably long deco times, I don't like the idea of doing all those dives with only one computer. Would I do it? Yes, absolutely. But, the "cost" of adding another analog cable to the unit is almost zero.

I would also really think about taking a day off if my controller AND my NERD2 died in the same week. If for no other reason that, as soon as you add an unused computer to your mix (e.g. the NERD1), it does not have your tissue loading info in it, so you couldn't really rely on it for deco calculations anyway. But, really, if you have 2 Shearwater computers die on your in the same week, that might be the Universe telling you to take a break and think about what you're doing.

I would not add a second 4-pin cable to my unit, so that I could dive with 2 NERDs at the same time.

I totally get that and I think most people would take the same approach and I don't think there is anything wrong with that.

But, to me, the cost of adding the additional cable was essentially zero and -- most importantly -- I already had the "spare" NERD computer.

If you are in that situation and you bring along the NERD and your Petrel controller does fail, there isn't anything you can do with that extra computer (except use it as a standalone computer similar to a Teric with an internal setpoint).

- brett

 

[stuartv]

At 75m+ with a major failure, bail out. You'll have a shorter TTS and not run the risk of something else sneaking up and killing you. The number of divers staying on the loop as long as possible and dying is actually quite high compared to the number of fatalities due to a BO ascent.

How would you have a shorter TTS on BO?

 

[Wibble]

How would you have a shorter TTS on BO?

Assume 15/55, 50%, 80% bailouts. Once switched to 50% at 21m, there’s no helium in the mix (aside from your off gassing). On CCR the diluent contains helium and slows down helium off gassing, extending your TTS.

Run some sample dives in MultiDeco and play with switching to 'air' dil at various depths which has a big effect on TTS. Loads of other issues arise as a result (IBCD, CNS, complexity...), but the TTS is interesting.

 

[lermontov]

Assume 15/55, 50%, 80% bailouts. Once switched to 50% at 21m, there’s no helium in the mix (aside from your off gassing). On CCR the diluent contains helium and slows down helium off gassing, extending your TTS.

Run some sample dives in MultiDeco and play with switching to 'air' dil at various depths which has a big effect on TTS. Loads of other issues arise as a result (IBCD, CNS, complexity...), but the TTS is interesting.

Im not following you ? if you spent 15 min at 75m and Sp of 1.2 then your RT is 63min - If you BO after 15 min with those gasses its 61MIN - its insignificant