deco calculations

[Jan Schubert]

On 01/05/13 01:31, Dirk Hohndel wrote:
> 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:
>>>> 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.

Sorry, nothing wrong or odd  - I just noted that some of the defined
halftimes for helium has been different from the ones I'd in mind so
far. Just minor differences on slower compartments and my ones has been
most likely wrongs, so nothing we should care about....


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

OK did some more investigations: My best guess is, that the reason would
be that we do not take the ascent into account while the dive computer
does. Deciding if there should be a stop and at which depth seems to be
done in deco_allowed_depth() based on the value of tissues_tolerance
related to surface pressure. As soon as tissues_tolerance is larger than
surface pressure we start to calculate the deco ceiling while the dive
computer calculates an ascent at the given ascent rate at exactly this
time resulting in some decompression on the way up resulting in no deco
stop at all. The same for all the following samples: We start
calculating the deco ceiling based on no future prediction while the
dive computer does it all the time. In my theory, this would also
explain while the calculated depth is always deeper than the real one.
Just a theory but my best so far...


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

I'm aware that we do not have dive planning capabilities yet, I just
wanted to point out something which could be helpful for further developing.

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

Sry, did not know on what you are working and that there is a relation
at the time of my writing...

Jan