Ceiling Popping Up - Take 2

[Goose_66]

Dear all,

toward the end of October a post appeared in this forum showing that in OSTC Planner the ceiling would go up. At that time I noticed but then it fell off the radar ... not much of discussione there at that time.
After that I did buy an OSTC 2n and played with it and during simulation I had the impression that the ceiling would go up, so I recorded a dive (full recording and pictures are available here).

The setup is in Gradient Factors OC dive mode with GF set at 15/80 and gas G1 10/50 (firts gas); G2 40/30 @30m; G3 80/0 @10m; Simulation diving straight to 60m.

Results
At 3.26 minutes the ceiling goes up to 12 mt:
[img]http://www.sardone.info/misc_host/OSTC/ ... up_a3.jpeg[/img]

Then at 3.32 goes back down to 6mt:
[img]http://www.sardone.info/misc_host/OSTC/ ... up_a4.jpeg[/img]

Once Again it goes back up to 12mt:
[img]http://www.sardone.info/misc_host/OSTC/ ... up_a5.jpeg[/img]

This is not all, I waited to see if there would be other issues and surely enough same thing happened at 5.35 with the ceiling going down from 24 to 12 mt:
[img]http://www.sardone.info/misc_host/OSTC/ ... up_b1.jpeg[/img]
[img]http://www.sardone.info/misc_host/OSTC/ ... up_b2.jpeg[/img]

OSTC Planner shares decompression code with OSTC and therefore I had a look at what Planner would do with such profile:
[img]http://www.sardone.info/misc_host/OSTC/Planner.jpg[/img].

This result is quite consistent with the dive profile I achieved in simulator mode on the OSTC 2N.

Gents the previous thread mentioned some concerns but there was no response. I thought that it could be limited to the DeskTop software but apparently is an issue with the decompression calculations that both the dive computer and the planning software share.

I pose again the question: should we be concerned?

• if yes - Then, and in my view, HW should be addressing it.
• If no - then why not!

Hope to spark some discussion this time

Happy diving.

Fabio

[heinrichsweikamp]

What's the CF55 setting?

Regards,
Matthias

[Goose_66]

Hello Matthias,

CF55 is default (0)

Fabio

[Paul S]

Yes, it was me who posted the original thread.

Nothing major to add, except that my CF55 is 0 too.

[MeRodent]

It could simply be that there is a change in the leading compartment controlling the decompression. Remember that decompression is based on both the on-gassing and off-gassing of whichever compartment is leading and they do this at different rates.

[Goose_66]

Ok then,

but if there is a change in the leading compartment, the formerly leading compartment cannot have reached a lower gas loading then before so either the new leading compartment has longer off-gassing or lower GF allowable otherwise there would be no change in leading compartment.

Bottom line is I do not see how a change in leading compartment would get the ceiling popping up (without exceeding the maximum allowable overpressure in the formerly leading compartment that was driving decompression when the ceiling was lower).

How would you figure this out?

Thanks

Fabio

[Clownfish]

Is it possible that the first screen is calculating deco on 10/50 mix and then a few seconds later recalculates doing deco from 10 m on 80/0. The third one is also calculating on 10/50 and then doing the deco from 10 m on 80/0 and then a few seconds later, recalculates on doing ascent from 30 m to 10 m on 40/30?

[Paul S]

MeRodent Wrote:
-------------------------------------------------------
> It could simply be that there is a change in the
> leading compartment controlling the decompression.
> Remember that decompression is based on both the
> on-gassing and off-gassing of whichever
> compartment is leading and they do this at
> different rates.

If the leading compartment changes then you still have to decompresses the previous leading compartment for the same amount of time. i.e. Compartment 1 still has to decompress the same, even if compartment 2 becomes the leading compartment. You don't suddenly get less decompression because you stayed at depth longer.

ClownFish Wrote:
-------------------------------------------------------
> Is it possible that the first screen is calculating
> deco on 10/50 mix and then a few seconds later
> recalculates doing deco from 10 m on 80/0. The third
> one is also calculating on 10/50 and then doing the
> deco from 10 m on 80/0 and then a few seconds later,
> recalculates on doing ascent from 30 m to 10 m on
> 40/30?

Possibly for the examples Goose_66 gives, but when I've seen this I was running on Air with no deco gasses programmed in.

My suspicion is that this is related to how Gradient Factors are computed, but I haven't been able to prove it.

[wrobell]

Paul S Wrote:
------------------------------------------------------- the previous >
> My suspicion is that this is related to how
> Gradient Factors are computed, but I haven't been
> able to prove it.

I suspect some bug as well. This looks like deco spike problem I have experienced few times in the past - NDL like 15 minutes, all the sudden it is gone with deco stop (6m, 1min) and after a minute or two it dissapears and you have NDL like 13 minutes - all of that when slowly constantly going up (sic!) on a reef (verified later by looking at dive profile).

w

[Clownfish]

What wrobell describes also happens with other computers. For example, my various Uwatec computers did this. However, this does seem to be the same as the depth is constant.

[JeanDo]

Hi all,

I am well aware of this. It is (I think) related to the Gradient Factor algorithme, that is unstable in deciding where the decompression starts (ie. what is the reference depth where to apply GF_low). I have been hunting it for nights. Literally...

The good news:
* As OSTC Planner improves, I have better tools to hunt that.
* Furthermore, as I now have a framework to automatize batches of tests, it is easier to make sure such changes won't introduce regressions... Which is a BIG concern.
* But most important: The unstability is mostly on the first deco stop. Not much on the TTS. AND it will stabilize as you start ascent, because this fixes the reference depth for GF_low.

Stay tuned.

[JeanDo]

Remarks:

• With a travel mix of Tx10/50, you are doomed. The latest version of OSTC Planner won't let you do that anymore...
• I can reproduce it with GF 15/80, And a single Tx18/50. So this is NOT a question of gas switch.
• I can reproduce it with just air. So this is not a question of Helium... Even if you have more spikes with it. Probably because the decompression is more sensitive to gaz changes.
• I can't reproduce it with Bühlmann model (pure ZHL-16c). And I can't reproduce it with GF100/100, GF80/80 or even the unprobable GF20/20. So it is related to GF formulas, when GF_low < GF_high.
• If you display leading compartiment (below), you will see it is NOT synchronized with spikes
  [img]file.php?2,file=359,filename=deco_spike_GF30-80.jpeg[/img]
• To get spikes (with this dive setting), I should have GF_low somewhat smaller than GF_high:
  • GF65/100 is ok. GF64/100 produces one spike. GF51/100 produces two.
  • GF50/75 is ok. GF51/75 produces one spike. GF45/75 produces two.
  • GF24/50 is ok. GF23/50 produces one spike. GF17/50 produces two.
  • etc...

[scubatinoo]

My idea was, that the ascent speed could have an influence on the ceiling - replacing a stopp or decotime do to offgasing while slow ascent. But while playing with OSTC Planner i recognized that this seems to have no effect... But if i play around with GF-Factors on a 40m/15min dive on air it is easily to reproduce different spikes on the ceiling...

[tiefunten]

JeanDo: Any progress so far? Unfortunately, I haven't got a good idea at all...

[DiverM]

I have seen this behaviour with other software, which use Bühlmann.

Common sense indicates that you stop worrying about this, as you can't reach the jumping ceiling within ascent speed limits anyway?

[Paul S]

[quote=DiverM]
Common sense indicates that you stop worrying about this, as you can't reach the jumping ceiling within ascent speed limits anyway?
[/quote]

I don't agree with that. An accurate picture of what my deco is going to be is pretty important to me. I appreciate that it's not changing the TTS much, but the less uncertainty the better.

In the 2.60 thread it sounds like they're working on fixing this before the next stable anyway.

[Goose_66]

Paul S Wrote:
-------------------------------------------------------
>
> In the 2.60 thread it sounds like they're working
> on fixing this before the next stable anyway.

True,
Mathias stated he was waiting to release next stable after looking into this.
I am glad he said so! Builds confidence into the product I am trusting with my life

Cheers

Fabio

[scubatinoo]

I guess the spikes are more a mathematical then a life threatening issue...

[DiverM]

scubatinoo Wrote:
-------------------------------------------------------
> I guess the spikes are more a mathematical then a
> life threatening issue...


Excactly my point.

[Goose_66]

Well,

I am a programmer (or I should say I used to be).
Since what we do in a situation like this is build a model in which each status is function of a previous state (i.e. in each moment we compute time elapsed at a given pressure to evaluate the amount of gas that is dissolved or off-gassed into/out of tissues) the existence of obviously "wrong" states in the chain would raise doubts on the correctness of any of the subsequent calculations, unless of course the state of the model is somehow disconnected from the computing of the ceiling .....

I do not have the time nor knowledge to get into the source code to understand why the ceiling pops up in order to understand if the model is sound and only ceiling calculation is the problem or if it if the model faulty and the ceiling popping up the symptom.

I believe this is the point that needs to be investigated ... to ensure this is not a life threatening issue.

Cheers

Fabio

[scubatinoo]

Don't forget: It's all about a mathematical model - not about reality! If you don't trust your dive computer, use tables. If you don't trust tables, don't go diving. No one can tell you what's right or what's wrong, only what could be more right or more wrong, maybe. If you exceed certain limits it's always a "try and fail"... No one will give you a guarantee of anything! But of course i believe that it is HW's intend to make their products as safe as possible... As Matthias said: Easiest solution would be smoothening the ceiling. This is probably what others do - to avoid discussions with their customers... So be happy that you even know about the situation

[scubatinoo]

Have a look at this attachement: A standard Trimix dive 15min@60m - as soon as you start to ascend the ceiling becomes nice and clear...

[Goose_66]

Scubatino,

totally agree with you.
There is a lot of discussion about Buhlmann, Gradient Factors, RGBM, VPM but all of these are just mathematical abstractions trying to represent a extremely complex problem in a system with finite states.

But once you go past the step about creating the model, you have the software implementation of it.

This step can be done:

-correctly and the data you read represent correctly the model (whether this represent the reality depends only on the quality of the model);
-incorrectly and therefore the data WILL NOT represent the model and even if the model represents reality, the data WILL NOT (barred obviously the chance that an incorrect model is then corrected by incorrect computations in which case I would recommend playing MegaMillions or Superenalotto or whatever lottery gives you the worst chances to became a multimillionaire: you are going to win anyway if you managed to do the fix to a faulty model with a faulty implementation).

So after comparing computer to tables (which I did and I will always do using a different model between the two: OSTC GF and Suunto RGBM and soon Vplanner VPM) I have seen no major differences, so I am not screaming bloody murder, but just raising a flag.

As you pointed out Mathias took it seriously and it is been worked on. The fact that software is Open Source, that there are people working on it external to HW and we are discussing the issue here, while not providing certainty (in a caos system), it is a sure sign of seriousness of the manufacturer.

Just to clear the air I trust HW and the OSTC computer with my life (but I verify with tables as any Tech Diver or anybody diving out of the NDL should do).

Cheers

Fabio

[scubatinoo]

Fabio, i understand your concerns.

Goose_66 Wrote:
-------------------------------------------------------
> -correctly and the data you read represent
> correctly the model (whether this represent the
> reality depends only on the quality of the
> model);
> -incorrectly and therefore the data WILL NOT
> represent the model and even if the model
> represents reality, the data WILL NOT

Yes, but at the end you need true humans to proof what's correct and what not.


> So after comparing computer to tables (which I did
> and I will always do using a different model
> between the two: OSTC GF and Suunto RGBM and soon
> Vplanner VPM) I have seen no major differences...

Did you ever try to compare different ZH-L16 GF implementations against each other? There are some planners on the Net, try it - you'll become crazy X(

[Paul S]

JeanDo Wrote:
-------------------------------------------------------
> Hi all,
>
> I am well aware of this. It is (I think) related
> to the Gradient Factor algorithme, that is
> unstable in deciding where the decompression
> starts (ie. what is the reference depth where to
> apply GF_low). I have been hunting it for nights.
> Literally...

Trying to leave the "is it worth worrying about" thread behind....

I was just wondering, when you ascend how does the OSTC decide which depth to fix GF_low to. It's easy in a simulator with a square profile as there's definate things called deco stops, but on a dive it's possible that you may come up a bit, start off gassing, raise your ceiling, but not actually be at a deco stop depth.

Does the GF_low get pinned to it's lowest point at any time in the dive or can it sloosh around?