- Messages
- 19,720
- Reaction score
- 18,571
- Location
- Philadelphia and Boynton Beach
- # of dives
- 1000 - 2499
What's your SurfGF and how does it compare to your (Rec) GFHi?
- Thread starter Jay
- Start date
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
CWK
Contributor
Rec GF Hi set to 99 so that NDL is at the theoretical maximum . Surfacing GF of 75 sets my desired level of conservatism. A long safety stop can bring surface GF of 99 down to below 75.
I believe that my last Tech dive was also with GF Hi of 75. Deco stop brings Surface GF of 100+ down to below 75.
I maintain the same level of conservatism irrespective of whether it is a Tech or Rec dive. The only difference is that in a Rec dive, I do not exceed M-value.
Shearwater
Contributor
@stuartv and @Jay, there is a philosophical consideration behind us removing GTR once you get into deco. Whenever divers go into an overhead (soft or hard), they should have a rigorous dive plan in place. This includes gas planning. GTR from a computer is no substitute for proper gas planning. One of the first warnings in our manuals reads:
I'll bring up the request once again, but it's good to have people be aware of our philosophy as described in our warnings and manuals.
No, don't.
I'll respectfully disagree with @stuartv on this one. There are simply too many opportunities for misprogramming your available gas (think: Sheck Exley and the discussion about valve full open, or 1/8 turn back), to even THINK about potentially relying on this data.
In theory, the advantage is huge. In practice, just like Communism, it won't work out.
I'll stay with your corporate stance and never display it if you implement it.
Shearwater
Contributor
In that case, it seems like you should remove GTR entirely. Because, it seems to me that the people doing recreational dives are the ones that are MOST likely to not have a proper gas plan, and to actually rely on GTR (vs using it as a simple sanity check).
Not giving GTR when in deco seems kind of like say "we're going to let pilots have GPS - but only ones that are flying visual flight plans in personal aircraft. We're not going to let commercial pilots have it, because it's no substitute for proper flight planning."
I prefer the Shearwater philosophy that I have seen of not holding the user's hand. The reason why Shearwater computers never lock the user into "Violation Gauge Mode".
Anyway.... it's really no big deal to me either way anymore. I'm only diving OC anymore for teaching and basic recreational dives when I fly without my CCR. I'm done diving tech on OC. So, GTR as it is meets my needs.
OP
Jay
Need to dive more!
I agree with you all @stuartv @Shearwater @rsingler... but I think there might be some unintended overlap in the audience of divers we're addressing our points to.
Re GTR: Part of the problem is/will always be where does Rec stop and Tec start. Either the Single Tank or One Active Gas definition works well for that answer. IMO this is what OC Rec mode should be confined to. (nb - I'm not saying OC-Tec should be changed, nor am I saying OC-Tec can no longer handle single gas/single tank). Using the One Active Gas definition might work better with two transmitters (e.g. watching a buddy's pressure, etc). Side-mount should be in Tec right ....
Given, OC Rec mode should only be for Rec divers, the unavoidable overlap will be single tank/gas divers who go into some intended light deco using OC Rec mode. There's nothing that can be done with that group to avoid them using GTR with the proposed change other than the current semi-nuke option of not displaying it when in any deco. I think that's a necessary (minor) evil that should be allowed given the larger and more important sway of Rec divers in OCRec mode:
The vast majority of Rec divers using Rec mode 'expect'/assume GTR in OC Rec mode (knowing they will do a SS; as it's programmed) that GTR tells them the gas.time.remaining WITH the known SS included. The GTR displayed will be more conservative relatively than not including the SS. I would argue for a Rec diver this is an important philosophical consideration; a known non-conservative/aggressive 'error' should not be displayed. It's also a logical assumption.
Taking this a step further, when the Rec diver stuffs up and unintentionally enters 'Deco', the diver doesn't want to have a display disappear that they were looking at / relying on. That could quickly lead to another error. They also would most likely want to know and be reassured that they've got enough gas to do what the computer wants them to do. The latter would lead to some 'comfort'/mitigation of the stuff-up.
I say 'deco' because being a 'conservative' diver they use the 'conservative' GF (which many't be a deco in a preset 'less conservative' GF).
What's the magnitude of the 'error'? At 5m, SAC 1.37 bar/min = the w.average SB diver (from @scubadada's previous poll, for a AL80) for 5 min SS you've got 10.1bar. Not trivial, nor major. Agreed ...from what we know re SB divers, we're not average ...
Confining OCRec to a single gas would also align well the Gas Edit vs. Switch proposed fix in this thread: Teric and Nitrox diving - Rec divers take care re method of changing gas (affects MOD). - i.e. in OCRec with a single gas permitted, only one gas will be Active with no other gases left on.
@Shearwater , I realise Rec has the benefit of your Tec orientation, experience, and philosophy, but in OC Rec mode for OC Rec divers, may I propose adjustments might be appropriate and perhaps necessary in order to achieve your goals for Rec divers.
Re SurfGF erring on the conservative side is great, but perhaps calc SurfGF using an 'emergency' ascent rate of 18m/min (I don't know the magnitude of the difference between that and the instantaneous version - it could be a case of it being very minor, IDK, but if it is, then I would agree it meh, otherwise something more realistic would be superior.
Re GTR: Part of the problem is/will always be where does Rec stop and Tec start. Either the Single Tank or One Active Gas definition works well for that answer. IMO this is what OC Rec mode should be confined to. (nb - I'm not saying OC-Tec should be changed, nor am I saying OC-Tec can no longer handle single gas/single tank). Using the One Active Gas definition might work better with two transmitters (e.g. watching a buddy's pressure, etc). Side-mount should be in Tec right ....
Given, OC Rec mode should only be for Rec divers, the unavoidable overlap will be single tank/gas divers who go into some intended light deco using OC Rec mode. There's nothing that can be done with that group to avoid them using GTR with the proposed change other than the current semi-nuke option of not displaying it when in any deco. I think that's a necessary (minor) evil that should be allowed given the larger and more important sway of Rec divers in OCRec mode:
The vast majority of Rec divers using Rec mode 'expect'/assume GTR in OC Rec mode (knowing they will do a SS; as it's programmed) that GTR tells them the gas.time.remaining WITH the known SS included. The GTR displayed will be more conservative relatively than not including the SS. I would argue for a Rec diver this is an important philosophical consideration; a known non-conservative/aggressive 'error' should not be displayed. It's also a logical assumption.
Taking this a step further, when the Rec diver stuffs up and unintentionally enters 'Deco', the diver doesn't want to have a display disappear that they were looking at / relying on. That could quickly lead to another error. They also would most likely want to know and be reassured that they've got enough gas to do what the computer wants them to do. The latter would lead to some 'comfort'/mitigation of the stuff-up.
I say 'deco' because being a 'conservative' diver they use the 'conservative' GF (which many't be a deco in a preset 'less conservative' GF).
What's the magnitude of the 'error'? At 5m, SAC 1.37 bar/min = the w.average SB diver (from @scubadada's previous poll, for a AL80) for 5 min SS you've got 10.1bar. Not trivial, nor major. Agreed ...from what we know re SB divers, we're not average ...
Confining OCRec to a single gas would also align well the Gas Edit vs. Switch proposed fix in this thread: Teric and Nitrox diving - Rec divers take care re method of changing gas (affects MOD). - i.e. in OCRec with a single gas permitted, only one gas will be Active with no other gases left on.
@Shearwater , I realise Rec has the benefit of your Tec orientation, experience, and philosophy, but in OC Rec mode for OC Rec divers, may I propose adjustments might be appropriate and perhaps necessary in order to achieve your goals for Rec divers.
Re SurfGF erring on the conservative side is great, but perhaps calc SurfGF using an 'emergency' ascent rate of 18m/min (I don't know the magnitude of the difference between that and the instantaneous version - it could be a case of it being very minor, IDK, but if it is, then I would agree it meh, otherwise something more realistic would be superior.
IMO about GTR and SurGF - requiring any more accuracy by adding in time spent at SS or doubling the ascent rate is really just pissing in the wind. Lets be realistic here:
How long is your safety stop? Mine varies from zero to 5+ minutes, depending on dive profile, how I feel etc.. How much gas do you breathe in a "normal" 3 minute safety stop? GTR is cool to look at, neat to know but I wouldn't ever take it to the bank - it's like one of them neat new car sensors that tells you there's a car beside you before changing lanes, cool to have but I still would look in the mirror and blind spot.
Ascent rate of 10m/minute verses 20m/minute adds/subtracts 90 seconds coming up from 100'. If you actively use and pay attention to surf GF, you'll get to understand how quickly it drops. For my aggressive profiles not into deco, I lose about 1 GF maybe every minute, slightly faster if I had to really guess - now that's at 20'. So scientifically wild ass guessing that coming up from 100' 90 seconds quicker than normal I maybe just maybe might lose 1 GF considering average depth and time. One. Really?
GTR for me is a cute concept - sometimes I play with it like trying to beat the GPS home, I see how out of wack I can get it.
Sur GF on the other hand is I think one of the greatest concepts. It allows you an accurate picture of where you are at - you the diver can decide do we stay or do we go kinda thing - that takes training and understanding though.
How long is your safety stop? Mine varies from zero to 5+ minutes, depending on dive profile, how I feel etc.. How much gas do you breathe in a "normal" 3 minute safety stop? GTR is cool to look at, neat to know but I wouldn't ever take it to the bank - it's like one of them neat new car sensors that tells you there's a car beside you before changing lanes, cool to have but I still would look in the mirror and blind spot.
Ascent rate of 10m/minute verses 20m/minute adds/subtracts 90 seconds coming up from 100'. If you actively use and pay attention to surf GF, you'll get to understand how quickly it drops. For my aggressive profiles not into deco, I lose about 1 GF maybe every minute, slightly faster if I had to really guess - now that's at 20'. So scientifically wild ass guessing that coming up from 100' 90 seconds quicker than normal I maybe just maybe might lose 1 GF considering average depth and time. One. Really?
GTR for me is a cute concept - sometimes I play with it like trying to beat the GPS home, I see how out of wack I can get it.
Sur GF on the other hand is I think one of the greatest concepts. It allows you an accurate picture of where you are at - you the diver can decide do we stay or do we go kinda thing - that takes training and understanding though.
OP
Jay
Need to dive more!
Definitely agreed re SurfGF being the bee's knees. And my next post is going to have some implementation ideas that I'd love feedback on.
But on the GTR topic, I would simply say do it once do it right - or as reasonably 'right' as you can make it, but don't make it wrong, and certainly don't make it slightly aggressive. See my math above, 10bar for an average SB breather, 20bar for a newbie perhaps, ok so the newbie shouldn't get in trouble given a forced minimum reserve but ... why bring on potential grief when you don't need to. FWIW in my head I just call it gas-to-stop, it 'works' for me, but sits wrong for me.
Knowing my dive SurfGF behaviour is something I'm not strong on as of yet. But if it is as you say, a minor difference (and it's relatively conservative too) then no one's going to disagree with you! I hope ... perhaps ...
But on the GTR topic, I would simply say do it once do it right - or as reasonably 'right' as you can make it, but don't make it wrong, and certainly don't make it slightly aggressive. See my math above, 10bar for an average SB breather, 20bar for a newbie perhaps, ok so the newbie shouldn't get in trouble given a forced minimum reserve but ... why bring on potential grief when you don't need to. FWIW in my head I just call it gas-to-stop, it 'works' for me, but sits wrong for me.
Knowing my dive SurfGF behaviour is something I'm not strong on as of yet. But if it is as you say, a minor difference (and it's relatively conservative too) then no one's going to disagree with you! I hope ... perhaps ...
OP
Jay
Need to dive more!
Re Gas remaining to target SurfGF - implementation - in OC Rc mode only.
Thanks @Shearwater for putting it on the list of potentials. I think SurfGF is/will be the (DCS) safety feature of the decade.
Knowing one's got enough gas (above reserve) to obtain the target SurfGF would be a cool tool.
re ideas on how to express/implement it ... concept: Keeping it simple and not wasting screen realestate; you don’t want/need to see it if you’re still able to comply with keeping or getting your SurfGF below target during the dive.
Given the most efficient place to decrease SurfGF is the SS, you want/need some warning before it tells you to head to your (now extended) SS, i.e. you want a chance to finish the bottom part of the dive and commence an ascent before it says do-it-now! (if you want to meet your SurfGF target). If a SS isn’t programmed, then the pre-warning still applies, just that you’ve given yourself quasi-SS.
My best implementation idea is:
Having it in the background and popping up with a blue warning box at 5mins (at depth) and a yellow (user clearable) at zero minutes telling the diver to ascend (to SS depth range) in order to achieve the targeted SurfGF given the amount of gas they’ve got left. Then it does nothing - the diver then completes his/her SS (if any) and watches SurfGF. Obviously the surface is post the SS and/or the SurfGF reduction, so when it tells you to leave the bottom, it calcs that based on a 9m/min ascent rate* and (gas used) of max(SS gas, Predicted gas to reduce SurfGF to target).
Other ideas were (typed incase they lead others to advancing them in a better way):
•Expressing it as a time at current depth until an ascent to SS must be commenced - say call it GTS: Gas to SurfGF_Target (but goes against screen realestate saving, creates yet another nemonic).
•and then when at SS depths (or above ?10m) it then displays a count-down in minutes (showing time until SurfGF_Target will be reached) <-this might be overcomplicating it, given a SS possibly would also be counting down, and you could simply watch the SurfGF number decrease when at the SS.
•Changing the colour of SurfGF or to add a background colour to warn of upcoming ascent.
•Having a green, yellow and red bar beside SurfGF.
•Having SurfGF and GTS available as a pair/combo
•When NDL increases to 'meaningless' numbers upon ascent, that field is replaced with GTS (for given current depth) <-- that mayn't be KISS/wise / muddle times/meanings.
•At depth, have GTR display the minimum of GTR or GTS; the effect is the same - go up to your SS (saves screen realestate - possibly) - or pair/combo the above - seems messy.
*One thing I quite like my slow meandering ascents (even on 'square' profiles) but I wonder if my super slow ascents from depth to 10m are in fact 'hurting' me in the sense of on-gassing i.e. a deep vs. shallow stop argument (I go at about 1/2 speed ~=4.5m/sec). It's 'obvious' from ~10m and shallower when observing the GF99 graph that a super slow ascent (~3m/min is what I seem to do) from there makes a lot of sense, below 10m, I'm not so sure - and I realise I’m merely looking at the leading theo tissue. So my question is, are variable ascents part of being smart with SurfGF. If materially so, then that’s a new thread of detail
If it’s minor fudge around the edges, then … fudge is fudge.
IDK if my ‘best’ implementation idea is best, but I do know that there's capacity for a good answer on SB with SW.
Thanks @Shearwater for putting it on the list of potentials. I think SurfGF is/will be the (DCS) safety feature of the decade.
Knowing one's got enough gas (above reserve) to obtain the target SurfGF would be a cool tool.
re ideas on how to express/implement it ... concept: Keeping it simple and not wasting screen realestate; you don’t want/need to see it if you’re still able to comply with keeping or getting your SurfGF below target during the dive.
Given the most efficient place to decrease SurfGF is the SS, you want/need some warning before it tells you to head to your (now extended) SS, i.e. you want a chance to finish the bottom part of the dive and commence an ascent before it says do-it-now! (if you want to meet your SurfGF target). If a SS isn’t programmed, then the pre-warning still applies, just that you’ve given yourself quasi-SS.
My best implementation idea is:
Having it in the background and popping up with a blue warning box at 5mins (at depth) and a yellow (user clearable) at zero minutes telling the diver to ascend (to SS depth range) in order to achieve the targeted SurfGF given the amount of gas they’ve got left. Then it does nothing - the diver then completes his/her SS (if any) and watches SurfGF. Obviously the surface is post the SS and/or the SurfGF reduction, so when it tells you to leave the bottom, it calcs that based on a 9m/min ascent rate* and (gas used) of max(SS gas, Predicted gas to reduce SurfGF to target).
Other ideas were (typed incase they lead others to advancing them in a better way):
•Expressing it as a time at current depth until an ascent to SS must be commenced - say call it GTS: Gas to SurfGF_Target (but goes against screen realestate saving, creates yet another nemonic).
•and then when at SS depths (or above ?10m) it then displays a count-down in minutes (showing time until SurfGF_Target will be reached) <-this might be overcomplicating it, given a SS possibly would also be counting down, and you could simply watch the SurfGF number decrease when at the SS.
•Changing the colour of SurfGF or to add a background colour to warn of upcoming ascent.
•Having a green, yellow and red bar beside SurfGF.
•Having SurfGF and GTS available as a pair/combo
•When NDL increases to 'meaningless' numbers upon ascent, that field is replaced with GTS (for given current depth) <-- that mayn't be KISS/wise / muddle times/meanings.
•At depth, have GTR display the minimum of GTR or GTS; the effect is the same - go up to your SS (saves screen realestate - possibly) - or pair/combo the above - seems messy.
*One thing I quite like my slow meandering ascents (even on 'square' profiles) but I wonder if my super slow ascents from depth to 10m are in fact 'hurting' me in the sense of on-gassing i.e. a deep vs. shallow stop argument (I go at about 1/2 speed ~=4.5m/sec). It's 'obvious' from ~10m and shallower when observing the GF99 graph that a super slow ascent (~3m/min is what I seem to do) from there makes a lot of sense, below 10m, I'm not so sure - and I realise I’m merely looking at the leading theo tissue. So my question is, are variable ascents part of being smart with SurfGF. If materially so, then that’s a new thread of detail
If it’s minor fudge around the edges, then … fudge is fudge.IDK if my ‘best’ implementation idea is best, but I do know that there's capacity for a good answer on SB with SW.
Similar threads
