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

[Davide DB]

On 17 May 2017 at 21:56, Davide DB  wrote:
> I uploaded a zip containing 54 eccr dives obtained via dctool from a
> JJ Petrel controller.
>
> https://drive.google.com/open?id=0B1RlIJJRLXsHX3JrcXllUXhDTmM
>
> All dives use 0,7 and 1,2 as setpoints.


Another batch of 24 eccr dives coming from a different JJ Petrel 2
divecan controller.
This time all of them have set-points at 0,7 and 1,3.

https://drive.google.com/open?id=0B1RlIJJRLXsHeWNoc09GT01EQWc

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

[Davide DB]

I uploaded a zip containing 54 eccr dives obtained via dctool from a
JJ Petrel controller.

https://drive.google.com/open?id=0B1RlIJJRLXsHX3JrcXllUXhDTmM

All dives use 0,7 and 1,2 as setpoints.

I hope they could be useful for testing this and future features. Just
keep them for future reference.

It's a shame I was not able to download all dives (108) from that
unit. He had a complete set of dives between sensor changes.
I always get a timeout error. I tried dozen of times without luck.
Host was a iMac. ATM I have no chance to find another computer.

INFO: Read: size=0, data=
ERROR: Failed to receive the response packet. [in
../../source/src/shearwater_common.c:319 (shearwater_common_transfer)]
ERROR: Failed to download the dive. [in
../../source/src/shearwater_petrel.c:265
(shearwater_petrel_device_foreach)]
[39.029349] ERROR: Error downloading the dives. [in
../../source/examples/dctool_download.c:218 (download)]
[39.029480] INFO: Write: size=9, data=FF0105002E902000C0
[39.681489] ERROR: Timeout

On Petrel display I just get Bluetooth error: Send packet Err. (dc has
a new Saft battery).

Sometimes I got the error just few seconds after the start, sometimes
at the end of the Petrel countdown.
How does it work? Is it a watchdog or he pretends to complete the full
download within 3 minutes?
___
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 11-05-17 14:37, Anton Lundin wrote:

On 11 May, 2017 - Jef Driesen wrote:

I replaced your patch with your latest version, and updated the rest
of the series. Please have a look. If you are okay with the changes,
I'll merge them to master.


LGTM.

You can add my Reviewed-by: Anton Lundin  tag to the
patches if you like.


I have pushed the changes to master.


I think its a good idea to keep the O2 sensors behind the SENSOR_AVERAGE
ifdef for now, and try to figure out a nice scheme to expose both the
raw sensors and the "voted average" value as different things to the
application.


Indeed. That'll be the next step.


The two other libdivecomputer backends emitting DC_SAMPLE_PPO2 are
diverite_nitekq_parser and the hw_ostc_parser. The HW values are raw
sensor values, but do you know what the diverite_nitekq_parser value
are?


It's been a while since I reverse engineered the nitekq and I simply don't 
remember anymore. But since there is just one value, my guess is that it's 
probably the average ppo2.


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

[Davide DB]

On 11 May 2017 at 16:44, Jef Driesen  wrote:
>
> There is no need to send me the other dives. I already managed to extract
> them from the log file. I just need to know which dives I should take look

The most recent 5 dives are all mCCR with a setpoint of 0,7

Then jump one dive and the 7th is a full eCCR dive.


-- 
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

[Jef Driesen]

On 2017-05-11 14:20, Davide DB wrote:

Ok so I made a mistake. I thought 21 was most recent. I even look
carefully at the log trying to see if there was some reference.


You can use dctool to parse those raw dive files:

./dctool -f petrel parse -o dive.X.xml dive.X.bin

And then you can easily check the date/time and other fields.


I'm out at the office now. I will send you everything again later in
the afternoon off list.
The dives you have now are a mess because they are logs of early
training dives changing continuously setpoints (0.7 and 1.3) and going
bailout as exercise.


There is no need to send me the other dives. I already managed to 
extract them from the log file. I just need to know which dives I should 
take look at.



Sorry for wasting your time.


No problem, that's part of the game.

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

[Anton Lundin]

On 11 May, 2017 - Jef Driesen wrote:

> On 2017-05-10 15:43, Anton Lundin wrote:
> >>>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.
> 
> That makes sense!
> 
> >>(*) 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.
> 
> My only concern here is that if the info is useless, like those zero
> millivolt values when external O2 sensor monitoring is disabled, the
> we better don't report them at all. But if that's not the case, then
> it's of course fine to keep reporting them.
> 
> >>>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.
> 
> I replaced your patch with your latest version, and updated the rest
> of the series. Please have a look. If you are okay with the changes,
> I'll merge them to master.

LGTM.

You can add my Reviewed-by: Anton Lundin  tag to the
patches if you like.


I think its a good idea to keep the O2 sensors behind the SENSOR_AVERAGE
ifdef for now, and try to figure out a nice scheme to expose both the
raw sensors and the "voted average" value as different things to the
application.


The two other libdivecomputer backends emitting DC_SAMPLE_PPO2 are
diverite_nitekq_parser and the hw_ostc_parser. The HW values are raw
sensor values, but do you know what the diverite_nitekq_parser value
are?


//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

[Davide DB]

Ok so I made a mistake. I thought 21 was most recent. I even look
carefully at the log trying to see if there was some reference.
I'm out at the office now. I will send you everything again later in
the afternoon off list.
The dives you have now are a mess because they are logs of early
training dives changing continuously setpoints (0.7 and 1.3) and going
bailout as exercise.

Sorry for wasting your time.

On 11 May 2017 at 14:15, Jef Driesen  wrote:
> On 2017-05-10 22:16, Davide DB wrote:
>>
>> I downloaded dives from my SF2 Petrel controller via dctool.
>> I attached some of them here.
>>
>> Dives: 17, 18, 19, 20, 21 are mCCR with a setpoint of 0,7
>> Dive 15 is eCCR with setpoints of 0,7 and 1,3. It was a training dive
>> so you will find OC parts (bailout mode) with ppO2 that goes down to
>> 0,4.
>>
>> I hope it helps
>
>
> Are you sure you didn't mix up the dive numbers? The dctool outputs the
> dives in the order they are download (newest first). Thus dive #0001 is your
> most recent dive, and #0021 your oldest.
>
> The reason why I'm asking is the setpoints in the data don't match your
> description:
>
> Number;Date/time;Setpoints
> 0015;2017-02-19 16:54:53;0.70
> 0017;2017-02-18 15:40:41;0.70
> 0018;2017-02-17 16:40:42;0.70 and 1.30
> 0019;2017-02-17 16:14:18;0.70
> 0020;2017-02-17 15:57:05;0.70
> 0021;2012-01-01 19:59:50;0.70
>
> Jef



-- 
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

[Jef Driesen]

On 2017-05-10 22:16, Davide DB wrote:

I downloaded dives from my SF2 Petrel controller via dctool.
I attached some of them here.

Dives: 17, 18, 19, 20, 21 are mCCR with a setpoint of 0,7
Dive 15 is eCCR with setpoints of 0,7 and 1,3. It was a training dive
so you will find OC parts (bailout mode) with ppO2 that goes down to
0,4.

I hope it helps


Are you sure you didn't mix up the dive numbers? The dctool outputs the 
dives in the order they are download (newest first). Thus dive #0001 is 
your most recent dive, and #0021 your oldest.


The reason why I'm asking is the setpoints in the data don't match your 
description:


Number;Date/time;Setpoints
0015;2017-02-19 16:54:53;0.70
0017;2017-02-18 15:40:41;0.70
0018;2017-02-17 16:40:42;0.70 and 1.30
0019;2017-02-17 16:14:18;0.70
0020;2017-02-17 15:57:05;0.70
0021;2012-01-01 19:59:50;0.70

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

[Jef Driesen]

On 2017-05-10 15:43, Anton Lundin wrote:

>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.


That makes sense!


(*) 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.


My only concern here is that if the info is useless, like those zero 
millivolt values when external O2 sensor monitoring is disabled, the we 
better don't report them at all. But if that's not the case, then it's 
of course fine to keep reporting them.



>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.


I replaced your patch with your latest version, and updated the rest of 
the series. Please have a look. If you are okay with the changes, I'll 
merge them to master.


JefFrom 588e7e7ab459b5df181d7600b891adc7458d9902 Mon Sep 17 00:00:00 2001
From: Dirk Hohndel 
Date: Fri, 6 Feb 2015 09:56:21 -0800
Subject: [PATCH 1/5] 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 d3ca3e87bd92bce7a59818998825652e025e341f Mon Sep 17 00:00:00 2001
From: Anton Lundin 
Date: Wed, 14 Oct 2015 19:49:25 +0200
Subject: [PATCH 2/5] 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 | 24 
 1 file changed, 24 insertions(+)

diff --git a/src/shearwater_predator_parser.c b/src/shearwater_predator_parser.c
index c71c9d7..7c36651 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,18 @@ shearwater_predator_parser_cache (shearwater_predator_parser_t *parser)
 		offset += parser->samplesize;
 	}
 
+	// Cache sensor calibration for later use
+	parser->calibration[0] = array_uint16_be(data + 87);
+	parser->calibration[1] = array_uint16_be(data + 89);
+	parser->calibration[2] = 

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 
<j...@libdivecomputer.org> Date:10/05/2017  21:37  (GMT+09:30) 
To: Anton Lundin <gla...@acc.umu.se> Cc: Subsurface 
<subsurface@subsurface-divelog.org> 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

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 @@ 

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

[Jef Driesen]

On 2017-04-17 22:34, Anton Lundin wrote:

On 17 April, 2017 - Jef Driesen wrote:


On 14-04-17 21:57, Anton Lundin wrote:
>On 13 April, 2017 - Jef Driesen wrote:
>
>>On 2017-04-12 10:47, Anton Lundin wrote:
>>>
>>>The issue with current libdivecomputer DC_SAMPLE_PPO2 is that you cant
>>>distinguish between ha "real" "voted" pO2 and the raw sensor value.
>>>
>>>I would like to see a option to export both, and be able to handle them
>>>differently
>>
>>We could introduce a new structure that carries a sensor index
>>(similar to DC_SAMPLE_PRESSURE):
>>
>>struct ppo2 {
>>unsigned int sensor;
>>double value;
>>};
>>
>>That way we can easily report multiple DC_SAMPLE_PPO2 values, each
>>with a
>>different sensor id. And for the voted/calculated ppO2, we can use
>>some magic value, like:
>>
>>#define DC_SENSOR_NONE 0x
>>
>>(Just like we already have DC_GASMIX_UNKNOWN).
>
>That would be great.
>
>Another thing would be to expose the voting information. Seeing when the
>sensor was voted out and the sensors performance after, is quite
>relevant for trying to diagnose what happened.

Unless I missed something, the voting info isn't stored in the
sample data, only in the dive header. I'm not a CCR diver, but isn't
the voting done for each sample? If that's correct, then the voting
bits in the dive header aren't very useful, right? So I don't think
we can report voting info.

I assume the voting bits in the dive header indicate the sensor has
been voted out one or more times during the dive, but not necessary
for the entire dive?


I guess that the voting is evaluated in each sample, but when a sensor
is voted out, its out for good.


If the voting information won't be exposed via mainline 
libdivecomputer,

its a simple patch to add a DC_FIELD_STRING as a Subsurface patch.


Anyway, I think its really important information that should be 
exposed.


I was referring to the voting per sample. That's info that isn't stored 
anywhere. Thus you can only observe it indirectly. (The ppO2 value from 
a sensor that is voted out will be significant different from the other 
two and the average ppO2 over the three sensors won't match the stored 
average. But the exact voting algorithm is probably not published.)


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

[Jef Driesen]

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.


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

[Jef Driesen]

On 14-04-17 21:57, Anton Lundin wrote:

On 13 April, 2017 - Jef Driesen wrote:


On 2017-04-12 10:47, Anton Lundin wrote:


The issue with current libdivecomputer DC_SAMPLE_PPO2 is that you cant
distinguish between ha "real" "voted" pO2 and the raw sensor value.

I would like to see a option to export both, and be able to handle them
differently


We could introduce a new structure that carries a sensor index
(similar to DC_SAMPLE_PRESSURE):

struct ppo2 {
unsigned int sensor;
double value;
};

That way we can easily report multiple DC_SAMPLE_PPO2 values, each
with a
different sensor id. And for the voted/calculated ppO2, we can use
some magic value, like:

#define DC_SENSOR_NONE 0x

(Just like we already have DC_GASMIX_UNKNOWN).


That would be great.

Another thing would be to expose the voting information. Seeing when the
sensor was voted out and the sensors performance after, is quite
relevant for trying to diagnose what happened.


Unless I missed something, the voting info isn't stored in the sample data, only 
in the dive header. I'm not a CCR diver, but isn't the voting done for each 
sample? If that's correct, then the voting bits in the dive header aren't very 
useful, right? So I don't think we can report voting info.


I assume the voting bits in the dive header indicate the sensor has been voted 
out one or more times during the dive, but not necessary for the entire dive?


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

[Anton Lundin]

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?

> And is correct for all Predators?

How did it line up on the petrels?


//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 13 April, 2017 - Jef Driesen wrote:

> On 2017-04-12 10:47, Anton Lundin wrote:
> >
> >The issue with current libdivecomputer DC_SAMPLE_PPO2 is that you cant
> >distinguish between ha "real" "voted" pO2 and the raw sensor value.
> >
> >I would like to see a option to export both, and be able to handle them
> >differently
> 
> We could introduce a new structure that carries a sensor index
> (similar to DC_SAMPLE_PRESSURE):
> 
> struct ppo2 {
> unsigned int sensor;
> double value;
> };
> 
> That way we can easily report multiple DC_SAMPLE_PPO2 values, each
> with a
> different sensor id. And for the voted/calculated ppO2, we can use
> some magic value, like:
> 
> #define DC_SENSOR_NONE 0x
> 
> (Just like we already have DC_GASMIX_UNKNOWN).

That would be great.

Another thing would be to expose the voting information. Seeing when the
sensor was voted out and the sensors performance after, is quite
relevant for trying to diagnose what happened.


//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-13 17:04, Jef Driesen wrote:

I don't entirely agree with that. If you check the available memory
dumps, 5 of them contain CCR dives. I analyzed all of them, and this
is what I found:

 * petrel.marklee.bin

The three mV values in the samples are always zero. But since all
three O2 sensors have their calibrated bit in the header disabled, no
ppO2 samples are reported. So that looks good.

Sensor 0: 0 0 2100 -1
Sensor 1: 0 0 2100 -1
Sensor 2: 0 0 2100 -1

(These numbers are respectively the voted bit, the calibrated bit, the
calibration value and the ADC offset.)

 * petrel.larrybainbridge.bin

The three mV values in the samples are always zero. But the O2 sensors
are calibrated, and thus we report ppO2 samples with all zeros. That's
not good. This might indicate that we need to take into account the
voted bit too, because that is disabled for all dives:

Sensor 0: 0 1 2045 44
Sensor 1: 0 1 2025 -9
Sensor 2: 0 1 2045 51

petrel.rainer.bin

Here we have non-zero mV values in the samples. The O2 sensors are
calibrated. In most samples, manually averaging the resulting ppO2
gives results that are very close to the average ppO2 value reported
by the device. In roughly 90% of the samples where the result is
different, the difference in average ppO2 is only 0.01. That might be
some rounding error. In only a few percent of the cases there is a
significant difference, and that are probably cases where a value is
voted out. So everything looks reasonable here.

Sensor 0: X 1  0   (with  ranging from 1671 to 2112)
Sensor 1: X 1  39  (with  ranging from 1810 to 2326)
Sensor 2: 1 1  2   (with  ranging from 1621 to 2108)

Note that sometimes sensor 0 or 1 have the voted bit disabled in the
header! So if we would take that bit into account (see above), then I
think we're disabling a sensor when it shouldn't. So I'm not really
sure what to do with the voted bit.

 * predator.janschubert.bin

All sensors are calibrated and voted in:

Sensor 0: 1 1  -16   (with  ranging from 859 to 895)
Sensor 1: 1 1  -24   (with  ranging from 812 to 843)
Sensor 2: 1 1  -11   (with  ranging from 827 to 856)

Note that compared to the petrel data, the calibration values are now
in an entirely different range. So the resulting ppO2 are way off.
That's what you tried to address in the second revision of you patch
with this code:

if (calibration < 1000)
calibration += 1024;

With this patch, the results look good again. When comparing the
calculated with the stored average ppO2, the largest difference is
only 0.021.

 * predator.marklee.bin

All sensors are calibrated and voted in:

Sensor 0: 1 1  -41   (with  ranging from  885 to 1069)
Sensor 1: 1 1  -39   (with  ranging from  989 to 1016)
Sensor 2: 1 1  -5(with  ranging from 1179 to 1376)

Very similar, except that some calibration values are above and other
below 1000. And that breaks the above patch. If we always add the
value 1024 (or just 1000) unconditionally, things are getting better.
I guess that's an indication that this is something specific for the
predator, but not the petrel. But it's not perfect yet. The difference
in average ppO2 is now between 0.043 and 0.212. This is much larger as
before, and if you look at the values, it's not caused by an outlier
that is getting voted out.

A random example:

Sensor 0: 0.639 = 33 mV * (885 + 1024) / 10.0
Sensor 1: 0.583 = 29 mV * (989 + 1024) / 10.0
Sensor 2: 0.572 = 26 mv * (1179 + 1024) / 10.0

But the average ppO2 reported by the device is 0.65. That's more than
our highest value, so it can't be due to sensor voting. Maybe the
calibration is done different for the predator?


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.


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? And 
is correct for all Predators?


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

[Jef Driesen]

On 2017-04-12 10:47, Anton Lundin wrote:

On 12 April, 2017 - Davide DB wrote:

On 11 April 2017 at 23:44, Jef Driesen  
wrote:


> I'll need to look again at the old discussion, but if I remember
> correctly, your patch produced bogus results for some of the data I tested
> against. And that's why I wanted to double check with Shearwater. But so
> far I wasn't able to get any info from Shearwater. So yes, let's have
> another look


Directly after that revision of the patch, I sent you another which
always handled the calibration values the same, no matter what they
were, which produced sane values even in that case.

I didn't have that test data you referenced when developing the code,
but after seeing that data, it clear that its the right thing to do.


I don't entirely agree with that. If you check the available memory 
dumps, 5 of them contain CCR dives. I analyzed all of them, and this is 
what I found:


 * petrel.marklee.bin

The three mV values in the samples are always zero. But since all three 
O2 sensors have their calibrated bit in the header disabled, no ppO2 
samples are reported. So that looks good.


Sensor 0: 0 0 2100 -1
Sensor 1: 0 0 2100 -1
Sensor 2: 0 0 2100 -1

(These numbers are respectively the voted bit, the calibrated bit, the 
calibration value and the ADC offset.)


 * petrel.larrybainbridge.bin

The three mV values in the samples are always zero. But the O2 sensors 
are calibrated, and thus we report ppO2 samples with all zeros. That's 
not good. This might indicate that we need to take into account the 
voted bit too, because that is disabled for all dives:


Sensor 0: 0 1 2045 44
Sensor 1: 0 1 2025 -9
Sensor 2: 0 1 2045 51

petrel.rainer.bin

Here we have non-zero mV values in the samples. The O2 sensors are 
calibrated. In most samples, manually averaging the resulting ppO2 gives 
results that are very close to the average ppO2 value reported by the 
device. In roughly 90% of the samples where the result is different, the 
difference in average ppO2 is only 0.01. That might be some rounding 
error. In only a few percent of the cases there is a significant 
difference, and that are probably cases where a value is voted out. So 
everything looks reasonable here.


Sensor 0: X 1  0   (with  ranging from 1671 to 2112)
Sensor 1: X 1  39  (with  ranging from 1810 to 2326)
Sensor 2: 1 1  2   (with  ranging from 1621 to 2108)

Note that sometimes sensor 0 or 1 have the voted bit disabled in the 
header! So if we would take that bit into account (see above), then I 
think we're disabling a sensor when it shouldn't. So I'm not really sure 
what to do with the voted bit.


 * predator.janschubert.bin

All sensors are calibrated and voted in:

Sensor 0: 1 1  -16   (with  ranging from 859 to 895)
Sensor 1: 1 1  -24   (with  ranging from 812 to 843)
Sensor 2: 1 1  -11   (with  ranging from 827 to 856)

Note that compared to the petrel data, the calibration values are now in 
an entirely different range. So the resulting ppO2 are way off. That's 
what you tried to address in the second revision of you patch with this 
code:


if (calibration < 1000)
calibration += 1024;

With this patch, the results look good again. When comparing the 
calculated with the stored average ppO2, the largest difference is only 
0.021.


 * predator.marklee.bin

All sensors are calibrated and voted in:

Sensor 0: 1 1  -41   (with  ranging from  885 to 1069)
Sensor 1: 1 1  -39   (with  ranging from  989 to 1016)
Sensor 2: 1 1  -5(with  ranging from 1179 to 1376)

Very similar, except that some calibration values are above and other 
below 1000. And that breaks the above patch. If we always add the value 
1024 (or just 1000) unconditionally, things are getting better. I guess 
that's an indication that this is something specific for the predator, 
but not the petrel. But it's not perfect yet. The difference in average 
ppO2 is now between 0.043 and 0.212. This is much larger as before, and 
if you look at the values, it's not caused by an outlier that is getting 
voted out.


A random example:

Sensor 0: 0.639 = 33 mV * (885 + 1024) / 10.0
Sensor 1: 0.583 = 29 mV * (989 + 1024) / 10.0
Sensor 2: 0.572 = 26 mv * (1179 + 1024) / 10.0

But the average ppO2 reported by the device is 0.65. That's more than 
our highest value, so it can't be due to sensor voting. Maybe the 
calibration is done different for the predator?


Maybe I'm really messing up things but reading Dirk email regarding 
his
contact at Shearwater "Perdix / Perdix AI info from Shearwater" it 
seems

that Perdix and Petrel devices don't carry O2 info via their protocol:




They carry only a global pO2 (I guess it's the result PO2 from so 
called
voting logic hence used in all further calculation) and mV values for 
each

sensor. BTW individual mV 02 sensor graph was added in version 2.3.5:

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

[Jef Driesen]

For the Shearwater Petrel CCR divers reading this: Can you supply us
with some more data to test against? The Petrel protocol doesn't
support memory dumps, so you'll need to dump the individual dives. You
can do that with libdivecomputer' dctool:

http://www.libdivecomputer.org/builds/stable/linux/dctool

Execute with these options:

./dctool -v -l petrel.log -f petrel download -o dive.%n.bin -f raw 
/dev/rfcommX


Send back the petrel.log and all the dive.*.bin files.


I will do this and send it over the weekend.
How much data/dives do you want/need?


More is always better :-)

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

[Anton Lundin]

On 12 April, 2017 - Davide DB wrote:

> On 11 April 2017 at 23:44, Jef Driesen  wrote:
> 
> >
> > I'll need to look again at the old discussion, but if I remember
> > correctly, your patch produced bogus results for some of the data I tested
> > against. And that's why I wanted to double check with Shearwater. But so
> > far I wasn't able to get any info from Shearwater. So yes, let's have
> > another look

Directly after that revision of the patch, I sent you another which
always handled the calibration values the same, no matter what they
were, which produced sane values even in that case.

I didn't have that test data you referenced when developing the code,
but after seeing that data, it clear that its the right thing to do.

> Maybe I'm really messing up things but reading Dirk email regarding his
> contact at Shearwater "Perdix / Perdix AI info from Shearwater" it seems
> that Perdix and Petrel devices don't carry O2 info via their protocol:



> They carry only a global pO2 (I guess it's the result PO2 from so called
> voting logic hence used in all further calculation) and mV values for each
> sensor. BTW individual mV 02 sensor graph was added in version 2.3.5:
> https://www.shearwater.com/release-notes-firmware/shearwater-desktop-2-3-5-released/
> 
> Hence would be impossible to display single individual pO2.

No, its not impossible. The calibration values are in the Dive header,
and with those, the mV values can be converted into pO2 values.


The issue with current libdivecomputer DC_SAMPLE_PPO2 is that you cant
distinguish between ha "real" "voted" pO2 and the raw sensor value.

I would like to see a option to export both, and be able to handle them
differently


> > For the Shearwater Petrel CCR divers reading this: Can you supply us with
> > some more data to test against? The Petrel protocol doesn't support memory
> > dumps, so you'll need to dump the individual dives. You can do that with
> > libdivecomputer' dctool:
> >
> > http://www.libdivecomputer.org/builds/stable/linux/dctool
> >
> > Execute with these options:
> >
> > ./dctool -v -l petrel.log -f petrel download -o dive.%n.bin -f raw
> > /dev/rfcommX
> >
> > Send back the petrel.log and all the dive.*.bin files.
>
> Is there something equivalent for a Windows CCR user? :-)
> 

http://www.libdivecomputer.org/builds/stable/windows/dctool.exe

replace /dev/rfcommX with COMX


//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

[Davide DB]

On 11 April 2017 at 23:44, Jef Driesen  wrote:

>
> I'll need to look again at the old discussion, but if I remember
> correctly, your patch produced bogus results for some of the data I tested
> against. And that's why I wanted to double check with Shearwater. But so
> far I wasn't able to get any info from Shearwater. So yes, let's have
> another look
>

Maybe I'm really messing up things but reading Dirk email regarding his
contact at Shearwater "Perdix / Perdix AI info from Shearwater" it seems
that Perdix and Petrel devices don't carry O2 info via their protocol:


*Contents*
Block Offset

LOG_RECORD_TYPE_DIVE_SAMPLE (0x01)
0-1
Depth, in current units
2-3
Next Stop Depth, in current units
4-5
Time-To-Surface (TTS), minutes
6
Average PPO2 in ata (x100, e.g.  123=1.23)
7
Current gas percent O2
8
Current gas percent He
9
Next stop time, minutes (If Next Stop Depth is Zero, then this is the NDL
time in minutes. Note that NDL was offset 10 in the old Predator log
versions).
10
Battery voltage Note: Legacy use only. More precise value available at
offset  16
11
Misc. Statuses:
Bit 0: 1=gas switch needed, 0=not needed
Bit 1: 1=external PPO2, 0=internal PPO2
Bit 2: 1=high setpoint, 0=low setpoint
Bit 3: 1=SC mode, 0=CC mode
Bit 4: 0 = Closed Circuit, 1= Open Circuit
12
O2 Sensor 1 millivolts (only valid when external PPO2 monitoring enabled)
13
Water temperature (Celsius when metric, Fahrenheit when imperial)
14
O2 Sensor 2 millivolts (only valid when external PPO2 monitoring enabled)
15
O2 Sensor 3 millivolts(only valid when external PPO2 monitoring enabled)
16-17
Battery voltage * 100
18
Current ppo2 set point (only valid for CC mode)
19 - 20
For Log Version 7 and greater (below this field is unused):
Wireless AI sensor 1 (T2), most 4 bits are battery level . 0= battery
normal, 1= critical low, 2 = warning low
Rest 12 bits are sensor1 pressure/2 in psi

· 0x: not paired / no communication for 90 seconds

· 0xFFFE: no communication for 30 seconds


21
For Log Version 7 and greater (below this field is unused):
Gas time remain minutes of Wireless AI

· 0xFF not paired,

· 0xFE no communication,

· 0xFD not available in current mode,

· 0xFC not available because of DECO,

· 0xFB Tank size or max pressure haven’t been set up,

· 0-0xFA valid range

22
CNS percentage
23
Decompression Ceiling Depth (current units)
24
Gf99 (current Buhlmann percent Gradient)
25-26
@+5 (in minutes)
27 - 28
For Log Version 7 and greater (below this field is unused):
Wireless AI sensor 0 (T1), most 4 bits are battery level . 0= battery
normal, 1= critical low, 2 = warning low
Rest 12 bits are sensor0 pressure/2 in psi

· 0x: not paired / no communication for 90 seconds

· 0xFFFE: no communication for 30 seconds

29-30
For Log Version 7 and greater (below this field is unused):
Surface Air Consumption (SAC) in PSI/min.
Value is x100. E.g. 3245 = 32.45 PSI/min
31
Reserved for future use



They carry only a global pO2 (I guess it's the result PO2 from so called
voting logic hence used in all further calculation) and mV values for each
sensor. BTW individual mV 02 sensor graph was added in version 2.3.5:
https://www.shearwater.com/release-notes-firmware/shearwater-desktop-2-3-5-released/

Hence would be impossible to display single individual pO2.



> For the Shearwater Petrel CCR divers reading this: Can you supply us with
> some more data to test against? The Petrel protocol doesn't support memory
> dumps, so you'll need to dump the individual dives. You can do that with
> libdivecomputer' dctool:
>
> http://www.libdivecomputer.org/builds/stable/linux/dctool
>
> Execute with these options:
>
> ./dctool -v -l petrel.log -f petrel download -o dive.%n.bin -f raw
> /dev/rfcommX
>
> Send back the petrel.log and all the dive.*.bin files.
>
> Jef
>

Is there something equivalent for a Windows CCR user? :-)

Bye


PS
Dirk, I tried to link your email form the mailing list archives but I get
this error:

Error
*subsurface roster authentication failed.*

-- 
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]

On 2017-04-09 14:00, Anton Lundin wrote:
> On 09 April, 2017 - Joakim Bygdell wrote:
>> Jef, how is on the backed side, how many sensors does libdivecomputer 
>> supports for the Petrel series?
> 
> I sort if figured out now to extract po2 valeues for all sensors from 
> Shearwater comptuers, but due to it being reverse-engineered code Jef 
> wanted to ask some contacts at Shearwater about it, and as far as I 
> know, we haven't yet had any answer from Shearwater.
> 
> 
> Attached is this 1.5 years old patch, which I think its time to apply.

I'll need to look again at the old discussion, but if I remember correctly, 
your patch produced bogus results for some of the data I tested against. And 
that's why I wanted to double check with Shearwater. 
But so far I wasn't able to get any info from Shearwater. So yes, let's have 
another look.


For the Shearwater Petrel CCR divers reading this: Can you supply us with some 
more data to test against? The Petrel protocol doesn't support memory dumps, so 
you'll need to dump the individual dives. You can do that with libdivecomputer' 
dctool:

http://www.libdivecomputer.org/builds/stable/linux/dctool

Execute with these options:

./dctool -v -l petrel.log -f petrel download -o dive.%n.bin -f raw /dev/rfcommX

Send back the petrel.log and all the dive.*.bin files.

Jef




I will do this and send it over the weekend.
How much data/dives do you want/need?

Steve

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

___
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-09 14:00, Anton Lundin wrote:

On 09 April, 2017 - Joakim Bygdell wrote:

Jef, how is on the backed side, how many sensors does libdivecomputer
supports for the Petrel series?


I sort if figured out now to extract po2 valeues for all sensors from
Shearwater comptuers, but due to it being reverse-engineered code Jef
wanted to ask some contacts at Shearwater about it, and as far as I
know, we haven't yet had any answer from Shearwater.


Attached is this 1.5 years old patch, which I think its time to apply.


I'll need to look again at the old discussion, but if I remember 
correctly, your patch produced bogus results for some of the data I 
tested against. And that's why I wanted to double check with Shearwater. 
But so far I wasn't able to get any info from Shearwater. So yes, let's 
have another look.



For the Shearwater Petrel CCR divers reading this: Can you supply us 
with some more data to test against? The Petrel protocol doesn't support 
memory dumps, so you'll need to dump the individual dives. You can do 
that with libdivecomputer' dctool:


http://www.libdivecomputer.org/builds/stable/linux/dctool

Execute with these options:

./dctool -v -l petrel.log -f petrel download -o dive.%n.bin -f raw 
/dev/rfcommX


Send back the petrel.log and all the dive.*.bin files.

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

[Anton Lundin]

On 09 April, 2017 - Joakim Bygdell wrote:

>  9 April 2017 at 11:39, Joakim Bygdell  wrote:
> 
> >  9 April 2017 at 11:30, Davide DB  wrote:
> >
> >> On 9 April 2017 at 11:22, Joakim Bygdell  wrote:
> >> >  9 April 2017 at 11:01, Davide DB  wrote:
> >> >>
> >> >> I update my settings and nothing happens.
> >> >> I have a Petrel 2 connected to a SF2 CCR with three sensors. I get
> >> >> only one green line.
> >> >
> >> >
> >> > I have data from both a Predator and a Petrel, in both cases only the
> >> > consensus pO2 are reported
> >> > together with the setpoint data.
> >> >
> >>
> >> Hi Joakim and Steve,
> >>
> >> Thanks for the feedback.did you try with Shearwater desktop?
> >>
> >
> > Not my DC so can't test.
> > But according to the guy who owns the Predator it only shows one cell with
> > Shearwaters software.
> >
> 
> At least the Petrel2 should report 3 sensors.
> 
> Jef, how is on the backed side, how many sensors does libdivecomputer
> supports for the Petrel series?

I sort if figured out now to extract po2 valeues for all sensors from
Shearwater comptuers, but due to it being reverse-engineered code Jef
wanted to ask some contacts at Shearwater about it, and as far as I
know, we haven't yet had any answer from Shearwater.


Attached is this 1.5 years old patch, which I think its time to apply.


//Anton


-- 
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

[Davide DB]

Hi Willem,

Actually I downoaded the Sweetwater directly via BT with subsurface. I did
not install Shearwater we at all.
Data format conversion should be libdivecom related or subsurface.
___
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

[Willem Ferguson]

Currently Subsurface only explicitly accommodates the Poseidon MKVI and 
the APD Inspiration family of rebreathers, having two/three oxygen 
sensors by default. The reason is simply: these are the equipment mostly 
used by local divers here. Since rebreathers often download only one 
dive at a time (one dive = one complete dive log file), a normal dive 
list-oriented download is not relevant. There is not the equivalent of a 
libdivecomputer for these CCR uploads and we import the MKVI and APD 
dives through the text file import mechanism. Currently, several third 
party manufacturers use Shearwater equipment as the controllers for CCR 
equipment (e.g. Hollis Prism). The addition of Shearwater-generated CCR 
imports will be the next quantum step for making Subsurface accessible 
to CCR divers. There are some problems with respect to the import of CCR 
dives:


1) Since there is not the equivalent of a libdivecomputer, we are 
dependent on doing the inital download from CCR to text file using 
proprietary software that comes with the equipment (mostly Win-only). 
Extremely inconvenient. Then import from text to Subsurface.


2) I do not know how many Subsurface users actually log CCR dives. I 
know of four users in our country. Clearly a pretty small user base. 
There has been no correspondence from CCR divers on the mail list, so we 
do not know in which ways to improve the existing code.


There is a possibility that the extension to Shearwater may be very 
simple, depending on whether Jeff includes sensor data in 
libdivecomputer, otherwise it may be a bit more complex.


Kind regards,
willem





___
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]

 9 April 2017 at 11:39, Joakim Bygdell  wrote:

>  9 April 2017 at 11:30, Davide DB  wrote:
>
>> On 9 April 2017 at 11:22, Joakim Bygdell  wrote:
>> >  9 April 2017 at 11:01, Davide DB  wrote:
>> >>
>> >> I update my settings and nothing happens.
>> >> I have a Petrel 2 connected to a SF2 CCR with three sensors. I get
>> >> only one green line.
>> >
>> >
>> > I have data from both a Predator and a Petrel, in both cases only the
>> > consensus pO2 are reported
>> > together with the setpoint data.
>> >
>>
>> Hi Joakim and Steve,
>>
>> Thanks for the feedback.did you try with Shearwater desktop?
>>
>
> Not my DC so can't test.
> But according to the guy who owns the Predator it only shows one cell with
> Shearwaters software.
>

At least the Petrel2 should report 3 sensors.

Jef, how is on the backed side, how many sensors does libdivecomputer
supports for the Petrel series?

-- 
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 9 April 2017 at 11:22, Joakim Bygdell  wrote:
>  9 April 2017 at 11:01, Davide DB  wrote:
>>
>> >
>> > Il 08 apr 2017 13:10, "Joakim Bygdell"  ha scritto:
>> >>
>> >>
>> >> Under Preferences -> Graph
>> >> You have "Show individual O2 sensors when viewing pO2"
>> >>
>> >> Once you toggle the "show pO2" button on in the profile it should show
>> >> data from all sensors.
>> >> Assuming of course that your divecomputer and the libdc backend
>> >> supports
>> >> multiple sensors.
>> >>
>>
>> I update my settings and nothing happens.
>> I have a Petrel 2 connected to a SF2 CCR with three sensors. I get
>> only one green line.
>
>
> I have data from both a Predator and a Petrel, in both cases only the
> consensus pO2 are reported
> together with the setpoint data.
>

Hi Joakim and Steve,

Thanks for the feedback.did you try with Shearwater desktop?

PS

I just got a new toy :

https://goo.gl/photos/Tcf1xn4ETSeoKViz8


-- 
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]

>
> Il 08 apr 2017 13:10, "Joakim Bygdell"  ha scritto:
>>
>>
>> Under Preferences -> Graph
>> You have "Show individual O2 sensors when viewing pO2"
>>
>> Once you toggle the "show pO2" button on in the profile it should 
>> show data from all sensors.
>> Assuming of course that your divecomputer and the libdc backend 
>> supports multiple sensors.
>>

>I update my settings and nothing happens.
>I have a Petrel 2 connected to a SF2 CCR with three sensors. I get only one 
>green line.

>Is there someone else downloading from a Petrel 2 on Windows?



Yes I have a Petrel 2 EXT connected to my CCR and only see Sensor 1 information 
downloaded and saved to the .xml file.
It would be useful to get all 3 o2 sensors information.


>PS
>I should try with Shearwater desktop but I would not like to install a new 
>crap on my machine.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
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]

>
> Il 08 apr 2017 13:10, "Joakim Bygdell"  ha scritto:
>>
>>
>> Under Preferences -> Graph
>> You have "Show individual O2 sensors when viewing pO2"
>>
>> Once you toggle the "show pO2" button on in the profile it should show
>> data from all sensors.
>> Assuming of course that your divecomputer and the libdc backend supports
>> multiple sensors.
>>

I update my settings and nothing happens.
I have a Petrel 2 connected to a SF2 CCR with three sensors. I get
only one green line.

Is there someone else downloading from a Petrel 2 on Windows?

PS
I should try with Shearwater desktop but I would not like to install a
new crap on my machine.
___
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]

Ouch!

Thanks a lot

Il 08 apr 2017 13:10, "Joakim Bygdell"  ha scritto:

> On 8 April 2017 at 12:35, Davide DB  wrote:
>
>> On 12 January 2015 at 09:41, Willem Ferguson
>>  wrote:
>>
>> Sorry guys, really a bad day :) So I bring bag to life this old hot topic.
>>
>> As far I see there's no way to see individual 02 sensor value plots or
>> am I missing some setting?
>>
>
> Under Preferences -> Graph
> You have "Show individual O2 sensors when viewing pO2"
>
> Once you toggle the "show pO2" button on in the profile it should show
> data from all sensors.
> Assuming of course that your divecomputer and the libdc backend supports
> multiple sensors.
>
>
>>
>> I understand different views on this but would it possible having a
>> YAB (Yet Another Button) to toggle single/multiple visualization?
>> There are rebs with up to five O2 sensors. I understand the resulting
>> graph could be a mess but if I have a problem I would like to be able
>> to see what's happened on Subsurface not another sw.
>>
>> Bye
>>
>> --
>> Davide
>> https://vimeo.com/bocio/videos
>> ___
>> 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

[Joakim Bygdell]

On 8 April 2017 at 12:35, Davide DB  wrote:

> On 12 January 2015 at 09:41, Willem Ferguson
>  wrote:
>
> Sorry guys, really a bad day :) So I bring bag to life this old hot topic.
>
> As far I see there's no way to see individual 02 sensor value plots or
> am I missing some setting?
>

Under Preferences -> Graph
You have "Show individual O2 sensors when viewing pO2"

Once you toggle the "show pO2" button on in the profile it should show data
from all sensors.
Assuming of course that your divecomputer and the libdc backend supports
multiple sensors.


>
> I understand different views on this but would it possible having a
> YAB (Yet Another Button) to toggle single/multiple visualization?
> There are rebs with up to five O2 sensors. I understand the resulting
> graph could be a mess but if I have a problem I would like to be able
> to see what's happened on Subsurface not another sw.
>
> Bye
>
> --
> Davide
> https://vimeo.com/bocio/videos
> ___
> 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

[Davide DB]

On 12 January 2015 at 09:41, Willem Ferguson
 wrote:
>
> On 10/01/2015 13:00, Anton Lundin wrote:
>>
>>
>> I've never suggested to remove all the code and start over. I'm
>> suggesting better goals to strive towards.
>>
>> We have discussed o2 sensor plotting on this mailinglist for 2-3 years,
>> and everytime before we have come to the conclusion that plotting
>> individual sensors is just noice. Yes, its what everybody else does but
>> everybody else are still butt ugly and stupid =)
>>
>>
>> Yes, if this is your puppy and your holy grail build it so then, but
>> make sain defaults like not plotting all the sensors individually, but
>> rather have the default as plotting the consensus/avenge/computed/whatnot
>> value and if the user like to, can turn on plotting the individual
>> values.
>>
>>
>> I hack on the parts of Subsurface which i think are fun. With this
>> attitude CCR-parts are not fun.
>>
>>
>> //Anton
>>
>>
> Anton,
>
> I am strongly under the impression of how difficult good communication is 
> when it occurs only via email. You do not see the other person to evaluate 
> facial expressions or body language. So, somehow, one has to interact and 
> still understand the real concerns of the other party. At least once a week I 
> am seriously misunderstood by others with whom I correspond because I assume 
> the other party has the same basic perspective as myself, which is not 
> necessarily true. Frequently also, I misunderstand mail from others because I 
> do not understand their broader perspective. This correspondence is no 
> exception. So I  totally misunderstood you and for that I apologise. At no 
> point did I willfully misinterpret you. Part of that comes from a 
> misinterpretation of what you meant by using the word 'tool'. May we start on 
> a fresh basis and address the real issues about CCR dive logs?
>
> There are some factors that come into play: what the average CCR diver would 
> expect, as opposed to what more enlightened divers would think makes sense.
>
> Would you be prepared at all to please start again and explain in greater 
> detail exactly what you have in mind and let us discuss that. ok?
>
> I would, however, request that we use the existing patch for visualising o2 
> sensor values as a starting point simply because I am under pressure from 
> local CCR divers to provide basic visualisation of po2 values and to make the 
> software available to them. But, I am prepared to change the present code to 
> do anythingt that contributes to the ease of use and interpretation of the 
> information. For that reason your point of view is highly pertinent. Please 
> explain in a bit more detail, will you?
> Kind regards,
> willem
>
>

Sorry guys, really a bad day :) So I bring bag to life this old hot topic.

As far I see there's no way to see individual 02 sensor value plots or
am I missing some setting?

I understand different views on this but would it possible having a
YAB (Yet Another Button) to toggle single/multiple visualization?
There are rebs with up to five O2 sensors. I understand the resulting
graph could be a mess but if I have a problem I would like to be able
to see what's happened on Subsurface not another sw.

Bye

-- 
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

[Willem Ferguson]

On 10/01/2015 13:00, Anton Lundin wrote:


I've never suggested to remove all the code and start over. I'm
suggesting better goals to strive towards.

We have discussed o2 sensor plotting on this mailinglist for 2-3 years,
and everytime before we have come to the conclusion that plotting
individual sensors is just noice. Yes, its what everybody else does but
everybody else are still butt ugly and stupid =)


Yes, if this is your puppy and your holy grail build it so then, but
make sain defaults like not plotting all the sensors individually, but
rather have the default as plotting the consensus/avenge/computed/whatnot
value and if the user like to, can turn on plotting the individual
values.


I hack on the parts of Subsurface which i think are fun. With this
attitude CCR-parts are not fun.


//Anton



Anton,

I am strongly under the impression of how difficult good communication 
is when it occurs only via email. You do not see the other person to 
evaluate facial expressions or body language. So, somehow, one has to 
interact and still understand the real concerns of the other party. At 
least once a week I am seriously misunderstood by others with whom I 
correspond because I assume the other party has the same basic 
perspective as myself, which is not necessarily true. Frequently also, I 
misunderstand mail from others because I do not understand their broader 
perspective. This correspondence is no exception. So I  totally 
misunderstood you and for that I apologise. At no point did I willfully 
misinterpret you. Part of that comes from a misinterpretation of what 
you meant by using the word 'tool'. May we start on a fresh basis and 
address the real issues about CCR dive logs?


There are some factors that come into play: what the average CCR diver 
would expect, as opposed to what more enlightened divers would think 
makes sense.


Would you be prepared at all to please start again and explain in 
greater detail exactly what you have in mind and let us discuss that. ok?


I would, however, request that we use the existing patch for visualising 
o2 sensor values as a starting point simply because I am under pressure 
from local CCR divers to provide basic visualisation of po2 values and 
to make the software available to them. But, I am prepared to change the 
present code to do anythingt that contributes to the ease of use and 
interpretation of the information. For that reason your point of view is 
highly pertinent. Please explain in a bit more detail, will you?

Kind regards,
willem

___
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 09 January, 2015 - Willem Ferguson wrote:

 On 09/01/2015 16:32, Anton Lundin wrote:
 
 I've bin thinking if this is a good idea to plot in our already massive
 plot.
 
 I'm more leaning towards just plotting a computed po2 value here, and
 the setpoint of course, and then rather add a some sort of separate tool
 to analyze the o2 cells, and how they correlate to each other, outside
 the general dive plot.
 
 I think thats going to be a way more useful tool.
 
 
 //Anton
 
 
 Anton,
 
 I hope I can offer a systematic argument here. So, for this reason, I have
 numbered the points below.
 
 1. In order to perform evaluation of oxygen sensors it is, as a start,
 necessary to visualise the individual sensor readings. Other CCR software
 also do this. Attached, as Image 1, is a screen dump from the APD software.
 This is part of the main graphical display of that software. It shows the
 measurements for each of the three sensors, the setpoint and the depth
 profile. Even though their graphical environment is somewhat rudimentary (at
 least compared to Subsurface) this is the sort of information that APD
 divers in this part of the world look at as an aid to evaluate the condition
 of their equipment's oxygen management system and also the diver's
 interaction with that system. Unfortunately my Poseidon software is not
 running at the moment (license issues), so I use APD software as an example.
 This type of visualisation is not exceptional. It is close to the norm.
 

Yea, its what everybody else is doing, but what does those values
actually tell you? Can you see with which margin the red sensor is
undershooting and with which margin the orange sensor is overshooting?
I'd say no.

I'd say its way better to plot the sensor lines only if they differ more
than X %/ppo2/mV from the expected readout. That will provide only the
relevant information and not the noise from just normal values visually
clogging the plot.

 4. I can sympathise with with your point of view of creating a separate
 tool. Now I wish to ask a question. Would you be prepared to generate the
 separate tool that you intend? Until now, I have been working mostly on my
 own, but with significant help from Miika and Robert. Do we need to wait
 until someone, some time in the future, will be prepared to push the
 Subsurface CCR initiative further? Or are you prepared to commit to a plan
 of action to create a new Subsurface tool?
 

Did i step on any virtual toes that i didn't notice?

 5. Would you like this to be an independent non-Subsurface tool? Would
 someone need to separately rewrite the whole infrastructure for and
 visualisation of dive logs that Sursurface already has?
 

Now you're just misinterpreting things for the sake of finding things to
argue about. Of course not, it will not be a standalone tool outside
Subsurface, it would be a tool inside Subsurface.

 5. My suggestion is this: Please, let's for the meantime work with the
 present code which is not perfect. There are one or two rough edges that
 need to be smoothed over. But let us use it until someone comes with a
 better idea of how to deal with CCR dive logging and interpretation in the
 open source domain. I perceive this to be an opportunity for Subsurface, not
 a threat.
 

I've never suggested to remove all the code and start over. I'm
suggesting better goals to strive towards.

We have discussed o2 sensor plotting on this mailinglist for 2-3 years,
and everytime before we have come to the conclusion that plotting
individual sensors is just noice. Yes, its what everybody else does but
everybody else are still butt ugly and stupid =)


Yes, if this is your puppy and your holy grail build it so then, but
make sain defaults like not plotting all the sensors individually, but
rather have the default as plotting the consensus/avenge/computed/whatnot
value and if the user like to, can turn on plotting the individual
values.


I hack on the parts of Subsurface which i think are fun. With this
attitude CCR-parts are not fun.


//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 09 January, 2015 - Willem Ferguson wrote:

 This patch implements the visualisation of the oxygen sensor data for CCR
 dives. The partial pressure measurements of each of the sensors are graphed
 using the existing partial pressure axis in the dive profile widget. There
 are now four separate sets of data that can be plotted using the partial
 pressure axis system: po2, pn2, phe, and this additional one: sensor data.
 The sensor data can be visualised individually or in combination with
 any of the other three partial pressure graphs, mentioned above. The display
 of the sensor data is activated by the button at the bottom of the toolbar,
 allowing the evaluation of data from individual oxygen sensors with respect
 to drift or fluctuation and with respect to the setpoint setting, these
 being important criteria for evaluating the reliability of these sensors
 for a particular set of CCR equipment. It is a feature that many
 implementations of proprietary CCR dive logs have.
 

I've bin thinking if this is a good idea to plot in our already massive
plot.

I'm more leaning towards just plotting a computed po2 value here, and
the setpoint of course, and then rather add a some sort of separate tool
to analyze the o2 cells, and how they correlate to each other, outside
the general dive plot.

I think thats going to be a way more useful tool.


//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

[Willem Ferguson]

On 09/01/2015 11:20, Davide DB wrote:

Any way to display  OX sensor values (if available) in a PSCR dive?



 I have no experience whatsoever with PSCR. Can these data be logged into
the existing fields of the structures of sample as defined in dive.h?

I suspect that the most important impediment is the way of logging po2
and uploading PSCR dive logs. From the little bit I know of these
systems it appears they do not have a large amount of electronics that
would allow dive logging (e.g. Halcyon RB80).

Is my perception correct at all? I imagine one could use a Shearwater
dive computer to log po2??
Kind regards,
willem





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