deco calculations

Miika Turkia miika.turkia at
Fri Jan 4 23:18:56 PST 2013

On Sat, Jan 5, 2013 at 3:11 AM, Jan Schubert <Jan.Schubert at> wrote:
> On 01/05/13 01:31, Dirk Hohndel wrote:
>> Jan Schubert <Jan.Schubert at> 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...

This sounds plausible when looking at my non-deco dives. I do see
ceilings on dives that did not go to deco (according to my DC).  And
playing with the GFs does not give any consistent correction to this
inaccuracy. However, this might also be the mentioned air bug, even
though some Nitrox dives do also get the ceiling without going into
deco in real life. 55/96 seems to get quite close to what my computers
thought during these dives, but I believe Suuntos (stinger and Vyper)
are more conservative than that (not that I would know what these GF
values really mean).

Anyway, the real reason for replying is to report that the 3m
increment selection is currently not functioning. It is in effect with
and without selecting it.


More information about the subsurface mailing list