Suunto Vyper **SERIOUS BUG** in CNS O2 computation
- Thread starter Genesis
- 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
A "serious" bug would be if it waited to long to sound the alarm. This is a PITA bug, not a serious one.
That doesn't change the fact that SUUNTO's biases to the already conservative basic algorithms make their computers smash-worthy.
E.
That doesn't change the fact that SUUNTO's biases to the already conservative basic algorithms make their computers smash-worthy.
E.
Charlie99
Contributor
- Messages
- 7,966
- Reaction score
- 166
- # of dives
- 500 - 999
Are you sure about this? IIRC, one of the complaints about Suunto computers in general has been that, although you can set the ppO2 alarm to 1.6, that your allowed time deeper than 1.4ppO2 is extremely short.
Hmmm... good point.
I just re-ran the simulation on the Vyper set to 1.5, 32% Nitrox, and a depth of 110% - WELL within the MOD.
The computer toxed me in 15 minutes with a warning, and at 20 minutes with a hard error. Even though I am WELL within the MOD of the set depth!
Interestingly enough, the Vytec does not display this behavior. Set to the same 32% FO2, 1.5 PO2, it does not tox me until I actually reach the NOAA-recommended limit.
This is an interesting data point that I had not run, and points out that the Vyper's behavior is in fact a BUG, in that I have not exceeded the setpoint in any way.
This effectively means that the CNS loading computation on the Vyper is for all intents and purposes worthless, as its "acceleration" is happening any time it thinks you're beyond a 1.4 PO2, with its internal rounding, and while the rounding error is interesting, it masks the true problem, which is....
DESPITE ALLOWING YOU TO SET THE PO2 ALLOWED, THE COMPUTER THEN IGNORES THE SETTING YOU SPECIFY, AND IMPOSES ITS VIEW OF ALLOWABLE PO2 UPON YOU, WITHOUT WARNING!
In other words the PO2 setpoint function on the Vyper IS A FUNCTIONAL NOOP!
Again, the Vytec DOES NOT do this. It actually honors the PO2 you set, for each gas (it supports three.)
...given the target market of the two computers. The Vytec being marketed to a slightly more "technically" oriented crowd that may want (or understand the ramifications involved) to change the po2 stuff..
setting the PO2 above 1.4 on the Vyper O-ring?
I'd agree with you IF the Vyper allowed the PO2 to be set ONLY in the range of 1.4 or below.
But it does not do that - it permits you to set the PO2 to any value you want up to 1.6, but IGNORES any setting over 1.4 for its CNS computation, and instead does the "gross acceleration" thing - WITHOUT WARNING.
This makes the "setpoint" an effective Noop, and makes this issue a far more serious problem than a small rounding error that would only show up in a 2' window on a dive to 107' on a 32% mix.
I'd agree with you IF the Vyper allowed the PO2 to be set ONLY in the range of 1.4 or below.
But it does not do that - it permits you to set the PO2 to any value you want up to 1.6, but IGNORES any setting over 1.4 for its CNS computation, and instead does the "gross acceleration" thing - WITHOUT WARNING.
This makes the "setpoint" an effective Noop, and makes this issue a far more serious problem than a small rounding error that would only show up in a 2' window on a dive to 107' on a 32% mix.
They should at least tell you about it or leave the option off since it effectively doesn't work..
Its worse than "not working", its falsely presenting information.
I've reported the problem to the CSPC this morning. Given that they seem to be getting rather aggressive with SP/Uwatec and THEIR computers of late, it will be interesting to see if they take a similar view on this one.
If you couldn't set a PO2 over 1.4 on the Vyper, the problem would be reduced but not eliminated. If they also computed the PO2 for acceleration in the same way they computed the PO2 alarm (so you could NOT get the acceleration without tripping the alarm), which is what the documentation states, then their algorythm would be acceptable.
As it stands they do neither, and its not.
IMHO Suunto should recall the affected computers and replace them with units that either correctly compute the CNS loading or, if they wish to retain the acceleration, refuse to accept PO2s over 1.4 AND make the computation consistently for both the PO2 alarm AND the acceleration setpoint.
Similar threads
