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

[Dirk Hohndel]

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.

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

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

/D