Ascent rate and other stored information

[Jef Driesen]

On 2012-04-17 17:07, Björn Spruck wrote:
> Am 03.04.2012 10:04, schrieb Jef Driesen:
>> Just to give an example, the ascent rate could be stored as a 
>> numeric
>> value (e.g. in m/s), an index into an array with ranges (e.g. 0-5,
>> 5-10, 10-15, 15+), etc. Because every model can have its own set of
>> ranges, you need all of them. And that's just for the ascent rate. 
>> Is
>> this really worth the trouble? I would say no, especially because
>> ascent rate can be calculated from the profile data. The results may
>> deviate slightly from the values reported by the dive computer, but 
>> is
>> that really a problem?
>>
> Actually, yes, because this is an "instant rate" based on the 
> sampling
> rate of the DC, while the one recalculated is from the stored 20s
> intervalls.

Are you sure about that? There is only one ascent rate value recorded 
for the entire sample interval. The dive computer can indeed sample more 
frequently, but in the end it will only record a single value. That 
value could be the minimum, maximum or average value within the sample 
interval, but regardless of how it's obtained, it will always be an 
approximation. Instant and interval don't really mix well.

I doubt the differences between the recorded and calculated values will 
be very high anyway. Especially with the relative short sample intervals 
that are used nowadays. And if the dive computer uses ranges to express 
the ascent rate, there is already a huge amount of rounding going on, 
which is probably greater than the differences due to using a calculated 
value.

Note that another advantage of calculating the ascent rate from the 
depth profile is that it will always yield a consistent result, 
independent of the type of dive computer you used. And last but not 
least you'll also have an ascent rate for dive computers that don't 
record that type of information.

> But it is a very nice example, because in this case it is really easy 
> to
> store the information in a way to satisfy most (all?) models:
> Store a numerical lower and upper bound, the values (corresponding to
> the integer values) can be found in the dive computers manual.
> I see this as an opportunity to think now (based on the knowledge of 
> the
> data of current DCs) to make decisions on the data formats.
>
> At least here it would be really bad to relay the work to the 
> front-end.
>
> The back-end should give values to the front-end in a way that the
> front-end does not need to know anything on the DC model to display 
> (or
> interpret) them correctly.
>
> Another example is the "deco" flag behaviour: (I mentioned this 
> before)
> Some computers store a start and end deco flag. some flag all samples
> where deco is "on".
> Here I see the task of teh backend to "translate" that to some 
> uniform
> behaviour. (either start/stop for all (prefered), or continous
> flagging). Thus having a uniform behaviour from the front-end view.

Don't get me wrong, I absolutely do want to move the interpretation as 
much as possible into the backends. That's exactly the reason why I want 
to get rid of the sample events as they exist today. They were never 
really carefully designed, with an inextensible format as the result. 
Removing them from the api right now and passing them as raw binary data 
instead, will allow us to re-introduce them later on, once we have 
figured out a more appropriate format.

But it's not a trivial task due to the many different formats and 
feature sets. And certainly don't forget it's also a very time consuming 
process. Adding a single new field means reverse engineering that piece 
of info for all 20+ backends and even more different models.

>> That's why I want to concentrate on the essential pieces of
>> information and make sure those are very well supported. Squeezing 
>> the
>> last bits of info out of the data is a huge amount of work, while 
>> the
>> majority of the applications won't need it.
>
> Essentials are different for different people ;-)

Of course! But I think you'll agree some are more essential than 
others. Things like date/time, divetime, maxdepth, gas mixes (e.g. the 
stuff you would write down in a paper logbook) are likely more essential 
for the majority of people than let's say ascent rate. I'm not claiming 
ascent rate is a useless piece of information, but only that it has a 
lower priority.

Also my resources (time) are limited, so I rather prefer to satisfy the 
majority of people with a more limited but well supported set of 
information, than to spend huge amounts of time on features that are 
little used.

Maybe a good start would be to make a list of what kind of information 
we consider essential and would like to see supported? Once we agree on 
what we want (or not), we can start discussing the corresponding data 
formats.

> PS: maybe this discussion should continue on the list?

Indeed.

Jef