forum.heinrichsweikamp.com

Hi!

I must say the OSTC is very rebreather friendly, but it is missing a feature that would be of a lot of help and that also would make the unit stand out even more compared to its competitors. Most CCR divers that I know participate in penetration dives and I think many of us would be quite happy with some help verifying we don’t exceed our bailout range in the overhead environment.

Most penetration dives requires that you return to the entry point, basically reversing the dive profile once reaching maximum penetration distance. This makes computing bailout needs very simple, at least if you are a calculator. For us humans however it is easy to make a mistake when trying to do multiplication under water.

What I propose is to integrate a gas counter with the Avg Depth counter. It needs to multiply a preset SAC-rate with the Avg Depth and runtime since last reset. Result could then be presented in litres/cuFt in the bottom right corner.
If the calculations are made in the same loop as the Average depth and resetted at the same time this will have minimal effect on CPU performance but would be of huge help for us.

Functional description would be:
m_dNeededBailoutBasedOnAverageDepth = m_dCurrentRuntimeInSeconds * m_dSecondSACRate * (m_dAverageDepth / 10 + 1);

If you want some people to help and alpha test it I know quite a few mine divers that have been waiting a long time for this feature and are eager to try it out.

What do you think?
/ [DF]

Hi,

Easy to implement
Do many people support this request ?

Cheers,

Hi,

I think it should be pointed out (In the Menu, CF, whatever) very clearly that this is only suitable for cave diving.

Cheers,
Matthias

Sure,
I know i would appreciate a funktion like that. Go for it!

Yep.
I support this.

I support this, it would be a great to have!!

I think it would be a really good feature.
Go for it.

@Matthias : Why only for cave divers ?

It make only sens if you have just one bailout mix.

Details:
- m_dCurrentRuntimeInSeconds is just current dive min:sec.
- m_dSecondSACRate is CF57. Note you can put either [l/min] or [bar/min]. Doesn't matter. And this is the place to put your security margin.
- should add a new CF59: 0 => don't show. 100 => go red when bigger than 100.

I'm not sure wether this calculation isn't too inaccurate to be of much use. At least I would switch it off... But as always: As long as it's cofigurable via CF - keep on going!

@JeanDo: Why only for cave divers? Because it only makes sense if you have the same profile on the way out, which is normally not the case within Lake/Ocean-diving.

@Tiefunten

Oups, off course I was reading TTS/runtime instead of past runtime...
Then we do have the seconds indeed...

Regards,

I would also like this feature

Thanks for taking the time to consider my request.

I will try to answer some of the questions that have come up.

It can be useful for anyone required do a reversed dive profile, ice diving, mine diving and cave diving. It can even be used during the penetration phase of a wreck dive. For those only doing OW dives it can be a fun tool showing them how much gas they would have used on OC with their previous SAC. Always nice to see how much you save by using a CCR.

In my opinion it makes sense regardless of how many bailout mixes and bottles you have as long as it shows the results in litres/cuFt. If it were to give decompression information or warnings when you were running out of bailout it would be different. I only want a calculator and leave all the decisions to the diver. However, it would really improve the gascounters functionality if both time and used gas volume is resetted when avg depth is.

I believe that the computers calculation would be much more accurate than the estimations I currently dive after. It will track the actual dive profile and I can’t see anything beating that accuracy. The caveline will not move and if I follow that I will have the same profile out as I had in. Most of the time I can even stay a bit above the line on the way home making the gas last a bit longer.

If you have more questions feel free to ask, i can’t write code but i would like to help as much as possible with this.

And thanks everyone for your support!
/ [DF]

Hello,

* You don't do deco-stops on the way back ?

* Let says it display 2000 ltr so far. You know you started with 6600 ltr, but with 2 different mixes. Can you be sure to have enough of the right mix for the right depth ?

Regards,

Hello,

Can we have an increase in the SAC rate we can enter? I'm usually planning 40l/mn for my bailouts.
Yes, I know I could convert it in bar/mn but the majority of dive log software doesn't use it and I must say I'm a bit lazzy ...

@Stephane

Does CF56 (SAC for bottom gas) is good for that purpose (meaning all bottom gas consumption will be computed with 40l/mn) ?

I don't do cave diving but I can see when this would be useful.
So I support this

Jean-Do,

I believe yes but in CCR mode this should only be valid when using a bailout gas.

I support it! Sounds like a great idea to me!

I strongly support this feature, mainly because the request actually originates from myself.

As for accuracy, I've done comparisons by calculating the bailout gas requirements recursively using the actual profile as well as by using the suggested method with the calculated average depth as base. Results are exactly the same and anyone interested can get a copy of the source code. From a CPU/memory performance point of view it's pretty useless to calculate recursively when not needed.

The calculated value can be used regardless of the number of bailout tanks/gases, *but* it surely requires the diver to know what s/he is doing. It's not a magical thing replacing predive planning, it's not a replacement for in-water-brain-operation. It's simply a great tool for allowing the diver to focus on other things than simple-but-annoying math calculations during the dive. Needed bailout gas has to be part of the predive planning, and based on the actual amount of (spare) bailout decogas and actual profile of the dive, the thinking diver has the possibility to modify the actual dive correspondingly. Great tool especially for exploration diving, but you need to plan for having access to enough deco gas.


If we had an endless amount of CPU and memory, it would obvious be great to include the actual deco bailout need based on the calculated deco profile as well. As it happens, we have an algorithm ready for that as well
Without knowing for a fact I assume that there are better use for such (possibly) available performance.
In order for this to be possible one would have to have two separate deco calculations running in parallell;
one doing the same thing as it is today and the other one calculating what would happen if you would actually turn the dive and run the reverse profile at any given moment. Compared to the "average depth counter", this would require loads of both CPU and memory. Presenting the information would also be more complicated than the suggested solution. It would also require a fair amount of simplifications, but since they err on the safe side the output would still be useful. Biggest downside is however the fact that the algorithm is fairly complex, i.e. it's harder for the diver to actually understand how (and if) the values are actually correct.


Back to the suggested solution:
The practical approach to using the counter would instead be to do the same thing as you do today. Plan your dive ahead of time and bring a satisfying amount of (spare) bailout deco gas depending on the planned dive and your personal/team preferences.
Use the calculator to verify that you don't extend your planned bailout, actual method may or may not include resetting of calculation depending on profile and/or number of bailout tanks/mixes. Planning responsibility remain with the diver and the calculator is only a tool, exactly as it should be on this level of diving. As a specific example of usage, the counter will tell you when you pass the point of no return in terms of getting back to surface using your own bailout vs. relying on the team bailout concept.


That said:
Once we have this feature implemented and verified we already have a suggestion for an extension. Will require some memory but no increase in CPU-usage. Upside for the user is extending the "current/suggested" linear in-and-out-profile with support of complex circuits

Let's get the first part up and running to start with though

Cheers

/Jonas

@ Dragan: I don’t know about originates, I am pretty sure the first person ever trying to do this kind of math during a cave dive wished he had a calculator confirming he was right. It is just that with the OSTC there is finally a platform and a forum to make this happen. Otherwise I agree with you.

@ Stephan: You are absolutely right, it needs to be possible to set the SAC to very high values. Good thing you brought this up, I have never fiddled with CF 56/57 as I plan dives with desktop software and did not know there was a limitation.

@ JeanDo: Excellent questions! You are right, you can’t know this by using only the gascounter.
I think that Dragan have explained it pretty well. You need to plan the dive ahead and figure out how much deco your assumed plan would give you. The gas needed for deco stops is however not part of the penetration volume and thus of no concern to the gascounter.

Simplified it is like a wreck penetration dive on OC. You have one specific volume for when inside the wreck and another volume for getting to the surface and decompress. For OC you use the rule of 1/3 for penetration and the CCR equivalent is called Bailout range. The bailout range can be calculated the way previously described and it is first and foremost this calculation we hope to get some help with.

Thanks again for your interest! If you have more questions, keep them coming.
/ [DF]

+1

Already requested by me some month ago, should be useful for "normal" dives also and consider TTS/Deco as well.

@ Solodiver: Yes, you have come with a lot of good suggestions in my opinion, having a future TTS is my favourite.

The feature I proposed is however a bit different from the one you suggested before as it is much easier to compute and implement. It does not take into consideration decompression or tank size and leaves this up to the diver. I believe this is a good thing since it forces one to plan the dive ahead.

With regards to OC bailout plan for OW or simple wreck dives I don’t see the same purpose as you. With just a little predive planning it is easy to figure out what maximum TTS ones current bailout setup will allow. OW divers need to ascend when their max TTS is reached to be able to get to the surface OC. Pretty simple and linear wreck divers that know how to do it can use the future TTS instead.

The problem as I see it comes when doing irregular penetration profiles during a part of or the whole dive. In order to get a reasonably accurate reversed TTS you however need to run two new separate deco algorithms, one for SP and one for bailout. If this is possible with regards to CPU and RAM i would not mind seeing that being implemented sometime in the future but i think that function may be more suitable to the DR5.

For these reasons I believe a simple gascounter is a better choice, it takes up very little resources and can probably be programmed in a few days since most of its functions are already there. Yet it would be a very powerful tool for all penetration divers wanting to be sure their penetration bailout is sufficient.

/ [DF]

I also like the idea of a GAS counter. But please do not just make this to a CCR bailout tool.

If kept as a simple gas counter it can also be used as a OC tool.
For example lets say you can set tanksize and starting pressure. The sac rate already exists.

Lets say that you can see the calculated remaining preassure in divemode all the time.

For bailout calculations, this means that when the preassure reaches 0, you turn the dive.

For an OC diver, this is great for calculating the real SAC rate, as a check against the SPG will tell if the real SAC is the same as the SAC in the OSTC.. Good for divers who want to confirm, and great for beginners to calculate their real SAC. At the end of the dive you just confirm with the SPG. If they give the same value, you know your SAC as set in the OSTC is your real SAC.

Another good thing would be to be able to set a warning value, a value that when reached would set the calculated preassure to red digits. Then this can be used to warn when rule of thirds have been reached or half, etc.
Of course a diver should always know his SAC, and confirm with the SPG.. But if you set the SAC rate a little bit higher, and have a preassure countdown that turns red when nearing 1/3 of the gas, thats a good thing to remaind the diver to check his SPG. and start preparing to turn his dive.

I dont know how to best implement this feature. My way is maybee a bad idea. All i want you to think about is of course to not implement just a specifick CCR thing if it with just some small modifications can serve just as well us OC divers to. I Like Dragans idea, but i want to use it as well down in Sala even though i dont use a Rebreather there (yet)

@wooflock
I agree that your suggestion might be a good thing for OC diving, but then again who dives OC these days
Honestly I don't personally really see the need for the suggested Oc-functionality, but then again loads of people don't see the need for the CCR bailout gascounter either. Who am I to judge...

From my point of view, displaying number of liters is the most flexible solution since it
A) Doesn't require any setup apart from SAC (which can be kept static for years)
B) Doesn't imply any restrictions in terms of number of gases/tanks and tank sizes

A fairly common CCR Cave dive within my group might involve 3-4 bottom bailout stages plus at least 2 deco tanks.

Implementing a generic solution that would support display of bars for an "infinite" number of tanks would require a lot of configuration which would increase complexity and memory usage.

As long as the combined OC/CCR solution does not delay the implementation of the CCR Cave bailout functionality which is dearly missed, feel free to extend the functionality. Just make sure that it will be possible to minimize the amount of configuration, e.g. unless tank size, pressure etc. has been configured simply display liters.


May I suggest implementing it in steps, i.e. create a release that support the simple gascounter and then decide on how to best implement a generic OC/CCR functionality.

Cheers

/Jonas

I have no problem with a liter display countdown. As long as à new function can serve the oc Diver as well. but who am i to judge what functions to be included. I really see the point of the ccr bailout function. And if it cant be included then maybee à Sala wannabee might try to kludge it in for you