Question Suunto D5 still lock out?

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!

I had the chance to get a used one at a really good price so unfortunatley I don't have $1000 to spend on somthing else in that range, but even at the good used price I am not interested if locks out so thanks for the confirmation, appreciated.
Getting one at a really good price = I don't want it and need to find someone else who will take it to cut my losses. They may be happy with the sub-standard performance since they got a 'deal' on it.
 
Or an engine that won't restart for 24 hours if it thinks you were speeding?
48 hours!
 
I think the error/"algorithm lock" is a natural result of the chosen algorithm.

RGBM is a bubble model -- the algorithm strives to calculate an ascent that doesn't result in unacceptable bubble formation. Once it thinks bubbles have formed (because you missed a stop) there is no solution to the algorithm -- it cannot compute an ascent that doesn't result in bubble formation because that's already happened.

When using Buhlman one can say "well, you're at 180% of the M-value, sucks to be you, but assuming you survived here's how long you need to stay here to get back to your GF". I don't think that option exists in RGBM. I don't think it's a tested scenario for Buhlman either but it's possible to compute something which makes mathematical sense, if perhaps not physiological.
 
You’re concerned with getting locked out if you violate a deco stop? Isn’t that like driving through red lights and expecting to not get into a crash? Why would you (or anyone) want a computer that allows you to violate a deco stop??

The problem is it can trigger when a deco stop is not required, e.g. been reported that it occured on a dive to a few m. I don't think anyone is suggesting that people should ignore appropriate deco stops then carry on regardless, rather that it either shouldn't trigger in some scenarios and when it does it is a pain becuase therre is no way to override it.
 
I think the error/"algorithm lock" is a natural result of the chosen algorithm.

RGBM is a bubble model -- the algorithm strives to calculate an ascent that doesn't result in unacceptable bubble formation. Once it thinks bubbles have formed (because you missed a stop) there is no solution to the algorithm -- it cannot compute an ascent that doesn't result in bubble formation because that's already happened.

When using Buhlman one can say "well, you're at 180% of the M-value, sucks to be you, but assuming you survived here's how long you need to stay here to get back to your GF". I don't think that option exists in RGBM. I don't think it's a tested scenario for Buhlman either but it's possible to compute something which makes mathematical sense, if perhaps not physiological.
That is an interesting way of looking at it. I bet it could be reverse calculated, but I could see that taking 10x the computing power with still unpredictable results.
 
I think the error/"algorithm lock" is a natural result of the chosen algorithm.

RGBM is a bubble model -- the algorithm strives to calculate an ascent that doesn't result in unacceptable bubble formation. Once it thinks bubbles have formed (because you missed a stop) there is no solution to the algorithm -- it cannot compute an ascent that doesn't result in bubble formation because that's already happened.
VPM is a bubble model too, and I don't recall ever hearing about such behavior associated with it. It certainly wasn't the case with my Liquivision X1 back in the day. What Suunto calls "RGBM" appears to be a collection of proprietary algorithms based to some degree or another on Wienke's model, and I think you have chalk up it's behavior to decisions made by Suunto, nothing more.
 
The problem is it can trigger when a deco stop is not required, e.g. been reported that it occured on a dive to a few m. I don't think anyone is suggesting that people should ignore appropriate deco stops then carry on regardless, rather that it either shouldn't trigger in some scenarios and when it does it is a pain becuase therre is no way to override it.
A deco stop can be triggered when it's not required??? How could you possibly know that? You're going to ignore a deco stop based on the assumption that it's not required? It may not be required by another computer, but that doesn't mean one is wrong.

And yeah, if anyone routinely drives through red lights, I'd want their car to lock them out of driving for a long time. Like forever.

Happy diving...

See post number 7 here:
 
A deco stop can be triggered when it's not required??? How could you possibly know that? You're going to ignore a deco stop based on the assumption that it's not required? It may not be required by another computer, but that doesn't mean one is wrong.

This is documented in the Suunto manual -- a "fast" ascent will mandate a safety stop. I say fast in quotes because it's not specified what the time interval over the measurement is, it's possible a reasonable change in depth or a fast movement of your arm might trigger the mandated safety stop.

And yeah, if anyone routinely drives through red lights, I'd want their car to lock them out of driving for a long time. Like forever.

Certainly suspending their driving privileges is not unreasonable, but what Suunto does is the equivalent of disabling the brakes (safety feature) while they are still speeding.

More detailed discussion here:
 

Attachments

  • 1675455834690.png
    1675455834690.png
    380.3 KB · Views: 64

Back
Top Bottom