deco calculations

[Jan Schubert]

On 01/04/13 22:38, Jan Schubert wrote:
> On 01/04/13 07:06, Dirk Hohndel wrote:
>> Jan, don't get your hopes up - it's OC only at this point. CC is on my
>> list, but not there, yet.
> Shouldn't be that tricky to switch to CC, in fact it should make life
> even easier as the pO2 is constant - OK not really flat on computer with
> integrated cell readings.

Played around with it and checking the source it seems CC is already
supported in most current git!?

>
>> I have some issues with this (as noted in the commit messages). My
>> biggest concern is that apparently changing the GFlow and GFhigh values
>> has no impact on the deco curve whatsoever. And that is a huge red flag
>> to me...
> In my dives overlay using mot current subsurface I can see clearly
> differences when changing GF settings but only in the calculated deco
> depth, not the duration!

I've checked several definitions and calculations and could also not
find any real bug so far (beside some minor variations in helium
halftimes for slower compartments compared to the data I had so far).

My best explanation for the similar deco calculations when changing GF
setting is, that we do not plan a new/virgin dive but rely on given dive
samples. This means that in theorie increasing GF High would speed up
and shorten (calculated) decompression but in real life we still stay at
certain depths and do not allow to use the advantages of higher GF. I'm
pretty sure we would see difference if we draw our own/new profile based
on theoretical data.

What still puzzles me is, that the calculated deco starts much earlier
and deeper than the deco given by my Predator and OSTC as well. There
might be something wrong with taking GFlow into account as when setting
it to 200% it seems there is a short and shallow deco obligation before
the one given by the dive computers which vanishes completely and
restarts quite at the same time as given by the dive computers. Will
have a look to this tommorow.

> Some notes:
> - seems there is a fixed last stop at 3m implemented as of now, in the
> long run this should be configurable as some people believe 6m is better
> (not me) and personaly I'd also like to have to opportunity to switch
> this last stop of or change to 2m or even 1m - just to play around and
> see what the difference is on dives with 6 hours of deco.

3m is defined in struct buehlmann_config, if it should be made
changeable I'd suggest to do it the same way as HF High and low. At the
Moment 3m should be fine.

> - looking at the outcome of your calculations compared to my real ones
> done at CC I get the impression the calculation is to optimistic (maybe
> there is a wrong gas used for calculations?) and especially the deco
> duration in total seems to be to short, but I'll have a look to this in
> more detail


See above, CC seems already be implemented and real dive samples avoid
speeding up decompression.

Some more notes: The deco calculation seems not to take the TTS (time to
surface) into account, which should be done if we speak about dive
planing. Example, lets do it easy at air and OC: If we do a dive to 40m
and stay in the NDL time we can not stay there right to the point where
NDL is finished and assume there is no deco. Given a ascent speed of 10
meters per minute the ascent will take 4 minutes, if we use 6m/min its
nealry 7min in which we might face deco obligations. In theory we'd also
need to calculate the future deco obligations based on a straight ascend
at max ascend speed until we reach surface or a deco stop.

HTH,
Jan