Hammerhead's Delrin vs Vision Electronics

In this respect, and the architecture of what is discribed as 'true' redundancy I agree with others that state that these systems are more suited to advanced users.
For advanced users, a failure of the system with insufficient 'real' information may be seen as a drawback which is why some of the premier cavers prefer these types of systems with multiple truly independant handsets.

Overlooked that remark previously, Joe.
Yep, that is true, but even if it doubles or triples compared to its normal current draw, it is still quite small compared to the big "offenders", i.e. the solenoid and backlight. We're talking quite efficient processors here, power-wise.
Given such a scenario, there are again two sub-scenarios. Let's suppose it is C1 that hangs/freezes and draws a relatively big current:

• if it is drawing power from the powerpath to B1, the powerpath from C2 to B2 is still clear, so C2 can still properly function.
• if it is drawing from both B1 and B2, the current draw will also be split over the two powerpaths, so will halve on each path, as the current draw from C1 will not get higher just because it has access to two powerpaths. So also in this case C2 will still have access to slightly higher than usual loaded powerpaths. They are not blocked.

The CRP2 batteries used in the Vision are pretty powerfull, at typically 1300 mA a piece. At 6 volts that is almost 8 watts. A typical AA Lithium (e.g. Energizer) does at best 3000 mA at 1.5 volt. The 3.6 volt ones (e.g. Saft LS14500) do 2250 mA, which is roughly the same as a CRP2: around 8 watt. So it would take quite a current draw from the hanging processor to cause havoc to the remaining non-hanging processor, having access to two powerpaths from which either one is still free, or both are half loaded by the offending hung processor.

So I guess it would take a hang from a processor with simultaneuosly AND the backlight full-on AND while driving the solenoid (effectively stuck-open) to cause a serious problem for the remaining processor. Even in that situation it will take many minutes to hours, not seconds, before both batteries run flat. The system can handle that simultaneous load, as can be easily seen during e.g. the battery test or calibration sequence during power-on, in which the solenoid is open for a long time, and both processors are simultaneously active with testing/calibrating.
In the meantime the remaining running non-frozen processor will only have to pick up the problem and notice the user, and in this (unlikely) extreme case issue a "high PO2" and/or "solenoid stuck" error warning on WDC and/or HUD/buzzer. I would expect that to last for hours to minutes, certainly not seconds.
That would of course mean the need for manual control of PO2 by use of the cylinder valve while the remaining processor still has power to indicate PO2, or OC bailout.

The same applies to an architecture like HH or Shearwater with only one active component (active as in: PO2 indincating and driving the solenoid) and a separate passive backup (passive as in: PO2 indicating, but not solenoid driving), where the active component hangs or freezes while driving the solenoid.

A weak point might be that in that scenario you will not be able to "hard" switch off the offending processor, as the Vision only has soft switch-off, and you might doubt if a hanging processor will still react properly to a "power-off" signal coming from the WDC.
This however also applies to other hardware architectures that only have a soft on/off, and many times have the power-off capability disabled while in divemode (which is very defendable IMHO).
I believe this applies to both HH and Shearwater, but am cautious in that statement as I don't know them well enough, and see lots of sensitivity here when I dare mention a (non)feature of another system than the Vision.
no doubt you or Mr. Hudson will correct me if I'm wrong...


ciao,

Tino.

Tino,
The HH does not have a hard off, so if there was some issue that it got stuck driving the solenoid.. I PERSONALLY would just flood the battery compartment...

You are right the big draw would be if it locked when the solenoid or backlight was engaged... But I can tell you from experience even VERY low power processors can draw alot of current when the Hard crash (not a software crash)..

There are also other considerations that I can't speak for namely what current the power supply is capable of independent of the batteries.. just because the cell can deliever current doesnt mean th PS can..

As you say, personal preferences. I know enough "others" and "advanced users" that do not agree with you. They prefer the level of automation offered in an active/active setup, reducing the additional taskload of having to do manual control in a difficult situation - especially in a cave where both hands are often needed with reels, lines, lights, etc.

As to the max. current draw capable: don't know that, but even here: suppose C1 is going wild, and draws so much power its own (independant!) powersupply fries as well - then it would just kill C1, not C2, who has its own powersupply (if you mean the typical power reducing chip on the circuit board that reduces power from variable DC 4-6 volt to, say, the 1.2 volt DC the processor needs).
Still do not see that affecting C2 in its operation, other than running through its available power more quickly. Or do I miss something....?

ciao,

Tino.

Fair reply, Joe, thanks. I would not bother to flood something (and that would be impossible on the Vision anyway, as it is a bit hard to reach behind your back, open the yellow case, then the scrubber head, and then the battery latch. I fear you would then also run a tiny risk of flooding & a twisted arm, I guess.....).
I would just close the O2 valve and either run manual from the valve, semi-closed for a while (at depth), or just be chicken, but a safe chicken, and go OC. Better safe & dumb than sophisticated & dead.....

As to the max. current draw capable: don't know that, but even here: suppose C1 is going wild, and draws so much power its own (independant!) powersupply fries as well - then it would just kill C1, not C2, who has its own powersupply (if you mean the typical power reducing chip on the circuit board that reduces power from variable DC 4-6 volt to, say, the 1.2 volt DC the processor needs).
Still do not see that affecting C2 in its operation, other than running through its available power more quickly. Or do I miss something....?

ciao,

Tino.

Tino,
I PERSONALLY would just flood the battery compartment...

Wouldn't that create a problem with LiIon batteries? Salt water and LiIon don't seem to mix very well.

If there was a direct short, such as in the windings of a solenoid, how would the system in the vision respond? Does the electronics have a solenoid failure detection which stops the current draw, or would it continue to try to fire the solenoid? Is the system limited in the amount of current it can supply in this circuit, as the battery depletion times would be based upon that figure.

It does feature a solenoid failure detection function. That can already be seen in action as part of the startup self-test functions. Same for the buzzer.

Wouldn't that create a problem with LiIon batteries? Salt water and LiIon don't seem to mix very well.