Re: Better diluent - gas change in new firmware
Date: April 19, 2019 01:31PM
The last post is a really good one, because it touches the underlaying question: what is the duty of a dive computer in technical decompression diving?
Propably everyone will agree on that in technical deco diving, one doesn't simply jump in and will take a look on the computer from time to time to see how the deco obligation evolves during the course of the dive. Instead, the dive is pre-planned and its maximums are established: max. depth, max. bottom time and turn press at least. That numbers should be known by the diver, additionally they can be put on a slate for backup-brain.
Now come the options: do i have one or two computers? One computer can fail for various reasons, so a printed run table for the main dive plan along with an independet depth and time gauge is required. Having a plan B table (+ a few minutes and/or meters) in the pocket won't hurt either. In case of two computers, the likelihood of both of them failing completely during the same dive is rather small. Still, if they are same brand and type, what they display can suffer from systematic design or programming failours. In terms of software complexity, depth and time gauging/displaying is rather simple and least likely to be compromised. Calculating a deco schedule is quite complex, and results depend on numerous details like - just for example - the personal gas switching protocol discusses earlier. That is also why very few computers produce identical data even if settings are the same. In the middle of both is the calculation i would call "as of now": current tissue pressures, saturation levels and thus ceiling depth / next stop depth. These data should be in line with the pre-planned dive-table, given the dive was done according to the plan so far. +/- 1 minute doesn't matter here. So here we have the first duty a dive computer can take: check if i am still within my plan as of now.
So what's with the calculated complete deco schedule? Several options: online replication of offline planning results from Multideco and other deco planning software. Hard job. Deco planning tools as of today have lots of options to shape the computations to personal preferences and diving protocols. Most documentations do not disclose how computations are affected in detail by the settings. So 1:1 replication in general isn't possible. Additionally, putting more options into the code makes it more complicated and raises the propability for programming errors.
Another option: replacement of the plan B tables, i.e. calculation of the current "no frills" emergency deco schedule - how to get to the surface within shortest time / gas demand, with the gases still available (-> lost gas function), while staying within Buhlmann + GF limits, fullstop. That's what the OSTC firmware is geared to now. If you have two computers and have reasonable trust in their computations, they could be used to replace the printed tables entirely. Else, or with one computer only, the number of plan B tables could be reduced, using the computer to give emergency schedules for intermediate + time / + depth scenarious, as well as a solution in case of a totally messed-up dive (hopefully never needed).
How to gain trust into the computer's calculations / verify its programming: The build-in deco calculator uses the deco schedule prediction code, thus the most complicated part of the OSTC firmware. The simulator runs in real-time and exactly as during a real dive, just that the depth can be manipulated. Running a planned dive in the simulator in real time thus checks the programming of the "as of now" calculations. As more you rely on the computer in handling your what-if scenarious of your dive, the more you should run them beforehand in the deco calculator and the realtime simulator to gain confidence that they'll work as expected when needed.
So to cut a long story short, the OSTC in its present form is made to back-up a dive, giving ceiling and next stop depth data for "as of now" plus a shortest way home (surface) controlled emergency schedule. When using the gas needs calculation function, it will also prompt when running out of resources for even an controlled emergeny ascent.