Help needed decoding data

[Linus Torvalds]

On Wed, Jul 2, 2014 at 10:39 AM, John Van Ostrand <john at vanostrand.com> wrote:
>
> It could be centimetres but because this is fresh water wouldn't that be
> identical to millibar?

No, it's the other way, actually.

The thing is, one cubic cm of pure water may weigh pretty much exactly
one gram, and that makes some metric people think that fresh water
gives you the nice straight "10m is one bar" thing, because they
assume that's how it all works out. But that's not actually true.

Bar being a measure of pressure, it's not the *mass* of water that
matters, but the *weight*. And that has another factor in it entirely:
the gravity of earth, giving a constant factor of 9.81.

So the normal "10m of water is on ATM" (note: ATM, not bar) is
actually not a result of metric powers-of-ten at all, but rather it's
a happenstance of the weigth of *SALT* water (roughly 1.03g per cubic
cm), and the gravity of earth (9.81m/s2), and one ATM being slightly
bigger than 1 bar.

Check it out:
 - one ATM = 1.013 bar
 - 9.81*1.03 = 1.010

and then it just so happens that the pressure at 10m ends up being
almost exactly 1 ATM more than surface pressure.

But in fresh water, you don't get the "1.03" factor, and you end up
having the pressure of 10m of water being about 981 mbar, ie 0.96 atm.
No round numbers anywhere.

> 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.

Interesting, I don't think I've seen (or been aware of) dive computers
that sense the salinity automatically.

Personally, I think salinity sensing is kind of stupid, actually. It
has no serious meaning, since the actual deco calculations do not care
at all. The sensor senses pressure, and that's the only thing that
really matters. The conversion to depth is "pointless" - it has no
real meaning for diving, except if you happen to have other depth
measurements that you want to match with, which is very very rare.

So the only reason to give depth at all is that it's what people
"expect", but since people don't actually care about the roughly 3%
"real absolute difference" in depth in any normal situation, why even
bother changing the calculations?  Even if you know the depth of the
dive site, on most diving things like tides etc tend to be more than
the 3% difference.

So I think "salt vs fresh" is interesting perhaps from a logging
standpoint - the same way that it can be interesting to differentiate
a boat dive from a shore dive. But I think it's over-engineering to
take it into account for depth calculations.

(But hey, maybe cochran users care, because they go deeper, and are
potentially matching up their dive depth against some other
measurement like sonar depths from a boat. At that point, you *might*
care. I find it unlikely, but whatever)

> 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.

Ok, that's a much bigger difference than I thought, so there's clearly
something else going on. The "couple of percent" differences you can
get from the whole salt-vs-fresh and atm-vs-bar confusions are *much*
smaller than that 5ft in 27ft.

> 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.

I never got anywhere with the cochran data, no.

            Linus