[PATCH 3/4] When merging non-overlapping dives, add surface events in between

[Jef Driesen]

On 21-11-12 18:17, Dirk Hohndel wrote:
> On Wed, 2012-11-21 at 17:56 +0100, Jef Driesen wrote:
>> On 2012-11-18 19:18, Linus Torvalds wrote:
>>> Most of the dive computers I have access to don't do the whole
>>> surface
>>> event thing at the beginning or the end of the dive, so when you
>>> merge
>>> two consecutive dives, you got this odd merged dive where the diver
>>> spent the time in between at a depth of 1.2m or so (whatever the 
>>> dive
>>> computer "I'm now under water" depth limit happens to be).
>>>
>>> Don't do that.  Add surface events at the end of the first dive to 
>>> be
>>> merged, and the beginning of the second one, so that the time in
>>> between
>>> dives is properly marked as being at the surface.
>>
>> That's maybe something we should deal with at the libdivecomputer
>> level? Maybe we should consider adding "endpoint samples" (with zero
>> depth) when they are not automatically provided by the dive 
>> computer. I
>> wrote some overview about that (and other sampling issues) some time
>> ago:
>>
>> http://www.divesoftware.org/libdc/sampling.html
>
> That is an excellent discussion of the issue. What I think would make
> sense for most modern dive computers (and I'd consider the Suunto
> Solution as a "oh well, too bad" case here), is to extend the first 
> (and
> last) descent (and ascent) speed to the surface. So if the samples 
> don't
> start / end at the surface, take the speed that the first two (and 
> last
> two) samples imply and extend that out to the surface. That might 
> change
> the duration of the dive by a few seconds (Subsurface already does
> manipulate the duration, anyway) and it might create the awkward
> situation that the first sample at the surface gets a negative time
> stamp (maybe you should then simply shift the whole series so that it
> starts at 0 again), but to me that seems like the more reasonable
> approach here.

I think using the ascent/descent rate for this purpose is a not such a 
good idea. First of all, many dive computers record an almost flat tail 
at the end of the dive, because the typical logic to end the dive is "X 
samples at a depth shallower than Y meters". In that case, you end up 
with at least X samples that are close to the surface, but not necessary 
exactly equal to zero. If you then calculate the ascent rate it will be 
close to zero (or even slightly negative if you have bad luck). Second 
reason is that most dive computers use a fixed sample rate. Extending 
using the ascent/descent rate may result in timestamps that are not a 
nice multiple of the samplerate. And last but not least, it may take 
more than one sample to reach the surface and thus increasing the total 
duration even more.

Simply adding a zero depth sample at the begin/end of the dive is 
easier, and not necessary worse. Negative timestamps are indeed not such 
a great idea, and shifting back to zero is probably the preferred 
solution.

BTW, at the time I wrote the document on the sampling issues, 
libdivecomputer didn't support the DC_FIELD_DIVETIME api yet. The dive 
time had to be calculated from the sample data. That's I preferred to 
keep the duration of the samples as close as possible to the real dive 
time. Now this is less of an issue. The DC_FIELD_DIVETIME can easily 
compensate for manually inserted endpoint samples (or for example the 
surface samples at the end of the dive for devices like the 
sensusultra).

>>> The logic for "time in between dives" is a bit iffy - it's "more 
>>> than
>>> 60
>>> seconds with no samples".  If somebody has dive computers with
>>> samples
>>> more than 60 seconds apart, this will break and we may have to
>>> revisit
>>> the logic.  But dang, that's some seriously broken sample rate.
>>
>> Unfortunately, they do exist. The Suunto Solution (a very old 
>> device)
>> uses a 3 min sample rate. And then there is the Oceanic variable 
>> sample
>> rate, which is *really* ugly. If the depth remains constant, there 
>> are
>> no samples recorded at all.
>
> Well, as long as the Oceanic computers don't create new dives for 
> that
> scenario it doesn't hurt us as we should only apply the logic that 
> Linus
> describes BETWEEN dives (but I need to look at his code to be sure).

I assumed (and I also haven't looked at the code yet) from Linus' 
description that any samples more than 60 seconds apart would be 
affected, regardless of where they are in the profile. That's why I 
responded to tell there are such devices out there.

I wanted to test this with some data from a Solution, but then I 
noticed an even bigger problem. Subsurface can't even download the dives 
from a Solution at all. I assume that's because the Solution doesn't 
store a date/time, and libdivecomputer will return 
DC_STATUS_UNSUPPORTED. So all dives will end up with the same (default 
initialized to zero) dc_datetime_t structure. I guess this does confuse 
the subsurface auto-merging, and discard (or merge?) all dives, except 
the first one.

> Still... a 3 min sample rate? That's a joke. That's not even worth
> plotting a graph for.

The Solution is one of the first dive computers to supported 
downloading dive profiles. So back in those days (15-20 years ago?) it 
was probably state of the art :-)

Jef