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 > >[email protected] , 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 [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
