<div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>Now that our branches match I went through last year's thread on Cochran development, "Cochran_commander refactoring".<br><br></div>I think this is a summary of where we left of:<br><br></div>1. dc_context_t pointer doesn't need to be passed to cochran serial open a setup functions. (fixed with patch pending.)<br><br></div>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.<br><br></div>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?<br><br><div><div><div><div><div><div><div>-- <br><div class="gmail_signature"><div dir="ltr"><div>John Van Ostrand<br></div><div>At large on sabbatical<br></div><br></div></div>
</div></div></div></div></div></div></div></div>