Odd calculated deco "ripples" (was Re: RFC: color change for calculated deco)

[Dirk Hohndel]

Linus Torvalds <torvalds at linux-foundation.org> writes:
>>
>> Understanding this requires more time than I have right now. But I will come back to this as soon as possible.
>
> It's interesting, but I am starting to think that it has something to
> do with divecomputer choice. I seem to *never* see ripples with my
> Suunto logs. With the Uemis, the ripples ar at 20-second intervals,
> and I just looked at Dirk's dives, and with the Atomic Aquatics, the
> ripples are at 15-second intervals.
>
> And in his dives, the OSTC doesn't shows ripples, nor do I find them
> in his old Suunto dives.

is this simply an issue with the way the drawing is done? Have you
looked if I'm doing something stupid when drawing the ceiling in
profile.c? The fact that it seems related to the sampling rate makes me
think that I may have messed something up there (but looking at the code
it seems simple and straight forward enough).

> We don't have a huge number of dives with lots of deco in them
> (although changing the gradient factors can be used to turn just about
> any dive into a deco dive ;), and not all dives show the rippling very
> much. But there *does* seem to be some tie-in to dive computer.

But how can it - except maybe with the sampling rate?

Can you try creating synthetic dives (either with the planner or with a
quick C loop) and see if you can reproduce it with those?

> The fact that two different dive computers seem to have *different*
> beats to them (15s vs 20s - and it does seem to be consistent from
> dive to dive, although I only looked at a few dives) makes me wonder.
> I'm starting to think it might be some "beat" from the sample
> frequency vs some rounding effect of the depth by the dive computer.
> It may be there in the depth samples too, it's just not visible, and
> hidden by the noise in the actual depth movement.  Although I'd assume
> that that noise would also be big enough to then drown any ripples.

Exactly. That's why I think it's got to be a weird rounding and clipping
effect in our code. The noise of data from the depth sensor should drown
out harmonic changes like that.

> Our own depth rounding does *not* seem to be an issue. Yes, we do
> depth to "only" a precision of mm, and we do this in integers, but the
> fact is, the sample precision itself is much less than that (the
> Suunto depth samples, for example, seems to actually be in whole feet,
> so the dive computer itself will have rounded the depth to *much* more
> than mm).

Yeah - that seems just too unlikely.

/D