Hammerhead's Delrin vs Vision Electronics

Steve

Excellent summary Dave. This thread seems to be a back and forth discussing which fat ugly chick to ask out instead of looking at the fit hottie. To each their own I suppose.

__________________
WARNING: I contain occasional coarse language, extreme sexual references, nudity, and adult themes, which may offend some people - Usually churchy types.

Liquid G

Same for me thanks, Hammerhead on my inspo, plus a hammer CCR, sold the new vision ages ago due to it being crap with the single handset and not having two totally redundant handsets. The Hammer is more expidition material by far. I still dive a classic as well, with normal electronics, thing is bullet proof and it does what you tell it. Had huge problems on the vision when the damn left side button malfunctioned when I went into a menu underwater, you do not want to know as after that I could not exit the menus, get info ,change setpoint or anything. Also busted 2 screens so far from.... heat, not abuse. It is a very nice unit for non expedition or cave type guys. Really wish they never moved to the single handset system.

The scrubber on the hammer is also way better,so is everything else in regards to machining etc. Drawback like downloading never worried me in the least, once again ,it is more a question of what your parameters are for deciding, for us it was easy, expedition,serious dives,happy to stay alive....we are now soley powered by HAMMERHEAD

Gerhard du Preez

Tino de Rijk

Joe,

Your responses suggest that you think the Vision has an intelligently switched power system, i.e. some sort of (power)hub that intelligently and selectively distributes power to the two controllers, and can cut it on demand.
That is NOT the case. It is in fact far simpler.

Let’s look at the following statements about the power system, which I have verified with the factory guys developing the Vision HW & SW. C1 stands for Controller 1, C2 for Controller 2, B1 for Battery 1, B2 for Battery 2 (same abbreviations as in my “Closer look at Vision” article, for consistency).
With “controller” I refer to the two controllers in the scrubberhead, not the wrist display controller (WDC), which functionally, as you stated correctly, actually only acts as “remote dumb screen” and “remote keyboard” as far as PO2 control goes.
It DOES have an independent function as to depth/deco/logbook/setpoint change functions, but that is outside the scope of this discussion here on the powersystem.
The PO2 control is not done by the WDC in any way or fashion, and as such can be lost without hampering the setpoint maintenance.
In fact, you then still have TWO displays (albeit rudimentary, like any HUD), as each controller has its own independent HUD. Many people still don’t understand that the Vision has a fully redundant dual HUD, not just one.
They are even galvanically separated from each other, as they are fibre-optic driven.
So loosing the single handset means loosing the keyboard (& deco info, but we all do carry backup tables, don’t we…? J) but not all of the displayed info on the functioning of both controllers. A simple dil flush will also quickly and easily verify proper operation of the controllers on the HUD’s (green à slow blink or red à green again), i.e. tell you if the controllers hang or not.

But: back to the main subject of a shared power system and its implementation.
The following statements are true:

• C1 ALWAYS has access to B1, and C2 ALWAYS has access to B2. This is hard-wired, like in the Classic. So there are no scenarios where the controllers do not have access to their own primary battery.
• C1 cannot block/prevent C2 to access its own battery (B2) in any case. In fact, powerpaths are never blocked; they are just sometimes not used by a controller.
• It is a sort of cross-bar power grid, with two always-on hard-wired primary power paths (C1/B1 and C2/B2), and two optionally selectable additional power paths (C1/B2 and C2/B1). These are effectively also always-on, just not always used.
• It is the controllers (C1 & C2) themselves that decide which powerpath they use, but the powerpaths themselves are always available to them. They are never blocked.
• C1 does not in any way interfere with the way C2 chooses its power paths, and vice versa.
• The power-sharing functionality is limited to C1 and C2 being able to OPTIONALLY also draw from the opposite battery (C1 from B2, or both, and vice versa), but the primary power path is always open/on and used.
• It is hard-wired functionality, i.e. a major f*ck-up of a fried or locked C1 still always leave the powerpaths of C2 to both B1 and B2 open.
• All of the CPU watchdog timers run off internal independent RC oscillators so the only thing that will stop them is no power and if they have no power neither does the CPU, so no point in going any further.

So there is no use for “timescales” as there is no “intelligent” power allocation: it is always-on hardwired paths that can be selected by each controller at will.


As to your statement “ Look at all the updates that have been done with regard to the power system. Tells me they haven’t been happy with the performance and reports of weird actions still keep showing up...” I have the following observations.
I scanned the release notes of the four SW releases that were sent out since January 2006. First of all, 4 releases in 2,5 years is not massive, and in line with the frequency of updates I see for e.g. the Shearwater of Hammerhead.
I have merges the four sets of release notes into one single document, which I have attached to this post for easy reference.
The only references I can see to power system changes are these two:

• “The battery switching is now latched. If a battery falls below the switch over value, the next battery selection is activated and latched, (once it switches – it stays switched, until power up restart). This ensures the batteries will be used in the sequence B1, then B2 then B1 + B2 together, regardless of how much a battery recovers after solenoid activation.”
• “New battery indicator switching levels: 3 to 2 at 5.25 volts; 2 to 1 at 5.0v ; 1 to 0 at 4.80v. Low battery warning and switch to 2nd battery at 4.8v.“

The latter one only involves the way the battery level is shown on the WDC. It does not affect the functionality of the power system.

So can you point me out where “they were not happy with the performance and reports” and “all the updates that have been done”…? I can’t see them…

As to the “weird actions popping up”: can you point me to them, especially with the latest SW release, that is out now for 8 months..?

I respect your personal choice for another, more “shared-nothing” architecture, and think the HH is a decent piece of kit (no personal experience yet, but two of my mates use it happily), but thought that the power system observations needed some adjustment.

Ciao,

Tino.

Attached Images

Merged Vision release notes.pdf (21.5 KB, 18 views)

jradomski

Tino,
You misinterpreted some of my comments (after rereading them some arent as clear as I would like)... I am aware of the hardwired aspect of c1->b1 ect, but unless c1 has a way of disabling c2 from using the battery, effectively c2 can deny c1 proper use of the cell IF for some reason its drawing excess current.. (and vice versa).. Thats the problem with shared power.. There are ways around it but it complicated the power design considerably.. and if c1 has a way of disabling c2 that could be a problem as well in certain conditions!

To me just the possibility of this without a built in method to protect is a problem no matter how remote it is.. I should have been more clear about how power use decisions were made..

btw since its introduction the HH has had virtually no software big fixes, just additional functionality with each new version.. there was a deco big fixed early on but thats really it (there are a few non critical bugs in the current software that need to be fixed)... most of the hardware tweaks have been to try and reduce the chances of problems.. by and large there have been few problems when you compare it to the number of handsets out there but even one is too many.. Some people never had any issues some had a bunch...

I would never consider the hud a redundant display...it does give you information and will allow you use of the loop with a degree of uncertainty.. There are ways a single handset form factor could have been used to give a true redundant display.. a second isolated cable into an isolated compartment of the same handset with a bare minimal display is a viable solution..

if you look at the hh changes there has only been 1 real change - rev a units used a 7.2v (nominal) power source, where as rev b,c and c+ (current) have the same power supply design and can use any voltage source >1v and less than 10V..

a common problem with microcontroller is that when they do lock up they tend to use alot more current than they are supposed to use..

__________________
Joe Radomski
CCR Trimix Instructor Trainer
ANDI Instructor Trainer Director #10

All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated.

Tino de Rijk

The Vision has not had any hardware revision/upgrade since its introduction. The only alteriation has been to get rid of the dark spot problem in the WDC, but that did not affect the core HW design in any way.

As to redundant HUD: I did not mean that I consider it a redundant replacement for the WDC. I will ALWAYS prefer (moving) numbers over (binary) lights. I fully agree with your qualification of "info with a degree of uncertainty".
With redundant I just meant to say: there are two HUD's, not just one.

For the rest, as I said: personal preferences. I respect yours, and see where you come from (or go to...? ). I had no intention to make the HH look bad; I take great care these days to restrict my comments to stuff I know personally.
I think there is room enough in the market for multiple good designs. I just happen to think the Vision is one of them, as well as the HH.

My post wast purely meant as informational: nothing more.

ciao,

Tino.

jradomski

Tino,
I understand where you are coming from and just wanted to clarify my point.. I have nothing against the vision and like the ergonomics.. I would use it for any reasonable length dive where I know I could easily carry 100% of my own bailout, on dives where I really have to plan to share gas, I rather have a design like the classic that IMHO alows me a greater chance to stay on the loop a bit longer...

Kevin's business model is a good one, come out with an upgrade every few years, offer a good price for the previous rev and many of your customers will go for it.. It keeps them on the cutting edge and it generates revenue.. Its one thing that I wish other manufacturers in the dive industry would do.. Right now Kevin effectively gives greater than a 50% discount on the upgraded unit, and he has been treating all his the same whether its a rev a or the last al handsets... If AP did this I doubt there would be many classics out there.. even I would do it for backup as a recreational unit..

__________________
Joe Radomski
CCR Trimix Instructor Trainer
ANDI Instructor Trainer Director #10

All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated.

divetheworld

Just so we're clear.
The updates for the Shearwater are to add functionality such as splash screens, 0.19 surface modes, semi-closed function and other value add properties. We have only two "fixes" applied in all our versions.

Brent

__________________

Tino de Rijk

If you would bother to read the merged release notes of the SW updates I attached to my previous post above, you'll notice the same applies to the Vision: the vast majority of changes is tuning in functionality (e.g. raising CNS from 80 to 100%, battery level indicator latching), adding new functionality (e.g. better depth sensor failure handling, moving from 6 to 12 selectable gasses, battery testing-under-load function, suppressable warnings) and fine-tuning (e.g. changing the window in which the system moves from continues injection to progressive injection from 0.05 to 0.2 bar from setpoint).

The number of "fixes" is quite limited, with the main one being the "missed deco/CNS/OTU" saga and associated on/off switch sensitivity adjusting.
That one took two releases to get right.

"Just so we're clear": any reason you are being so defensive on the Shearwater (which I consider one of the decent systems in the market, FWIW) in an Inspo forum on a thread about the Vision power system and the HH...?
AFAIK I have never said anything nasty about the Shearwater - which cannot be said about you & the Inspo.

ciao,

Tino.

divetheworld

Simply a statement of fact, to which I fail to see how it could be interpreted as defensive.
Tino, your last comment may be taken as baiting. Please try to restrain yourself, it detracts from an interesting thread. Try do get over our previous diffences or we will never be able to debate in a mature manner.

Brent

<furher thoughts>
I think that a great deal of those who debate the "which is better than which" generally have a mindset of what they prefer and judge a system based on their metric. There are sufficient differences in every units control system feature lists that, IMHO, make it an apples for oranges comparison.
To make an example;
Unit A hs two or more 'true' redundant handsets but only one has solenoid control.
Unit B has two seperate controllers which each can control the solenoid but not the level of redundancy of unit A.
Which is better? That depends on the user.
To summarise, one systems philosophy may or may not fit better with the users requirments and personal comfort. But better? Not quite so easy to define.
There are further factors which should be considered. The HH and the Deep Pursuit replacements for the Classic are small volume in comparison, and for a beginner there will be the liklihood that on dive boats and small groups, the inexperienced will not be able to benefit from others experience in the same way that you would with a system that has more market penetration. 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.

__________________

Tino de Rijk

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.