Pro Plus 2

[Dirk Hohndel]

On Jan 15, 2012, at 8:45 AM, Jef Driesen wrote:
>>> It's this timestamp that is causing the trouble in your case. Normally with a
>>> time based sample rate, there is a fixed number of samples per time unit. For
>>> example a 15s samplerate will always have 4 samples per minute. But that
>>> assumption is violated in your problematic dive. There are 5 samples with a
>>> timestamp of 37 minutes. I have absolutely no idea why the dive computer does
>>> this. It's the first time I encounter this.
>> 
>> But that shouldn't be a problem, if you then spread those evenly and
>> give us an artificial 12 sec resolution. Subsurface makes no assumptions
>> that the sample rate has to be constant.
> 
> The spreading only happens for the depth based sample rates. For the normal time based sample rates, we assume the number of samples per minute is fixed. This is a perfectly fine assumption, except that Philip happens to have a dive with one extra sample at the 37th minute. We currently fail to parse this anomaly, because if we would continue the timestamps won't be strictly monotone anymore. In the worst case (e.g. more than one extra sample), time may move backwards.

Instead of failing to parse, you could simply drop the extraneous sample - that would be much more user friendly, don't you think? After all, the rest of the data from the dive should be usable…

> This particular dive has a 15s sample rate, so normally you would see these times reported (where X is the timestamp in minutes, as stored in the data):
> 
> X:15
> X:30
> X:45
> X:60 (= X+1:00)
> 
> X+1:15
> X+1:30
> X+1:45
> X+1:60 (= X+2:00)
> 
> But if there is a 5th sample, you would see this:
> 
> X:15
> X:30
> X:45
> X:60 (= X+1:00)
> X:75 (= X+1:15) <- Identical timestamp as the next sample!
> 
> X+1:15
> X+1:30
> X+1:45
> X+1:60 (= X+2:00)
> 
> We could workaround this by using the same workaround as for the depth based sample rate, and distribute those 5 samples evenly (causing trouble for apps that assume a fixed sample rate). Or just ignore the presence of the timestamps in the data for dives with a time based sample rate. In that case the timestamp reported by libdivecomputer will go out of sync with the one stored in the data. This seems to be what Oceanlog does, although I wouldn't rely on it too much, because I have seen suspicious things there already (like having two samples with the exact same timestamps), and certainly with those depth based sample rates. No wonder they dropped that feature in the newer devices :-) Another alternative would be to just skip the extra samples, and pretend they are not there.

Here's the moment where libDC gets to define the semantics and make them reasonable, and the software that uses libDC (MacDive, DivingLog, Subsurface) can then rely on that semantic. So once you release version 1.0, you should simply define that there is NO SUCH THING as a guarantee that the samples are evenly spaced and that instead the user of libDC has to take the time information in every sample into account.

In that case you can simply distribute the samples within that minute range (what a weird thing to do on Oceanic's part…). And if there are more than 60 of them, go to half second sampling rate (and simply announce that somewhere in the data structure).

This way whatever junk the dive computer throws at us, libDC converts it into something reasonable and consistent that the software can then rely on and use.

Bingo, everyone wins.

/D