On 01/15/2012 03:53 PM, Dirk Hohndel wrote:
On Sun, 15 Jan 2012 08:31:31 +0100, Jef Driesenjefdriesen@telenet.be wrote:
On 01/14/2012 07:57 PM, Philip Balister wrote:
On 01/14/2012 01:25 AM, Jef Driesen wrote:
On 01/13/2012 11:04 PM, Philip Balister wrote:
- I have six dives in the computer, but only the first 5 show in
subsurface.
Depending on your (short) sample rate setting and (long) dive times, it's possible there is not enough memory to store profiles for all dives. In addition to the profile data, the oceanic dive computers maintain a summary for each dive stored in separate memory area. So it's possible the dive computer can show dives for which it doesn't have the profile data anymore.
Sample rate looks like 15 seconds. It is the most recent dive that does not show up.
I already found where it goes wrong. The dive is downloaded correctly, but the parsing fails, and I guess subsurface doesn't import anything at all in that case.
The problem is that the vtpro compatible dive computers support a depth based sample rate in addition to the time based sample rate. This means the dive computer doesn't record at fixed time intervals, but whenever a change in depth crosses a certain threshold. To be able to draw the profile graph, a timestamp is recorded for each sample. This "feature" is a real pain in the ass because it does break any application that assumes a fixed time interval between two samples. To make things even worse, the timestamp only has a resolution of one minute, which means there can be several samples with the same timestamp.
Yikes. Subsurface would be rather unhappy with this. We definitely assume that the time stamps are strictly monotone.
Another potential problem because applications are likely to expect the timestamps to be unique and increasing for each sample. To workaround this issue, the libdivecomputer code counts the number of samples within the same minute, and then spread them evenly.
So you give them an artificial 15 sec resolution?
I agree that the timestamps should be strictly montone. Having two or more samples at the exact same time doesn't make any sense. To avoid this problem with the depth based sample rate, the libdivecomputer code distribute those samples evenly within that minute.
The resulting (artificial) resolution varies depending on the number of samples that is present. For example if you have 3 samples with the same timestamp, they are spaced 60/3=20s apart. The next minute you could have 7 samples, and then they get spaced 60/7=8.57s (rounded to the nearest second because we don't support a higher resolution).
It gets worse if you stay at constant depth (or only very small changes within the depth threshold), because then you get no samples at all. This is problematic for drawing, because you typically draw a straight line between two samples, and thus the time without any samples will get drawn with a certain slope, rather than at a constant depth.
Last year, I wrote a detailed document describing all those sampling issues:
http://www.divesoftware.org/libdc/sampling.html
The missing samples would be very similar to surface intervals in section 2.3.4, where the only difference is that you are not at the surface but a certain depth of course :-)
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.
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.
Jef