On 06-02-15 23:16, Robert C. Helling wrote:
quick answer: The problem is that it is not a _dive_ that is CCR or OC, it is really a moment in time. Actually, the realisation that it was a bad design idea to mark a whole dive (or even more stupid: a dive computer) with a dive mode (used to be dctype) is not very helpful in situations like bailout or decoing on OC (e.g. a habitat). The dive mode is really time based and should thus be handled by events. The function that you mention is there to move in that direction: It adds a corresponding event at t=0 to make the event based information (which is more fine grained) agree with the dive mode of the dive (or: dive computer). I was hoping to completely get rid of the dive mode eventually (in the per dive sense) as I think the doubled information about the dive mode has to be resolved in this direction.
Most dive computers have a divemode setting per dive. The Shearwater is one of the exceptions here, with its divemode setting per sample.
I don't agree that a per dive divemode setting is a design mistake. In most cases changing divemode during the dive simply doesn't make any sense. For example, I don't know any device that supports switching from freedive/gauge to oc/cc (or vice versa). The only scenarios that do make sense to me are the ones you describe (e.g. bailout or deco). But I assume such a dive is still considered a CC dive, right? It's still useful info, it just serves a different purpose.
So I guess what we really want here is not to get rid of the per dive divemode setting, but some way to indicate the switch from CC to OC. That could be done with a per sample divemode (as the shearwater does) or a bailout event (as the ostc does).
But that is separate from the double semantic of SAMPLE_EVENT_PO2 which I was not aware of and which is simply bad. I am convinced, we need some event that has the meaning “this is a set-point change of a CCR with the special meaning of a set-point of zero being OC or actually non-CCR like e.g. PSCR). I can see that the problem is related to an earlier confusion we had between pO2 and O2setpoint (those were one variable at some point): Before we were dealing with sensor data, the only information about the gas a CCR diver was breathing, was the set point. But with sensor data (which we will be having also for pscr dives which will cause another minor headache) that is no longer true. So now, we use the set point only as a default for the actual pO2 if there is no better sensor data available. So what is the way to proceed? We need to disentangle the two event types: CCR set point changes and high/low pO2 warnings. Did we inherit this ambiguity from libdivecomputer or is that only using that event for the latter meaning? I wrote code that inserted these events in two places: The function you quote inserts them only at t=0 and those should thus be trivial to find. But there is also the profile context menu which adds set point changes. And that also adds these events.
See my response to Dirk's mail. Jef _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
