Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

Davide DB dbdavide at gmail.com
Fri Jun 22 06:19:50 PDT 2018

On Thu, 21 Jun 2018 at 22:57, Anton Lundin <glance at acc.umu.se> wrote:

> On 21 June, 2018 - Dirk Hohndel wrote:
> > I am reasonably certain that we can rectify this.
> >
> > Please make a copy of your dive data (simply export them to an XML
> > file), open that XML file, and then re-download from the Shearwater.
> > In the Download dialog check the two boxes (sorry, English text, I'm
> > sure you can figure out the Italian version):
> > "Force download of all dives"
> > "Always prefer downloaded dives"
> >
> > With these options checked it should keep all of your other data like
> > notes, buddies, etc, but replace the downloaded data with the new
> > version which we assume will be corrected with the fix in place.
> >
> > So this should be reasonably easy to recover from.

Great Dirk!
This completely change everything. I always thought it would have delete
I will try ASAP.


> > > A CCR dive without pO2 samples is like a cake with no sugar. If I
> > > still have them on my Petrel (I never investigated how many profiles
> > > it stores) I should import everything from scratch into Subsurface and
> > > compile everything again. Not a nice perspective for the future. Right
> > > now I'm diving two/three times per week so the count will increase
> > > rapidly. I've tons of notes, wrecks positions, all dives have GPS
> > > locations...
> >
> > See above - you should be able to do this without having to manually
> > re-edit all of this work!
> I would rather describe it as without the pretty icing on the cake.
> Every thing else about the profile is correct. Time, depth, temp and so
> on. The pO2 is just affecting your deco and the monitoring of your
> rebreather performance. Thats my view on it.

I respect your point but I run my unit completely manual from the beginning
so pO2 matters to me. It's a way to monitor my progress and see how the
Shearwater Buhlmann behaves with the pO2 when I do not use ratio deco.

> If someone can extract this as one or two sample dives that show the
> > problem and add words that make enough sense to me, I'll reach out
> > to Shearwater again to see if they have suggestions. I know I sent them
> > one of the earliest exchanges on this topic but neither they nor I really
> > understood the problem and it got dropped
> The calibration constants stored in the dive header are the default
> value of 2100, and not the actual calibration constant.
> First, that caused us to incorrectly convert the mV values from the
> sensors into po2 values, and the later code did just skip exposing any
> po2 values at all.
> Now we fall back to the averaged/voted po2 value stored in a different
> position in the samples.
> > > Moreover other questions remained unanswered; In one year my unique
> > > Petrel was identified as 3 different devices with random number of
> > > sensors. My logbook is a mess and nobody knows the reason.
> >
> > Also something I can ask about if you give me more information.
> I rarely thing its random.
> The old code exposed 1 value, the averaged/voted one.
> Later, we exposed the individual sensor values.
> Now we will expose the individual sensor values if we can find sane
> calibration constants, otherwise the averaged/voted one. We will also
> add a row in the "Extra info" pane saying which one it is.

I was referring to my logbook. Looking into my logbook I find 4 different
computers (deviceid it's the same):

<divecomputer model='Shearwater Petrel 2' deviceid='1a2d46b1'
diveid='3db7eb77' dctype='CCR' no_o2sensors='1'>
<divecomputer model='Shearwater Petrel 2' deviceid='1a2d46b1'
diveid='52d4ba3e' dctype='CCR' no_o2sensors='3'>
<divecomputer model='Shearwater Petrel' deviceid='1a2d46b1'
diveid='a6e05a10' dctype='CCR'>
<divecomputer model='Shearwater Petrel 2' deviceid='1a2d46b1'
diveid='3db24900' dctype='CCR'>

Where these differences originate from?
1 sensor, 3 sensor, no sensor, Petrel and Petrel 2

Different Subsurface versions with different approach?

> > > Months ago, given your good relationship with Shearwater, I warmly
> > > recommended to contact them privately asking info on this nasty
> > > behaviour of some devices.
> >
> > I will look again if there are more emails that I've missed.
> The devices behave just fine. Its just our reverse engineered code who
> doesn't work any longer.
> There has bin some email exchanges, (don't remember who talked to them
> or when), about how to use the calibration constants and the comment
> from Shearwater back then was that this is a internal detail they didn't
> want to say anything about it.
> The answer might change when someone else asks them, but thats the last
> thing I heard.
> I don't have any Shearwater devices nor any contacts at that company. I
> just stared at the data long enough and figured out a (what later turned
> out to be a faulty) relationship between them. Later Jef figured out
> what the real relation ship was which matched the data way better.
> (To my defence, my formula matched all the test data I had =)
Two users affected in a very small Subsurface user base. Who knows how many
units expose the default calibration values?

Anyway, mine was just a suggestion. No problem at all.
I will try Dirk suggestion so I can save my old data.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180622/8717bdad/attachment.html>

More information about the subsurface mailing list