Ceiling/Deco obligation in recreational diving
- Thread starter nick73
- Start date
Please register or login
Welcome to ScubaBoard, the world's largest scuba diving community. Registration is not required to read the forums, but we encourage you to join. Joining has its benefits and enables you to participate in the discussions.
Benefits of registering include
- Ability to post and comment on topics and discussions.
- A Free photo gallery to share your dive photos with the world.
- You can make this box go away
Can you identify for me a recreational dive computer that implements Baker's code?
Though you can't (so you still have not refuted the point I have made, which you summarized and I quoted), I will add this:
The code you quoted is from a subroutine called CALC_DECO_CEILING. It is called from within this routine:
Code:
C===============================================================================
C SUBROUTINE CALC_START_OF_DECO_ZONE
C Purpose: This subroutine uses the Bisection Method to find the depth at
C which the leading compartment just enters the decompression zone.
C Source: "Numerical Recipes in Fortran 77", Cambridge University Press,
C 1992.
C===============================================================================
SUBROUTINE CALC_START_OF_DECO_ZONE (Starting_Depth, Rate,
* Depth_Start_of_Deco_Zone)
[some code for initialization based on metric or Imperial omitted]
C===============================================================================
C CALCULATE CURRENT DECO CEILING AND SET FIRST DECO STOP. CHECK TO MAKE
C SURE THAT SELECTED STEP SIZE WILL NOT ROUND UP FIRST STOP TO A DEPTH THAT
C IS BELOW THE DECO ZONE.
C===============================================================================
CALL CALC_DECO_CEILING (Deco_Ceiling_Depth) !subroutine
[more code for boundary condition error checking omitted]
C===============================================================================
C PERFORM A SEPARATE "PROJECTED ASCENT" OUTSIDE OF THE MAIN PROGRAM TO MAKE
C SURE THAT AN INCREASE IN GAS LOADINGS DURING ASCENT TO THE FIRST STOP WILL
C NOT CAUSE A VIOLATION OF THE DECO CEILING. IF SO, ADJUST THE FIRST STOP
C DEEPER BASED ON STEP SIZE UNTIL A SAFE ASCENT CAN BE MADE.
C Note: this situation is a possibility when ascending from extremely deep
C dives or due to an unusual gas mix selection.
C CHECK AGAIN TO MAKE SURE THAT ADJUSTED FIRST STOP WILL NOT BE BELOW THE
C DECO ZONE.
C===============================================================================
CALL PROJECTED_ASCENT (Starting_Depth, Rate,
* Deco_Stop_Depth, Step_Size)As you can see, CALC_START_OF_DECO_ZONE does factor in ascent rate.
It does so by calling PROJECTED_ASCENT (uses ascent rate) right after it calls CALC_DECO_CEILING (does not use ascent rate). Whereupon it will revise the ceiling downward, if necessary.
Thus, you can have no deco (i.e. still an NDL dive) and then then your ascent rate can result in a mandatory deco stop being imposed, even though you began your ascent with NDL > 0.
Notice that even his comments reflect the observation that an increase in gas loadings during ascent can result in a deeper first stop than was calculated in CALC_DECO_CEILING. It should be obvious that by "increase in gas loadings", he really means a higher tissue overpressurization than what CALC_DECO_CEILING was expecting. And, it should also be obvious that, since he was coding for an ascent rate that is fixed, then the tissue overpressurization to check for could come from a slow ascent resulting in more on-gassing than expected, or it could come from a fast ascent resulting in less off-gassing than expected. Either way, you could arrive at the ceiling that CALC_DECO_CEILING calculated with a greater tissue overpressurization than it was expecting.
Suunto's behavior is based on a different model which yields the same conclusion: Ascend too fast from an NDL dive and you can get a mandatory deco stop.
The discussion we've been having has been based on a different model - the Buhlmann/Baker model. It does its calculations in a different way to arrive at the same conclusion.
In other words, neither is based on NDL. Both are based on violating the constraints that are programmed into the computer. The Suunto looks at critical bubble radius (I think). A Buhlmann/GF computer looks at tissue pressure vs M-value. They both expect a certain ascent rate and the NDL is shown based on doing that ascent and getting to the surface without violating the "conservatism settings". They both could impose a mandatory deco stop if the ascent rate is faster than the computer wants, because the quick ascent doesn't allow enough off-gassing to happen before getting to the surface, resulting in a violation of that computer's model for safety - whether it's violating the critical bubble radius or the tissue over-pressurization.
Ok. I admit much of this is over my head but you are stating that if I am within x of NDL on my Shearwater set for Buhlmann and I have an emergency and ascend faster then recommended it will show me a ceiling beyond the safety stop?
Is this fact or theory?
Is this fact or theory?
Which is the opposite case to the one with the 1mm ceiling I quoted above. So his projection is to increase the depth of the ceiling not reduce it. That is why I expressed what I thought your position was in the previous post, as your quoting the code does not support it.
This code says 1 - can I move instantly to the surface? No - then this is a dive with stops. 2 - if I move at 10m/minute to the surface do I get a DEEPER stop (the OP's concern)?
What it does not do is say - can I move at 10m/minute to the surface?
My GF implementation doesn't bother with checking whether the ceiling gets deeper than the stop. I have never had it happen. Maybe I should add code to test and try some extreme depths with high GF lo to find when it could. I do calculate stops based on either the current or projected ceiling accounting for the off gassing. That makes a small difference but then fails to match my check profiles. It is an implementation choice but costs.
I certainly have not personally tested it. You could test it pretty easily, though. Take your Petrel/Perdix down for a dive. Stay down until NDL=1. Attach your Petrel/Perdix to an SMB and send it to the surface. When you arrive a few minutes later, it will either show a missed deco stop or it won't. I think. I've never omitted deco, so I don't know for sure exactly how my Perdix would behave in that situation.
I can't find it now and I could be totally misremembering. But, I SEEM to recall a thread here in the last year-ish where there was confirmation posted that a Petrel/Perdix will not display deco stops that it calculates will be satisfied before your ascent actually gets you to that depth. I *think* that confirmation was from someone at Shearwater. I had a quick look but could not find it. If that could be found, it certainly seems like confirmation that a fast ascent could cause a deco stop to be displayed that wasn't otherwise shown.
As another point of information, I ran a plan using Subsurface. 110' for 25 minutes, using EAN32. GF100/100 (i.e. pure Buhlmann ZHL-16C). (Side note: Interesting that the NOAA EAN32 table gives 30 minutes NDL at 110')
With a 30ft/min ascent rate setting, this is an NDL dive. Subsurface gives no deco stops.
If I only change the ascent rate setting to 60 ft/min, the plan changes to require a 1 minute stop at 10'.
With my normal settings of GF50/80, it's a 17 minute NDL dive (and 30ft/min ascent). 60 ft/min ascent gives a 1 minute stop at 10'.
Also notice that the fast ascent does actually get you out of the water quicker even with a stop. 28 minutes for GF100/100 versus 29 minutes with a slower ascent. 21 minutes with GF50/80 and a slow ascent versus 20 minutes with a fast ascent.
But, doing a fast ascent still turns an NDL dive into a dive with a mandatory deco stop.
So, if the first subroutine returns a ceiling of 0 and then a subsequent check, using the ascent rate, requires it, you could get a ceiling of (for example) 10'. Yes?
In other words, as I have been saying from the beginning, your deco stops are dependent on the ascent rate that is used by the dive computer. And, if you ascend more quickly than the computer wants, your first deco stop could be moved deeper than what the computer is showing at the start of the ascent. Thus, it could move from a "ceiling" of 0 feet to a ceiling of 10 feet, as the result of a too-fast ascent.
Last edited:
Subsurface looks forwards for GF. If you read the author's blog he mentions that. All part of the game of having no proper spec.
The code can look forward for two reasons. One to allow longer at depth because you will have off gassed by the time you get there, the other deepen the ceiling because you may on gas more. I am saying a dive computer ought not to do the first as it 1) increases the risk during a fast ascent 2) is expensive computationally 3) makes no odds really, as when the actual ascent happens the actual gas loading will drive the stops. That is the 1mm ceiling argument. The second I don't think makes a difference in the kind of dives the OP is talking about and is also computationally expensive unless fudged. The fudge would be easy and cheap but loose points with those who choose dive computers by the NDL times.
Can you tell if a Perdix missed a stop? Mine just goes red and moody, then I go deeper again. It isn't obvious later when this happened.
If a diver surface so fast as to outrun their computer, they will have other problems than an extra minute of stops and it is likely to be time to be cracking open the o2. That Is the point of no stop diving, to reduce the chances of getting bent.
So, now you're talking about what a dive computer "ought" to do? That's fine, but I have been talking about what current computers actually do. And responding to the question the OP asked. Namely, could he have had a ceiling, even though his dive computer did not show him being in deco. I believe I have provided ample information to support saying that the answer to his question is Yes. If you want to talk about what a computer "ought" to do, have at it, but I am out.
As for "outrunning" a computer, who is talking about that? Or, what do you mean? I would interpret "outrunning their computer" to mean that you ascended faster than the computer can recalculate and tell you what to do. Kind of like when you make a wrong turn and your GPS starts recalculating and you turn again before your GPS can even finish recalculating and tell you what to do.
If a diver is simply ascending faster than what his computer is programmed to expect, but not "outrunning" (per my explanation just given), then they should NOT have any other problem than stops (or extra stops) that they have to do - as long as they actually DO the stops that are called for.
That said, I note that your statement suggests that you believe that ascending too fast from an NDL dive could get you bent. This seems to be at odds with your arguments that have all seemed to be trying to make the point that if your are still within your NDL you don't have a ceiling, so you can always go straight to the surface, and your ascent rate doesn't affect that. You even quoted Fortran code to try and make the point that ascent rate has no bearing on whether you are within NDL or not.
So, which one are you saying? If you are within your NDL, you don't have a ceiling, so you can go straight to the surface, as fast as you want? I mean, you have tried to make the point several times that your NDL is not at all calculated based on ascent rate.
Or are you saying that, even if you're within your NDL, you could have a ceiling, which you COULD break if you ascend too fast (thus having a significant increase in chance of DCS)?
Bob DBF
Contributor
My take is that you jumped out of the normal parameters of the algorithm and it can't determine if you are in or out of NDL until you follow its instructions. Since it cannot determine the Deco status it will not give a deco violation but will give an ascent violation. You may very well have a greater chance of DCS, but it is beyond the ability of the computer to quantify it.
There is research that fast ascents increase the likelihood of DCS however, unfortunately there is no meangingful way yet to adjust the tables or dive algorithms according to ascent rate so a computer can only warn of ascent violations and hope the diver stays within computer limits.
Bob
You can get bent doing any ascent from any dive.
Doing a faster ascent (than the computer is set for) will increase the chances of getting bent.
The computer should give the diver a reasonable chance of avoiding getting bent. Telling him he can stay down with a ceiling on the basis it will be gone if he ascents at 10m/minute is not helpful if he messes up and ascents at 30m/minute. It is a forseable circumstance.
I offer the evidence that the SB favourite algorithm in it's raw form gives the ceiling regardless of the ascent rate. If your saturation at depth is too high to surface you have a ceiling and are past the no stop limit. When you get there, moving slowly, it may be gone. People often comment that the stops vanish as they ascend.
You seem to talk like the computer is somehow involved in any of this. It is simply the guide, based on crude modelling.
Fast ascents are bad beyond the dissolved gas models. Yo yo diving is bad. Would you do 6 CBL ascents in one dive? A dissolved gas model doesn't care. Good diving practice goes beyond the computer saying yes or no.
My opinion isn't the computer will not add a stop in the circumstances put forward by the OP., because the gas saturation was not exceeded. However, if ascending quickly he ought to do some stops and go on O2 asap. 99.something % of the time he will be fine not to but for the rest the O2 will be a help.
That is what we do. Screw up an SMB deployment from a 15m drift with 10m of NDL left? On to O2, TLC and observation.
Doing a faster ascent (than the computer is set for) will increase the chances of getting bent.
The computer should give the diver a reasonable chance of avoiding getting bent. Telling him he can stay down with a ceiling on the basis it will be gone if he ascents at 10m/minute is not helpful if he messes up and ascents at 30m/minute. It is a forseable circumstance.
I offer the evidence that the SB favourite algorithm in it's raw form gives the ceiling regardless of the ascent rate. If your saturation at depth is too high to surface you have a ceiling and are past the no stop limit. When you get there, moving slowly, it may be gone. People often comment that the stops vanish as they ascend.
You seem to talk like the computer is somehow involved in any of this. It is simply the guide, based on crude modelling.
Fast ascents are bad beyond the dissolved gas models. Yo yo diving is bad. Would you do 6 CBL ascents in one dive? A dissolved gas model doesn't care. Good diving practice goes beyond the computer saying yes or no.
My opinion isn't the computer will not add a stop in the circumstances put forward by the OP., because the gas saturation was not exceeded. However, if ascending quickly he ought to do some stops and go on O2 asap. 99.something % of the time he will be fine not to but for the rest the O2 will be a help.
That is what we do. Screw up an SMB deployment from a 15m drift with 10m of NDL left? On to O2, TLC and observation.
Similar threads
