deco calculations

[Miika Turkia]

On Sat, Jan 5, 2013 at 10:13 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> Miika Turkia <miika.turkia at gmail.com> writes:
>>> 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.
>
> Well - I don't see this as an inaccuracy. I don't try to model dive
> computer behavior. I try to model the situation at a specific moment of
> time. Think of it this way... if you had a catastrophic equipment
> failure and shot to the surface. And let's assume you managed to avoid
> an embolism or anything... would you have violated the deco ceiling?

No ceiling violation in such emergency according to my dive computers
but as said Subsurface disagrees with that (at least with the default
GF values). However, I do not know how my computer calculates the
ascent for the no-decompression limit.

> If most people feel differently and want the ceiling calculated assuming
> some reasonable speed ascent then we can of course do that - but that to
> me is not the point of what I am displaying. I'm literally showing you
> that you have what the literature calls a ceiling. You can not do a safe
> CESA (controlled emergency swimming ascent).

This makes sense and I do agree with your thinking.

> But what you really want, I think, is what I have done in the planner
> mode. Time to stop is taken into account.
>
>> 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.
>
> That bug is fixed in master, too.
>
>> 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).
>
> Neither do I. But as I mentioned in my commit message - the shape of
> that ceiling seems awfully strange to me at times. Yes, I can easily
> hide that (switching to 3m increments usually does the trick), but it
> still makes me nervous.
>
>> 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.
>
> I don't think that's true. I do see odd jumps in the ceiling, but I do
> see smooth changes and lots of values that aren't multiples of 3m

OK, I do see some small changes now that I switch between 3m option
ticked and not. It must have been broken when I first tested as it
behaved totally differently then...

miika