Multi Deco vs Baltic - Matching and use

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!

Something that does seem a bit strange is your equivalent air depth (EAD). Your preprogrammed gas being 21%, the EAD should surely be the same as your actual depth.

Just me being curious as, both profiles being the same, it wouldn't account for this anomaly.
Yeah thats also and odd one I didn't notice. Maybe just rounding or a setting. As I looked in that column the other day and it was in fact correct
 
I suspect you're getting rounding errors between the last stop depth and the stop time and the altitude wanting a slow ascent. change to 1sec stops and 1m last stop and you get this.

MultiDeco 4.14 by Ross Hemingway,
ZHL code by Erik C. Baker.
Decompression model: ZHL16-C + GF

DIVE PLAN
Surface interval = 5 day 0 hr 0 min.
Elevation = 1,275m (s)
Conservatism = GF 45/80


Dec to 23m (1:22) Air 18m/min descent.
Level 23m 17:38 (19:00) Air 0.68 ppO2, 23m ead
Asc to 4m (21:22) Air -8m/min ascent.
Stop at 4m 0:01 (21:24) Air 0.29 ppO2, 4m ead
Stop at 3m 0:11 (21:35) Air 0.27 ppO2, 3m ead
Stop at 2m 0:11 (21:46) Air 0.25 ppO2, 2m ead
Stop at 1m 0:15 (22:01) Air 0.23 ppO2, 1m ead
Surface (22:26) Air -6m/min ascent.

The total is less than a minute. By changing the last stop depth downwards I can increase the "deco" to up to a 1:15, so 30 seconds more. Which makes sense for an altitude dive on the cusp of the GF high. You need to linger longer at 6m to get your leading compartment <85% so when you surface it doesnt spike. There's a stronger pressure gradient at 3m so you get the leading compartment a little lower faster - like 20-40 seconds faster in this case. Last stop 1m is fastest of all as you are bumping up at 84-85 the whole way
 
What’s your surfacing rate at?

For me, a 1 minute stop isn’t a ‘stop’ in that, 9m/min ascent for at least half your ascent, and 3/min after that.

A <=1min stop just means (to me) you better be going 3m/min

So changing your last stop from 3m to 6m, and you still have a 3m/min ascent gives you the same profile...


Now if I misunderstood and the total stop is 1min shorter, than that’s a different thing than what I’m saying..


_R
 
I suspect that it's a factor of travel time as well, so that 1:00 at 3m would easily be explained by that. The 0:18 at 6m has me a little flummoxed though. It is an interesting theory exercise, but in practice this would be one of those "measure with a micrometer, mark with chalk and cut with an axe" kind of things. A minute or two on planning software washes out in the noise of an actual dive pretty fast.

As to the OP, If I can run a plan within a team where we all end up within 2 min of each other on all the important stops, I would be happy. In real life, we are going to sit at each stop until the last computer on the last diver has cleared anyway, for me the major utility of these plans is for establishing gas requirements and having a "get out of jail free" plan for if everything goes sideways. In those cases, unless both your computers died at exactly the same time, RIGHT at the end of your planned BT, whatever tables you have in your wetnotes are going to be conservative anyway.
 
Absolutely. Unfortunately, I don't read german...

Nor do I so I looked around instead -- evidently I did not look at HW sources long enough. But I did look at others, so here's the subsurface numbers, also attributed to HW:

* based on an implemention by heinrichs weikamp for the DR5
* the original file was given to Subsurface under the GPLv2
* by Matthias Heinrichs
* based on Bühlmann ZHL-16b
...
static const double buehlmann_He_a[] = { 1.6189, 1.383, 1.1919, 1.0458,
0.922, 0.8205, 0.7305, 0.6502,
0.595, 0.5545, 0.5333, 0.5189,
0.5181, 0.5176, 0.5172, 0.5119 };

static const double buehlmann_He_b[] = { 0.4770, 0.5747, 0.6527, 0.7223,
0.7582, 0.7957, 0.8279, 0.8553,
0.8757, 0.8903, 0.8997, 0.9073,
0.9122, 0.9171, 0.9217, 0.9267 };

static const double buehlmann_He_t_halflife[] = { 1.88, 3.02, 4.72, 6.99,
10.21, 14.48, 20.53, 29.11,
41.20, 55.19, 70.69, 90.34,
115.29, 147.42, 188.24, 240.03 };

-- and you'll notice they're 'based on "B"' and they match your "C" except for the 1st compartment.

And here's the numbers from Powell:

zhc16a.png


-- where the 1st compartment's half-time matches your "C", only it's "A" and its a and b coefficients are different again.:confused:


Baker writes that He 1.51-minute TC goes with N 4-minute TC, and He 1.88-minute TC goes with N 5-minute TC. You pick one or the other for your implementation. He picks the latter (in "decolessons") and uses the same a&b as subsurface.
 
And the point of it all is that unless you read the source for each implementation and see exactly what numbers it uses, and where/how it does its rounding, etfc., you can't really expect them to match better than +/-4 minutes.
 
https://www.shearwater.com/products/teric/
http://cavediveflorida.com/Rum_House.htm

Back
Top Bottom