On Wed, Jul 2, 2014 at 10:39 AM, John Van Ostrand john@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