Nobody wants things to go wrong on a technical dive - but each negative

RECALL THOSE BUMPER STICKERS Remember When Sex Was Safe And Diving Was Dangerous Funny stuff.
Diving apparently went from Dangerous to Safe a few years back (probably to suit somebodys marketing theme for the year), but the opposite is true of technical diving. It seems to claim more victims every year.
If the equipment isnt failing - despite carrying that prized CE (Chinese Export) mark - or our skills arent eroding because we never take time to improve them, the last thing we need is to be expected to use dive tables that have undergone about as much pre-sales testing as marijuana.
A dozen years ago, divers were semi-happy with Buhlmann and US Navy dive tables. Then, I dont know why, some bright sparks dusted off 30-year-old papers about an algorithm that never worked then, added some Internet hype and, hey presto, we had Bubble Models!
More-traditional algorithms such as Buhlmann, USN and DCIEM fall under the Dissolved Gas Model umbrella. Like the Bubble Model, they were derived to fit as closely as possible to real-world data.
Sadly, what constitutes success for a product nowadays largely depends on whether you are selling or buying. Recent validations of decompression algorithms seem to be severely lacking in objectivity, because so few people really know what theyre looking at.
I remember using some software called DPA (Dive Profile Analysis) that was all the rage in 1994 to plan my early technical dives. Users in those days kept their dive software close to their chests, because trying to explain it always revealed that they actually knew as much about it as the average driver knows about his car.
DPAs weakness was its DOS interface, but I cant remember any bends it produced, other than those caused by poor diving and the Rohypnol air quality of the time. In those days we ascended like champagne bubbles, and deep stops were added only on an if I can be bothered basis.
We didnt get the bends because we were either bounce-diving for fewer than five minutes, breathing air only, or, if it was trimix, made sure to use enough helium to prevent us being mere passengers on the ride.
Recently, I saw a diver who had been swimming around DIR-style at 30m using 45% helium suffer a bend. Through the oxygen mask, he cited one of those it could happen to anybody pesky runaway ascents, though the cause of that ascent had clearly been his having no clue about correct drysuit use.
Another reason for the bends staying away was our instructors insistence on slow ascents - 10m/min was the way forward, he said, and as he had had more bends than anyone in the group, we took notice and became healthily sceptical of the traditional 18-24m/min ascents that had been set in stone since Cousteau was taking swimming lessons.

A COUPLE OF YEARS LATER, the new software on the block was Proplanner. This had an almost Star Trek look compared with DPA, and an interface that was almost designed for humans.
Proplanner went though several incarnations, some bad (allowing faster ascents) and some apparently good (deeper stops).
Looking back, if we had routinely ascended a bit more slowly deep stops wouldnt have been necessary, but the gurus of the day had decided that it was stop depths and TTS (time to surface) predictions that needed improvement, rather than speed through the water.
Proplanner was the tech divers main crystal ball for a while, but fell behind when newer offerings seemed to offer better usability. Proplanner is still about, bizarrely still as a DOS program, but when used properly the Buhlmann-based version still gives perfectly adequate deco times.
Many competitors arrived over the years, and often disappeared again after sending their followers limping off for recompression therapy. Abyss was spawned and, despite containing more bugs than a Chinese cookbook, it was the most comprehensive program (it even wanted to know whether you smoked, and, for some reason, your regulator brand) and was widely used.
Abyss was a Windows-based offering, and the shiny interface lured the unwary like insurgents to a mini-gun.
All OK things come to an end. Abyss programmers jumped on the technology bandwagon, getting carried away with the Bubble Model mania seeded on the Internet seven or eight years ago. Much like a tsunami, early Bubble Models looked impressive at a distance, but were very dangerous when you actually got caught up in the flow.
Abyss got hitched to the Reduced Bubble Gradient Model (RGBM) algorithm, at the time a line-by-line hijacked version of VPM sprinkled with some altitude-diving fudges. The inventor of RGBM has about as much practical deep-diving experience as Stephen Hawking, but the Internet buzz hooked many divers like flapping fishies.

The Abyss team even sold me on the idea that lengthy decompression stops were for idiots, and that by doing a plethora of short-but-deep stops, I could avoid decompressing in the shallows. I tried it dozens of times between 60-90m with moderate bottom times, with varying success.
Proof of the pudding came doing dives with 3-5 hours of stop time. I got bent each time - I believe marketing folk call this limited success.
I was managing to shave several hours off some deeper dives, and the bends I received seemed minor enough on the pain scale. Slowly but surely,
I realised that adding extra time in the shallows might lengthen my skeletal future, and that all was not well with the Bubble Models miraculous promises.
For some reason, I naively believed in 1999 that Abyss was better than Vplanner - after all, I had paid for Abyss, whereas the VPM program was free.
I did try a 20-minute dive to 120m with Vplanner and got bent before surfacing, which put me off a tad.
The dive profile then called for about 80 minutes of decompression time, and in hindsight gave me odds worse than a lemmings. Oh well.

GOING DEEPER AND DEEPER WAS MY AIM, but I was still undecided about the ascent-speed lottery. I could either rocket up from the bottom before starting to do lots of deep(er) stops, or ascend at a slower rate and bear the burden of extensive decompression.
Bubble Models work by shaving, say, 30-50% off the shallow-stop time. Many tech divers incur no more than 20-30 minutes of proper decompression stops, and knocking half of this off gets them out of the water 15 minutes early, usually without needing a trip to the recompression chamber.
While Bubble Models are shaving off shallow-stop time, they are adding it in deeper. Doing this affects only our slower tissues, the ones that dont grab our attention the way insulting their faster, more CNS-based cousins would do.
If we knock the same 50% off, say, four hours of deco, this may save a couple of hours but our reward is a ride in the chamber - or several.
Bubble Models tended to give very short deco times in the shallows when they first came to market, but after users started complaining in droves about bends, the lawyers couldnt keep saying: Well, its your fault because you clicked I Agree on the disclaimer.
The rusty ship slowly changed direction and started adding back the time in the shallows. Since 1999, the two main Bubble Model providers have been honing their products on a largely unaware user base.
Can you imagine if drugs companies simply put their products on the market and then waited outside doctors surgeries to check the severity of the side-effects If that does happen, it shouldnt, but testing of that sort definitely goes on inside the bodies of technical divers.
What we see in the following figures is the total time to surface (TTS) from the same software packages as they have evolved based on data derived from all the bends they are likely to have caused. The dive in the following example is to 120m for 20 minutes:

 TTS (min)
VPM (A) 2000110
VPM (E) 2006189
RGBM 200099
RGBM 2003142
RGBM 2006165

As you can see, 2000 was a dangerous year for tech divers, with risk at the sort of level posed by opening a McDonalds in the Sunni Triangle.
The earliest versions of Bubble Models give just 99 minutes total dive time. The latest (2006) offering gives 189 minutes.
Its staggering that these modifications were made only after divers got the bends. The original guesses were so way out as to defy belief. It is even more worrying to see just how much deco obligations vary when selecting different levels of conservatism.
What would constitute adequate decompression in commercial diving circles is called conservative now. Online divers today prefer the words Aggressive and Extreme when they discuss deco-plans, as if theyre talking about the strength of their favourite lager. Well, its their bodies.

AGAIN, IT WOULD BE INTERESTING if pharmaceutical companies let the sick decide just how much of a drug they need using trial and error, or if the motor industry allowed drivers and passengers to set the elasticity of their car seatbelts.
Lets see how that 120m dive for 20 minutes would look using the same programs but with their individual user-decided levels of bent.
Here are the time to surface figures from three popular deco planners, and the dramatic differences given by using the various levels of conservatism for the same dive:

 TTS (min)
RGBM (Extreme Deco)122
RGBM (Recreational Deco) 165
VPM (Nominal)150
VPM (+ Five)211
Gradient Factor (100/100)143
Gradient Factor (20/70)228

What we see here is a minefield - just how will the user decide whats fine and whats not Adequate decompression is not just about feeling pain, its about keeping our bodies fit for purpose.
These six examples show the amazing differences obtained by switching conservatism one way or another, and I am being generous, because two of these programs have multiple models available within the same program, and switching between Bubble Model and Dissolved Gas Model while playing with the level of bentness required can make the above differences look tame.
Who knows which calculation is OK Well, by using these programs eventually somebody will find out, very roughly and at the users expense.
Here I must declare an interest. After years of unintentionally testing dive software for others, I thought I would have a go at producing something that actually worked now and again.
Teaming up with people who understand the maths, but using my honed with chamber rides experience to shape the final product, I came up with the Decochek Optimizer.
Unusually, I wanted the program to provide adequate deco profiles based only on previously tested data. Users may add stop time if they wish - if, for example, they anticipate getting cold, or have a history of getting the bends - but what this approach wont do is expose the diver to profiles that are way outside established commonsense parameters.
Its going well so far, and was tested in the actually dived sense of the word to 220m recently.
The moral of all this is that software users should use only the latest version of a product. They should use maximum conservatism initially, working backwards, 10 similar dives at a time, until reaching the mid-point.
Going into aggressive or bandit country levels of adequacy exposes the user to extensive risk.
No dive-tables will ever guarantee that you remain bends-free. There are too many variables - existing injuries, circulation problems, dehydration, post-dive exertion, dive-computer straps and suit wrist seals done up too tight... phew!
One hundred years ago, diving physiologists used hyperbaric workers and then Navy divers to make the numbers fit the symptoms.
Nowadays regulatory bodies would frown on letting showers of expanding bubbles rip through peoples brains and cause irreparable damage, because this may lead to inconvenience, pain or, even worse, compensation claims.
Modern deco-gurus dont need the hassle of expensive but credible testing, because the Internet culture will gladly undergo the deco-lottery for free in the name of pseudo-science and online kudos. Caveat emptor, apparently.

Gradient lottery Three examples of conservatism-level settings on deco-planning software illustrate the amount of latitude afforded to technical divers.
Mark Ellyatt has been inside a number of hyperbaric chambers - and has used the experiences to develop his own deco-planning software.