[PATCH] Correct bug: setpoint handling of Poseidon CCR dive logs

Linus Torvalds torvalds at linux-foundation.org
Thu Oct 30 10:39:22 PDT 2014


On Thu, Oct 30, 2014 at 10:32 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> I think I remember now. The logic was that many tank sensors don't give a
> reading in every sample. And somehow, somewhere this got converted into
> samples with no pressure reading ending up with the previous pressure
> reading which gave rather "step function" looking plots.

Yeah, I think we did that to fix up the fact that we used to
originally populate samples with the previous sample data, and so to
correct old cases we'd clear duplicates, and do the much nicer
interpolation instead.

>> The pre-existing code also zeroed out duplicate temperature values [~line
>> 1169]. You can see there that the style of the commenting for that
>> particular operation is different from my style of commenting.
>
> Same logic I believe.

Yes, except I think for temperatures we don't clear out duplicates, we
clear out ranges (so we leave the end-points). But yes, same
situation.

> And at least for O2 setpoint that's problematic, given that we use this to
> distinguish CCR and OC. Maybe that's wrong and we need to fix THAT
> elsewhere, but right now that's what we do.

Yes, I think the O2 setpoints should not try to clear out duplicates,
since you'd *expect* things to be duplicate.

Of course, many of these things are then also tied into with
saving/loading issues. For example, O2 setpoints you would expect to
save only once, and not save for each sample, and then loading would
populate the subsequent ones with the previous value.

Which is what we used to incorrectly do for pressure data. But
cylinder pressure really is a "sample once in a while", while
setpoints are "set once and leave until it changes" with no
interpolation.

Of course, then we have the question about things like O2 _sensor_
data as opposed to manually set setpoints. Should those be "sample
once in a while and interpolate in between", or what?

                       Linus


More information about the subsurface mailing list