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

Wed May 23 07:37:26 PDT 2018

I have a JJ CCR (2017 CE model) with a Petrel 2 DiveCAN computer attached.

I do all my downloads using the Android app (I'm on the beta channel) and I
mostly view the data on Linux. I never use the Shearwater desktop
application. I haven't noticed any discrepancies in the data so far.

I'm hoping to dive this weekend, I'll revert back with additional feedback
once I've dived.

Sorry for not responding sooner.

Aaron

On Wed, May 23, 2018 at 4:22 PM, 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.
>
> Jef
>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180523/9a2194a3/attachment.html>