“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.