Individual sensor PO2 for Shearwater Petrel

[jimbodude]

I have a Petrel 2 with latest firmware (v72) on a CCR that has 3 PO2 sensors.  I've downloaded the log into Subsurface Desktop 4.9.3.  I see the computer voted/averaged PO2 and set point displayed.  I also see "PPO2 Source: voted/averaged" in the "Extra Info" tab on the dive.  All of this is great.

Is there a way to display the individual reading of each PO2 sensor?  I see that Shearwater Desktop also only provides the voted/averaged PO2, however there is an Android App called "CCR Tools: Shearwater Mate" that appears to be able to access the individual mV readings of each sensor.

The use case for individual readings is diagnosing deteriorating sensors over time, so it's not critical to me to have an actual PO2 value - mV would be fine.

[Linus Torvalds]

On Wed, Jun 3, 2020 at 10:21 AM jimbodude <j...@jimbodude.net> wrote:
>
> I also see "PPO2 Source: voted/averaged" in the "Extra Info" tab on the dive.
>

> Is there a way to display the individual reading of each PO2 sensor?

If you see "voted/averaged", then that means that the parser decided
that the individual sensors aren't actually calibrated.

From libdivecomputer comments:

// If all (calibrated) sensors still have their factory default
// calibration values (2100), they are probably not calibrated
// properly. To avoid returning incorrect ppO2 values to the
// application, they are manually disabled (e.g. marked as
// uncalibrated).

I suspect that "CCR Tools: Shearwater Mate" app just ignores this, and
gives the raw data.

For your "deteriorating sensors" use-case, maybe the raw data is
useful despite the apparent lack of calibration data.

It might be useful to have some way to report both the used PPO2 and
the raw sensor data, but , right now libdivecomputer doesn't really
have that interface (there's only a "report PPO2") and - as a result -
subsurface doesn't really have any way to distinguish (and handle) the
difference between "trusted PP02" and "raw PP02 data".

It's not technically impossible to do, but I suspect none of the
developers have a use-case for this and are thus not very motivated.

If you want to take a look yourself, look for DC_SAMPLE_PPO2 in

- libdivecomputer: src/shearwater_predator_parser.c

// PPO2
if ((status & PPO2_EXTERNAL) == 0) {
if (!parser->calibrated) {
sample.ppo2 = data[offset + pnf + 6] / 100.0;
if (callback) callback (DC_SAMPLE_PPO2, sample, userdata);
} else {
sample.ppo2 = data[offset + pnf + 12] * parser->calibration[0];
if (callback && (parser->calibrated & 0x01)) callback
(DC_SAMPLE_PPO2, sample, userdata);

sample.ppo2 = data[offset + pnf + 14] * parser->calibration[1];
if (callback && (parser->calibrated & 0x02)) callback
(DC_SAMPLE_PPO2, sample, userdata);

sample.ppo2 = data[offset + pnf + 15] * parser->calibration[2];
if (callback && (parser->calibrated & 0x04)) callback
(DC_SAMPLE_PPO2, sample, userdata);
}
}

where it currently sends either one averaged one, or three
calibrated ones, and it would need to have some logic for "send raw
data" for the non-calibrated case".

- subsurface:

look for that DC_SAMPLE_PPO2 in core/libdivecomputer.c for the
interface, and then "sample->o2sensor[]" data for the uses..

So it's technically possible, but not really done right now..

Linus

[jimbodude]

On Wednesday, June 3, 2020 at 2:10:40 PM UTC-4, Linus Torvalds wrote:

On Wed, Jun 3, 2020 at 10:21 AM jimbodude <j...@jimbodude.net> wrote:
>
> I also see "PPO2 Source: voted/averaged" in the "Extra Info" tab on the dive.
>
> Is there a way to display the individual reading of each PO2 sensor?

If you see "voted/averaged", then that means that the parser decided
that the individual sensors aren't actually calibrated.

They are, of course, actually calibrated...

 

From libdivecomputer comments:

                // If all (calibrated) sensors still have their factory default
                // calibration values (2100), they are probably not calibrated
                // properly. To avoid returning incorrect ppO2 values to the
                // application, they are manually disabled (e.g. marked as
                // uncalibrated).

I suspect that "CCR Tools: Shearwater Mate" app just ignores this, and
gives the raw data.

For your "deteriorating sensors" use-case, maybe the raw data is
useful despite the apparent lack of calibration data.

It might be useful to have some way to report both the used PPO2 and
the raw sensor data, but , right now libdivecomputer doesn't really
have that interface (there's only a "report PPO2") and - as a result -
subsurface doesn't really have any way to distinguish (and handle) the
difference between "trusted PP02" and "raw PP02 data".

It's not technically impossible to do, but I suspect none of the
developers have a use-case for this and are thus not very motivated.

My read of this and the code references is: We'd expect to get individual cell PO2 values reported when the calibration changes to "not the default" on at least one of the cells.  So I should validate whether the calibration related to the dive is actually "the defaults".  If it isn't, then validate that the calibration status is being read and interpreted correctly by libdivecomputer.

I don't see how the calibration could be set to default, since the mV values across cells are +/-4mV with all cells reporting the same PO2 to the .01 decimal place, but that's the obvious starting point.  Any hints on a fast way to pull that raw information and validate against the handset's display?

Thanks for the quick and informative response, Linus.

[Jef Driesen]

On 3/06/2020 20:41, jimbodude wrote:
> My read of this and the code references is: We'd expect to get individual cell
> PO2 values reported when the calibration changes to "not the default" on at
> least one of the cells.  So I should validate whether the calibration related to
> the dive is actually "the defaults".  If it isn't, then validate that the
> calibration status is being read and interpreted correctly by libdivecomputer.
>
> I don't see how the calibration could be set to default, since the mV values
> across cells are +/-4mV with all cells reporting the same PO2 to the .01 decimal
> place, but that's the obvious starting point.  Any hints on a fast way to pull
> that raw information and validate against the handset's display?

I suspect the problem is not that the sensors are not calibrated. Because if
that would be the case, then you have much more important things to worry about.
It's more likely that the calibration values are not stored in the dive data,
and we're stuck with the default values instead. Why this happens or under which
circumstances? I have no idea.

Without those calibration values we can't calculate a ppO2 value, or at least
not a correct one. If I remember correctly the ppO2 values were disabled because
people complained the values were bogus.

The easiest way to see the per sensor ppO2 anyway, is to replace

parser->calibrated = 0;

with

parser->calibrated = data[base];

after to the WARNING (abstract->context, "Disabled all O2 sensors due to a
default calibration value.") statement.

If you try this, let us know what the results are. Maybe we learn something new,
and can improve this?

Jef

[Stuart Vernon]

I don't know if this helps or not. Probably not.

But, I download my log from the Predator controller on my rEvo via Subsurface-mobile on my Android phone.

When I look at it in Subsurface on my laptop (a Macbook), it shows me a line that appears to be my actual controller setpoint and 4 lines that appear to be the ppO2 from each of the 3 sensors plus (I assume) a line that is the "average ppO2" that is being used to calculate deco.

One thing that might be nice is if there was a way to tell which ppO2 line corresponded to which sensor, and which one is the "average". As well, for the popup Information box to show the actual values of each of those lines. Looking at the data, my suspicion is that the green line is the "average ppO2" line. But, I don't see anything that confirms that. Regardless, I can see that on my last dive, I had one sensor that was reading consistently lower than the other 2. It would be nice if there was a way to tell which sensor # that was.

Oh, and while I'm at it, I have AI on my dil and O2. It would be nice if the log showed me the cylinder pressure data for those, too.

- Stuart

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/4208a7e1-727c-2657-009a-7b33cb5c12af%40libdivecomputer.org.

[Stuart Vernon]

Thanks, Willem.

I will have a look at the manual for the colors. But, it would still be nice if the Information popup dialog box showed the numeric values as you move your mouse over the profile. Maybe color-coded 1, 2, and 3 as labels for the individual sensor values. It already shows pO2 with a value, which I assume is the average of the 3.

And... yeah... uhhh... duh! Apparently, I was having a bad brain fart! Obviously if I don't download the log from my NERD (which I haven't), it's not going to have the AI data to show me. What a moron (I am - sometimes)!

- Stuart

On 6/4/20, 3:12 PM, "Willem Ferguson" <willemf...@zoology.up.ac.za> wrote:

On 2020/06/04 17:19, Stuart Vernon wrote:
> I don't know if this helps or not. Probably not.
>
> But, I download my log from the Predator controller on my rEvo via Subsurface-mobile on my Android phone.
>
> When I look at it in Subsurface on my laptop (a Macbook), it shows me a line that appears to be my actual controller setpoint and 4 lines that appear to be the ppO2 from each of the 3 sensors plus (I assume) a line that is the "average ppO2" that is being used to calculate deco.
>
> One thing that might be nice is if there was a way to tell which ppO2 line corresponded to which sensor, and which one is the "average". As well, for the popup Information box to show the actual values of each of those lines. Looking at the data, my suspicion is that the green line is the "average ppO2" line. But, I don't see anything that confirms that. Regardless, I can see that on my last dive, I had one sensor that was reading consistently lower than the other 2. It would be nice if there was a way to tell which sensor # that was.
>
> Oh, and while I'm at it, I have AI on my dil and O2. It would be nice if the log showed me the cylinder pressure data for those, too.
>
> - Stuart

Hi Stuart,

See section 4.6.4 in the user manual where the colours of the CCR PO2
lines are explained.

You can upload the data for your AI as a 2nd dive computer (in addition
to the Predator) and you will be able to flick between the two dive
computers (Predator & AI) to see the different data provided by each of
the two dive computers. To display PO2 data as well as cylinder pressure
data on a single profile would require you write a parser that merges
the two dives (from predator and AI) in the exact way that you want it.

Kind regards,

willem





--
This message and attachments are subject to a disclaimer.

Please refer to
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.

[jimbodude]

Ok, I got Subsurface to build after having some issues getting Qt set up.  Here is the change I made - if I did my git-fu correctly, this should be based on the version that was used to create subsurface v4.9.3, which is what I was originally using.  https://github.com/libdivecomputer/libdivecomputer/compare/ce6d9896a79afaa82641132e338f8744714c8593...jimbodude:individual-PO2

With that change in place, I get 4 lines for pO2 in Subsurface - none of them are "correct".  They're all the right "shape", but the individual lines are shifted up or down fairly significantly from what I would expect, which matches the original claim that the calibration information is not coming through.  For a specific example, I'm expecting around 0.7, but the readings are coming in between 0.75-1.03.  This is throwing off the average line, which I expect is now being calculated by Subsurface instead of the voted and averaged value reported by the computer.

The other change I made, to get the raw calibration data into a string, appears to have had no effect.  Is there something else I need to do to get that information into Subsurface?

[Linus Torvalds]

On Mon, Jun 8, 2020 at 1:44 PM jimbodude <j...@jimbodude.net> wrote:
>
> With that change in place, I get 4 lines for pO2 in Subsurface - none of them are "correct".

Is the original "voted/averaged" pO2 you saw correct? You'd hope so,
because that's presumably what the Sheatwater itself uses for deco
calculations..

Anyway, I think that trying to force some kind of calibrated end
result for individual sensors when there is no indication of actual
calibration values is wrong.

But what *may* make sense is to

(a) continue to export the voted/average pO2 as the pO2 value

(b) export the raw individual values - _without_ any calibration at
all as "O2 sensor mV" values. They aren't pO2 values, but they are
presumably _some_ kind of raw data, and they can be useful for
figuring out when/if a sensor might be going bad.

So something like the attached patch (but please realize that this is
a bogus pseudo-patch - it needs support for that DC_SAMPLE_O2mV sample
type).

That said, the Shearwater docs say "O2 Sensor X millivolts (only valid
when external PPO2 monitoring enabled)", and this code is all inside
the "internal PPo2 monitoring" if-statement. So I'm not sure this is
sensible at all. Thos values may be entirely random.

> The other change I made, to get the raw calibration data into a string, appears to have had no effect. Is there something else I need to do to get that information into Subsurface?

It should show up in the "extra info" tab. It doesn't?

Linus

[jimbodude]

On Monday, June 8, 2020 at 5:07:24 PM UTC-4, Linus Torvalds wrote:

On Mon, Jun 8, 2020 at 1:44 PM jimbodude <j...@jimbodude.net> wrote:
>
> With that change in place, I get 4 lines for pO2 in Subsurface - none of them are "correct".

Is the original "voted/averaged" pO2 you saw correct? You'd hope so,
because that's presumably what the Sheatwater itself uses for deco
calculations..

Yes - the values in the released version are correct, and that's what I'm comparing these individual pO2 values from my build to.

 

Anyway, I think that trying to force some kind of calibrated end
result for individual sensors when there is no indication of actual
calibration values is wrong.

Agreed.  Unless there is real calibration data available, it doesn't make sense to guess or reverse engineer.  It looks like this CCR Tools app has calibration data, since it shows a pO2 per cell over the whole dive, but I can't see the calibration data.  I also can't get that app to work on my phone, only my wife's...

 

But what *may* make sense is to

 (a) continue to export the voted/average pO2 as the pO2 value

 (b) export the raw individual values - _without_ any calibration at
all as "O2 sensor mV" values. They aren't pO2 values, but they are
presumably _some_ kind of raw data, and they can be useful for
figuring out when/if a sensor might be going bad.

So something like the attached patch (but please realize that this is
a bogus pseudo-patch - it needs support for that DC_SAMPLE_O2mV sample
type).

That said, the Shearwater docs say "O2 Sensor X millivolts (only valid
when external PPO2 monitoring enabled)", and this code is all inside
the "internal PPo2 monitoring" if-statement. So I'm not sure this is
sensible at all. Thos values may be entirely random.

I'll poke at it.

 

> The other change I made, to get the raw calibration data into a string, appears to have had no effect.  Is there something else I need to do to get that information into Subsurface?

It should show up in the "extra info" tab. It doesn't?

I deleted Subsurface.app and rebuilt to make sure.  Still no calibration values in extra info.

[Willem Ferguson]

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/6cfdaa82-d694-4fa3-b781-ba45601c89dco%40googlegroups.com.

Its been some time since I worked with this, but this is what I think happens. The three individual 'PO2' values are actually voltages. The meaning of each of these voltages is dependent on the reference values when calibrating that particular O2 sensor. IIRC this is also affected by altitude. From these voltages the Shearwater calculates a voted Po2 value that is readily accessible. However the calibration values for each of the sensors are, as far as I can remember, not accessible. So doing anything useful with the voltages is not easy. IIRC the Shearwater software also does not give individual PO2 values, only the voltages.

Kind regards,

willem

This message and attachments are subject to a disclaimer.

Please refer to http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full details.

[Jef Driesen]

On 8/06/2020 22:44, jimbodude wrote:
> With that change in place, I get 4 lines for pO2 in Subsurface - none of
> them are "correct". They're all the right "shape", but the individual
> lines are shifted up or down fairly significantly from what I would expect,
> which matches the original claim that the calibration information is not
> coming through. For a specific example, I'm expecting around 0.7, but the
> readings are coming in between 0.75-1.03. This is throwing off the average
> line, which I expect is now being calculated by Subsurface instead of the
> voted and averaged value reported by the computer.

That's the result I was expecting. Since we're doing a simple linear calibration
(ppO2 = mV * calibration), the "shape" of the mV and ppO2 curves will always be
the same. But of course the numerical values are different.

Note that if all three calibration values are the same (e.g. the default value
of 2100), then the resulting ppO2 values are simply scaled mV values.

Jef

[Jef Driesen]

On 8/06/2020 23:49, jimbodude wrote:
> Agreed. Unless there is real calibration data available, it doesn't make
> sense to guess or reverse engineer. It looks like this CCR Tools app has
> calibration data, since it shows a pO2 per cell over the whole dive, but I
> can't see the calibration data. I also can't get that app to work on my
> phone, only my wife's...

Are you sure the CCR Tools app shows the ppO2 value, and not just the mV values?
If it really shows a (correct) ppO2 value, that would be interesting. Because
that means it must have access to the calibration values somehow.

Those calibration values obviously can't be hardcoded in the application. They
must come from the dive computer somehow. Maybe they are stored elsewhere in the
data, and we just don't know where? There aren't many unused bytes left, so I
don't where they could be hiding.

The Shearwater documentations says this about those calibration fields:

"Only valid when configured as an analog PPO2 monitor (i.e. this is not
valid when a DiveCAN PPO2 monitor, as this info is stored in the peripheral
circuit board)."

So that's seems to confirm the values are just not there for the DiveCAN
monitor. Unfortunately it also doesn't say how to detect whether an analog or
DiveCAN monitor was used. Which model do you have?

Jef

[jimbodude]

Jef:

That's the result I was expecting. Since we're doing a simple linear calibration
(ppO2 = mV * calibration), the "shape" of the mV and ppO2 curves will always be
the same. But of course the numerical values are different.

Note that if all three calibration values are the same (e.g. the default value
of 2100), then the resulting ppO2 values are simply scaled mV values.

I agree - the result of the experiment makes sense mathematically and logically.

 

Willem:

Its been some time since I worked with this, but this is what I think happens. The three individual 'PO2' values are actually voltages. The meaning of each of these voltages is dependent on the reference values when calibrating that particular O2 sensor. IIRC this is also affected by altitude. From these voltages the Shearwater calculates a voted Po2 value that is readily accessible. However the calibration values for each of the sensors are, as far as I can remember, not accessible. So doing anything useful with the voltages is not easy. IIRC the Shearwater software also does not give individual PO2 values, only the voltages.

This aligns with what I'm seeing and what others are hinting at.

Jef:

The Shearwater documentations says this about those calibration fields:

"Only valid when configured as an analog PPO2 monitor (i.e. this is not
valid when a DiveCAN PPO2 monitor, as this info is stored in the peripheral
circuit board)."

So that's seems to confirm the values are just not there for the DiveCAN
monitor. Unfortunately it also doesn't say how to detect whether an analog or
DiveCAN monitor was used. Which model do you have?

I have a DiveCAN.  Is that documentation available online?

 

Jef:

Are you sure the CCR Tools app shows the ppO2 value, and not just the mV values?
If it really shows a (correct) ppO2 value, that would be interesting. Because
that means it must have access to the calibration values somehow.

 

It shows individual ppO2 values over the whole dive, and they are within a valid range.  I will try to challenge the assumption that the app has access to calibration data, since it doesn't sound like calibration data should be available based on documentation and experimentation.  Maybe it's doing something "smart", like figuring out its own calibration based on the cell values and the reported average...

[Stuart Vernon]

Since he has a DiveCAN monitor, that means that it is connected to an OBOE board in the CCR itself, and the calibration values are stored there. That is what supports the capability to unplug a monitor from one CCR and plug it into another (e.g. a backup CCR) and continue to use the monitor with the new unit. If the NERD (or whatever) stored the calibration coefficients then plugging it into a different unit would yield erroneous ppO2 readings.

 

Since CCR Tools is able to show sensor readings and mV values, then I speculate one of two things is happening:

 

One, the DiveCAN interface is supplying both pieces of data (ppO2 value and mV value) to the computer. This seems very likely, whether the computer includes both pieces of data in the log or not.

 

Or, two, it is assuming a calibration coefficient and Jef is just lucky enough to have sensors that match or are very close to the default calibration coefficient, thus yielding “believable” values in what CCR Tools is showing.

 

Any chance of emailing the author of CCR Tools to ask?

--

You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/9efb424c-8581-4552-bae4-fcc3eb91919co%40googlegroups.com.

[jimbodude]

On Tuesday, June 9, 2020 at 9:46:24 AM UTC-4, Stuart Vernon wrote:

Any chance of emailing the author of CCR Tools to ask?

Question sent to developer.