Discussion of Latest Vision Article by Tino.

Tino de Rijk

I have submitted an updated version of my "A closer look at Vision" into the library (that is: tried to, but Stuart pointed out I cannot do that, so he has to clean up the mess.... Sorry, Sturart... :-) ).
Main addition is a part at the end dealing with bad batteries & what they cause in the system if you use them. This was driven by a logfile someone asked me to inspect after some strange behaviour.
As with previous versions, it has been scanned by "the powers that be" within APD so should not contain nonsense - I hope....

you can find it here:
http://www.rebreatherworld.com/inspi...ok-vision.html

Have fun reading it!

Ciao,

Tino.

schford

This thread is to discuss the latest indepth and insightful article Tino has written abotu the Vision electronics.

You can read it here - http://www.rebreatherworld.com/inspi...ok-vision.html

__________________
Bailout and Kit Management account for Murphy's Law

The only bad question is one you did not ask and later wish you had.

Use of RBW is subject to the Rebreather World Terms & Conditions of Use

AD_ward9

Tino, you have written a good article and your update is very welcome.

The items raised here are two small issues:

1. "If a SPC fails, its HUD will go off (its lights will go off), ". This depends on the failure. The HUD may not go off.

2. Please could you clarify if the idependence of the two Vision SPCs. believe they have the same master-slave relationship as the Classic. This means that the master must be working properly in order to hand over to the slave. Are you able to clarify this issue?

Alex

bambang

Awesome stuff dude...!

I downloaded them to my Memory stick for future references, I hope you do not mind.

Bambang.

Gill Envy

Tino, Thank you for posting your article, it's very informative on the details of the controllers. Your explanation has helped me get a more detailed understanding of the vision's specific needs, although ever since I started reading about some of the anamolies and then experiencing some myself i've been aggressively gathering information from reports and personal experience that have lead me to the same conclusions about what habits are critical to proper functioning.

Like Alex, I am interested in looking into the relationship of the visions SPC's a bit more closely.



As I have noted in a "few" other threads, it seems that if either the battery in B1 out right fails or a significant contact issue occurs, the whole system can become dissabled.

I'm wondering if there is any way to fix that without a major redesign, because while these scenarios are rare, if using the proper battery and assuring clean contacts, the fact that they can happen at all reveals a common failure point... not true redundancy.

My evolution in thinking toward a fourth cell has been fuelled by this revelation. Back up deco and po2 on a totally independent 3rd party monitoring system has always had an appeal to me just as a general precaution but now i'm feeling a little more adement about it as I am considering going beyond recreational limits.

__________________
Gill Envy

...Because I wasn't born with gills!
><(°>><(°>><(°>><(°>><(°>><(°>><(°>><(°>

PCDiver

Hi Gill,

I was thinking about a 4th cell as well. Then I started using proper batteries (not Panasonic) and I've dropped all 4th cell ideas. No problems at all since swapping to Duracel/fuji.

The moment I venture in the 100 meter region, I will be looking at a 4th cell again. I'm comforable with the Vision + backup VR3 (not linked) with my current diving (70 meters).

Peter

Gill Envy

Peter, I hear you. I definitely don't have the Hebe Jebes like a did for a while, now that the true cause of many of the timing issues has been identified (perhaps my persistant posts helped with that ).

But, that said, the fact that there is a common failure point leaves me wondering what other unforseen scenarios might cause a total system failure due to sudden voltage drop...even Duracell puts out a bum battery on occasion (although i'm very glad to hear that the new version of the software has a load test in the predive check). I carry a 40cf BO on even recreational dives to 130fsw that involve little to no deco. As I will be venturing deeper longer, and into significant deco, I don't want to get so out on a limb without a truly redundant system (maybe i'm paranoid...but hay, i'm still alive!).

When I can turn on the vision and pull the battery from B1 and have B2 pick up without the screen going blank and everything turning off i'll consider the system truly redundant. this will leave me confident that the system can handle the rare but possible bad battery (even with proper brand), a B1 contact failure or a user screw up like mixing up the the batteries when changing and accidently putting a low battery in B1.

All that said, i've had no problems either since sticking to a somewhat conservative regimen with Duracell's (Swapping out the batteries when the read out dips to one bar at the end of the dive/ascent during heavy load-solenoid firing), chucking after 17hrs of use, using batteries that are well within their use by date, Buying in bulk/holesale so i'm not tempted to save a few pennies by pushing the limits).

g

__________________
Gill Envy

...Because I wasn't born with gills!
><(°>><(°>><(°>><(°>><(°>><(°>><(°>><(°>

Tino de Rijk

Alex,

Ad 1.: I have not seen reports on this phenomenon as such yet, so it remains a general theory applicable to any piece of hardware (speaking from 30+ years of experience in IT infra....). The design however of the HUD controller is such that the only possible cause of the LED staying on is if the switch driving the LED shorted out. In this case the LED would go to full brightness (and as such would stick out, compared to the other HUD, unless that was also set to full brightness; so a tip: don't put the HUD's to full brightness). You would then be able to verify its correct operation still on the WDC (moving cell values, in line with the other SPC, etc.). If this was the only failure, the remainder of SPC would continue to provide life support; it just doesn't show up properly anymore on the HUD. In all other SPC failure cases the design is such that the LED *will* go off. But again: not seen reports about that so far, here on RBW or on the Inspiration list.

Ad 2.: First of all: your statement about the Classic is wrong. The master does NOT have to be functioning properly in order to be able to hand over to the slave. It is the slave that takes the initiative to promote itself, seeing the bus signal drop from the master. So the master doesn't hand over, but the slave takes over. This is very easily demonstrated my switching of the master, or even more extreme remove the master battery "in mid air": slave will take over seamlessly even though the master has no time to react. Also architecturally confirmed by my sources in APD.

In the Vision, there is no "master/slave". The best way to describe it is it has two masters at the same time: one running the system at 100% of setpoint, and one (trying to) run the system at 80% of setpoint. If all is well, the 80%-SPC will never have to get into action, as the setpoint is always above 80% of the desired value. The 80%-SPC has full access to the solenoid at all times (same for the classic, BTW). So forget about master & slave, call it a 100%-SPC and an 80%-SPC.
BTW: I described a scenario in my article where the 80%-SPC comes into action and shows it can indeed run the solenoid as well, in parallel: that is during a normal setpoint switch-up (from 0.7 to 1.3), either manual or automatic. Happens during every dive, and is perfectly normal, given the Vision’s design.

In "normal" handover conditions (e.g. battery low) it is not the other SPC but in fact the WDC that sees one controller dying, after which it instructs the remaining controller to go to 100% mode (if the remaining one is the 80% controller). So the 80%-SPC never "promotes" itself to 100%-SPC by itself: only the WDC can instruct it to do that. This is by design; it could easily be altered, also in the current HW/SW design, but APD has chosen to design it like this.
If both the 100%-SPC AND the WDC die (a very, very unlikely scenario, but still...) the remaining controller will continue running the system at 80% of setpoint, still communicating with the diver thru the HUD. It does not have to do anything special to do this, e.g. promote itself to master or something; it continues in its normal mode, but just observes the setpoint dropping as the 100%-SPC ceased action. In this extreme case you have lost deco-info though (that comes solely from the WDC), so in that extreme case, if you decide to stay on the loop, you need to reset your backup-computer (e.g. VR3 or Nexus) to a setpoint of 1 instead of 1,3, as 0,8 * 1,3 = 1,01. Or, of you happened to be at low setpoint, to 0,6 (as 0,8 * 0,7 = 0,56). Once you reach 6 meter, you could run it manually to 1,6 without risk of overshooting. The remaining HUD will show you if you indeed up'ed your setpoint manually succesfully by flashing fast, as it considers this a "PO2 high" condition.

As to Gil Envy's worry about successfully handing over control: I did a very simple test in my shed. I started the system and watched the WDC show normal values (plus an alarm for "low PO2", as I was having the scrubber lid in my hand, exposed to a PO2 of 0.21). Then I opened the battery-room and removed B1.
SPC2 took over without a glitch, as shown in the upper left corner of the WDC ("C1" changes into "C2", indicating the new governing "100%-SPC") .
Then I put B1 back again: SPC1 immediately comes up again, but as "slave" (i.e. 80%-controller). This is verifiable by keeping the left button pushed: SPC1 supplies correct PO2 values again. Next I removed B2: control jumps back to SPC1, SPC2 shows zeroes. Put B2 back again: SPC2 wakes up & shows normal PO2 values.
All as you would wish & expect. But it is nice to see it indeed also works as documented.
Can't try this in diving conditions: a bit hard to remove a battery then...... But the principle of taking over seamlessly has nothing to do with diving mode or surface mode: important is the seamless handover - including pending alarms (in my case the "low PO2" alarm. If it works in surface mode, it should also work in dive mode: from a HW-technical point of view the same.

I hope this is enough explanation, and enough detail. If you want technical details about the inner-bowel workings of Vision, you have to go to APD yourself.


Ciao,

Tino.

AD_ward9

The IT experience is probably not a good indicator here, because things like disk drives failing or electolytics running dry on the motherboard tend to dominate the failures, however, you have seen enough faulty memories and the effect these can have on a program. In an operating system it causes the program to hang. In an embedded application such as a rebreather controller, it can cause one part of the program controlled by a watchdog or interrupt to work fine but the part controlling the PPO2 to misfunction. This is why high SIL safety systems double store variables in memory (See the guide I suggested, NASA-GB-8719.13, Appendix H if I recall correctly).
I am afraid it does. I can show you faults where the master hangs. Just try it: put a very short glitch on the power to hang the processor (after Sept 2000, it has to be under 10us, before that any brownout would do it). You will find the slave will not take over but the master has completely hung.

Thanks for describing the improvements in the Vision in more detail.

Alex

Tino de Rijk

All nice theory, Alex, but I repeat: do you have any proof this in fact ever happened in a Vision....? Untill that moment it remains what we call FUD: Fear, Uncertainty & Doubt. You don't know if any of the things you suggest have indeed been implemented in Vision.
There are BTW other methods, like checksumming memory. The debate about double caches or checksummed memory e.g. went on for years & years on EMC's SAN systems versus HDS' SAN systems.

As to your other point: that is not what you asked in your original post. You said, and I quote: "This means that the master must be working properly in order to hand over to the slave." That is simply not true, both for the Classic as well as the Vision. What you describe is a situation where for some reason the Master keeps the bus signal high. with the recent Classics (as in:last 5 years or so......) It takes quite some tricketry to get it done, and even if you manage to get that done, you will easily spot a hanging master (cell values do not move anymore) and a still-working slave (cell values still move).
For the Vision even this scenario is impossible, as I described. The slave does not promote itself anymore, and is always active.

Any CCR diver should always watch for non-static, moving cell values: it is part of "always know your PO2". So, if he spots the situation you describe on a Classic, the remedy is quite simple: switch off both, switch slave on first, then master. Almost 100% chance the previous slave will come up as perfectly working master. And it is also quite likely the ex-master will come up again as a perfectly working slave, but that is beside the point here: we're only looking for another working master. If not: OC bailout time. Both makes you survive perfectly o.k.

Ciao,

Tino.