PresentationPDF Available

On the reliability of dive computer generated run-times (23.02.2022) Part VI: Error Propagation

Authors:

Abstract

On the reliability of dive computer generated run-times, Part VI: Error Propagation Abstract: Here, in Part VI, we only point out to the law of error propagation. During the previous 5 parts ([1] to [5] and all the references therein), we observed by some of the dive computer manufacturers deviations from documented algorithms/decompression models. Additionally to these software-driven variations are those, driven by hardware and the statistical errors by measuring ambient pressure, time, temperature and the inertgas contents of the breathed gas-mix.
1
On the reliability of
dive computer generated run-times
23.02.2022, Part VI:
Error Propagation
Miri Rosenblat, TAU
Nurit Vered, Technion Haifa
Yael Eisenstein & Albi Salm,
SubMarineConsulting
DOI:
2
On the reliability of dive computer
generated run-times, Part VI:
Error Propagation
Abstract:
Here, in Part VI, we only point out to the law of error propagation.
During the previous 5 parts ([1] to [5] and all the references therein), we
observed by some of the dive computer manufacturers deviations from
documented algorithms/decompression models. Additionally to these
software-driven variations are those, driven by hardware and the statistical
errors by measuring ambient pressure, time, temperature and the inertgas
contents of the breathed gas-mix.
Introduction: slides # 3 & 4
Error Propagation: slides # 5 8
References: slides # 9 & 10
Attachment: slide # 11
3
Introduction (1):
The variance of the TTS, Δ TTS, i.e. the delta-„time-to-surface
between the TTS calculated by a dive computer, be it @ run-time, i.e. in the
water, or on the desk with the planning tools, vs. a TTS of a printed diving
table is basically a linear combination of these 3 elements [8]:
modifications of algorithms & constants, that is the manufacturers decision
to modify a documented (& sometimes tested) published algorithm or the
related constants, for eg. water density, ambient air pressure at start of
dive, the respiratory coefficient, etc. …
purely software driven deviations, mainly through high level language
compilers (FORTRAN, C, etc.) during compiling & linking:
truncations
rounding off/ -on
the precision / binary word-length of the used variables
floating point errors through the linked mathematical libraries
purely hardware driven, i.e.: uncompensated, systematic errors
AND statistical measurement errors
4
Introduction (2):
That is:
Δ TTS = TTS TableTTS Dive Computer
Δ TTS = Σ modifications + Σ software + Σ hardware
with the TTS, the „time-to-surfacedefined as:
TTS = sum of all stop times + ascent time (+ transit times)
TTS = stop times + (bottom depth / ascent speed)
The error contributions from term 1 (Σ modifications), and at least partially,
from the 2nd. term, Σ software, were covered in Part I Part V of this series;
here in Part VI we look exclusively at the error propagation of the 3rd. term:
Σ hardware, [8].
5
Error Propagation (1):
The calculated inertgas pressure Pt within a compartment of
any deterministic decompression model, be it a perfusion-, diffusion-,
bubble-model or any (linear) combination thereof is basically a function of the
3 variables ambient pressure (pamb), fraction of inertgas in the breathing mix
(fInert) and dive-time t:
Pt(t) = P(pamb, fInert, t) (1)
i.e. the change, the error that is, of Pt is found in its total differential:
dPt(t) = (δP/δpamb ) * dpamb + (δP/δfInert) * dfInert + (δP/δt) * dt (2)
by neglecting 2nd. order variations and errors/variations in time and other
variables, a Taylor expansion gives the variation of Pt(t) and reduces
approximately to:
∂Pt(t) pamb * ∂ fInert + fInert * ∂pamb (3)
(pls. cf. attachment, slide # 11)
6
Error Propagation (2):
∂Pt(t) pamb * fInert + fInert * pamb (3)
The first term of (3) reflects variations in the composition of the breathing mix,
i.e. the error of the gasanalyzer, whereas the second term reflects the
variations in depth, i.e. the error in the pressure reading, that is the intrinsic
errors of, for eg. a piezo-sensor. Both errors have to be added!
A real dive profile consists of consequtive pressure jumps, measured by a
dive computer every n seconds. The then calculated Pt(t) is used as the start
value for the next pressure jump, thus the errors are accumulated with each
step. As the analyzers and piezo errors are each in the range of ca. 2 to 5 %,
so are then the errors for calculated NDL / stop times etc. for each step the
sum of these errors, neglecting all the other possible errors!
This is quite in contrast to a calculation for a table-output for a standard box-
/square profile: as there is only one time step (the bottom time) and only one
pressure jump (the bottom depth), the error from (3) is limited in comparison
to a dive computers calculation in real-time.
7
Error Propagation (3):
This, as such, would be a minor problem, if it were not for:
the (usual, non-professional) diver, watching his/her dive computers
display, lured into a false feeling of the safety of his/her device, thinking:
„Wow, a computer display! And Ahh: with 1 decimal place:
then it must be precise!“
the (usual) dive computer manufacturers euphemisms in the technical
specifications of their products concerning the precision of the used piezo
(=pressure)-sensors. There are abundant tests from independant sources,
showing the manufactures negligence in: compensating the usual piezo
drifts (temperature, age, voltage), the errors through pressure offset
against vacuum & clock jitter and the quantisation noises.
That is: besides the statistical errors through measurements there are the
manufacturers modifications from prescribed & documented (& sometimes
tested) algorithms on-top, leaving the user (diver) completely in the dark
about function and safety; i.e. the dive computer presents itself as a totally
intransparent black-box.
8
Error Propagation (4):
That is: usually the dive computers manuals and/or
on-line documentation concerning these things are either:
cryptic, or incomplete, or flat false, or:
any combination of the above.
Up to now, the complete set of the dive computers hardware with its
soft-/firmware does not comply to any safety-& security standard,
for e.g.: a safety-integrity level like the SIL from IEC61508 (except one
singular box, the BIO350 from Open Safety Equipment).
Nevertheless, as a pure data-logger, i.e. an electronic recorder of the dive-
profile, a dive computer could give useful information, esp. for forensic
assessments.
As well, large binary collections of the really dived profiles could be used
to improve statistically based decompression calculations, like theDiver
Safety Guardian“ from DAN!
Still, all the recommendations / conclusions from the previous
Part I to Part V yield here as well.
9
On the reliability of dive computer
generated run-times, Part VI
References:
[1] Rosenblat M., Vered N., Eisenstein Y., Salm A. (26.07.2021)
On the reliability of dive computer generated run-times, Part I;
DOI: 10.13140/RG.2.2.16260.65929
[2] Rosenblat M., Vered N., Eisenstein Y., Salm A. (11.01.2022)
On the reliability of dive computer generated run-times, Part II;
DOI: 10.13140/RG.2.2.11343.41126
[3] Rosenblat M., Vered N., Eisenstein Y., Salm A. (02.02.2022)
On the reliability of dive computer generated run-times, Part III;
DOI: 10.13140/RG.2.2.21973.50405
[4] Rosenblat M., Vered N., Eisenstein Y., Salm A. (22.02.2022)
On the reliability of dive computer generated run-times, Part IV;
DOI: 10.13140/RG.2.2.11469.72169
[5] Rosenblat M., Vered N., Eisenstein Y., Salm A. (07.02.2022)
On the reliability of dive computer generated run-times, Part V;
DOI: 10.13140/RG.2.2.18129.81763
10
On the reliability of dive computer
generated run-times, Part VI
References:
[6] Vered N., Rosenblat M., Salm A. (2021) Synopsis & Fact Sheet
DIVE Version 3_11,
DOI: https://dx.doi.org/10.13140/RG.2.2.17024.56326
[7] Rosenblat M., Vered N., Eisenstein Y., Salm A. (2022) Recovery of
selected ZH-86 air-diving schedules via a decompression shareware
DOI: 10.13140/RG.2.2.34235.13609
[8] Salm, A. (2012) Variations in the TTS: where do they come from?
International Journal of the Society for Underwater Technology, Vol 31, No 1,
pp 4347
The „Diver Safety Guardian“ :
https://www.diversafetyguardian.org/
DAN, the „Divers Alert Network“: https://dan.org/
11
Error Propagation, eqn. (3) on slide #6:
... For the Shearwater Perdix running the ZH-L model this is covered in-depth in Ref. [5]. ...
... & IV, the TTS of the Predix follow closely the ZH-L 16 C algorithm for air dives (ref.[5]), the G2 TEK is always more conservative: the proximity to the values with the Bühlmann Safety Factor (table II, column[3]), particularly the schedules with longer bottom times, insinuates either a proprietary modification of the original ZH-L16 coefficients or an undocumented "safety feature". But this is open to conjecture and no further conclusions can be drawn: the presently available documentation (per 07/2022) for the G2 TEK does not specify precisely the used N 2 -coefficient set & the water density. ...
Presentation
Full-text available
On the reliability of dive computer generated run-times, Part VIII: G2 TEK Abstract: Here, in Part VIII, we performed some basic comparisons with the highly topical SCUBAPRO / Uwatec mix-gas dive computer Galileo 2 TEK / G2 TEK along the SHEARWATER PERDIX. Both have been set to a standard perfusion model ZH-L 16 without and as well with gradient factors.
... During the previous parts I to VI ([1] to [6] and all the references therein), we observed by some of the dive computer manufacturers deviations from documented algorithms/decompression models with simulated dives on sealevel (SL), whereas Part VII covers a test at reduced ambient pressure of ca. 0.8 Bar, i.e. a mountain lake at a ca. ...
Presentation
Full-text available
Here, in Part VII, we performed an altitude test, i.e. the simulation of diving in a mountain lake. During the previous parts I to VI ([1] to [6] and all the references therein), we observed by some of the dive computer manufacturers deviations from documented algorithms/decompression models with simulated dives on sea-level (SL), whereas Part VII covers a test at reduced ambient pressure of ca. 0.8 Bar, i.e. a mountain lake at a ca. altitude of 2.000 m above SL.
Presentation
Full-text available
Here, in Part X, we offer our conciliatory proposal of a performance benchmark for diver-carried computers, as these devices are usually sold as “black boxes”, i.e.: the end-user, that is: the diver, is kept completely in the dark concerning the safety/security performance of his/her equipment. This yields also for desktop decompression software. As well dive computers and decompression software offer deviations from proven algorithms/dive tables which go unnoticed by the divers resp. are undocumented from the side of the diving-equipment manufacturers.
Conference Paper
Full-text available
On the reliability of dive computer generated run-times: Synopsis Abstract: Here we give as a closure to this series a synopsis on the previous 6 parts. During the 6 parts of „On the reliability of dive computer generated run-times“ Part I --> Part VI, we observed from some dive computers manufacturers deviations from documented algorithms/decompression models. Additionally to these software-driven variations are those, driven solely by hardware and the statistical errors by measuring ambient pressure, time, temperature and the inertgas contents of the breathed gas-mix.
Presentation
Full-text available
On the reliability of dive computer generated run-times (22.02.2022) Part IV Here, in Part IV, we checked the DCIEM implementation of one SHEARWATER® dive computer with the original source, the air diving table from the DCIEM Diving Manual [1] along selected table entries. Conclusion: the manufacturers claims on using the DCIEM model could be verified only partially, since deviations with longer bottom times surfaced.
Presentation
Full-text available
On the reliability of dive computer generated run-times: Part III Here, in Part III, we checked 3 simple run-times with bottom depth 18 m / 60 min, 33 m / 60 min & 51 m / 30 min bottom times on air with the RATIO iX3M DEEP from Dive System® in comparison with the original source, the ZH-86 from A.A. Bühlmann [2] and DIVE Version 3_11 [1] & [3]. Conclusion: the manufacturers claims on using the ZH-L16B set of coefficients with a certain set of pre-defined gradient factors could not be verified.
Presentation
Full-text available
On the reliability of dive computer generated run-times, 11.01.2022, Part II Abstract: Here, in Part II, we checked a simple run-time (bottom depth 45 m / bottom time 30 min on air) with the 3 different dive computers in comparison with the original source, the ZH-86 from A.A. Bühlmann and two free-ware desktop deco-programs. Results: there is substantial variation in the TTS: these variations could not be substantiated with the dive computer manufacturers claims. The original source claims to use a „safety sur-charge“: this as well could not be verified for the choosen particular dive schedule here.
Presentation
Full-text available
Abstract: in Part I we checked a simple run-time for a dive with: @bottom depth 42 m / bottom time 25 min. with 2 breathing gases (air & Trimix21/50) with the Scubapro/UWATEC G2 computer with various firmware releases from 2017 up to now (08 / 2021). Methods: pls. cf. slides # 3 to 11, and References [1], [2] & [4], [5] Results: there is variation in the TTS from 10 % up to 21 %, depending on breathing gas and user set conservativism Discussion / Recommendations: pls. cf. slide #12 & 13