Hi, now, I have done some reading, both in the source and in trac (I should have done this earlier):
> On 06 Feb 2015, at 22:54, Dirk Hohndel <d...@hohndel.org> wrote: > > But a bug report from an OC diver forced me to dig into this and what I > think I'm beginning to understand doesn't make me happy. Double use of the event is not nice, but it does not seem to be the problem here: When the interpretation is „set-point change“, the name of the event (the fourth argument of add_event) is always „SP change“ and whenever we read this event, we not only compare the event type but also the name. So there cannot be any confusion from that point. The double use should be resolved, but this is not the problem in #826. The problem for the user arises (as you comment in trac correctly) as the predator reports pO2 even in OC mode (probably a value that it computed) and historically (from the time before we had a dive-mode or even dctype) we determined a CCR from the fact that there was pO2 information. That should not be there. I would say, the bug is here. So, how shall we proceed? In the future, I would say, we should not save those values. What about old logs? We could delete all those pO2 values if the dive computer is a Predator and the user selects OC as dive mode? Independent of that, the SP change at t=0 should not be displayed to the user as that is actually the dive mode at the start of the dive which is selected in the combo box. But that is a display problem (that can easily be solved). Best Robert
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
