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

[Anton Lundin]

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