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

[Anton Lundin]

On 23 May, 2018 - Jef Driesen 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.

The simple solution is to just emit the average/voted ppO2 when we can't
find the calibration values.

Its a graceful degradation of functionality, and way better than not
showing any ppO2 at all.


It should be simple to write.


//Anton


-- 
Anton Lundin	+46702-161604