Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Joakim Bygdell]

 10 May 2017 at 15:47, Anton Lundin  wrote:

> On 10 May, 2017 - Joakim Bygdell wrote:
>
> > On 10 May 2017 at 11:33, Anton Lundin  wrote:
> >
> > > Do we have any data from a Shearwater running as solenoid controller?
> >
> > I have data from a JJ in eCCr mode.
> > There is no sensor data in that log, only setpoint information at the
> > start,
> > when the setpoint changes during the descent and before surfacing.
>
> Are you sure? How did you look?


> You need to have applied the patches discussed here to have
> libdivecomputer expose that information.
>

To get individual cell information yes, and there is probably more
information we can get from those DCs.

Based on what was saved to subsurface logfile, eCCR log shows only setpoint
information, mCCR setpoint (which is unused) and voted ppO2.



> Anyway, looking at the data would be interesting, trying to figure out
> if there is any bits there disclosing that the computer was running in a
> controller mode, and if there are any bits there saying when it fired
> the solenoid.
>
>
> //Anton
>
>
> --
> Anton Lundin+46702-161604
>



-- 
// Jocke
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Davide DB]

On 10 May 2017 at 15:47, Anton Lundin  wrote:
>
> Anyway, looking at the data would be interesting, trying to figure out
> if there is any bits there disclosing that the computer was running in a
> controller mode, and if there are any bits there saying when it fired
> the solenoid.

I guess you need raw data coming from the DC.
I have with me a JJ dive in eCCR mode exported in xml from Shearwater desktop.
I can share it if you need.

-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Steve]

From phone. I am happy for you to show my dives.
I am diving a Kiss manual ccr so the computer is only used as a display of the 
sensors.
It doesnt do any control, that is up to the computer in my head ;)
Eg where it goes up to 1.75 it would have been me checking that the cells were 
not current limited.
Also as I cave dive the environment dictates ups and down a fair bit.
I might let the ppo2 wander around rather than always wasteing gas (adding and 
removing gas constantly) just to be within 1% of a target number like the 
computer running a solenoid controlling the o2 would.
Steve

 Original message From: Jef Driesen 
 Date:10/05/2017  21:37  (GMT+09:30) 
To: Anton Lundin  Cc: Subsurface 
 Subject: Re: [PATCH] 
Visualisation of individual oxygen sensor data for CCR
  dives 
On 2017-05-10 11:33, Anton Lundin wrote:
> On 10 May, 2017 - Jef Driesen wrote:
>> I've implemented the scaling factor now. See attached set of
>> patches. It took me a bit longer than expected because there were a
>> few cases where the ppO2 still ended up being zero. And that turned
>> out to be for dives without external O2 sensors enabled (e.g. fixed
>> setpoint mode). But the tricky part was that the external PPO2 bit
>> seems to be reversed. According to the documentation [1] external
>> PPO2 is 1 and internal PPO2 is 0. But based on the data I have, it
>> seems to be the opposite.
>> 
>> BTW, I wonder if we should ignore the setpoint value when external
>> O2 sensors are used? Are setpoint still used in such case?
> 
> Do we have any data from a Shearwater running as solenoid controller?
> 
> Ex. On the JJ-CCR's they use a Shearwater Petrel with sensors which
> controls the o2 solenoid to try to get the o2 sensor values to match
> your configured setpoint.

I have data from several Petrels, but I have no idea how they were being 
used. Is it possible to detect this somehow based on the data itself?

> That said, I think setpoint values are still interesting to see, to
> validate how well the controller did manage to try to keep the o2 close
> to the setpoint.

After looking at the data, I had the impression that the setpoint value 
is "unused" because it seems to just contain some "dummy" value (for 
example the last used value, or some default value).

I'll illustrate with an example dive from Steve's Petrel (*). This dive 
has a fixed setpoint of 0.70 on every sample, but the ppo2 values range 
from 0.32 to 1.74!

(*) I can send you the data if you want to take a look. I don't know if 
Steve is okay with sending his dives to a public mailinglist, so I 
didn't attach it to this email.

To me that doesn't look like the dive computer is even trying to keep 
the ppo2 close to the setpoint. At least not to the setpoint value 
that's stored in the sample. Hence my question whether this value is 
relevant or not?

> Attached is the last iteration I did of the sensors patch. It has some
> minor differences from the one you included, but most of them isn't 
> that
> relevant.

The part where you add 1024 to the calibration value is actually worse 
then the original version where you only did that if the value is 
smaller than 1000. It works (although not perfect) for the Predator, but 
it breaks for the Petrel because it doesn't need any correction at all. 
The variant with the if < 1000 works for the Petrel because the values 
are always greater than 1000, and also for some Predators, but not all 
because sometimes the values are greater than 1000 too. So if you want 
to do it correctly, then you would need to check on the model as I did 
in the third patch. If you want, I can move that code from the third 
patch to the second one.

The SENSOR_AVERAGE is maybe a good idea to keep around. Might come in 
handy once we have a way to communicate the type of value (sensor vs 
average/voted).

> The only relevant information is that the adc offset value is probably
> in 0.025 mV as unit.
> Thats party based on the information in
> https://www.shearwater.com/wp-content/uploads/2016/07/O2-Offsets-Public-Notice-RevA.pdf

The info in the comments is indeed useful knowledge, but since we're not 
using the adc values, it's pretty pointless to store them in the parser 
struct. It's just a waste of space there. I know it's only a few bytes, 
but I see no good reason to clutter the code with unused stuff.

> The only real comment about the code is that I would have liked to see
> the calibration factor kept as a int, and just change the unit factor
> from .1 to .22, between the models.

What would be the advantage of that? That would mean yet some other 
field to store the scaling factor, or doing some "if (model == 
PREDATOR)" when calculating the ppo2. Now it's just done once in 
advance, making the conversion from millivolt to ppO2 independent of the 
model. I'm even tempted to pre-multiply the value with the 10.0 
factor too, to get rid 

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Anton Lundin]

On 10 May, 2017 - Joakim Bygdell wrote:

> On 10 May 2017 at 11:33, Anton Lundin  wrote:
>
> > Do we have any data from a Shearwater running as solenoid controller?
>
> I have data from a JJ in eCCr mode.
> There is no sensor data in that log, only setpoint information at the
> start,
> when the setpoint changes during the descent and before surfacing.

Are you sure? How did you look?

You need to have applied the patches discussed here to have
libdivecomputer expose that information.

Anyway, looking at the data would be interesting, trying to figure out
if there is any bits there disclosing that the computer was running in a
controller mode, and if there are any bits there saying when it fired
the solenoid.


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Anton Lundin]

On 10 May, 2017 - Jef Driesen wrote:

> On 2017-05-10 11:33, Anton Lundin wrote:
> >On 10 May, 2017 - Jef Driesen wrote:
> >>I've implemented the scaling factor now. See attached set of
> >>patches. It took me a bit longer than expected because there were a
> >>few cases where the ppO2 still ended up being zero. And that turned
> >>out to be for dives without external O2 sensors enabled (e.g. fixed
> >>setpoint mode). But the tricky part was that the external PPO2 bit
> >>seems to be reversed. According to the documentation [1] external
> >>PPO2 is 1 and internal PPO2 is 0. But based on the data I have, it
> >>seems to be the opposite.
> >>
> >>BTW, I wonder if we should ignore the setpoint value when external
> >>O2 sensors are used? Are setpoint still used in such case?
> >
> >Do we have any data from a Shearwater running as solenoid controller?
> >
> >Ex. On the JJ-CCR's they use a Shearwater Petrel with sensors which
> >controls the o2 solenoid to try to get the o2 sensor values to match
> >your configured setpoint.
> 
> I have data from several Petrels, but I have no idea how they were
> being used. Is it possible to detect this somehow based on the data
> itself?
> 

Might be some bits there indicating that, but none that I know off.

> >That said, I think setpoint values are still interesting to see, to
> >validate how well the controller did manage to try to keep the o2 close
> >to the setpoint.
> 
> After looking at the data, I had the impression that the setpoint
> value is "unused" because it seems to just contain some "dummy"
> value (for example the last used value, or some default value).
> 
> I'll illustrate with an example dive from Steve's Petrel (*). This
> dive has a fixed setpoint of 0.70 on every sample, but the ppo2
> values range from 0.32 to 1.74!

This sounds like a mCCR. Then its up to the diver to press a button
until the ppo2 matches what the diver would like to have.

> (*) I can send you the data if you want to take a look. I don't know
> if Steve is okay with sending his dives to a public mailinglist, so
> I didn't attach it to this email.
> 
> To me that doesn't look like the dive computer is even trying to
> keep the ppo2 close to the setpoint. At least not to the setpoint
> value that's stored in the sample. Hence my question whether this
> value is relevant or not?

I think so.

My guess is that the setpoint is what the computer will continue to use
as its ppo2 value if it looses the connection with the sensors.

Its better to expose the information to the user, and let the user
ignore/delete it if they don't care about it.

> >Attached is the last iteration I did of the sensors patch. It has some
> >minor differences from the one you included, but most of them
> >isn't that
> >relevant.
> 
> The part where you add 1024 to the calibration value is actually
> worse then the original version where you only did that if the value
> is smaller than 1000. It works (although not perfect) for the
> Predator, but it breaks for the Petrel because it doesn't need any
> correction at all. The variant with the if < 1000 works for the
> Petrel because the values are always greater than 1000, and also for
> some Predators, but not all because sometimes the values are greater
> than 1000 too. So if you want to do it correctly, then you would
> need to check on the model as I did in the third patch. If you want,
> I can move that code from the third patch to the second one.
> 
> The SENSOR_AVERAGE is maybe a good idea to keep around. Might come
> in handy once we have a way to communicate the type of value (sensor
> vs average/voted).
> 
> >The only relevant information is that the adc offset value is probably
> >in 0.025 mV as unit.
> >Thats party based on the information in
> >https://www.shearwater.com/wp-content/uploads/2016/07/O2-Offsets-Public-Notice-RevA.pdf
> 
> The info in the comments is indeed useful knowledge, but since we're
> not using the adc values, it's pretty pointless to store them in the
> parser struct. It's just a waste of space there. I know it's only a
> few bytes, but I see no good reason to clutter the code with unused
> stuff.
> 
> >The only real comment about the code is that I would have liked to see
> >the calibration factor kept as a int, and just change the unit factor
> >from .1 to .22, between the models.
> 
> What would be the advantage of that? That would mean yet some other
> field to store the scaling factor, or doing some "if (model ==
> PREDATOR)" when calculating the ppo2. Now it's just done once in
> advance, making the conversion from millivolt to ppO2 independent of
> the model. I'm even tempted to pre-multiply the value with the
> 10.0 factor too, to get rid of an extra

I'd store it as a separate calibration factor unit. Anyway, if you
multiply the calibration factor with 2.2 as of now, its better to
include the 1/10 factor to, rather than having them in two separate
places.


//Anton


-- 
Anton Lundin+46702-161604

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Davide DB]

On 10 May 2017 at 14:33, Joakim Bygdell  wrote:
>
> I have seen similar things on data from mCCRs, fixed setpoint and variable
> sensor data, the setpoint of 0.7 seems to be some sort of default value on
> shearwaters DCs.
> When the DC is used only as a visual reference of the measured ppO2 the
> resulting data structure is logical.

I'm using my SF2 in mCCR mode so I left the setpoint to 0.7 then I
manually fly the unit to the desired ppO2. 0,7 is a sort of safe-net.
On the Petrel you can change the LOW setpoint but the minimum allowed
value is 0,4 I guess.

Do you need some log of this type?

Bye

--
davide
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Joakim Bygdell]

On 10 May 2017 at 14:07, Jef Driesen  wrote:

> On 2017-05-10 11:33, Anton Lundin wrote:
>
>> On 10 May, 2017 - Jef Driesen wrote:
>>
>>> I've implemented the scaling factor now. See attached set of
>>> patches. It took me a bit longer than expected because there were a
>>> few cases where the ppO2 still ended up being zero. And that turned
>>> out to be for dives without external O2 sensors enabled (e.g. fixed
>>> setpoint mode). But the tricky part was that the external PPO2 bit
>>> seems to be reversed. According to the documentation [1] external
>>> PPO2 is 1 and internal PPO2 is 0. But based on the data I have, it
>>> seems to be the opposite.
>>>
>>> BTW, I wonder if we should ignore the setpoint value when external
>>> O2 sensors are used? Are setpoint still used in such case?
>>>
>>
>> Do we have any data from a Shearwater running as solenoid controller?
>>
>> Ex. On the JJ-CCR's they use a Shearwater Petrel with sensors which
>> controls the o2 solenoid to try to get the o2 sensor values to match
>> your configured setpoint.
>>
>
> I have data from several Petrels, but I have no idea how they were being
> used. Is it possible to detect this somehow based on the data itself?
>
> That said, I think setpoint values are still interesting to see, to
>> validate how well the controller did manage to try to keep the o2 close
>> to the setpoint.
>>
>
> After looking at the data, I had the impression that the setpoint value is
> "unused" because it seems to just contain some "dummy" value (for example
> the last used value, or some default value).
>
> I'll illustrate with an example dive from Steve's Petrel (*). This dive
> has a fixed setpoint of 0.70 on every sample, but the ppo2 values range
> from 0.32 to 1.74!


> (*) I can send you the data if you want to take a look. I don't know if
> Steve is okay with sending his dives to a public mailinglist, so I didn't
> attach it to this email.
>
> To me that doesn't look like the dive computer is even trying to keep the
> ppo2 close to the setpoint. At least not to the setpoint value that's
> stored in the sample. Hence my question whether this value is relevant or
> not?


I have seen similar things on data from mCCRs, fixed setpoint and variable
sensor data, the setpoint of 0.7 seems to be some sort of default value on
shearwaters DCs.
When the DC is used only as a visual reference of the measured ppO2 the
resulting data structure is logical.


>
> Attached is the last iteration I did of the sensors patch. It has some
>> minor differences from the one you included, but most of them isn't that
>> relevant.
>>
>
> The part where you add 1024 to the calibration value is actually worse
> then the original version where you only did that if the value is smaller
> than 1000. It works (although not perfect) for the Predator, but it breaks
> for the Petrel because it doesn't need any correction at all. The variant
> with the if < 1000 works for the Petrel because the values are always
> greater than 1000, and also for some Predators, but not all because
> sometimes the values are greater than 1000 too. So if you want to do it
> correctly, then you would need to check on the model as I did in the third
> patch. If you want, I can move that code from the third patch to the second
> one.
>
> The SENSOR_AVERAGE is maybe a good idea to keep around. Might come in
> handy once we have a way to communicate the type of value (sensor vs
> average/voted).
>
> The only relevant information is that the adc offset value is probably
>> in 0.025 mV as unit.
>> Thats party based on the information in
>> https://www.shearwater.com/wp-content/uploads/2016/07/O2-Off
>> sets-Public-Notice-RevA.pdf
>>
>
> The info in the comments is indeed useful knowledge, but since we're not
> using the adc values, it's pretty pointless to store them in the parser
> struct. It's just a waste of space there. I know it's only a few bytes, but
> I see no good reason to clutter the code with unused stuff.
>
> The only real comment about the code is that I would have liked to see
>> the calibration factor kept as a int, and just change the unit factor
>> from .1 to .22, between the models.
>>
>
> What would be the advantage of that? That would mean yet some other field
> to store the scaling factor, or doing some "if (model == PREDATOR)" when
> calculating the ppo2. Now it's just done once in advance, making the
> conversion from millivolt to ppO2 independent of the model. I'm even
> tempted to pre-multiply the value with the 10.0 factor too, to get rid
> of an extra
>
> Jef
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>



-- 
// Jocke
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Jef Driesen]

On 2017-05-10 11:33, Anton Lundin wrote:

On 10 May, 2017 - Jef Driesen wrote:

I've implemented the scaling factor now. See attached set of
patches. It took me a bit longer than expected because there were a
few cases where the ppO2 still ended up being zero. And that turned
out to be for dives without external O2 sensors enabled (e.g. fixed
setpoint mode). But the tricky part was that the external PPO2 bit
seems to be reversed. According to the documentation [1] external
PPO2 is 1 and internal PPO2 is 0. But based on the data I have, it
seems to be the opposite.

BTW, I wonder if we should ignore the setpoint value when external
O2 sensors are used? Are setpoint still used in such case?


Do we have any data from a Shearwater running as solenoid controller?

Ex. On the JJ-CCR's they use a Shearwater Petrel with sensors which
controls the o2 solenoid to try to get the o2 sensor values to match
your configured setpoint.


I have data from several Petrels, but I have no idea how they were being 
used. Is it possible to detect this somehow based on the data itself?



That said, I think setpoint values are still interesting to see, to
validate how well the controller did manage to try to keep the o2 close
to the setpoint.


After looking at the data, I had the impression that the setpoint value 
is "unused" because it seems to just contain some "dummy" value (for 
example the last used value, or some default value).


I'll illustrate with an example dive from Steve's Petrel (*). This dive 
has a fixed setpoint of 0.70 on every sample, but the ppo2 values range 
from 0.32 to 1.74!


(*) I can send you the data if you want to take a look. I don't know if 
Steve is okay with sending his dives to a public mailinglist, so I 
didn't attach it to this email.


To me that doesn't look like the dive computer is even trying to keep 
the ppo2 close to the setpoint. At least not to the setpoint value 
that's stored in the sample. Hence my question whether this value is 
relevant or not?



Attached is the last iteration I did of the sensors patch. It has some
minor differences from the one you included, but most of them isn't 
that

relevant.


The part where you add 1024 to the calibration value is actually worse 
then the original version where you only did that if the value is 
smaller than 1000. It works (although not perfect) for the Predator, but 
it breaks for the Petrel because it doesn't need any correction at all. 
The variant with the if < 1000 works for the Petrel because the values 
are always greater than 1000, and also for some Predators, but not all 
because sometimes the values are greater than 1000 too. So if you want 
to do it correctly, then you would need to check on the model as I did 
in the third patch. If you want, I can move that code from the third 
patch to the second one.


The SENSOR_AVERAGE is maybe a good idea to keep around. Might come in 
handy once we have a way to communicate the type of value (sensor vs 
average/voted).



The only relevant information is that the adc offset value is probably
in 0.025 mV as unit.
Thats party based on the information in
https://www.shearwater.com/wp-content/uploads/2016/07/O2-Offsets-Public-Notice-RevA.pdf


The info in the comments is indeed useful knowledge, but since we're not 
using the adc values, it's pretty pointless to store them in the parser 
struct. It's just a waste of space there. I know it's only a few bytes, 
but I see no good reason to clutter the code with unused stuff.



The only real comment about the code is that I would have liked to see
the calibration factor kept as a int, and just change the unit factor
from .1 to .22, between the models.


What would be the advantage of that? That would mean yet some other 
field to store the scaling factor, or doing some "if (model == 
PREDATOR)" when calculating the ppo2. Now it's just done once in 
advance, making the conversion from millivolt to ppO2 independent of the 
model. I'm even tempted to pre-multiply the value with the 10.0 
factor too, to get rid of an extra


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Joakim Bygdell]

On 10 May 2017 at 11:33, Anton Lundin  wrote:

> On 10 May, 2017 - Jef Driesen wrote:
>

 

Do we have any data from a Shearwater running as solenoid controller?
>
> Ex. On the JJ-CCR's they use a Shearwater Petrel with sensors which
> controls the o2 solenoid to try to get the o2 sensor values to match
> your configured setpoint.
>
> I have data from a JJ in eCCr mode.
There is no sensor data in that log, only setpoint information at the
start,
when the setpoint changes during the descent and before surfacing.


> That said, I think setpoint values are still interesting to see, to
> validate how well the controller did manage to try to keep the o2 close
> to the setpoint.
>
>
> Attached is the last iteration I did of the sensors patch. It has some
> minor differences from the one you included, but most of them isn't that
> relevant.
>
>
> The only relevant information is that the adc offset value is probably
> in 0.025 mV as unit.
> Thats party based on the information in
> https://www.shearwater.com/wp-content/uploads/2016/07/O2-
> Offsets-Public-Notice-RevA.pdf
>
>
> The only real comment about the code is that I would have liked to see
> the calibration factor kept as a int, and just change the unit factor
> from .1 to .22, between the models.
>
>
> //Anton
>
>
> --
> Anton Lundin+46702-161604
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>



-- 
// Jocke
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Anton Lundin]

On 10 May, 2017 - Anton Lundin wrote:

> Attached is the last iteration I did of the sensors patch. It has some
> minor differences from the one you included, but most of them isn't that
> relevant.
> 
> 
> The only relevant information is that the adc offset value is probably
> in 0.025 mV as unit.
> Thats party based on the information in
> https://www.shearwater.com/wp-content/uploads/2016/07/O2-Offsets-Public-Notice-RevA.pdf
> 

Of course I forgot to attach the patch, so here it comes.

-- 
Anton Lundin+46702-161604
>From 0aa217a6f4253e12db3e440dde10647ca3a8a4c1 Mon Sep 17 00:00:00 2001
From: Anton Lundin 
Date: Wed, 14 Oct 2015 19:49:25 +0200
Subject: [PATCH] shearwater: Report individual sensor values

This reads the reported mV values from the sensors, and based on the
calibration values converts it into a ppo2 value to report.

Signed-off-by: Anton Lundin 
---
 src/shearwater_predator_parser.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/src/shearwater_predator_parser.c b/src/shearwater_predator_parser.c
index fba5629..254af5b 100644
--- a/src/shearwater_predator_parser.c
+++ b/src/shearwater_predator_parser.c
@@ -69,6 +69,8 @@ struct shearwater_predator_parser_t {
 	unsigned int helium[NGASMIXES];
 	unsigned int serial;
 	dc_divemode_t mode;
+	unsigned int sensor_cal_value[3];
+	signed char sensor_adc_offset[3];
 };
 
 static dc_status_t shearwater_predator_parser_set_data (dc_parser_t *abstract, const unsigned char *data, unsigned int size);
@@ -297,6 +299,25 @@ shearwater_predator_parser_cache (shearwater_predator_parser_t *parser)
 		offset += parser->samplesize;
 	}
 
+	// Cache sensor calibration for later use
+	parser->sensor_cal_value[0] = array_uint16_be(data + 87);
+	parser->sensor_cal_value[1] = array_uint16_be(data + 89);
+	parser->sensor_cal_value[2] = array_uint16_be(data + 91);
+	// The Predator expects the mV output of the cells to be within 30mV to
+	// 70mV in 100% O2 at 1 atmosphere.
+	// If we add 1024 (1000?) to the cal value, then the sensors lines up
+	// and matches the average
+	parser->sensor_cal_value[0] += 1024;
+	parser->sensor_cal_value[1] += 1024;
+	parser->sensor_cal_value[2] += 1024;
+
+	// Cache sensor adc offset for later use
+	// Unit is probably 0.025 mV
+	// Is this included in the stored value, or its it "raw"?
+	parser->sensor_adc_offset[0] = data[93];
+	parser->sensor_adc_offset[1] = data[94];
+	parser->sensor_adc_offset[2] = data[95];
+
 	// Cache the data for later use.
 	parser->headersize = headersize;
 	parser->footersize = footersize;
@@ -493,8 +514,19 @@ shearwater_predator_parser_samples_foreach (dc_parser_t *abstract, dc_sample_cal
 
 		if ((status & OC) == 0) {
 			// PPO2 -- only return PPO2 if we are in closed circuit mode
+#ifdef SENSOR_AVERAGE
 			sample.ppo2 = data[offset + 6] / 100.0;
 			if (callback) callback (DC_SAMPLE_PPO2, sample, userdata);
+#else
+			sample.ppo2 = data[offset + 12] * parser->sensor_cal_value[0] / 10.0;
+			if (callback && (data[86] & 0x01)) callback (DC_SAMPLE_PPO2, sample, userdata);
+
+			sample.ppo2 = data[offset + 14] * parser->sensor_cal_value[1] / 10.0;
+			if (callback && (data[86] & 0x02)) callback (DC_SAMPLE_PPO2, sample, userdata);
+
+			sample.ppo2 = data[offset + 15] * parser->sensor_cal_value[2] / 10.0;
+			if (callback && (data[86] & 0x04)) callback (DC_SAMPLE_PPO2, sample, userdata);
+#endif
 
 			// Setpoint
 			if (parser->petrel) {
-- 
2.9.3

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Anton Lundin]

On 10 May, 2017 - Jef Driesen wrote:

> On 2017-04-17 21:49, Jef Driesen wrote:
> >On 14-04-17 22:04, Anton Lundin wrote:
> >>On 14 April, 2017 - Jef Driesen wrote:
> >>
> >>>On 2017-04-13 17:04, Jef Driesen wrote:
> >>>I tried a different approach yesterday. Instead of adding 1024 to
> >>>the calibration value, I simply used the stored value as is, and
> >>>calculated the average ppO2 over all three sensors. Then I plotted
> >>>all those values against the average ppO2 reported by the device.
> >>>And guess what, there is a nice linear relationship between the two!
> >>>Doing a linear regression on the data gives a scaling factor of 2.2.
> >>
> >>Interesting find.
> >>
> >>>For the example above this gives:
> >>>
> >>>Sensor 0: 0.642 = 33 mV * 885 / 10.0 * 2.2
> >>>Sensor 1: 0.630 = 29 mV * 989 / 10.0 * 2.2
> >>>Sensor 2: 0.674 = 26 mv * 1179 / 10.0 * 2.2
> >>>
> >>>As you can see, the average ppO2 (0.648) is now very close to the
> >>>average ppO2 reported by the device (0.65). This seems to be true
> >>>for all samples. The largest difference is now 0.018.
> >>>
> >>>The next question is of course what's the source of this factor 2.2?
> >>
> >>Could it be that the calibration value is stored in some odd
> >>format, and
> >>thats where the / 10.0 * 2.2 part comes from?
> >
> >My first thought was that it represents some kind of relative value.
> >If you look at one of my previous emails, you'll notice that the
> >default value for the calibration (when not yet calibrated) is 2100
> >for the Petrel. And the calibration values for the Predator are all
> >near the value 1000. Relative that's a factor of 2.1. That's not close
> >enough to 2.2 to produce correct ppO2 values, but it's the only
> >explanation I have that makes some sense to me.
> >
> >BTW, the fact that the calibration values are near 1000 is also why
> >adding 1024 worked for most samples. If the value is a bit higher than
> >1000, then the result is pretty close to multiplying with 2.2.
> >
> >>>And is correct for all Predators?
> >>
> >>How did it line up on the petrels?
> >
> >I only checked for the predators. For the petrel, the results are
> >already correct without the 2.2 scaling factor. So applying it there
> >too, will produce wrong results. So this is most likely something
> >specific to the predators only.
> 
> I've implemented the scaling factor now. See attached set of
> patches. It took me a bit longer than expected because there were a
> few cases where the ppO2 still ended up being zero. And that turned
> out to be for dives without external O2 sensors enabled (e.g. fixed
> setpoint mode). But the tricky part was that the external PPO2 bit
> seems to be reversed. According to the documentation [1] external
> PPO2 is 1 and internal PPO2 is 0. But based on the data I have, it
> seems to be the opposite.
> 
> BTW, I wonder if we should ignore the setpoint value when external
> O2 sensors are used? Are setpoint still used in such case?

Do we have any data from a Shearwater running as solenoid controller?

Ex. On the JJ-CCR's they use a Shearwater Petrel with sensors which
controls the o2 solenoid to try to get the o2 sensor values to match
your configured setpoint.


That said, I think setpoint values are still interesting to see, to
validate how well the controller did manage to try to keep the o2 close
to the setpoint.


Attached is the last iteration I did of the sensors patch. It has some
minor differences from the one you included, but most of them isn't that
relevant.


The only relevant information is that the adc offset value is probably
in 0.025 mV as unit.
Thats party based on the information in
https://www.shearwater.com/wp-content/uploads/2016/07/O2-Offsets-Public-Notice-RevA.pdf


The only real comment about the code is that I would have liked to see
the calibration factor kept as a int, and just change the unit factor
from .1 to .22, between the models.


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Visualisation of individual oxygen sensor data for CCR dives

[Jef Driesen]

On 2017-04-17 21:49, Jef Driesen wrote:

On 14-04-17 22:04, Anton Lundin wrote:

On 14 April, 2017 - Jef Driesen wrote:


On 2017-04-13 17:04, Jef Driesen wrote:
I tried a different approach yesterday. Instead of adding 1024 to
the calibration value, I simply used the stored value as is, and
calculated the average ppO2 over all three sensors. Then I plotted
all those values against the average ppO2 reported by the device.
And guess what, there is a nice linear relationship between the two!
Doing a linear regression on the data gives a scaling factor of 2.2.


Interesting find.


For the example above this gives:

Sensor 0: 0.642 = 33 mV * 885 / 10.0 * 2.2
Sensor 1: 0.630 = 29 mV * 989 / 10.0 * 2.2
Sensor 2: 0.674 = 26 mv * 1179 / 10.0 * 2.2

As you can see, the average ppO2 (0.648) is now very close to the
average ppO2 reported by the device (0.65). This seems to be true
for all samples. The largest difference is now 0.018.

The next question is of course what's the source of this factor 2.2?


Could it be that the calibration value is stored in some odd format, 
and

thats where the / 10.0 * 2.2 part comes from?


My first thought was that it represents some kind of relative value.
If you look at one of my previous emails, you'll notice that the
default value for the calibration (when not yet calibrated) is 2100
for the Petrel. And the calibration values for the Predator are all
near the value 1000. Relative that's a factor of 2.1. That's not close
enough to 2.2 to produce correct ppO2 values, but it's the only
explanation I have that makes some sense to me.

BTW, the fact that the calibration values are near 1000 is also why
adding 1024 worked for most samples. If the value is a bit higher than
1000, then the result is pretty close to multiplying with 2.2.


And is correct for all Predators?


How did it line up on the petrels?


I only checked for the predators. For the petrel, the results are
already correct without the 2.2 scaling factor. So applying it there
too, will produce wrong results. So this is most likely something
specific to the predators only.


I've implemented the scaling factor now. See attached set of patches. It 
took me a bit longer than expected because there were a few cases where 
the ppO2 still ended up being zero. And that turned out to be for dives 
without external O2 sensors enabled (e.g. fixed setpoint mode). But the 
tricky part was that the external PPO2 bit seems to be reversed. 
According to the documentation [1] external PPO2 is 1 and internal PPO2 
is 0. But based on the data I have, it seems to be the opposite.


BTW, I wonder if we should ignore the setpoint value when external O2 
sensors are used? Are setpoint still used in such case?


[1] 
http://lists.subsurface-divelog.org/pipermail/subsurface/2017-April/028144.html


JefFrom 4e97d96246a5500865585d93c96be17939705d98 Mon Sep 17 00:00:00 2001
From: Dirk Hohndel 
Date: Fri, 6 Feb 2015 09:56:21 -0800
Subject: [PATCH 1/4] Predator: don't report PPO2 unless in CC mode

Sending this in OC mode is redundant and might confuse applications that
assume they only get PPO2 data in CC mode.

Signed-off-by: Dirk Hohndel 
---
 src/shearwater_predator_parser.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/shearwater_predator_parser.c b/src/shearwater_predator_parser.c
index 039926f..c71c9d7 100644
--- a/src/shearwater_predator_parser.c
+++ b/src/shearwater_predator_parser.c
@@ -422,11 +422,11 @@ shearwater_predator_parser_samples_foreach (dc_parser_t *abstract, dc_sample_cal
 		// Status flags.
 		unsigned int status = data[offset + 11];
 
-		// PPO2
-		sample.ppo2 = data[offset + 6] / 100.0;
-		if (callback) callback (DC_SAMPLE_PPO2, sample, userdata);
-
 		if ((status & OC) == 0) {
+			// PPO2
+			sample.ppo2 = data[offset + 6] / 100.0;
+			if (callback) callback (DC_SAMPLE_PPO2, sample, userdata);
+
 			// Setpoint
 			if (parser->petrel) {
 sample.setpoint = data[offset + 18] / 100.0;
-- 
2.11.0

From fe5e519519a3bae9637dcc2467b3d0354f47c631 Mon Sep 17 00:00:00 2001
From: Anton Lundin 
Date: Wed, 14 Oct 2015 19:49:25 +0200
Subject: [PATCH 2/4] shearwater: Report individual sensor values

This reads the reported mV values from the sensors, and based on the
calibration values converts it into a ppo2 value to report.

Signed-off-by: Anton Lundin 
---
 src/shearwater_predator_parser.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/src/shearwater_predator_parser.c b/src/shearwater_predator_parser.c
index c71c9d7..9b80fa5 100644
--- a/src/shearwater_predator_parser.c
+++ b/src/shearwater_predator_parser.c
@@ -61,6 +61,7 @@ struct shearwater_predator_parser_t {
 	unsigned int ngasmixes;
 	unsigned int oxygen[NGASMIXES];
 	unsigned int helium[NGASMIXES];
+	unsigned int calibration[3];
 	dc_divemode_t mode;
 };
 
@@ -281,6 +282,23 @@