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

[Anton Lundin]

On 25 May, 2018 - Jef Driesen wrote:

> On 25-05-18 16:35, Willem Ferguson wrote:
> >On 25/05/2018 15:55, Jef Driesen wrote:
> >>The main disadvantage is that you'll no longer know which type of ppO2
> >>(sensor or voted/average) you are getting. Especially if you only have
> >>one sensor.
> >
> >I would agree, but at least one gets the calculated pO2 as perceived by
> >the machine at the time, even though there is no idea about sensor
> >problems during the dive. It is so much better than having no pO2 data
> >to evaluate after a dive. This pO2  would still correspond to the data
> >in the pO2 graph of the Shearwater Desktop software.
> >
> >I do not quite get the argument about one sensor? For one sensor there
> >is no averaging or voting?? I'm not seeing something, so please spell it
> >out?
> 
> The average ppO2 is always a single value. But there is often more
> than one sensor. So you could assume that if you get more than one
> ppO2 value that they are values from a sensor. But in the case of a
> single sensor, that doesn't work, and you won't be able to tell
> which value you got.
> 
> I'm not sure if the average ppO2 is always equal to the sensor ppO2
> for the single sensor case. Maybe the dive computer does averaging
> over several measurements to ignore outliers? (Is simply don't
> know.)

Any way, its better that we get A value, than no value.

It would be dead simple to emit a SAMPLE_EVENT_STRING, or a
DC_FIELD_STRING just saying, "hey, these are not the raw ppO2 values you
where looking for, but the next best thing", if you would have taken
those patches.


//Anton


-- 
Anton Lundin	+46702-161604