deco calculations

[Dirk Hohndel]

Jan Schubert <Jan.Schubert at GMX.li> writes:

> 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!?

Correct.

>>> 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).

That's odd. I would assume either a consistent bug, or consistent
correctness. Being off in a couple of compartments is... unexpected.

Oh, is this in multidive scenarios where the previous dives are on air
(seems unlikely with you)? There is a neat bug in the current code where
for previous dives we assume that air is actually 100% N2 (yeah, Linus,
it's the f*cking stupid air == O2=0 thing again... yeah yeah yeah, you
told me all the reasons why this is the right thing to do... I still
hate it)

> 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.

That's what planning will allow you to do.

> 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.

Please do. This should use the same math as the hw DR5 (which is not the
same algorithm as the OSTC - the CPU in that isn't fast enough for the
code running on the DR5 according to hw).

>> 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.

Again - you are reading what is displayed incorrectly. All that is
displayed is your ceiling for the dive that you are looking at. And its
rounded up to 3m blocks. This is not (YET) a dive plan.

>> - 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.

You are STILL mixing what is displayed on an existing dive with what you
would expect from dive planning software.

Why don't you wait for what I'm working on and then comment on that?

Thanks

/D