Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]
dbdavide at gmail.com
Wed May 23 07:49:45 PDT 2018
On Wed, 23 May 2018 at 16:22, Jef Driesen <jef at libdivecomputer.org> wrote:
> On 2018-05-23 14:58, Davide DB wrote:
> > On Wed, May 23, 2018, 12:08 Willem Ferguson
> > <willemferguson at zoology.up.ac.za>
> > wrote:
> >> If this is the case, then the problem should in principle be solvable
> >> and it possibly means that the coding in the dive log is slightly
> >> different from that of the standard Petrel and the Fischer Petrel 2.
> >> The
> >> most knowledgeable person to approach is Jef Driesen but he would need
> >> some specific information from your download. A first approach is to
> >> inspect the .bin dumpfile generated for debug in Subsurface. Then use
> >> his dctool executable (If I remember correctly it can do Bluetooth and
> >> it is extremely flexible) and see if you can trace the pO2 values.
> >> I am not sure this is what you may want to hear, but assume that (if
> >> you
> >> want the problem solved) you need to take the initiative. You may
> >> possibly be the only person in this circle which has a divecan Petrel
> >> so
> >> you are in the best position to address the problem.
> > While I do not pretend anything (of course), regarding your questions I
> > can
> > assure you that I made everything I could as end user. I gave
> > - Shearwater desktop screenshots
> > - Shearwater xml exported logs
> > - Subsurface xml logs
> > - Subsurface bin dumps
> > - dctool dump files
> > My only fault was not filing a bug report on Github to resume
> > everything in
> > one place.
> > I even asked on the list if someone else was using a Shearwater Petrel
> > ECCR
> > controller and, maybe experiencing the same behavior. No reply. So I
> > don't
> > know if it's my specific unit or not.
> > BTW I recently updated Petrel firmware to the latest version without
> > results. While it's possible I'm the only Shearwater ccr user on this
> > list,
> > we are speaking of the most common eccr controller on the market
> > nowadays.
> > It's used on countless rebreathers not an obscure dive computer
> > implementation.
> > Everything started months ago when I discovered that pO2 samples
> > reported
> > by Subsurface were completely different (and wrong) from Shearwater
> > desktop.
> > There was a long email thread in which AFAIK no solution was found: my
> > Petrel is strange.
> > Maybe I missed something and Jef or Anton modified something. I don't
> > know
> > but at some point pO2 samples disappeared from Subsurface hence I
> > opened
> > this thread but I'm failing to understand what "default calibration"
> > means
> > and why in my logbook I find the same device listed with random number
> > of
> > sensors.
> > I asked again today because because even a "guy you must die!" reply
> > it's
> > ok but I got no replies at all.
> Sorry for the lack of response, but for the last few weeks, I was just
> too busy with non-libdivecomputer related things.
> Anyway, the problem is as follows. The shearwater devices record two
> different things:
> 1. The average/voted ppO2.
> 2. The value from each O2 sensor. Unfortunately this value is not the
> ppO2 value, but the raw millivolt measurement from the sensor. In order
> to convert this value to a ppO2 value, we need to take into account the
> calibration values.
> Last time I checked, shearwater desktop only shows the average/voted
> ppO2 (#1). It doesn't show the individual ppO2 from each sensor (#2) at
> all (e.g. no millivolt values nor the converted ppO2).
> Now, originally libdivecomputer only reported the average/vote ppO2.
> Later on we figured out how the sensor calibration worked, and this was
> replaced with the ppO2 value from the individual sensors. But afterwards
> we also discovered that some devices (like the one from Davide) don't
> seem to store the calibration values correctly, and leave them at their
> default values (2100). I have no idea why this happens. Anyway, because
> applying those calibration values produces incorrect ppO2 values, I
> added some code to detect this case and disable the ppO2 from the
> sensors. Since the average/voted ppO2 was already disabled earlier, that
> also means you won't get any ppO2 values at all anymore.
> For those bogus default calibration values, there is not much we can do
> about that. Without the (correct) calibration values, we simply can't
> calculate the ppO2 values. So unless the calibration values are for some
> reason stored elsewhere, and we just don't know about this, we're simply
> stuck here. Shearwater desktop doesn't show this info, so it's difficult
> to tell what's going on.
> The only part that we can do something about, is restoring the
> average/voted ppO2 again. That's already on my todo list. But right now
> the libdivecomputer api doesn't have a way to indicate the type of the
> ppO2 value (e.g. average/voted or from an individual sensor), so that
> would cause confusing. So this will require some (backwards
> incompatible) changes, and that's why it's not done yet.
Thank you Jef.
Everything is much clear now.
Now i understand why pO2 samples disappeared.
The current version of Shearwater desktop shows average pO2 and individual
mV values (see attachment).
I forgot that for the wrong pO2 samples I filed an Github issue on december
2017. Sorry I did not reply at some point because Anton and Robert replied
on Xmas day and I missed the email :)
Anton solution would be great.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 102642 bytes
Desc: not available
More information about the subsurface