RGBM Algorithm for Technical Diving

Please register or login

Welcome to ScubaBoard, the world's largest scuba diving community. Registration is not required to read the forums, but we encourage you to join. Joining has its benefits and enables you to participate in the discussions.

Benefits of registering include

  • Ability to post and comment on topics and discussions.
  • A Free photo gallery to share your dive photos with the world.
  • You can make this box go away

Joining is quick and easy. Log in or Register now!

Sevenrider860

Contributor
Scuba Instructor
Messages
1,220
Reaction score
947
Location
Newnan, GA
# of dives
1000 - 2499
The topic of the RGBM algorithm and the suitability of the algorithm for technical diving was brought up in the recent AI thread. I thought I would open a new thread to discuss the RGBM algorithm specifically. Like many issues there are some who use it and others that say run away from it. I am interested in seeing why others feel one way or another.


My tables for Tec40/45/50 training and a number of dives after training were all based on the RGBM algorithm. I used the GAP diveplanner software. I also used the GAP RGBM software for planning my Normoxic TriMix dives. I had a Liquivision XEO running the Free Phase RGBM algorithm at the time. The computer and the GAP tables were always very close...maybe off by 1 minute on one or two stops. I don't remember seeing a large variance between the two.


I now use MultiDeco for dive planning and my computer is a Petrel with VPM. I did not change because of problems using the RGBM algorithm, it had more to do with hating my XEO and upgrading my personal computer and losing the license key for the GAP diveplanner software. For my diving at the time ( less than 220ft ) the RGBM algorithm seemed to have worked fine for me.


Suunto makes computers for technical diving and they have dive planning software. I ran 150ft for 30 minutes on air with 50% deco gas through MultiDeco and Suunto DM5. The DM5 software using the Fused RGBM algorithm generated a profile that was very close to the a MultiDeco VPM-B profile. Runtime for the Fused RGBM was 72 and VPM-B had 75.


For those that dislike the RGBM algorithm...


Is it that the algorithm is "bad" for dives deeper than what I have performed?
Is it because Dr. Wienke's algorithm is proprietary and not open to review?
It RGBM implemented wrong or poorly in some computers?


I am just curious what other's opinions are and why.
 
Just out of interest.... what conservatism was VPM-B set at? And was the RGBM set for conservatism? (can it be?... and how does it work?)
 
VPM-B was set at +2 Conservatism.

Suunto was at P0 which is default and described as "ideal conditions". You can decrease two steps (P-1, P-2) with P-2 described as "ideal conditions, excellent physical fitness, highly experienced with a lot of dives in the near past" or increase two steps (P1, P2) with P2 described as "several risk factors or conditions exist".
 
The full implementation for the Xeo doesn't seem to be available any more, and there's no way of knowing what Suunto is providing.
 
Out of curiosity I just took a look at the dive planner DM5 since I have it on my PC, but I don't use it, it seems that you can't have travel gas, only one dive mix and one Deco gas if I introduce a second gas on the list it throws a bunch of mixed numbers that I believe it is a comparison chart according to the gas but all together and it is confusing, am I doing something wrong ?? any hints ?
 
The topic of the RGBM algorithm and the suitability of the algorithm for technical diving was brought up in the recent AI thread. I thought I would open a new thread to discuss the RGBM algorithm specifically. Like many issues there are some who use it and others that say run away from it. I am interested in seeing why others feel one way or another.


My tables for Tec40/45/50 training and a number of dives after training were all based on the RGBM algorithm. I used the GAP diveplanner software. I also used the GAP RGBM software for planning my Normoxic TriMix dives. I had a Liquivision XEO running the Free Phase RGBM algorithm at the time. The computer and the GAP tables were always very close...maybe off by 1 minute on one or two stops. I don't remember seeing a large variance between the two.


I now use MultiDeco for dive planning and my computer is a Petrel with VPM. I did not change because of problems using the RGBM algorithm, it had more to do with hating my XEO and upgrading my personal computer and losing the license key for the GAP diveplanner software. For my diving at the time ( less than 220ft ) the RGBM algorithm seemed to have worked fine for me.


Suunto makes computers for technical diving and they have dive planning software. I ran 150ft for 30 minutes on air with 50% deco gas through MultiDeco and Suunto DM5. The DM5 software using the Fused RGBM algorithm generated a profile that was very close to the a MultiDeco VPM-B profile. Runtime for the Fused RGBM was 72 and VPM-B had 75.


For those that dislike the RGBM algorithm...


Is it that the algorithm is "bad" for dives deeper than what I have performed?
Is it because Dr. Wienke's algorithm is proprietary and not open to review?
It RGBM implemented wrong or poorly in some computers?


I am just curious what other's opinions are and why.

I recoginise some of these criticisms and I believe I may have participated in some of the threads that precipitated this.

In my mind there are a number of elements here which are relevant to the discussion:

(1) the scientific validity of RGBM.
I don't know how long you've been diving but RGBM pretty much "fell out of the heavens" in.... I want to say round about the millennium. It was adopted quickly because of two things. (a) it formalized "Pyle" stops in an algorithm and (b) the WKPP liked it. It was based on initial research by Dr. Bruce Wienke that sounded *really* promising, to say the least.

However, There were some problems. First of all Dr. Wienke had a good theory but didn't have the resources to test it. At the time, NASA and the US Navy had the resources to test it, but neither were "early adopters". So what happened, in reality, is that it was tested on WKPP dives. Some divers got bent, some didn't, some "he-said-she-said" ensued on the internet and due to the leadership of the WKPP at the time, the discussion got severely bogged down in "he who screams the loudest wins" and any kind of empirical analysis degenerated into internet flame wars. At that time there was no science to discuss, only Wienke's hypothesis.

Literally NONE of this early legacy was dealt with scientifically until the US navy tested Wienke's ASSUMPTIONS (which is all they were) in 2006-2007. The research was published in 2011 and the jury is in. Deep stops do NOT allow for shorter shallow stops. PERIOD. We can now view that as the only scientifically proven data point in the entire discussion. There is room for more research but the screws in Wienke's hypothesis are loose.

(2) Early "pushing of the envelop"
Several divers, among whom, Mark Ellyatt, tried using RGBM on extreme dives in the early 2000's. They literally all got bent. It seemed to them, as it did to us, as a gift from the deco God's. Stay deep a little longer and your shallow stops are shorter. Getting out of the water faster when you have 6 hours of deco seems appealing. By 2003-2004 they were all going back to Buhlmann and Wienke (and this is important) was blaming EVERYONE, the divers, the software programmers, people on the internet, people who didn't believe in the WKPP, people who didn't believe that Wienke himself was the God of deco...... Everyone and everything got blamed, except Wienke. Is this the personality and attitude you want to see from the ONLY person on the planet who really understands why this algorithm isn't working?

(3) Greed
Wienke started very early on protecting and failing to share any critical data on his theory. It was all licensed. On the one hand, I respect his right to want to get rich from his intellectual property but on the other hand, there was so much that was empirically proven to be "wrong" about his algorithm that there was a need to put it under the microscope. Even NASA and the US navy, as far as I know, were not allowed full access to his research. Bruce wanted his goose to lay a golden egg.... even if it meant that divers were diving (as he knew they were) with an untested algorithm full of holes.

After all, even the great Dr. Bruce Wienke needs to retire at some point. This was his retirement plan. As a result we STILL don't know for sure why his algorithm isn't working. We've had 15 years that we could have been doing research, but he has blocked that from happening in order to get rich. (or try).

(4) choice
When it comes down to choosing a dive computer, you have choices. Let's take two typical ones. Shearwater and Suunto. Shearwater uses (or can use) two algorithms. (a) G/F Buhlmann and (b) VPM. Both of those algorithms are well known, well researched and "public property". I could go on the internet tomorrow and download everything I ever needed to know to program (say) Excel to simulate either of those algorithms. Shearwater, therefore is doing two things that I, as a technical diver, appreciate. First of all, they are giving me *ALL* of the information about how my algorithm works so taht I can inform myself and secondly they are selling their computer based on the fact that it's a f'n good computer. Not because it's running some kind of magic.

Suunto have taken another approach. They've gone in business with Wienke and are either unwilling or unable (or both) to share critical information with divers about what their algorithm is doing or how it works. We already know that Wienke blames everyone except himself when divers get bent and is mostly interested in getting rich .... so Suunto have gone down the rabbit hole of thinking that divers should just "trust them". In 2003 we heard that from Wienke and we already know that RGBM can't be trusted so what, exactly, are we supposed to TRUST From Suunto.... especially when they won't tell us the first thing about what that computer is doing. Therefore, in contrast to Shearwater, Suunto is NOT interested in selling a f'n good computer. They want to sell us the "magic".

For recreational divers this all makes no sense and it makes not difference because just about any computer on the market will calculate NDL's for a no-decompression dive within .... I want to say.... a minute of one another. These differences only become important if you really want/need to know what your computer is doing and your dives are getting deeper and longer.

R..
 
I was under the impression that RGBM was overly conservative, how were they getting bent, as for what I heard, you will need a 18 wheeler tank to have enough gas before you get out to surface without running out of gas to follow the RGBM Deco times.
 
Remy, that is assuming you are using a suunto recreational computer.

I have never run RGBM from an app or a computer. I have used RGBM paper tables, and I haven't been bent yet. Mind you, this is all on dives between 100-330fsw.

Mark E's issues are beyond RGBM issues. He claims that he dove RGBM "many" times both at relatively shallow depths and obviously at extreme depths...and got bent EVERY SINGLE TIME. One has to question not only why he got bent every time(even though other people have hundreds of dives without issue using the same algorithm), but also why someone that got bent even on shallow dives using RGBM would willingly continue to use it...on pinnacle dives none the less. His own website has correspondence with Bruce...where Bruce flat out tells him to back the hell off of these dives.
My conclusion is that mark is a nut job, and that he's either lying to some extent about his experiences with RGBM or he has a PFO that you could fly the Goodyear blimp through.
 
I was under the impression that RGBM was overly conservative, how were they getting bent, as for what I heard, you will need a 18 wheeler tank to have enough gas before you get out to surface without running out of gas to follow the RGBM Deco times.

At least some of the "conservative" stuff is penalties for is fast ascents and short SSs and SIs built into recreational computers specifically for us "4 tanks a day for a week straight all within NDL" vacation divers. How much of that is part of the deco algorithm per se is questionable, and we'll never know. The other part is it's mostly recreational divers doing the complaining while dives with 18-wheeler tank or those requiring a deco stop are not recreational dives.
 
http://cavediveflorida.com/Rum_House.htm

Back
Top Bottom