Help needed decoding data

John Van Ostrand john at vanostrand.com
Wed Jul 2 10:39:47 PDT 2014


On Mon, Jun 30, 2014 at 11:30 AM, Linus Torvalds <
torvalds at linux-foundation.org> wrote:

> On Mon, Jun 30, 2014 at 2:20 AM, Jef Driesen <jef at libdivecomputer.org>
> wrote:
> >
> >
> >> I've extracted what appears to be the mbar
> >> increment data bits and graphed them. They closely, but not exactly,
> >> follow
> >> a dive profile from the vendor software. There is detail missing and the
> >> computed depths are a few feet off. I may not have mbar to feet
> conversion
> >> right or there is a calibration I need to consider.
> >
> > They might take into account atmospheric pressure and/or salinity. If
> there
> > is a fixed absolute different, then there is a different atmospheric
> > correction. If it's a fixed scale factor, then that's likely a different
> > salinity factor.
>

FWIW this is fresh water which also means atmospheric pressure is below 1
atm. It's somewhere between 70 and 700 feet depending on dive site. I'll
have to look at how much pressure change that is but the DC reports 0 Kft
of altitude.

Also, Jeff, I considered that it might be interpolating depth to make 1 sec
samples so I looked in the vendor's own software for an example of data
where that couldn't have been the case. I found an example of a "W" shaped
profile where the depth was up, down, up, down at 1 second intervals. I
don't know how a two second sample rate and interpolation could produce
that.


> Also, how sure are you (John) that the sample data is actually in millibar?
>

It could easily be in actual depth - in cm. The pressure of one cm of
> water is very close to one mbar, so the two are almost
> interchangeable, but it would be a difference of a couple of percent -
> so a foot or two off depending on depth. And from what I've seen, most
> dive computers do tend to sample actual depth, not pressure, if only
> because that is what they show on the screen. Logically, "pressure" is
> what the sensors give you, and what really matters for deco
> calculations, so converting to "depth" is fraught with problems
> (surface pressure, salf-vs-fresh, yadda yadda), but it's (a) what
> people want to see and (b) in the end, the errors of a percent or two
> are not really material, so ..
>

It could be centimetres but because this is fresh water wouldn't that be
identical to millibar? The computer has external contacts and can sense
between fresh and salt water. I may try diving the computer in a zip-lock
bag full of salt water aquarium water to see how it logs salt water dives.
I suspect that the dive start structure will have a salt/fresh water flag
so the vendor software can display depth.

The difference on a dive to 27 ft is about 5ft, that's quite significant by
itself and the difference grows as the depth does.


> But yes, as Jef says, it could be any number of other factors too. The
> difference between salt/fresh water is a few percent too, and quite
> frankly, having seen the mess some dive log software make of things,
> just being *wrong* can be a few percent too (ie not actually using
> proper calculations at all, ie just using the rough "1 atm is 10 m of
> depth", or just mixing up atm and bar). We've had those kinds of
> errors too, and judging from what I've seen, we've definitely had
> _less_ than some.


It's confusing me to the point that I'm looking for other clues for
speculation. One clue may be that the vendor software exports data rounded
to what looks like 0.25 increments. So depths of 0.3, 0.5, 0.8 are seen but
in the vendor's graphs the depths use two decimal digits and are 0.25
increments but shifted. One profile shows data like 0.07, 0.32, 0.57, 0.82
and another shows 0.18, 0.43, 0.68, 0.93. There's a minor shift happening.
Temperature? Altitude?

Maybe the most productive idea would be to get the data from the .CAN file
in the hopes it's stored in a more accurate form. Linus you were looking
for help deciphering a CAN file a while ago. Did you ever find the depth
data?  I've taken a cursory look and I can see that the start of the file
has offsets into the data, each offset looks like a dive.

-- 
John Van Ostrand
At large on sabbatical
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20140702/2231131f/attachment.html>


More information about the devel mailing list