Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Long, Martin]

I'm in agreement with Davide that any interim solution we can get running
is better than the way it is working now. It's a regression, and tbh if
there isn't an interim solution then it ought to be reverted to the old
behaviour. At the moment I'm having to use Shearwater desktop for reviewing
all my logs.

On 11 June 2018 at 21:46, Anton Lundin <glance at acc.umu.se> wrote:

> On 11 June, 2018 - Jef Driesen wrote:
>
> > On 11-06-18 20:21, Anton Lundin wrote:
> > >On 04 June, 2018 - Dirk Hohndel wrote:
> > >
> > >>I don't have an outstanding patch from you, so not sure what you are
> referring to.
> > >
> > >There was a diff a while back in this thread, in
> > >20180523144751.GC12507 at hirohito.acc.umu.se , which made the code fall
> > >back to the voted/averaged ppo2 instead of reporting individual sensors
> > >if we couldn't find sane calibration values.
> > >
> > >
> > >Jef didn't like it, but I think its a step to a better place than where
> > >we're right now, and as far as I've read it, both Davide and Martin who
> > >is affected agrees.
> > >
> > >
> > >Anyway, now when I'm back on solid ground (I still feel the waves in my
> > >legs) I might get around to making up a commit message and formating it
> > >as a patch.
> >
> > It's not that I really disliked the patch. I just wanted to point
> > out that it introduces a possible disambiguity in the sense that in
> > the application you no longer know which type of ppo2 you are
> > getting (voted or sensor). I would rather go for a solution that
> > indicates the type. That's exactly what's on my (long) todo list.
> >
>
> Yes, that would have bin great to have, but we don't have it, and its
> mixed already. Some backends return voted/average/computed and some
> return sensor values.
>
> Return real mV values would be nice to.
>
> > But I'm fine with your patch as an interim solution as well. Btw, an
> > alternative could be to always deliver both the voted *and* the
> > sensor ppO2. Then you know for sure that the first value is always
> > the voted value, and the remaining ones (if present) are the sensor
> > ones.
>
> Would we then invent a averaged value for backends who doesn't have it,
> like the ostc3?
>
> This sounds like a even bigger mess to me.
>
> //Anton
>
> --
> Anton Lundin    +46702-161604
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180614/07e9ca5d/attachment.html>