Cochran Changes

[Jef Driesen]

On 2016-01-20 18:41, John Van Ostrand wrote:
> I think this is a summary of where we left of:
> 
> 1. dc_context_t pointer doesn't need to be passed to cochran serial 
> open a
> setup functions. (fixed with patch pending.)

Patch looks fine to me.

> 2. Cochran can store more log entries than profiles. So when the 
> profile
> ring buffer wraps earlier logs will point to profile data from other 
> dives.
> Jef suggests processing dives in reverse chronological order, adding up
> profile data used and not processing profiles after it's processed a 
> full
> ring-buffer of data. I have yet to work on this or consider 
> alternatives.

The dc_device_foreach() function must return the dives in reverse 
chronological order. This is a requirement for the download only new 
dives feature. When dives are returned in reverse chronological order, 
an application (or libdivecomputer itself) can simply stop downloading 
dives as soon as a previously downloaded dive is recognized. Very simple 
and efficient.

Thus if we need to return the dives in reverse chronological order, it 
makes sense to process (and also download) the data in this order. 
Otherwise you'll end up with a rather inefficient implementation.

I have to read through your documentation again, but processing the 
dives in reverse order might also make the recovery of corrupt dives 
easier. If the tail of a dive is missing, then it can run at most until 
the start of the next dive. And due the reverse order we already have 
that one.

> 3. Corrupt dive handling. In some cases (like a low battery especially 
> in
> cold water) the computer resets during a dive. This results in a
> "start-dive" block written but no valid "end-dive" block written. We 
> know
> information from the start of a dive (like date/time, gasses, profile 
> start
> pointer, etc.) but we don't know information accumulated during or at 
> the
> end of a dive (like end-profile pointer, max depth, min temp, etc.) 
> I've
> taken to guessing the end of a dive by starting with the next dive's
> pre-dive-profile-pointer and backing up until we think we have the 
> previous
> dive's end. We haven't resolved our differences on this. It seems to 
> down
> to the question: Do we present a partial or broken profile in the 
> interest
> of giving the diver something or do we give nothing in the interest of
> being accurate?

That's a difficult question. In general, I prefer to be very strict and 
simply fail on unexpected data. Usually this is the correct thing to do, 
because such unexpected data often turns out to be an wrong assumption 
in the code. So being strict helps finding bugs. But sometimes the data 
is really wrong (due to a firmware bug, running out of battery during 
the dive, etc), and if it happens frequently, then a workaround might 
indeed be necessary.

It also depends on where the data "corruption" is located. If the 
information needed to move from one dive to another is good, but we are 
unsure about the contents of the dive, then we can return the bogus dive 
to the application and let the parser deal with it. You might get 
incorrect data for that particular dive, or even a failure to parse the 
dive. This would ensure that we can still download the other dives. But 
if the primary structure is damaged and we can no longer safely move to 
the next dive, then I think we should fail.

Jef