On a NDL dive, which computers' NDLs are not affected by GFLo?

[KenGordon]

Nonsense, and you know it. Hence your popcorn emoji. Why do you post this crap?

Because it is true.

There is fudging going on. Previously it was claimed that that first stop is instantly gone as the next step is the surface and so the next limit is GF High. So an implementer could choose to ignore such a stop.

 

[dmaziuk]

Nonsense, and you know it. Hence your popcorn emoji. Why do you post this crap?

Because I actually read Erik Baker's papers and Buhlmann's "Decompression" and a few sources for NDL calculation, and that's what they say. It is indeed nonsense, that is the whole point.

And you can read them yourself, at least Erik's papers are available on-line free of charge.

 

[Jay]

Time out for 1 sec please .....

I created this thread to simply answer the question of if NDL is affected (on a NDL dive) by GFLo, not how.

The 'how' question is interesting, and I do enjoy reading informed views, but please in another thread.

thank you.

 

[Jay]

To answer the IF question. I've emailed Mares and their initial response was "a very 'basic' answer for NDL dives the GF low affects the total ascent time to the surface, so length and number of deco stops, and the GF High controls the NDL limits" so I've gone back and asked if running two dive plans on the Genius one being 10/90 the other being 90/90 if it produces a different NDL, to which I've not yet received a response to.

I emailed Suunto, and received a 'non-answer' so have re-asked and am still waiting.

The TDC-3 computer does what multi-deco does.
We know what Shearwater does and also Dive Rite's (discontinued) Nitek Q.

I've not got around to asking other manufacturers on the list.

 

[scubadada]

Hi @Jay_Antipodean

Could you please summarize what you have learned so far about whether GF low affects NDL?

BRAND YES/NO
Divecomputer.eu/Deep 6
Dive Soft
Garmin
Heinrichs Weikamp
Mares
Ratio
Scubapro
Shearwater NO
Suunto
Technical Dive Computers

Thanks, Craig

Sorry Jay, I saw your last response just after I posted. Maybe folks that have these other computers will take the time to check the planner for 10/90 vs. 90/90, or some other easy comparison to see if GF low affects NDL

 

[dmaziuk]

Time out for 1 sec please .....

I created this thread to simply answer the question of if NDL is affected (on a NDL dive) by GFLo, not how.

And the correct answer is: applying Erik Baker's gradient factors to a no-stop dive is nonsense.

But you need to understand how ZHL works, and why GF were added, to understand why that is the correct answer.

You are absolutely right to ask the manufacturers what they've actually implemented, and I'll be really surprised if you get any answers other than the canned "GF Hi at the surface" blurb.

 

[stuartv]

Because I actually read Erik Baker's papers and Buhlmann's "Decompression" and a few sources for NDL calculation, and that's what they say. It is indeed nonsense, that is the whole point.

And you can read them yourself, at least Erik's papers are available on-line free of charge.

You left out the fact that the algorithm and Baker's mods to it apply to calculating a dive plan - not maintaining a real-time calculation on the fly.

Some reasons that makes a difference:

Baker's code knows exactly when your dive is over and you are starting your ascent to the surface. Because the whole premise of its operation is that you tell it your entire dive, up front, and then it gives you an ascent plan. On the other hand, your dive computer does not know when you are actually starting your ascent to the surface. When you ascend from 90' to 85', your computer doesn't know whether you just started your ascent to the surface or you were just going up and over a barrel sponge.

Baker's code does not check to see if the dive segments you put in would violate a deco ceiling. For example, you could input a dive plan of 2 legs:

60 min @ 100'
5 min @ 10'

Baker's code would not tell you that you totally busted your deco ceiling during your ascent from 100' to 10'. It would only tell you what your ascent should be starting from 10' and 65 minutes into your dive.

However, the fundamental principle applies at all times: Give the diver an ascent that allows the diver to reach the surface without exceeding the GFHi % of the M-value in any compartment. And when you are calculating that in real-time, on the fly, with no way to know when the diver is surfacing versus just ascending 1 foot, I don't see how anyone can say that is wrong to do it the way Shearwater does it - which doesn't utilize GF Lo until such time as it detects that GF Hi would be exceeded on a continuous ascent (at 30ft/10m per minute). Why calculate the first stop when you don't even need a stop?

The number of places in Baker's code where it checks for a condition - one that IS possible - and just aborts with an error might be surprising to some people. But, Baker's code can afford to do that because it's intended to calculate a complete plan in advance. How would you like your dive computer to do that during a dive?

Baker's code is simply not a model that anyone (in their right mind) should hold up as an example of exactly how a dive computer should implement Buhlmann ZHL-16B/C with Gradient Factors.

 

[stuartv]

Time out for 1 sec please .....

I created this thread to simply answer the question of if NDL is affected (on a NDL dive) by GFLo, not how.

The 'how' question is interesting, and I do enjoy reading informed views, but please in another thread.

thank you.

Respect. Roger, wilco.

 

[Jay]

Hi @Jay_Antipodean

Could you please summarize what you have learned so far about whether GF low affects NDL?

BRAND YES/NO
Divecomputer.eu/Deep 6
Dive Soft
Garmin
Heinrichs Weikamp
Mares
Ratio
Scubapro
Shearwater NO
Suunto
Technical Dive Computers

Thanks, Craig

Sorry Jay, I saw your last response just after I posted. Maybe folks that have these other computers will take the time to check the planner for 10/90 vs. 90/90, or some other easy comparison to see if GF low affects NDL

I think the table might need to be more like no / marginal / yes ... (reason in post #46) ... bit of chicken and egg as it depends on the results.
no - GFLo does not affect NDL on a NDL dive
marginal - GFLo does not typically affect NDL on a NDL dive and/or the effect is very minimal
yes - GF Lo affects NDL on a NDL Dive.

And the correct answer is: applying Erik Baker's gradient factors to a no-stop dive is nonsense.

And you're probably totally correct, but this thread is merely what does the computer output and does it change.

But you need to understand how ZHL works, and why GF were added, to understand why that is the correct answer.

Again, both those points are interesting and dare I say are a logical way to answer my OP, but they're for another thread because this thread is merely what does the computer output and does it change, and once we've built a list, then we can confidently say in future posts that GF Lo doesn't affect NDL times on NDL dives (/re GFs: NDLs are solely determined by GF Hi) and not debate that point.

 

[Jay]

You left out the fact that the algorithm and Baker's mods to it apply to calculating a dive plan - not maintaining a real-time calculation on the fly.

Some reasons that makes a difference:

Baker's code knows exactly when your dive is over and you are starting your ascent to the surface. Because the whole premise of its operation is that you tell it your entire dive, up front, and then it gives you an ascent plan. On the other hand, your dive computer does not know when you are actually starting your ascent to the surface. When you ascend from 90' to 85', your computer doesn't know whether you just started your ascent to the surface or you were just going up and over a barrel sponge.

Baker's code does not check to see if the dive segments you put in would violate a deco ceiling. For example, you could input a dive plan of 2 legs:

60 min @ 100'
5 min @ 10'

Baker's code would not tell you that you totally busted your deco ceiling during your ascent from 100' to 10'. It would only tell you what your ascent should be starting from 10' and 65 minutes into your dive.

However, the fundamental principle applies at all times: Give the diver an ascent that allows the diver to reach the surface without exceeding the GFHi % of the M-value in any compartment. And when you are calculating that in real-time, on the fly, with no way to know when the diver is surfacing versus just ascending 1 foot, I don't see how anyone can say that is wrong to do it the way Shearwater does it - which doesn't utilize GF Lo until such time as it detects that GF Hi would be exceeded on a continuous ascent (at 30ft/10m per minute). Why calculate the first stop when you don't even need a stop?

The number of places in Baker's code where it checks for a condition - one that IS possible - and just aborts with an error might be surprising to some people. But, Baker's code can afford to do that because it's intended to calculate a complete plan in advance. How would you like your dive computer to do that during a dive?

Baker's code is simply not a model that anyone (in their right mind) should hold up as an example of exactly how a dive computer should implement Buhlmann ZHL-16B/C with Gradient Factors.

Respect. Roger, wilco.

I guess someone's got to make a new OP with the 'how' topic ... just not me