Nitrox and computers

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!

They added 3 conservatism settings: Conservative, Normal, and Progressive. But, they don't tell you what any of them are or do. And you can only change that setting from the app on your phone. You can't change it on the computer itself.
 
They added 3 conservatism settings: Conservative, Normal, and Progressive. But, they don't tell you what any of them are or do. And you can only change that setting from the app on your phone. You can't change it on the computer itself.

A more detailed explanation would be very welcome, it's all very secretive.

It's interesting that they added both a more conservative and a more liberal setting to the default, normal setting. If this is adjusting the GFs of the Buhlmann ZHL-16C algorithm, that would be encouraging. I'd love to see what the air NDLs for the progressive setting look like, to compare to the table I included in post #34
 
If it's just using pure Buhlmann with different GFs, then they should make public what those parameters are. As much as people talk about concerns of liability, it seems like the OEMs would WANT to use a non-proprietary algorithm and to make public what they are using. Not to mention that I would expect industry pros and more knowledgeable non-pros would feel more comfortable recommending the computer to new divers.

That said, I suspect that a lot of these "Buhlmann-based" computers are actually implementing an algorithm that is a very dumbed-down version of Buhlmann, replacing a lot of actual, real-time computations with pre-calculated table lookups, in order to reduce the computing power required of the processor in the dive computer itself. Thus making it less expensive to manufacture. And meaning it's not really implementing Buhlmann - just something that approximates Buhlmann (conservatively) within the limits of recreational sport diving.

But, that's definitely just speculation on my part....
 
If it's just using pure Buhlmann with different GFs, then they should make public what those parameters are. As much as people talk about concerns of liability, it seems like the OEMs would WANT to use a non-proprietary algorithm and to make public what they are using. Not to mention that I would expect industry pros and more knowledgeable non-pros would feel more comfortable recommending the computer to new divers.

That said, I suspect that a lot of these "Buhlmann-based" computers are actually implementing an algorithm that is a very dumbed-down version of Buhlmann, replacing a lot of actual, real-time computations with pre-calculated table lookups, in order to reduce the computing power required of the processor in the dive computer itself. Thus making it less expensive to manufacture. And meaning it's not really implementing Buhlmann - just something that approximates Buhlmann (conservatively) within the limits of recreational sport diving.

But, that's definitely just speculation on my part....

Your speculation may very well be correct.

Maybe Deepblu will tell us. Maybe Pelagic Pressure Systems will tell us about PZ+, increasing conservatism by increasing the altitude category by 1 has never seemed very sophisticated to me. I'm not holding my breath waiting for any of this information.
 
... replacing a lot of actual, real-time computations with pre-calculated table lookups, in order to reduce the computing power required of the processor in the dive computer itself. Thus making it less expensive to manufacture.

You have to wonder, though: at which point using commodity ARM A9 setup becomes cheaper than sourcing a custom "less powerful" microprocessor. OSTC 4 has some kind of "dual-core CPU" and runs Buhlmann and VPM-B side by side already. There's plenty of quad-core versions of A9 or you could go fancy with A17 and their shiny! big-little setup...
 
Other than being cheaper, I'm not sure what the cosmiq offers that other computers don't. Shearwater has had bluetooth connectivity for years. They have an app you can connect to if you'd rather use a cell phone than a PC or Mac.

In any event, to the OP. I don't think there are any currently manufactured dive computers that do not support nitrox. I looked a few years ago and could not find even one. Buy what you want on features/price - nitrox support is going to be there unless you buy used.

I know a lot of people who use the zoop with nitrox. Changing your mix is not as big a deal as some in this thread have made it out to be. As with any dive computer, you should spend time and get familiar with it. You'll be glad you did later.

That doesn't mean I'm recommending suunto by the way. There are a lot of things about their computers that I don't like. I own two shearwater petrel, and one Scubapro Galileo Luna. I like both models, as each offers something the other does not.

Also, keep in mind that your LDS may actually have the best price on a dive computer. Some manufacturers allow dive shops to offer "in store" discounts that they can't advertise. Scubapro is one example. I'm not saying don't buy online, but at least check your local dive shop (LDS) first. If prices are competitive, and you ever need to get it worked on.. the LDS will most likely be a faster route if you've bought from them.
 
You have to wonder, though: at which point using commodity ARM A9 setup becomes cheaper than sourcing a custom "less powerful" microprocessor. OSTC 4 has some kind of "dual-core CPU" and runs Buhlmann and VPM-B side by side already. There's plenty of quad-core versions of A9 or you could go fancy with A17 and their shiny! big-little setup...
Excellent point. nVidia Tegra is another example. I've often wondered why in the heck most DC's don't use ARM or Tegra chips. It's certainly way way more processing power than needed for a dive computer. If you aren't stressing them with a huge load (I see no reason why existing DC functions would) then they have excellent power consumption. Even somewhat older models in the phone world would be far more than needed for a dive computer.
 
You have to wonder, though: at which point using commodity ARM A9 setup becomes cheaper than sourcing a custom "less powerful" microprocessor. OSTC 4 has some kind of "dual-core CPU" and runs Buhlmann and VPM-B side by side already. There's plenty of quad-core versions of A9 or you could go fancy with A17 and their shiny! big-little setup...

Excellent point. nVidia Tegra is another example. I've often wondered why in the heck most DC's don't use ARM or Tegra chips. It's certainly way way more processing power than needed for a dive computer. If you aren't stressing them with a huge load (I see no reason why existing DC functions would) then they have excellent power consumption. Even somewhat older models in the phone world would be far more than needed for a dive computer.

I agree with y'all. I fully expect, at some point, that some commodity DC OEM will go to some garden variety processor that is used in the mobile space.

I suspect that the delay may be as simple as already having code implemented that works on their existing chips and it's easier and cheaper to just keep reusing that code than to port it to an ARM or whatever. Well, and the "watch" processor that (I assume) they're using in a lot of these DCs probably saves them at least $2 or $3 on the cost to manufacture. :)

Plus the power consumption bit. Can you even imagine a watch-sized device that uses any ARM or similar processor that could run for a year with a coin-sized battery? If you think about what a Geo 2 or Atom 3 does, combined with the fact that it will easily run for over a year on one coin battery, it's pretty darn impressive, really.

I was looking at the OSTC4 and noted that they calculate Buhlmann and VPM simultaneously, letting you switch between algorithms on the fly. I have not used a Shearwater with the VPM upgrade, but it would not surprise me if the SW does not let you do that.

OTOH, what I got from reading the OSTC4 manual is that you configure your VPM and Buhlmann conservatism factors before you start the dive. You configure one CF for VPM and 2 different sets of Gradient Factors for the Buhlmann side. One Buhlmann set is your set that you plan to use and the other set is your emergency contingency set. I.e. you might configure 30/70 and 95/95. My understanding is that once you start the dive, you cannot change any of those parameters. All you can do is switch between which of the 3 alternatives you are currently using. If that's true, I'd have to say I like the way Shearwater does it better. I don't expect to ever change any of those parameters during a dive. But, if I decide I want to, I'd rather be able to set them to whatever I want than be locked into choices I made (or forgot to make) before the dive started.

Caveat: I could be totally wrong about the OSTC4 and not being able to change the GF during a dive. The manual did not say that explicitly. I inferred that limitation from what I read.
 
That said, I suspect that a lot of these "Buhlmann-based" computers are actually implementing an algorithm that is a very dumbed-down version of Buhlmann, replacing a lot of actual, real-time computations with pre-calculated table lookups, in order to reduce the computing power required of the processor in the dive computer itself. Thus making it less expensive to manufacture. And meaning it's not really implementing Buhlmann - just something that approximates Buhlmann (conservatively) within the limits of recreational sport diving. But, that's definitely just speculation on my part....

There's no need to dumb down anything. The calculations for N2 TC loading, NDL, and deco ceilings are all based on straight forward equations (see Baker's papers if you are interested). What certainly is stored in a table are the Buhlmann ZHL-16C m-values for a 100/100 GF. Simple calculations can be done to get the m-values for the Hi and Lo GF's entered by the diver. Retrieving data from tables is generally faster than calculations but speed is only an issue for slow processors. As Dmaziuk points out there are quite a few very fast controllers available for dive computers. The limiting factor is memory because the real estate available is limited. This limits the amount of data you can (or want) to put into tables. A large chunk of memory must be reserved for storing data for the logs.

stuartv:
I was looking at the OSTC4 and noted that they calculate Buhlmann and VPM simultaneously, letting you switch between algorithms on the fly. I have not used a Shearwater with the VPM upgrade, but it would not surprise me if the SW does not let you do that.

I have Buhlmann and VPM on my Shearwater Perdix. Buhlmann comes with the computer. VPM is already installed but is locked until you cough up money to unlock it. The algorithm can only be selected via the system setup menu which is disabled during the dive. Both algorithm don't need to be running concurrently. Switching to the alternate algorithm on the surface will use the TC loadings which were stored by the previous algorithm.
 
Last edited:

Back
Top Bottom