Cressi Leonardo- Too conservative?

[stuartv]

So you ARE saying that every implementation of the RGBM algorithm is exactly identical. Okay. I'm certainly open to the notion that software implementations on dive computers is done quite differently than software implementations on any of the platforms with which I am intimately familiar. As I said earlier, my prior statements were pure speculation.

 

[Freewillow]

RGBM algorithms are all the same ::shocked2:

Dive 2 (max depth 46m)	7min/44m	20min/20m	25min/13m	29min/9m	36min/4m
Suunto Vyper Air (RGBM 100)	4min/3m (24m DS)	8min/3m (13m DS)	9min/3m (11m DS)	10min/3m	4min/3m
Suunto D6 (RGBM 50)	4min/3m (24m DS)	6min/3m (14m DS)	7min/3m	7min/3m	2min/3m
Mares Nemo Wide (RGBM PF1)	zero no stop time	15min/3m	23min/3m	24min/3m	21min/3m
Mares Nemo Excel (RGBM PF0)	1min/no stop time	5min/3m	7min/3m	9min/3m	5min/3m

 

[lowviz]

RGBM algorithms are all the same ::shocked2:

Dive 2 (max depth 46m)	7min/44m	20min/20m	25min/13m	29min/9m	36min/4m
Suunto Vyper Air (RGBM 100)	4min/3m (24m DS)	8min/3m (13m DS)	9min/3m (11m DS)	10min/3m	4min/3m
Suunto D6 (RGBM 50)	4min/3m (24m DS)	6min/3m (14m DS)	7min/3m	7min/3m	2min/3m
Mares Nemo Wide (RGBM PF1)	zero no stop time	15min/3m	23min/3m	24min/3m	21min/3m
Mares Nemo Excel (RGBM PF0)	1min/no stop time	5min/3m	7min/3m	9min/3m	5min/3m

RGBM 100, RGBM 50, PF1, and PF0 are all from the same algorithm, sir.

---------- Post added January 4th, 2015 at 02:35 PM ----------

Maybe you should just stick with gradient factors until you understand them. They change the outcome too...

 

[Freewillow]

Stop giving lessons, man . This was an answer to your's to stuartv. As I said, you are picking on people and insulting them on subject that you barelly know. The Cressi leonardo, that you never had in your hands, is a very good example. You are very funny . But I am really tired now. So fare well :admingreet::wavey:

 

[lowviz]

Let's go back to post #11. I only checked in to help a fellow local diver. I was pulled into this tar pit. I don't give lessons. You speak in generalities. I took the time to read everything you posted on ScubaBoard. Nothing of substance.

You are a waste of my time. I do, however, defend myself. That is why this insanity has gone on so long. So from this point on, you are on "Ignore".

Feel free to make your next point, there will be no reply from me.

Best,
Dennis.

 

[Freewillow]

Great, I felt the same about you . good hunting :kiss2:

 

[dmaziuk]

Based on the OP, I would have to speculate that the Leonardo may possibly use a simplified implementation that still complies with the algorithm specs. For example, instead of doing updated calculations based on current depth, it could be taking the max depth and just using that while watching for a threshold value, like the safety stop depth.

(as a sysprog who is diving with the leonardo) the "algorithm" in this context is an approximation of the real good bends model, for a given micro-processor., sampling rate, recalc rate, etc. so there'd be some amount of variance even if they all tried for the exact same thing. which they don't: they add different "conservatism" fudge factors and so on.

I do agree about the safety stop, it should trigger a bit deeper.

 

[cool79]

I agree that it may end up beeing dangerous to select a computor that let you surface ahead of the other divers. In fact on my replacement computor, I have a conservative level of +2 - the safest option. ( Bühlmann G16 with 80/120% on desat/sat) . But I also agree that people should not "follow" stupidly their computors without understanding it.

This is why I believe that the Cressi Leonardo is not a good computor FOR MY STYLE OF DIVING.

What I do not understand is that the NDL does not increase significantly when you are going shallower ( see my explanations on page 1 of this post)

What I do not understand is that when I am in DECO mode @ 7 to 8 m (20/23 feet ) my Leonardo manages to add minutes to my DECO time while other computer start to shorten the DECO obligations.

What I do not like is that for your last DECO stop @ 3m (10 feet), the count down barelly starts if you are @ 4M or slightly bellow. When you are diving in a pass of an atoll and you are finishing your deco obligations in 3 to 5 feet waves, you do not want to stop at 10 feet but rather a bit lower.

These are the 3 main reasons, why I believe that the LEONARDO is not good for MY practice.

Now if you are diving and staying very far from any deco obligations, it is a greet computor. High visibility on numbers, cheap. One button programming for me is a nonsense but this is another story

my wife is using Leonardo and she has already become much more experienced. This Leonardo is much more for beginner. It is far too conservative for my liking... my zoop is already consider quite conservative. when I had 15mins left of NDL, her Leonardo only have like 4 mins left!!!

now she is bugging me to upgrade her DC, as she can enjoy the dive more!!!

 

[Freewillow]

Have been diving 10 days in the Maldives: I had 3 different computors during all the dives: Cressi Leonardo, Heinrich Weinkamp Sport and Aladin Pro: Only the leonardo was blocked twice durong these dives. The reason. As I have alredy noticed and reported, Le Leonardo start to ""air out" ( or decompress ) at very shallow depth ( +/- 10/15 feet ) while the two other start the process mich deaper. When it comes to NDLs, they were quite similar between the 3 computors.

 

[RonR]

Look, Wienke worked and LANL developing simulations for nuclear weapons. Get his book and read it, I'm on my fourth try. You are telling me that a Leonardo can't do the calcs??? NO **** SHERLOCK!!! But I won't accept that the Leonardo's model of the grand model causes deviations on the order of magnitude that incense freewillow.

So you ARE saying that every implementation of the RGBM algorithm is exactly identical. Okay. I'm certainly open to the notion that software implementations on dive computers is done quite differently than software implementations on any of the platforms with which I am intimately familiar. As I said earlier, my prior statements were pure speculation.

Having implemented here multiple algorithms, including two flavors of RGBM (paid the price, got the code and the t-shirt) and Haldane/ Buhlmann, I think I can offer some clarification. It’s a common misconception that algorithms are hard and fast rule books- they are not. They are abstract mathematical models that must be interpreted and implemented in a real world-real time system.

RGBM implementations can vary considerably and still be “RGBM”. there is quite a bit of latitude for different levels of conservatism, and the algorithm contains knobs that can be turned to arrive at various conservatism/ risk levels. These are choices made by the computer manufacturer. Bubble models emphasize reducing bubble formation rather than reabsorption, and are based on and grew out of the known physics of bubble formation. They will tend to have deeper stops, emphasize slow ascents, and penalize multi day diving a bit more. But it’s a range, and RGBM is not inherently more conservative. Haldane / Buhlmann models grew from a clinical observation or medical background. These represent two directions of attacking the same problem.

Most of what is marketed as RGBM is in fact a Haldane / Buhlmann framework, built around M-value calculations, that has been tweaked with additional factors to approximate the results that would come from running a fully iterative bubble model. This is true of Suunto, Cressi, and others. The fully iterative calculations are very processor intensive and involve a lot of code, and in fact there is not a lot of (any) advantage in shallower or no deco diving. To my knowledge the only computer that ships with a fully iterative RGBM algorithm in place is our Atomic Cobalt, and that only uses the “full” RGBM on dives deeper than 150’. Shallower dives use a “folded” algorithm. Fully iterative bubble software (RGBM or VPM) is available as an add on for Liquivision and Shearwater- there may well be others, but the point is that RGBM is not a monolithic structure, it varies from implementation to implementation. The “full” version running iterative calculations in real time is very rare in the world of dive computers, and mostly has to do with significant deco schedules. “Full” RGBM does not, in fact give you no-stop times, for instance, something recreational divers tend to depend on.

A much bigger, and not well appreciated point, is that any algorithm’s implementation in a real time system greatly affects the diver’s experience. Most of this is not dictated by the algorithm. The algorithm doesn’t tell a designer if they should start counting a last stop at 10’ or at 15’, or much about how various unexpected profiles are handled. Sawtooth, or re-descent after starting a schedule, or missing a last deco stop by 15 seconds are things that various computers could handle very differently. Under what circumstances do you re-create a safety stop after a re-descent? Do you ever lock out a diver? How far away from a stop, in time or depth, can you get before it becomes a missed stop? In designing a computer interface there are literally hundreds of these choices that must be made, and they have everything to do with the user experience. Many of these things tend to get pinned on the algorithm, when in fact they are user interface choices made by the computer developers.

So even if the underlying algorithm were 100% identical, there is a lot of latitude for computers to have differing user experiences in the same dive profiles.