CCR mode and our implementation of the setpoint

[Robert C. Helling]

Hi,

> On 07 Feb 2015, at 06:08, Willem Ferguson <willemferguson at zoology.up.ac.za> wrote:
> 
> As far as the dive logging of CCR dives is concerned, all the information is kept in the sample structures (for the moment, forget about the plot_info structure that only lives when a dive is being displayed on-screen). The setpoint information is kept in the sample.setpoint member. Particularly near the start and the end of a dive, the setpoint values may change quite a bit, but a SAMPLE_EVENT_PO2 is not triggered, as far as I am aware due to these changes in setpoint. Specifically for the Poseidon, as far as I am aware, there is also not an event in the dive log that indicates change in setpoint.

my understanding is that a set point is manually changed only a few times in a dive. So it is natural (at least when saving files) to treat those changes as events rather than have them in every sample (in memory, I think of the per sample data as a cache of the event data).


> There are all sorts of other events. My perception is that, for logging purposes, the setpoint is is just recorded on a sample-by-sample basis just as po2 for any of the o2 sensors. So maybe with respect to CCR, it is only the planner that uses the SAMPLE_EVENT_PO2 event.

I am not a rebreather diver myself. But my impression was that you have to press buttons on your unit to change the set point during the dive. And that would produce these events (or you add them when you download your data from an independent computer). In fact, having logged sensor data available as for you Poseidon CCR is rather an exception than the rule.

> 
> The solution is clear, if the SAMPLE_EVENT_PO2 is ambiguous, then a new event type is required.
> 
> The Galileo has an po2-warning event. In general I would prefer not to make a list of DCs that have po2-warning-events because then the code has to deal with exceptional cases all the time, something that I dislike.

Of course, for the future we want to use separate events. My concern was what to do when reading files that were written by the current version of subsurface, how to recover from the clash. I would suggest to do two things:

Have one header file where we define our own subsurface events (in addition to the libdivecomputer name space). We already have one for images. Currently it is not clear to me, if amongst the ldc events there is one that I should have used for set point changes (Jef, could you comment?) or if we have to create a new one for that. We will definitely need a new one for dive mode (OC, CCR, PSCR, FREEDIVE)

In addition, have a function that maps event types upon reading subsurface files. A SAMPLE_EVENT_PO2 is mapped to the other event, if it occurs at t=0 or if it comes from a dive computer that has no high/low warnings.

In fact, from a git grep SAMPLE_EVENT_PO2 in the libdivecomputer sources, the warning events can only come from Atomics Cobalt, OSTC, and Suunto D9. And for the OSTC it is not even clear to me that this is not using the double meaning as well. So the list of exceptions is rather short.

Best
Robert

PS: Sorry, have to run now. Hope to have time to send some code later.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150207/c4067f81/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150207/c4067f81/attachment.sig>