A Closer Look at Vision

 

 

 

Menupage Inspiration 

 

A closer Look at Vision

 

Tino de Rijk, The Netherlands, April 2007 (version 1.3)

This 1.3 version is updated based on the new V02.01.03 Vision firmware release

Introduction

 

In November 2006 an experienced Inspiration diver reported a strange incident: during a dive in the Red Sea, his CO2 sensor TempStik readings suddenly flatlined, and his PO2 readings were frozen (as in: not changing anymore, stuck to the same value) on the wrist display.

 It triggered a lot of E-mails with people wondering if the Inspiration would still be life-supporting in this stage. It occurred to me that a lot of reasoning about this was by Vision and non-Vision divers that still reason with the “old” Inspiration Classic (the one with the dual handsets) in mind.

In a Classic, a frozen display typically indicates that that controller isn’t properly functioning anymore. However, the total hardware setup of the Vision is so radically different from the Classic that these comparisons have little value anymore.

 Having translated the Vision manuals into Dutch, I know that not all text about the inner workings of the Vision, and especially of the workings in case of component failure(s), is nicely put together in one place. So I compiled a set of questions, fired them off to the as usual friendly & helpful people at Ambient Pressure Diving, and as usual I got a very extensive reply back pronto.

 

The rest of this memo is split in two parts:

1)       a closer look at Vision: which component of Vision controls which function?

2)       A “what if component x fails?” section, digging into what you might see during a failure, and what it could mean to you in terms of appropriate reactions.

 

Here we go!

A closer look at Vision: which component controls which function?

 

Vision component sum-up

 

The vision Electronics consist of three controllers, three displays, two batteries, an intelligent bus, a buzzer and an optional TempStik scrubber monitor:

-          1 computer in the wrist display unit, further referred to by me as the WDC (Wrist Display Controller);

-          2 redundant, but independent controllers in the lid of the scrubber with as main function oxygen level (PO2) control, referred to by me further on as SPC (SetPoint Controllers);

-          A serial databus that connects the WDC with the SPC’s and also houses a real-time clock (RTC) to supply the logbook functions of the Vision with the correct date & time.

It also contains a “hub” to provide electrical and functional isolation in the event of a failure of any one component hooked up to the databus;

-          Physically, the databus bus is represented by the electric cables running through the rubber medium-pressure hose between scrubberlid and WDC;

-          1 LCD wrist display, built into the WDC that shows the detailed status of the system;

-          2 redundant, but independent HUD displays, comprising a green and red light each, placed on top of the mouthpiece. It is important to note that the actual LED’s themselves are located in the scrubber lid, near the SPC’s, and the light is transported to the end of the HUD through a fiber-optic cable. This was done to avoid having to use a thin, vulnerable electric cable all the way to the mouthpiece and having to use relatively big LED’s there, as in most other HUD designs.

-          2 batteries (non-rechargeable CRP2 type Lithium), placed next to the SPC’s in the scrubber lid, in a water-resistant housing.

-          A “buzzer on a stalk”, located to the left ear, and driven by the SPC’s.

-          An optional TempStik, that measure the progressing warmth front that travels through the scrubber bed as the Sofnolime progressively gets spent, causing an exothermic reaction in the process.
The measurement is done by a number of serially placed temperature sensors in the central pole of the scrubber container.

 

Functions per component

 

So, after this sum-up, let’s look at which component does what. This is VERY important in order to determine later on which functionality you may loose if a given component fails on you!

 

-          Contrary to popular believe, and probably also driven by wrong comparisons between the Classic and the Vision, the WDC is in my view NOT the most important component of Vision. Yes, it gives you a detailed view of it’s status, and it lets you control all settings of the system, but it also does NOT do some important things:

o        it does NOT control the PO2 (setpoint maintenance),

o        it does NOT control the solenoid,

o        it does NOT control the two HUD’s (that is done by the SPC’s: each SPC runs its own HUD),

o        it does NOT control the buzzer, and

o        it does NOT control power management (switching between batteries, and combining them, in case of an empty battery)

 

-          The WDC does some other important things though:

o        It contains the pressure transducer (digital pressure gauge) for depth measurement. It is located in the bottom of the WDC, shielded by the bottom plate that holds the straps;

o        It executes all CCR and OC decompression calculation functions;

o        It does control the value of the two setpoints, and (auto-)switching between them;

o        It contains the round-robin (FIFO) log memory for later readout of dive profile and warnings.

-          So, loosing the WDC does NOT mean losing a reliable setpoint maintenance, or even the ability to verify that, as the HUD’s are driven directly by the SPC’s (each SPC has its own HUD). However, you would loose your decompression information, but more on that later.

 

-          Realize also that for proper CCR deco calculations, you only need three external inputs:

o        depth (coming from the built-in pressure transducer in the WDC),

o        time (coming from its internal oscillator in the WDC; see below) and

o        PO2 (supplied to the WDC by the SPC’s, its datastream transported to the WDC over the databus).

For OC calculations you even only need depth and time and the gas mix (entered by the diver through the menu’s), nothing more; the rest is algorithm, executed by the program code in the WDC.

 

-          The RTC is located near the SPC’s on the databus; it is only used for time-stamping logbook entries (dive profile, warnings and errors). However, each controller (WDC and the 2 SPC’s) maintains its own internal tick count, based on its own built-in oscillators.

 

-          The solenoid is controlled by both SPC’s, which is also different from the Classic.
The Master SPC controls the setpoint and thus the solenoid if everything is normal and o.k., but the solenoid is linked through a so-called “wired-or” configuration to both SPC’s.
The secondary SPC (slave is actually not a good word anymore in Vision terms) also independently monitors the PO2 (through its own cell readings), and starts acting when the PO2 falls below 80% of the current target setpoint. This happens without the need to switch from master to slave, as on the Classic, and acts as a “catch all” safety-net function.

 

-          A similar thing happens for power management. Normally the primary (“master”) SPC will perform battery management (switching to the secondary battery in case of battery-low, and later combining the two parallel when both are low). But also here, the secondary SPC can intervene if the active “master” SPC is not able to perform this function properly.

 

-          The SPC’s also contain the calibration correction factors, established during calibration of the unit.
As in the Classic, each SPC calculates (during calibration) and retains its own set of correction factors: 3 of them, one for each cell.

 

Now, let’s look closer at the WDC:

-          As mentioned before, it contains the log memory, on non-volatile, round-robin, FIFO memory.
This means a “dead” battery will not cause a loss of logbook info, as unfortunately many diving computers still do.

-          The WDC receives the following data from the SPC’s over the databus:

o        Real-time PO2 info, supplied by the SPC’s;

o        Battery status info, also supplied by the SPC’s;

o        TempStik data, received directly from the TempStik (no SPC “interference” here);

o        PO2- and cell-related warnings and errors, as generated by the SPC’s.

 

-          The WDC on its turn can send commands to the SPC’s:

o        Power up/down;

o        Do calibration;

o        Change setpoint. The SPC however does a validation of the new setpoint request.
It will e.g. refuse a new setpoint of 2.0 if for some error reason the WDC would send that.

o        Switch setpoint. This is effectively a setpoint change, initiated by the WDC, either on instruction of the user (long press of center button), or by the auto-switch function, driven by passing a certain depth. Remember that only the WDC ‘knows” the current depth!

o        Warnings and errors that are not PO2-related, e.g. decompression errors and warnings. They are sent from the WDC to the SPC with the sole purpose of showing them on the HUD’s and the buzzer, as both of these are controlled by the SPC’s.

 

-          The WDC cannot trigger the buzzer by itself: it needs a SPC to do that. The same applies to displaying errors and warnings on the HUD’s.

 

 

“What if component X fails?”

 

In this paragraph I will not go into what bail-out or other actions are appropriate if a component fails.
That is up to the instruction agencies or your smart self to decide. E.g.: do you stay on the loop or not in case of a WDC or databus failure? In my PERSONAL view it is totally justified to do that, flying it on the HUD’s, but at the same time for sake of “peace of mind” I could very well defend going OC, as you have less info to draw on.

 

So by now it should be clear that e.g. auto-switching, or in fact any change in setpoint, will not occur anymore if the WDC malfunctions, or the databus link is lost. The latter was the most likely reason of the failure reported by the diver in the introduction, by the way.

 

If the databus link is lost (e.g. broken cable in the wiring loom between WDC and SPC’s, the following will occur:

-          The WDC will not show the proper PO2 numbers anymore. In the previous versions of the Vision firmware (before V02.01.03) this showed up as a seemingly frozen PO2 display.
From version V02.01.03 on the WDC will show a line of dashes (“---  ---  ---“) instead of the last received value when it does not receive proper PO2 data anymore. This will make it much easier to spot, even though static numbers in itself should already be a clear tell-tale of trouble for a CCR diver.

o        I stress the wording “frozen PO2 display” instead of “frozen computer”, as the other display functions (e.g. decompression, time, depth) continue showing valid data if only the databus fails;

-          The TempStik data will not show anymore, its black and white temperature progression bar also replaced by dashes. This was also reported by the same diver;

-          Depth and time continues to run, and is logged correctly in memory, as can be clearly seen in the logbook download file supplied by the affected diver on Internet. This includes things like ascent alarms till the very end of the dive, but at the same time will not contain proper PO2 data and/or PO2 related warnings and errors anymore.

-          Switching off is not possible anymore: the WDC cannot instruct the SPC’s to do this anymore.
(So, after the dive you will have to remove the batteries to switch the unit off in this scenario).

-          Setpoint changing (either auto or manual) cannot be performed anymore. The most recent setpoint is maintained by the SPC’s.

-          Setpoint maintenance however can be verified: a quick squirt on the manual O2 button, followed by a diluent flush, will run the HUD’s and buzzer through all main functions: rapid blinking and red due to setpoint higher that 1.6, followed by green, followed by slow blinking and red due to setpoint low, followed by green again when the SPC instructs the solenoid to open till the setpoint is o.k. again. This is a quick set of actions that can easily be performed.

-          Your CCR deco-calculations are however not linked to the actual PO2 value in the loop anymore: they will feed on the last received frozen PO2 values or, in the next version of the firmware, the current static setpoint value.
You could elect to switch the computer to OC-mode, even if you decide to stay on the loop.
This is in most cases safe because OC decostop-times are typically longer than stops for a similar profiled CCR dive, so this would be a justified action. As of firmware version V02.01.03 the unit will in this scenario default to the current setpoint value and so will act as if it is an unlinked deco computer and as such can be used safely. Very much like a Buddy Nexus or a VR3 without 4th cell!

-          Similarly, with the previous versions of the firmware (V02.01.02 or lower),  if the frozen PO2 values were close to the setpoint then the value used is again sufficiently close to act as an unlinked deco computer, and is again safe to use.  Proper dive planning should however ensure you always have tables as backup.

 

Let’s run through some other, more simple error scenario’s, to be sure we’re all on the same page by now:

-          if a SPC fails, its HUD will go off (its lights will go off), and its values will not show anymore on the WDC. (currently shown as all zeros, newer version will show as asterisks)

-          If you suspect a SPC of being frozen, do the “squirt with O2 + dil flush” test as described above. It that case the WDC can instruct the secondary SPC to take over. This SPC already has the above described “catch all” function that kicks in if the PO2 drops to 80% of the current setpoint.

-          If the WDC or databus fails, deco- and ascent-related errors will not pop up on the HUD’s, or trigger the buzzer.

-          If the WDC or databus fails, and you do not feel comfortable flying it solely on the HUD’s (which give less info than the WDC screen), you can still elect to do the ascent on OC, taking extra care when using hypoxic mixes, but go back to CC at 6 meters, effectively running it as an oxygen rebreather. You can then use the HUD as indication you should inject O2 again, as you likely strive to maintain a PO2 of 1.5 or 1.6, which will cause the HUD the blink fast. If the PO2 drops to 1.3 (assuming the last selected setpoint was 1.3), the HUD’s will go steady green, indication you to inject O2 again. Nice feature!

-          If only the databus link fails, that will show up as frozen or asterisk PO2 data and dashes in the TempStik data (if fitted), but depth and time will still run. Check it, to isolate the error. It also means the WDC is still usable as an unlinked multi-gas constant PO2 and OC computer, as described above. Or at the very least as depth gauge + timer.

-          If the last selected setpoint was 1.3, and the WDC or databus fails, the unit will NOT switch back to low setpoint at 3 meters of depth. So: stay deeper than 3 meters to avoid wasting O2. Realize also that, contrary to the Classic, the Vision will keep the solenoid continuously open if the setpoint is too low; the classic does this in 17-second intervals, followed by 6 seconds “rest”.

-          Once you get to the surface, do NOT close the O2 valves: in the stress of the situation (after all, you experienced an annoying failure), you might keep the CC mouthpiece in and get hypoxic. Better to loose all of your O2 slowly than go hypoxic! Better still: go to OC once on the surface. Once on the boat, unit taken off, close the O2 supply. You have to, as you will also not be able to switch the system off, as this is done by the WDC instructing the SPC’s…. you’ll have to remove the batteries.

A closer look at  power management

 

Now that we’ve looked at the “roles” of the WDC and SPC’s, let’s look a little bit closer to the power management functionality of vision and the way it deals with low and flat battery situations.

This is an important area, as the whole “power grid” of Vision is majorly different from that in the Classic Inspiration. In the Classic, B1 powers handset 1, and B2 powers handset 2, and that’s it.

In the Classic the handsets communicate with each other over a bus, to see if they are still alive, and the slave handset can take the master-function over from the current master if that one runs out of power, but that’s it: there is no capability to use each other’s battery power.

 

In the Vision however, each SPC is technically capable of accessing both batteries, and even use them simultaneously (in parallel) if needed. I’ll describe this functionality below in three separate scenarios.

 

 

Scenario 1: B1 running low and flat.

 

Let’s first explore the situation where B1 is running out and starts generating lower than wanted voltages:

-          In a normal situation, where B1 and B2 are full batteries, B1 powers SPC1 (and its HUD), and B2 powers SPC2 (and its HUD). SPC1 is the primary controller (i.e. “Master”).

-          B1, being the master battery, also additionally powers "the big consumers": the solenoid, the WDC (think about backlighting...) and the TempStik.

-          The WDC can see if any SPC is still present and alive by regularly sending “pings” over the databus to both SPC’s. The SPC’s on their turn respond to these “pings”, indicating “I’m alive & kicking!”.

-          If B1 now gradually looses power and drops below 4.7 volt, SPC1, being the current primary/master, will start to draw also from B2 for driving the solenoid and the WDC.

-          So now it effectively draws from both batteries at the same time, but each battery is powering different functions:

o        B1 now only powers the "core functions" of SPC1,

o        B1 has stopped powering the solenoid and WDC,

o        B2 now does the "heavy lifting", powering solenoid and the WDC,

o        B2 of course also still powers the “core functions” of SPC2,

o        and SPC1 is still the master controller.

-          If B1 drops further (to around 3.2 volt), SPC1 cannot function properly anymore, and will stop answering the “pings” from the WDC, effectively shutting itself logically (but not yet physically) down:

o        Even below 3.2V, SPC1 is still alive, but it deliberately stops responding to the databus "pings" it gets sent from the WDC to see if it is still up & running.
To the WDC, SPC1 now appears as having shut down.

o        When the B1 voltage falls below 3.2V, SPC1 doesn’t want to be considered “alive” anymore by the WDC because at such a low voltage it's analogue measurements (specifically PO2 and battery voltages) can no longer be relied upon.

o        When B1 eventually reaches 2.7V eventually, SPC1 will really shut down. This is called the “brown out” voltage.

-          Once B1 is below 3.2V, and subsequently SPC1 stops answering pings from the WDC, the WDC will instruct SPC2 to take over the primary controller function. SPC2 was and is still driven by its own B2 battery. So, now B2 powers all functions: controller, solenoid and WDC.

-          B1 and SPC1 are now effectively taken out of operation in the whole Vision setup.

-          In this case of B1 not properly powering SPC1 anymore, SPC2 can of course still answer the “pings” from the WDC, as it is independently powered by B2.

o        If you think about it, this is logical; it is a typical "chicken & egg"-problem: if B1 would also have been the sole power-supplier of SPC2, it would not be able to get promoted to primary controller, as it would be running on a flat battery....

 

It is easy to spot that SPC1 powered off, because its two HUD lights will go out.

 

So, in the above scenario, with a degrading and subsequently flat B1, SPC2 eventually ends up running the show, controlling solenoid, WDC and TempStik, and using B2 for its power.

Scenario 2: B1 and B2 both running low, but not flat.

 

In another scenario, with B1 gradually running low (but not flat), and next B2 also gradually running low (but not flat), power management eventually ends up putting both B1 and B2 in parallel mode, and draws power from them in parallel. So now:

-          B1 still powers SPC1 (and its HUD),

-          B2 still powers SPC2 (and its HUD), and

-          both batteries power the WDC, solenoid and TempStik.

 

Let's explore this scenario a bit further. Let’s assume that earlier on B1 ran low (below 4.7V), so B2 became the primary battery (powering WDC and solenoid), but SPC1 is still the primary (master) controller.  

 

This could then be the sequence of events in practice:

1.       As described above, we assume that B1 ran low (drops below 4.7V), issuing a battery warning;

2.       On request op SPC1, B2 then starts helping out, for doing the “heavy lifting”, while at the same time it also continues serving SPC2’s “core” functions;

3.       As B2 now starts to degrade faster than before (because of it having to do the heavy lifting), B1 in contrast has gotten an extension of life, because it is now relieved from having to do the heavy lifting work;

4.       If B1 and B2 now both end up running low before B1 runs flat, the "parallel" scenario as described above kicks in: both batteries will now drive the WDC, solenoid and TempStik.

 

This situation with both batteries being put in parallel is quite likely to happen, because the “relieved of its duty” B1 battery now only has to supply around 3 mA for powering the SPC1 core functions and HUD, while “heavy lifting” B2 now has to deliver up to 450 mA for solenoid, backlighting etc. as well as the power for SPC2 core functions and HUD.

 

 

Freak scenario 3: B1 running low while the WDC encounters an unrecoverable error.

 

Let’s assume the quite unlikely “freak” scenario of B1 running low, while simultaneously for whatever reason (e.g. a broken cable in the databus) the WDC can not monitor and instruct the SPC’s anymore. This means it can subsequently not switch the primary controller function over from SPC1 to SPC2 anymore.

 

This is what will happen:

1.       B1 runs low (drops below 4.7V);

2.       B1 and SPC1 will sooner or later not be able to operate the solenoid anymore, drop below 3.2V, switch off and its     HUD lights will go out;

3.       SPC2 however still has the earlier described autonomous “80% safety net” function!

4.       This means it will start actively driving the solenoid when the PO2 drops below 80% of the expected setpoint. So, the setpoint will typically be maintained at a PO2 of 0,8 * 1,3 = 1,04 bar. Good enough to survive!

 

Realize though that in this scenario you should re-calculate your deco from this point on, based on a setpoint of 1,0 instead of 1,3.

 

To me however the loss of a WDC, an SPC (as seen by its HUD switching off) and not being able to monitor the actual PO2 anymore would typically mean “bail-out” time, if only for peace of mind…

So as you can see, it is not just under manual control or in case of malfunction that there is a switch from SPC1 to SPC2 as master.

 

A note on battery choices

 

Although Vision’s battery management system is quite sophisticated, it cannot perform magic.

Basically, when fitted with good batteries, it will perform better than the Inspiration Classic, with its additional capabilities to put both batteries in parallel.

However, this automation might turn against you when fitted with bad batteries!

Let me define “good” and “bad”. “Good” for the Vision electronics is a battery that will not show sudden big drops in voltage when put under high load. A sort of worst-case high load situation is putting the backlight on “always on” and in the brightest setting, and then switching up from low to high setpoint, causing a long injection from the solenoid. A good battery will show a drop in voltage, but with only 0.5-1 volt or so.
So, over its lifetime, voltage will drop nice and slow and linear, at least until 4.7 volt, after which vision decides it is used up and will switch over to the secondary battery.

 

Now, a bad battery will “reward” such a high power drain with a sudden and unexpected dropping of its voltage to way below 4.7 volt or lower: no nice and slow linear drop in voltage over its lifetime, but a “bungeejump” drop somewhere during its lifetime instead. Bare in mind that the typical CRP2 battery is used in digital photo camera’s, where the maximum load is not that high (most cameras don't have a solenoid J…), so these big drops are less likely to occur in e.g. a digital camera.

So using good brand CRP2 batteries is very important for a proper functioning of the Vision.


If fitted with bad batteries, the following nasty scenario can occur:

-          somewhere halfway during its battery life, the battery develops the nasty habit of showing big “dips” in voltage under high load;

-          you dive with backlight in the always-on setting;

-          having arrived at the bottom, you switch from low to high setpoint, as such setting the solenoid into a long injection action – and even SPC2 temporarily!

o        an interesting phenomenon now occurs. Remember the earlier described “80% safety net” function of the two SPC’s? Well, that now kicks into action for B2 and SPC2! Why? Because you switch up from 0.7 to 1.3 bar. SPC2 is programmed to kick in at 80% of the desired setpoint, which after the switch-up is set to 1.3 bar. The 80% kick-in point is re-established by SPC2 at 0.8 x 1.3 = 1.04 bar. As the setpoint is coming from 0.7 bar however, so is temporarily below that 1.04 bar level, SPC2 now decides to give SPC1 a helping hand, by co-opening the solenoid. After having passed the 1.04 bar mark, it will stop interfering again and let SPC1 do the remaining work.

o        If you inspect your downloaded log files closely, you can see this phenomenon clearly in action. You will see a steady, flat voltage line for B2, and an frequently dropping voltage line for B1 (in sync with its opening the solenoid when needed).
However, right after a switch-up in setpoint, you will notice a one-off sudden drop in voltage of B2, indicating its temporary helping hand during the setpoint switch.

-          Being a bad battery, B1 now unexpectedly decides to suddenly drop below 4.7 volt, and B2 will be lined up to help out by SPC1. If the voltage suddenly drops all the way to below 3.2 volt, SPC1 will give up, assuming the WDC will instruct SPC2 to take over its functions.

-          However B2, also being a bad battery, suddenly now has to cope also with driving the WDC (with backlight on), and the solenoid – and decides to “reward” this with also dropping below 4.7 volt, or even below 3.2 volt, and switching off……

-          Now the system is suddenly dead. After a push on the left button, it will hopefully restart again (punishing you by showing a “start error” message as a thank-you), and if you’re smart the first thing you do is switch off the backlighting!

-          The next thing you do is try to leave the water a.s.a.p., as your power provision has become quite unreliable…

 

So, not trying to save some money by buying “cheapo” batteries is VERY important for a proper functioning of Vision. Good batteries are a.o. the Duracell, Energizer, Fujitsu and Varta batteries.
Batteries with to say the least a mixed track record are the Panasonic’s: some are good, some are bad; but do you want to find out which one you got during a dive…..?

 

Last remark: as you can see above, B2 doesn’t stay totally unused during its lifetime as backup battery. It will loose some power due to helping out B1 occasionally during setpoint switch-up’s.
So it is NOT a good idea to leave B2 always in its place, and only replace B1 when it runs low.
The two recommended scenario’s are:

-          if you are rich and want to play it 100% safe: swap both batteries for new ones when B1 runs low.

-          If you are not rich, move B2 to the B1 slot, and fit a new full one in the B2 slot. That way you have a fully loaded “safety net” in place when B1 decides it’s time to go. Why carry a spare parachute if it full of holes…?

 

 

New in firmware version V02.01.03:  battery level display and “latching”.

 

From firmware version V02.01.03 on, the WDC will show a real-time battery voltage screen immediately after startup of the system. This is a very nice addition. It will activate the solenoid from each SPC in sequence for 5 seconds, while showing all four real-time voltage values during this activation (B1 and B2, observed by both SPC1 and SPC2). This gives you good voltage information on both of your batteries under (solenoid driving-)load, giving you a good idea if the batteries you are about to use for your upcoming dive are still up to the job, or should be replaced upfront.

 

During the dive the new V02.01.03 firmware version will also “latch down” (=lock) the battery level indicators as shown on the WDC through the two battery symbols in the upper right corner.

The latch down values are as follows:

-          the battery level display on the WDC will move from 3 to 2 bars when the voltage reaches 5.25 Volt;

-          the battery level display on the WDC will move from 2 to 1 bars when the voltage reaches 5.10 Volt;

-          the battery level display on the WDC will move from 1 to 0 bars when the voltage reaches 4.80 Volt;

This latch down function means that the WDC, once having displayed a smaller number of bars, will not increase the number of displayed bars, even if the voltage recuperates because e.g. it doesn’t have to drive the solenoid for a long time because you stay at the same depth.

In previous firmware versions the number of bars displayed by the WDC would fall and rise again with the voltage levels of the batteries.

 

This software change has its small downside as well, because it will give the impression that your batteries are faster running out – while in fact nothing has changed with this firmware update that causes a higher power consumption in the system. It is just another approach of displaying voltage levels.
But if you e.g. use the backlight while you simultaneously switch up to a high setpoint, your B1 battery may drop temporarily to below 5.25 or even 5.10 volt, causing the WDC to display 2 or even only 1 power level bar, even if the battery recuperates nicely after having done its temporary “heavy lifting”. The power level display has effectively become a “worst voltage level observed, even if only temporary” display.

 

If this really puts you off, and you are sure it was only a one time big load causing a temporary drop in power, you can apply a simple (well, simple….) “trick” to restore the voltage level bars on the WDC:

1.       Switch off SPC1 (press the middle + right button and select “switch C1 off”). SPC2 has now taken over control of the system. You can monitor that by the symbol in the top left corner of the display, showing C2 now instead of C1.

2.       Next switch SPC1 back on. SPC1 becomes active, but is not the main controller anymore. The top left corner symbol is still showing C2.

3.       Next switch SPC2 off. SPC1 gets in charge again of the system. This preserves the power in B2 for use by SPC2, as backup. The top left symbol now shows C1 again instead of C2.

4.       As last action you switch SPC2 back on again. SPC2 becomes active again, but as secondary, semi-passive controller: exactly the way it was when you started this whole “trick”-sequence.

 

The net result of these 2 switch off + on actions is that the power level displays start from scratch, showing the current levels and not the previously shown lowest observed values.

HOWEVER, it is most likely a totally useless trick, as the battery level indicators will drop again to the current “voltage under load” values at the very first injection of the solenoid. So at best it will indicate for a very short time the voltage “at rest”, which is itself not a very meaningful piece of info anyway….

So all in all it is quite a sequence to pull off, just to see a short-lived higher battery level indicator to make you feel better – because nothing has structurally changed by this trick: the batteries do not suddenly have more power, or switch over later.

The only thing you did was reset the “latch down function”. If that makes you feel happy: fine….

 

 

 

Final remarks

 

I don't consider a low battery a malfunction. I consider it a lazy diver or a “penny wise, pound foolish” diver, or bad luck with a dodgy battery, but that's an entirely other discussion.....

 

Given my experiences with the two most unreliable parts in ANY rebreather (oxygen cells & batteries), the way power management in the Vision works is pretty sophisticated.

 

What remains however is that by far the best advice is to avoid power management having to kick in anyway in the first place! This is easily done by:

-          Renewing batteries in time. I swap them after some 15 hours, assuming their normal lifespan should be around a bit more hours.

-          Using good brands of batteries. Never go “cheap” in a life-support system. If I assume a new good battery costs around 6 euros (4 pound) or less, and assuming you make 15 dives of an hour with it, it will set you back a “whopping” 40 eurocents or 30 pennies for a dive. Need I say more….?

 

Recently I also observed a long discussion on one of the Inspiration mailing lists about the use of CRP2 rechargeable batteries. The conclusion, also followed by an explicit recommendation of the factory, was simple: Don’t Do It!! The whole design of the Vision power management functions is tailored, tuned and tested for non-rechargeable lithium batteries. Results with rechargeable batteries are unpredictable, and the limited testing APD has done with some of them was not encouraging at all.
So another road not to choose.

Also remember, with 2 fresh batteries you will have about 30 hours of dive time: 15 hours from B1, followed by another 15 hours from B2. The scrubber is rated at 3 hours (although generally speaking you can push out some more, using the TempStik as gauge) and the O2 on board will “only” last 8-10 hours on a full 200 bar fill.

As such you will burn the scrubber, or run out of O2 in one dive way before just even one battery gives out. So on a task-loaded long and deep dive, starting out with at least a fresh battery in B1 is a really good idea.

The power management system is like an airbag in a car: it is good to know it is there, because it may save your life in an unplanned and/or erroneous situation, but do you REALLY want to test if it works….? Me, I hope to never having to find out if it really works….

Having said that though, it is good practice to once in a while (e.g. after a software upgrade) test if it still works o.k., by allowing B1 to run low. However, in my opinion you should choose a quiet and unchallenging dive to do that.

 

That’s all. I hope this contributes to a better understanding of the Vision electronics, and effects of possible failure modes.

 Ciao,

 Tino.


 

Tino, thanks for contributing to my website!

 

Published 04-01-2007
updated 9-may-2007

Top of page

Please sign my Guestbook