So, Will Shearwater offer Gas Integration

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!

True, but blindly trusting a computer is best left to recreational divers who can simply ascend anytime things go wrong. For other diving, multiple sources of information and the ability to verify that what they're telling you is at least in the ballpark of being correct is prudent. For example, as you point out human error is rampant - that includes human error in setting up the computer for the dive in the first place.

Guess what happens when you simply trust what it's telling you when that happens? :D

Your right that's why you have redundant back ups
And a solid dive plan
Sent from my SGH-I337M using Tapatalk
 
Neither of these statements are at all accurate. There is NO lack of relationship between deco algo and AI implementation as the same computer has to run both features simultaneously. Period. It's how these things work. A crash in the AI-side will cause a crash in the deco side. If you look through the Aeris A300CS failures and many of the Suunto failures, you'll see that a mid-dive lockout was often pre-empted by an AI-failure. Confirming that it was AI-caused, however, is impossible. What IS obvious, though, is that added complexities (like AI) add potential failure points and hangups in the computer. The more that there is to crash, the more likely that it will. Period. Hollis DG03s had this issue for a while, and a firmware update SUPPOSEDLY fixed it. Mine had it, so I can confirm.

As for "All evidence pointing".....you provided no evidence at all. There's nothing pointing that they're separate. The fact that one processor is inputting all items to one screen means that they ARE connected. Period. The fact that one piece of firmware has to take inputs from an extra piece of hardware means that they do, in fact, interfere with eachother.

What you write is very much true, complexity generally makes things less robust, and should be avoided like a plague. On the other hand, the same can be said about adding a compass to the Petrel, and nobody is reacting quite as hysterically to it as the anti-AI crowd is reacting to the mere thought of embedding another sensor...
 
It's ALWAYS the human's fault. The human that maintained them, the human that wrote the code, the human that forged the chip, etc.
Probably irrelevant to the discussion but as a card carrying geek I feel the need to point out that computers forge computer chips, not humans. Humans do design them as far as I know. Keep one eye open just in case I'm wrong about that last part.

---------- Post added November 18th, 2014 at 09:07 PM ----------

If you look through the Aeris A300CS failures and many of the Suunto failures, you'll see that a mid-dive lockout was often pre-empted by an AI-failure. Confirming that it was AI-caused, however, is impossible. What IS obvious, though, is that added complexities (like AI) add potential failure points and hangups in the computer. The more that there is to crash, the more likely that it will. Period. Hollis DG03s had this issue for a while, and a firmware update SUPPOSEDLY fixed it. Mine had it, so I can confirm.

Seems like a lot of conjecture without detailed internal logging. Which, btw there is absolutely NO reason any dive computer should not be capable of maintaining detailed operation and audit logging of its-self. Solid state storage is so tiny and cheap a DC could probably output detailed debug logs to a reasonably dense 2mm flash wafer for a year with room to spare. Things like real time readings from all sensors, error states of the chips, etc. All those are very reasonable to log.

But, such detailed operational logging is not really a "sales" point. So far it's not been required as the result of any laws our judgements. Therefore it doesn't exist. If I'm wrong and it does exist, there should be no doubt about the accuracy of your assertion.
 
Your right that's why you have redundant back ups
And a solid dive plan
Sent from my SGH-I337M using Tapatalk

I dive with two Shearwaters, one of which is wired into my CCR, plus another pO2 monitor wired into a separate set of cells. I use all of them, and trust none of them.
 
I dive with two Shearwaters, one of which is wired into my CCR, plus another pO2 monitor wired into a separate set of cells. I use all of them, and trust none of them.

Why not wire the other petrel into the second monitor?
 
Why not wire the other petrel into the second monitor?

My backup deco and backup pO2 systems remain fully redundant this way. It sacrifices some deco accuracy since it's a fixed set point, but I'm not concerned about that. And if somehow both my Shearwaters are somehow compromised (by something like a bad firmware bug) I can still fly the unit home on tables, an analog gauge I carry, my watch, and the revodream.
 
My backup deco and backup pO2 systems remain fully redundant this way. It sacrifices some deco accuracy since it's a fixed set point, but I'm not concerned about that. And if somehow both my Shearwaters are somehow compromised (by something like a bad firmware bug) I can still fly the unit home on tables, an analog gauge I carry, my watch, and the revodream.

Unless you've done some reconfiguring, you can't wire **** into your petrel even if you wanted to.... Last time I saw it, it was a stand alone. :)
 
Unless you've done some reconfiguring, you can't wire **** into your petrel even if you wanted to.... Last time I saw it, it was a stand alone. :)

When I need to buy an EXT, I know who to talk to :D
 
divecan was asked about.
CAN bus - Wikipedia, the free encyclopedia
works just like that. Each function has its own module that then sends the data out to the main controller and any monitor. For AI they would simply have a digital pressure gauge somewhere in the head, then that would output to the controller or monitor. Same as the O2 controllers, instead of one little analog wire going out for each output, it has a core group of cables that send the data digitally out to the controllers. Identical to how airplanes and cars operate now. Much more reliable system and easy to diagnose issues with it. The AI chip would be a nonissue, but it wouldn't require any change to the controller or monitors other than a firmware update to read the data coming out and display it somewhere. Putting a wireless receiver in the computer itself would be identical for wireless AI if they could get it to function properly with bluetooth since the computer already has it. Unfortunately bluetooth is a battery hog and doesn't have a reliable enough range underwater, so it's not going to happen. The development cost to design a proper AI transmitter is a lot more than a lot of people seem to be thinking, it's not quite as simple as it looks and the ceramic pressure sensors aren't cheap to purchase and since Shearwaters target audience would never buy them *CCR and tech divers*, there's no point in them investing in it, regardless of how big the recreational market is. The Predator and Petrel were successful enough to the point that they released the recreational nitrox mode for the Petrel, but I don't think you'll be seeing much if anything else oriented specifically at the recreational market, especially since that would detract from their CCR development.
 
Despite the comments above, no one has pointed to a single concrete examples of deco algorithm failure related to AI.

Just because no one can point to an example does not mean it hasn't occurred. Is every instance in which a failure occurred reported on the Internet? Maybe someone didn't interpret a failure for what it was--mistook a failure for a valid reading. Not every failure may present itself on the display in a way that someone clearly knows it's a failure. It's not like when a failure occurs the display necessary goes blank or shows an error reading or whatever. In some cases, yes, but not necessarily in all cases.

With all of the evidence pointing to a conclusion that AI does not affect deco reliability, . . .

There is no such evidence. What there is is an absence of evidence. From an absence of evidence, we can't draw any conclusion. So it does not seem unreasonable that some of us are concerned that every additional feature can increase the likelihood that something will fail to operate in the intended way at some point.

The least of your worries would be the software. There are 'tools' that do line by line test and run through automated test cases by the thousands. Do you think a DC is more complicated then an airplane?

Right. The question is just how much effort/expense Shearwater or any other dive computer manufacturer is going to put into such testing. I used to work in the aerospace field, and as you know, the hardware and software involved was priced way way above what could be considered "consumer electronics." The simpler they keep the hardware and software of a dive computer, the more I'm inclined to believe in its robustness, i.e., that it's been thoroughly tested under all possible sets of conditions and is capable of dealing with it all. I realize that at its price point this is a bit much to expect, but I like to believe a Shearwater computer is more like instrumentation than consumer electronics.
 
https://www.shearwater.com/products/peregrine/

Back
Top Bottom