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

[Anton Lundin]

On 23 June, 2018 - Davide DB wrote:

> Anton,
> 
> I don't see any compelling reason to express your antipathy toward me.

There's no antipathy, just answers to questions and statements.


//Anton


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

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

[Davide DB]

Anton,

I don't see any compelling reason to express your antipathy toward me.

Take care

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

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

[Anton Lundin]

On 21 June, 2018 - Dirk Hohndel wrote:

> Hi Davide,
> 
> We just merged the patches from Anton, a new test build should show up in
> https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous 
> 
> soon.
> This link always gets you the latest test installer - and sometimes it may be
> missing because it's just being built (or because there was an error in the
> build). If that's the case (a) wait 10 minutes and (b) if it's still missing, 
> send
> an email to the list so we know to kick it :-)
> 
> > On Jun 18, 2018, at 9:15 PM, Davide DB  wrote:
> > 
> > I'm sure that this problem will solved.
> 
> The frustrating part is that it took so long. And that is definitely my fault
> because as I said, I didn't pay enough attention to the issue.
> 
> > As you see my report is dated back on december 2017. I cannot blame
> > nobody except my self for being lenient checking my profiles after
> > discovering that bug. On the other side I know well how open-source
> > projects works. People write code or generally help (like me) for what
> > is important for themselves and not so quickly for other things that
> > are not so important for themselves. No one gets paid for the work, so
> > one cannot force anybody.
> 
> So true

Long story on short format. I had other things on my mind, like a new
born.
 
> > Hence this bug was thought provoking for me. I've been always a
> > minority but with a divecan shearwater controller I thought I was
> > mainstream but I was wrong. This bug hit me hard. I have over 60 ccr
> > maniacally logged dives with completely wrong or missing pO2 samples.
> 
> I am reasonably certain that we can rectify this.
> 
> Please make a copy of your dive data (simply export them to an XML
> file), open that XML file, and then re-download from the Shearwater.
> In the Download dialog check the two boxes (sorry, English text, I'm
> sure you can figure out the Italian version):
> "Force download of all dives"
> "Always prefer downloaded dives"
> 
> With these options checked it should keep all of your other data like
> notes, buddies, etc, but replace the downloaded data with the new
> version which we assume will be corrected with the fix in place.
> 
> So this should be reasonably easy to recover from.
> 
> > A CCR dive without pO2 samples is like a cake with no sugar. If I
> > still have them on my Petrel (I never investigated how many profiles
> > it stores) I should import everything from scratch into Subsurface and
> > compile everything again. Not a nice perspective for the future. Right
> > now I'm diving two/three times per week so the count will increase
> > rapidly. I've tons of notes, wrecks positions, all dives have GPS
> > locations...
> 
> See above - you should be able to do this without having to manually
> re-edit all of this work!

I would rather describe it as without the pretty icing on the cake.
Every thing else about the profile is correct. Time, depth, temp and so
on. The pO2 is just affecting your deco and the monitoring of your
rebreather performance. Thats my view on it.

> > I think I will use Shearwater desktop for the time being
> > and leave old dives in Subsurface. When a complete solution will be
> > found I will evaluate how much effort is needed to realign everything
> > because I do not see a real solution coming soon.
> 
> This is where my ignorance shows. I thought Anton's fix solves the problem
> for you. Can you explain in non-CCR diver terms what is still missing?
> 
> > Anton (and now Aaron) patches are blessed workarounds but  don't solve
> > the inner problem:  for some mysterious reason, on some devices we
> > cannot use/decode Shearwater data.
> 
> If someone can extract this as one or two sample dives that show the
> problem and add words that make enough sense to me, I'll reach out
> to Shearwater again to see if they have suggestions. I know I sent them
> one of the earliest exchanges on this topic but neither they nor I really
> understood the problem and it got dropped

The calibration constants stored in the dive header are the default
value of 2100, and not the actual calibration constant.

First, that caused us to incorrectly convert the mV values from the
sensors into po2 values, and the later code did just skip exposing any
po2 values at all.

Now we fall back to the averaged/voted po2 value stored in a different
position in the samples.

> > Moreover other questions remained unanswered; In one year my unique
> > Petrel was identified as 3 different devices with random number of
> > sensors. My logbook is a mess and nobody knows the reason.
> 
> Also something I can ask about if you give me more information.

I rarely thing its random.

The old code exposed 1 value, the averaged/voted one.

Later, we exposed the individual sensor values.

Now we will expose the individual sensor values if we can find sane
calibration constants, otherwise the averaged/voted 

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

[Dirk Hohndel]

Hi Davide,

We just merged the patches from Anton, a new test build should show up in
https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous 

soon.
This link always gets you the latest test installer - and sometimes it may be
missing because it's just being built (or because there was an error in the
build). If that's the case (a) wait 10 minutes and (b) if it's still missing, 
send
an email to the list so we know to kick it :-)

> On Jun 18, 2018, at 9:15 PM, Davide DB  wrote:
> 
> I'm sure that this problem will solved.

The frustrating part is that it took so long. And that is definitely my fault
because as I said, I didn't pay enough attention to the issue.

> As you see my report is dated back on december 2017. I cannot blame
> nobody except my self for being lenient checking my profiles after
> discovering that bug. On the other side I know well how open-source
> projects works. People write code or generally help (like me) for what
> is important for themselves and not so quickly for other things that
> are not so important for themselves. No one gets paid for the work, so
> one cannot force anybody.

So true

> Hence this bug was thought provoking for me. I've been always a
> minority but with a divecan shearwater controller I thought I was
> mainstream but I was wrong. This bug hit me hard. I have over 60 ccr
> maniacally logged dives with completely wrong or missing pO2 samples.

I am reasonably certain that we can rectify this.

Please make a copy of your dive data (simply export them to an XML
file), open that XML file, and then re-download from the Shearwater.
In the Download dialog check the two boxes (sorry, English text, I'm
sure you can figure out the Italian version):
"Force download of all dives"
"Always prefer downloaded dives"

With these options checked it should keep all of your other data like
notes, buddies, etc, but replace the downloaded data with the new
version which we assume will be corrected with the fix in place.

So this should be reasonably easy to recover from.

> A CCR dive without pO2 samples is like a cake with no sugar. If I
> still have them on my Petrel (I never investigated how many profiles
> it stores) I should import everything from scratch into Subsurface and
> compile everything again. Not a nice perspective for the future. Right
> now I'm diving two/three times per week so the count will increase
> rapidly. I've tons of notes, wrecks positions, all dives have GPS
> locations...

See above - you should be able to do this without having to manually
re-edit all of this work!

> I think I will use Shearwater desktop for the time being
> and leave old dives in Subsurface. When a complete solution will be
> found I will evaluate how much effort is needed to realign everything
> because I do not see a real solution coming soon.

This is where my ignorance shows. I thought Anton's fix solves the problem
for you. Can you explain in non-CCR diver terms what is still missing?

> Anton (and now Aaron) patches are blessed workarounds but  don't solve
> the inner problem:  for some mysterious reason, on some devices we
> cannot use/decode Shearwater data.

If someone can extract this as one or two sample dives that show the
problem and add words that make enough sense to me, I'll reach out
to Shearwater again to see if they have suggestions. I know I sent them
one of the earliest exchanges on this topic but neither they nor I really
understood the problem and it got dropped

> Moreover other questions remained unanswered; In one year my unique
> Petrel was identified as 3 different devices with random number of
> sensors. My logbook is a mess and nobody knows the reason.

Also something I can ask about if you give me more information.

> Frankly speaking I think nobody with a shearwater petrel ccr
> controller knowing in advance this bug  would use Subsurface as their
> logbook. My profiles shows 2,1 bar of pO2 at 80 meters. Nothing you
> would show to anybody.

That would be, err, unsafe. Even I know that.

> Months ago, given your good relationship with Shearwater, I warmly
> recommended to contact them privately asking info on this nasty
> behaviour of some devices.

I will look again if there are more emails that I've missed.

Again, all I can do is apologize. You've done so much for Subsurface
and we have not taken good care of you. I hope you'll consider the
option I outlined above.

All the best

/D

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

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

[Linus Torvalds]

On Thu, Jun 21, 2018 at 4:20 AM Dirk Hohndel  wrote:
>
> Thanks, Anton. This looks reasonable. Assuming Linus sees no issue we can add 
> this today and if Davide is still interested he can test the new binaries.

I've taken them.

I pulled Jef's fix for the Uwatec Aladin Tec too.

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

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

[Martin Long]

I'll test them either way once a binary is available. This problem has
affected me too.

On Wed, 20 Jun 2018, 20:20 Dirk Hohndel,  wrote:

> Thanks, Anton. This looks reasonable. Assuming Linus sees no issue we can
> add this today and if Davide is still interested he can test the new
> binaries.
>
> /D
>
> > On Jun 21, 2018, at 4:06 AM, Anton Lundin  wrote:
> >
> > Of course I forgot to even compile it, so here's a updated 0002 patch
> > which actually compiles.
> >
> >
> > //Anton
> >
> >
> > On 20 June, 2018 - Anton Lundin wrote:
> >
> >> Here's the patches.
> >>
> >> I splitted them into two, so Jef can cherry-pick the first one, and a
> >> second one which adds a strings that says the source of the PPO2 values.
> >>
> >>
> >> //Anton
> >>
> >>
> >> On 18 June, 2018 - Dirk Hohndel wrote:
> >>
> >>> As I said before, I can't seem to find that patch. No idea why. If
> someone sends it to me I'll be happy to add it. I said that before as well.
> >>> If hate to see Davide abandon Subsurface over this...
> >>>
> >>> /D
> >>>
> >>> On June 18, 2018 5:39:43 AM GMT+09:00, "Long, Martin" <
> mar...@longhome.co.uk> wrote:
>  Dirk,
> 
>  I would say that Anton's patch would do it as an interim solution. Jef
>  isn't keen, as he has a better solution, but doesn't have the time to
>  work
>  on it yet. However, it does remove the regression, and prevent further
>  loss
>  of data in imports, until the *ideal* solution can be added. Data is
>  still
>  being lost, which is frustrating - I can't seem my actual ppO2 from
>  dives I
>  did yesterday, and now I never will, for those dives.
> 
>  Rather take an imperfect patch, which works now, than leave it broken
>  waiting for the perfect one (and no idea of how long it will take).
> 
>  On 17 June 2018 at 12:02, Dirk Hohndel  wrote:
> 
> >
> > On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
> >
> > On Thu, Jun 14, 2018, 15:34 Long, Martin 
>  wrote:
> >
> >> I'm in agreement with Davide that any interim solution we can get
>  running
> >> is better than the way it is working now. It's a regression, and tbh
>  if
> >> there isn't an interim solution then it ought to be reverted to the
>  old
> >> behaviour. At the moment I'm having to use Shearwater desktop for
>  reviewing
> >> all my logs.
> >>
> >
> > I had to stop using Subsurface for the time being. First time in so
>  many
> > years.
> >
> > If the bug will be solved I would have to transfer and compile from
> > scratch more than 60 dives (until now). I don't know if I will have
>  the
> > time or will to do all this work and frankly speaking I'm tired to be
> > always a minority.
> >
> > Farewell my friends. It has been a nice journey. Thank you all for
>  the
> > amazing work.
> >
> >>
> > Sorry to see you leave and thank you for all the great contributions.
> > Subsurface-mobile wouldn't be anywhere near where it is today if it
>  wasn't
> > for you.
> >
> > I'll admit that I completely tune out rebreather discussions - I
>  assume
> > that those who care about rebreathers will figure things out and will
>  send
> > me pull requests.
> >
> > Since I'd hate to see you go, is there actually something that we can
>  do
> > to fix this? Or are we (as in so many small odd corner cases) at a
>  point
> > where we just don't have the right person to work on something (like
>  the
> > FTDI download on Android)?
> >
> > /D
> >
> >
> >>>
> >>> --
> >>> from my phone.
> >>
> >>> ___
> >>> subsurface mailing list
> >>> subsurface@subsurface-divelog.org
> >>>
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> >>
> >>
> >> --
> >> Anton Lundin +46702-161604
> >
> >>> From c60d498661bac58e4182dfaab8d7e3e27b968b5b Mon Sep 17 00:00:00 2001
> >> From: Anton Lundin 
> >> Date: Wed, 20 Jun 2018 20:04:55 +0200
> >> Subject: [PATCH 1/2] shearwater: Fallback to average/voted ppo2
> >>
> >> If we can't find any calibration values for the individual sensors,
> >> fallback to emitting the average/voted ppo2 instead, so users always get
> >> a ppo2 value.
> >>
> >> Signed-off-by: Anton Lundin 
> >> ---
> >> src/shearwater_predator_parser.c | 26 +-
> >> 1 file changed, 13 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/src/shearwater_predator_parser.c
> b/src/shearwater_predator_parser.c
> >> index dda042c..6b1ae43 100644
> >> --- a/src/shearwater_predator_parser.c
> >> +++ b/src/shearwater_predator_parser.c
> >> @@ -669,19 +669,19 @@ shearwater_predator_parser_samples_foreach
> (dc_parser_t *abstract, dc_sample_cal
> >>  if ((status & OC) == 0) {
> >>  // PPO2
> >>  if ((status & PPO2_EXTERNAL) == 0) {
> 

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

[Dirk Hohndel]

Thanks, Anton. This looks reasonable. Assuming Linus sees no issue we can add 
this today and if Davide is still interested he can test the new binaries.

/D

> On Jun 21, 2018, at 4:06 AM, Anton Lundin  wrote:
> 
> Of course I forgot to even compile it, so here's a updated 0002 patch
> which actually compiles.
> 
> 
> //Anton
> 
> 
> On 20 June, 2018 - Anton Lundin wrote:
> 
>> Here's the patches.
>> 
>> I splitted them into two, so Jef can cherry-pick the first one, and a
>> second one which adds a strings that says the source of the PPO2 values.
>> 
>> 
>> //Anton
>> 
>> 
>> On 18 June, 2018 - Dirk Hohndel wrote:
>> 
>>> As I said before, I can't seem to find that patch. No idea why. If someone 
>>> sends it to me I'll be happy to add it. I said that before as well.
>>> If hate to see Davide abandon Subsurface over this...
>>> 
>>> /D
>>> 
>>> On June 18, 2018 5:39:43 AM GMT+09:00, "Long, Martin" 
>>>  wrote:
 Dirk,
 
 I would say that Anton's patch would do it as an interim solution. Jef
 isn't keen, as he has a better solution, but doesn't have the time to
 work
 on it yet. However, it does remove the regression, and prevent further
 loss
 of data in imports, until the *ideal* solution can be added. Data is
 still
 being lost, which is frustrating - I can't seem my actual ppO2 from
 dives I
 did yesterday, and now I never will, for those dives.
 
 Rather take an imperfect patch, which works now, than leave it broken
 waiting for the perfect one (and no idea of how long it will take).
 
 On 17 June 2018 at 12:02, Dirk Hohndel  wrote:
 
> 
> On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
> 
> On Thu, Jun 14, 2018, 15:34 Long, Martin 
 wrote:
> 
>> I'm in agreement with Davide that any interim solution we can get
 running
>> is better than the way it is working now. It's a regression, and tbh
 if
>> there isn't an interim solution then it ought to be reverted to the
 old
>> behaviour. At the moment I'm having to use Shearwater desktop for
 reviewing
>> all my logs.
>> 
> 
> I had to stop using Subsurface for the time being. First time in so
 many
> years.
> 
> If the bug will be solved I would have to transfer and compile from
> scratch more than 60 dives (until now). I don't know if I will have
 the
> time or will to do all this work and frankly speaking I'm tired to be
> always a minority.
> 
> Farewell my friends. It has been a nice journey. Thank you all for
 the
> amazing work.
> 
>> 
> Sorry to see you leave and thank you for all the great contributions.
> Subsurface-mobile wouldn't be anywhere near where it is today if it
 wasn't
> for you.
> 
> I'll admit that I completely tune out rebreather discussions - I
 assume
> that those who care about rebreathers will figure things out and will
 send
> me pull requests.
> 
> Since I'd hate to see you go, is there actually something that we can
 do
> to fix this? Or are we (as in so many small odd corner cases) at a
 point
> where we just don't have the right person to work on something (like
 the
> FTDI download on Android)?
> 
> /D
> 
> 
>>> 
>>> -- 
>>> from my phone.
>> 
>>> ___
>>> subsurface mailing list
>>> subsurface@subsurface-divelog.org
>>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>> 
>> 
>> -- 
>> Anton Lundin +46702-161604
> 
>>> From c60d498661bac58e4182dfaab8d7e3e27b968b5b Mon Sep 17 00:00:00 2001
>> From: Anton Lundin 
>> Date: Wed, 20 Jun 2018 20:04:55 +0200
>> Subject: [PATCH 1/2] shearwater: Fallback to average/voted ppo2
>> 
>> If we can't find any calibration values for the individual sensors,
>> fallback to emitting the average/voted ppo2 instead, so users always get
>> a ppo2 value.
>> 
>> Signed-off-by: Anton Lundin 
>> ---
>> src/shearwater_predator_parser.c | 26 +-
>> 1 file changed, 13 insertions(+), 13 deletions(-)
>> 
>> diff --git a/src/shearwater_predator_parser.c 
>> b/src/shearwater_predator_parser.c
>> index dda042c..6b1ae43 100644
>> --- a/src/shearwater_predator_parser.c
>> +++ b/src/shearwater_predator_parser.c
>> @@ -669,19 +669,19 @@ shearwater_predator_parser_samples_foreach 
>> (dc_parser_t *abstract, dc_sample_cal
>>  if ((status & OC) == 0) {
>>  // PPO2
>>  if ((status & PPO2_EXTERNAL) == 0) {
>> -#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->calibration[0];
>> -if (callback && (parser->calibrated & 0x01)) 
>> callback 

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

[Anton Lundin]

Of course I forgot to even compile it, so here's a updated 0002 patch
which actually compiles.


//Anton


On 20 June, 2018 - Anton Lundin wrote:

> Here's the patches.
> 
> I splitted them into two, so Jef can cherry-pick the first one, and a
> second one which adds a strings that says the source of the PPO2 values.
> 
> 
> //Anton
> 
> 
> On 18 June, 2018 - Dirk Hohndel wrote:
> 
> > As I said before, I can't seem to find that patch. No idea why. If someone 
> > sends it to me I'll be happy to add it. I said that before as well.
> > If hate to see Davide abandon Subsurface over this...
> > 
> > /D
> > 
> > On June 18, 2018 5:39:43 AM GMT+09:00, "Long, Martin" 
> >  wrote:
> > >Dirk,
> > >
> > >I would say that Anton's patch would do it as an interim solution. Jef
> > >isn't keen, as he has a better solution, but doesn't have the time to
> > >work
> > >on it yet. However, it does remove the regression, and prevent further
> > >loss
> > >of data in imports, until the *ideal* solution can be added. Data is
> > >still
> > >being lost, which is frustrating - I can't seem my actual ppO2 from
> > >dives I
> > >did yesterday, and now I never will, for those dives.
> > >
> > >Rather take an imperfect patch, which works now, than leave it broken
> > >waiting for the perfect one (and no idea of how long it will take).
> > >
> > >On 17 June 2018 at 12:02, Dirk Hohndel  wrote:
> > >
> > >>
> > >> On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
> > >>
> > >> On Thu, Jun 14, 2018, 15:34 Long, Martin 
> > >wrote:
> > >>
> > >>> I'm in agreement with Davide that any interim solution we can get
> > >running
> > >>> is better than the way it is working now. It's a regression, and tbh
> > >if
> > >>> there isn't an interim solution then it ought to be reverted to the
> > >old
> > >>> behaviour. At the moment I'm having to use Shearwater desktop for
> > >reviewing
> > >>> all my logs.
> > >>>
> > >>
> > >> I had to stop using Subsurface for the time being. First time in so
> > >many
> > >> years.
> > >>
> > >> If the bug will be solved I would have to transfer and compile from
> > >> scratch more than 60 dives (until now). I don't know if I will have
> > >the
> > >> time or will to do all this work and frankly speaking I'm tired to be
> > >> always a minority.
> > >>
> > >> Farewell my friends. It has been a nice journey. Thank you all for
> > >the
> > >> amazing work.
> > >>
> > >>>
> > >> Sorry to see you leave and thank you for all the great contributions.
> > >> Subsurface-mobile wouldn't be anywhere near where it is today if it
> > >wasn't
> > >> for you.
> > >>
> > >> I'll admit that I completely tune out rebreather discussions - I
> > >assume
> > >> that those who care about rebreathers will figure things out and will
> > >send
> > >> me pull requests.
> > >>
> > >> Since I'd hate to see you go, is there actually something that we can
> > >do
> > >> to fix this? Or are we (as in so many small odd corner cases) at a
> > >point
> > >> where we just don't have the right person to work on something (like
> > >the
> > >> FTDI download on Android)?
> > >>
> > >> /D
> > >>
> > >>
> > 
> > -- 
> > from my phone.
> 
> > ___
> > subsurface mailing list
> > subsurface@subsurface-divelog.org
> > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> 
> 
> -- 
> Anton Lundin  +46702-161604

> >From c60d498661bac58e4182dfaab8d7e3e27b968b5b Mon Sep 17 00:00:00 2001
> From: Anton Lundin 
> Date: Wed, 20 Jun 2018 20:04:55 +0200
> Subject: [PATCH 1/2] shearwater: Fallback to average/voted ppo2
> 
> If we can't find any calibration values for the individual sensors,
> fallback to emitting the average/voted ppo2 instead, so users always get
> a ppo2 value.
> 
> Signed-off-by: Anton Lundin 
> ---
>  src/shearwater_predator_parser.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/src/shearwater_predator_parser.c 
> b/src/shearwater_predator_parser.c
> index dda042c..6b1ae43 100644
> --- a/src/shearwater_predator_parser.c
> +++ b/src/shearwater_predator_parser.c
> @@ -669,19 +669,19 @@ shearwater_predator_parser_samples_foreach (dc_parser_t 
> *abstract, dc_sample_cal
>   if ((status & OC) == 0) {
>   // PPO2
>   if ((status & PPO2_EXTERNAL) == 0) {
> -#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->calibration[0];
> - if (callback && (parser->calibrated & 0x01)) 
> callback (DC_SAMPLE_PPO2, sample, userdata);
> -
> - sample.ppo2 = data[offset + 14] * 
> parser->calibration[1];
> - if (callback && (parser->calibrated & 0x02)) 
> callback (DC_SAMPLE_PPO2, sample, 

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

[Anton Lundin]

Here's the patches.

I splitted them into two, so Jef can cherry-pick the first one, and a
second one which adds a strings that says the source of the PPO2 values.


//Anton


On 18 June, 2018 - Dirk Hohndel wrote:

> As I said before, I can't seem to find that patch. No idea why. If someone 
> sends it to me I'll be happy to add it. I said that before as well.
> If hate to see Davide abandon Subsurface over this...
> 
> /D
> 
> On June 18, 2018 5:39:43 AM GMT+09:00, "Long, Martin"  
> wrote:
> >Dirk,
> >
> >I would say that Anton's patch would do it as an interim solution. Jef
> >isn't keen, as he has a better solution, but doesn't have the time to
> >work
> >on it yet. However, it does remove the regression, and prevent further
> >loss
> >of data in imports, until the *ideal* solution can be added. Data is
> >still
> >being lost, which is frustrating - I can't seem my actual ppO2 from
> >dives I
> >did yesterday, and now I never will, for those dives.
> >
> >Rather take an imperfect patch, which works now, than leave it broken
> >waiting for the perfect one (and no idea of how long it will take).
> >
> >On 17 June 2018 at 12:02, Dirk Hohndel  wrote:
> >
> >>
> >> On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
> >>
> >> On Thu, Jun 14, 2018, 15:34 Long, Martin 
> >wrote:
> >>
> >>> I'm in agreement with Davide that any interim solution we can get
> >running
> >>> is better than the way it is working now. It's a regression, and tbh
> >if
> >>> there isn't an interim solution then it ought to be reverted to the
> >old
> >>> behaviour. At the moment I'm having to use Shearwater desktop for
> >reviewing
> >>> all my logs.
> >>>
> >>
> >> I had to stop using Subsurface for the time being. First time in so
> >many
> >> years.
> >>
> >> If the bug will be solved I would have to transfer and compile from
> >> scratch more than 60 dives (until now). I don't know if I will have
> >the
> >> time or will to do all this work and frankly speaking I'm tired to be
> >> always a minority.
> >>
> >> Farewell my friends. It has been a nice journey. Thank you all for
> >the
> >> amazing work.
> >>
> >>>
> >> Sorry to see you leave and thank you for all the great contributions.
> >> Subsurface-mobile wouldn't be anywhere near where it is today if it
> >wasn't
> >> for you.
> >>
> >> I'll admit that I completely tune out rebreather discussions - I
> >assume
> >> that those who care about rebreathers will figure things out and will
> >send
> >> me pull requests.
> >>
> >> Since I'd hate to see you go, is there actually something that we can
> >do
> >> to fix this? Or are we (as in so many small odd corner cases) at a
> >point
> >> where we just don't have the right person to work on something (like
> >the
> >> FTDI download on Android)?
> >>
> >> /D
> >>
> >>
> 
> -- 
> from my phone.

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


-- 
Anton Lundin+46702-161604
>From c60d498661bac58e4182dfaab8d7e3e27b968b5b Mon Sep 17 00:00:00 2001
From: Anton Lundin 
Date: Wed, 20 Jun 2018 20:04:55 +0200
Subject: [PATCH 1/2] shearwater: Fallback to average/voted ppo2

If we can't find any calibration values for the individual sensors,
fallback to emitting the average/voted ppo2 instead, so users always get
a ppo2 value.

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

diff --git a/src/shearwater_predator_parser.c b/src/shearwater_predator_parser.c
index dda042c..6b1ae43 100644
--- a/src/shearwater_predator_parser.c
+++ b/src/shearwater_predator_parser.c
@@ -669,19 +669,19 @@ shearwater_predator_parser_samples_foreach (dc_parser_t *abstract, dc_sample_cal
 		if ((status & OC) == 0) {
 			// PPO2
 			if ((status & PPO2_EXTERNAL) == 0) {
-#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->calibration[0];
-if (callback && (parser->calibrated & 0x01)) callback (DC_SAMPLE_PPO2, sample, userdata);
-
-sample.ppo2 = data[offset + 14] * parser->calibration[1];
-if (callback && (parser->calibrated & 0x02)) callback (DC_SAMPLE_PPO2, sample, userdata);
-
-sample.ppo2 = data[offset + 15] * parser->calibration[2];
-if (callback && (parser->calibrated & 0x04)) callback (DC_SAMPLE_PPO2, sample, userdata);
-#endif
+if (!parser->calibrated) {
+	sample.ppo2 = data[offset + 6] / 100.0;
+	if (callback) callback (DC_SAMPLE_PPO2, sample, userdata);
+} else {
+	sample.ppo2 = data[offset + 12] * parser->calibration[0];
+	if (callback && (parser->calibrated & 0x01)) callback (DC_SAMPLE_PPO2, sample, userdata);
+
+	sample.ppo2 = data[offset + 14] * parser->calibration[1];
+	if (callback && (parser->calibrated & 0x02)) callback (DC_SAMPLE_PPO2, 

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

[Long, Martin]

I can't seem to get my Android build environment working at the moment. If
anyone is able to give me an apk with these patches, I'll happily test
them.

Thanks

 Martin

On 17 June 2018 at 23:05, Aaron Scheiner  wrote:

> In the attached screenshot the green line is the voted PO2 from the DC (I
> changed the colours because... messing around. They're not colour blindness
> friendly). On my JJ the reported PO2 from the dive computer (Petrel 2) is
> slightly lower than the uncalibrated sensor values.
>
> I've tested saving/loading from XML and saving/loading from git, which
> work.
>
> In a nutshell I've added an additional field in both libdivecomputer and
> Subsurface. If the additional field is populated, Subsurface will use that
> instead of trying to average/calculate the PO2.
>
> I still need to test what it does on Android. I still need to clean up
> stuff. There's probably a better way of implementing this functionality.
>
> Aaron
>
> On Sun, Jun 17, 2018 at 5:18 PM, Aaron Scheiner 
> wrote:
>
>> I'm in the same boat and last week I started working on adding an
>> additional field to both subsurface and libdivecomputer (I called it voted
>> PO2). I managed to get the import and display of it working before I got
>> interrupted by other stuff. It has subsequently occurred to me that this
>> may not be the best approach.
>>
>> I'll have a look at it again and try and come up with a better way.
>>
>> Aaron
>>
>> On Sun, Jun 17, 2018, 11:53 Davide DB  wrote:
>>
>>> On Thu, Jun 14, 2018, 15:34 Long, Martin  wrote:
>>>
 I'm in agreement with Davide that any interim solution we can get
 running is better than the way it is working now. It's a regression, and
 tbh if there isn't an interim solution then it ought to be reverted to the
 old behaviour. At the moment I'm having to use Shearwater desktop for
 reviewing all my logs.

>>>
>>> I had to stop using Subsurface for the time being. First time in so many
>>> years.
>>>
>>> If the bug will be solved I would have to transfer and compile from
>>> scratch more than 60 dives (until now). I don't know if I will have the
>>> time or will to do all this work and frankly speaking I'm tired to be
>>> always a minority.
>>>
>>> Farewell my friends. It has been a nice journey. Thank you all for the
>>> amazing work.
>>>

>>>
>>> davide@mobile
>>>
>>>
>>>
 ___
>>> 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: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Davide DB]

Hi Dirk,

I'm sure that this problem will solved.
It's clear that is anyway a Shearwater problem or an undocumented feature.
The interim solution proposed by Anton is already a good step forward.
BTW you will not find a patch: Anton just posted a "diff". You will
find everything here:

https://github.com/Subsurface-divelog/subsurface/issues/971

As you see my report is dated back on december 2017. I cannot blame
nobody except my self for being lenient checking my profiles after
discovering that bug. On the other side I know well how open-source
projects works. People write code or generally help (like me) for what
is important for themselves and not so quickly for other things that
are not so important for themselves. No one gets paid for the work, so
one cannot force anybody.
Hence this bug was thought provoking for me. I've been always a
minority but with a divecan shearwater controller I thought I was
mainstream but I was wrong. This bug hit me hard. I have over 60 ccr
maniacally logged dives with completely wrong or missing pO2 samples.
A CCR dive without pO2 samples is like a cake with no sugar. If I
still have them on my Petrel (I never investigated how many profiles
it stores) I should import everything from scratch into Subsurface and
compile everything again. Not a nice perspective for the future. Right
now I'm diving two/three times per week so the count will increase
rapidly. I've tons of notes, wrecks positions, all dives have GPS
locations... I think I will use Shearwater desktop for the time being
and leave old dives in Subsurface. When a complete solution will be
found I will evaluate how much effort is needed to realign everything
because I do not see a real solution coming soon.
Anton (and now Aaron) patches are blessed workarounds but  don't solve
the inner problem:  for some mysterious reason, on some devices we
cannot use/decode Shearwater data.
Moreover other questions remained unanswered; In one year my unique
Petrel was identified as 3 different devices with random number of
sensors. My logbook is a mess and nobody knows the reason.
Frankly speaking I think nobody with a shearwater petrel ccr
controller knowing in advance this bug  would use Subsurface as their
logbook. My profiles shows 2,1 bar of pO2 at 80 meters. Nothing you
would show to anybody.

Months ago, given your good relationship with Shearwater, I warmly
recommended to contact them privately asking info on this nasty
behaviour of some devices.

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: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Long, Martin]

The problem is it wasn't really a patch, it was just a diff posted in this
thread, but Jef then said he wasn't happy with it.

I guess that Aaron's stuff above superceeds this now.

On 17 June 2018 at 23:26, Dirk Hohndel  wrote:

> As I said before, I can't seem to find that patch. No idea why. If someone
> sends it to me I'll be happy to add it. I said that before as well.
> If hate to see Davide abandon Subsurface over this...
>
> /D
>
>
> On June 18, 2018 5:39:43 AM GMT+09:00, "Long, Martin" <
> mar...@longhome.co.uk> wrote:
>>
>> Dirk,
>>
>> I would say that Anton's patch would do it as an interim solution. Jef
>> isn't keen, as he has a better solution, but doesn't have the time to work
>> on it yet. However, it does remove the regression, and prevent further loss
>> of data in imports, until the *ideal* solution can be added. Data is still
>> being lost, which is frustrating - I can't seem my actual ppO2 from dives I
>> did yesterday, and now I never will, for those dives.
>>
>> Rather take an imperfect patch, which works now, than leave it broken
>> waiting for the perfect one (and no idea of how long it will take).
>>
>> On 17 June 2018 at 12:02, Dirk Hohndel  wrote:
>>
>>>
>>> On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
>>>
>>> On Thu, Jun 14, 2018, 15:34 Long, Martin  wrote:
>>>
 I'm in agreement with Davide that any interim solution we can get
 running is better than the way it is working now. It's a regression, and
 tbh if there isn't an interim solution then it ought to be reverted to the
 old behaviour. At the moment I'm having to use Shearwater desktop for
 reviewing all my logs.

>>>
>>> I had to stop using Subsurface for the time being. First time in so many
>>> years.
>>>
>>> If the bug will be solved I would have to transfer and compile from
>>> scratch more than 60 dives (until now). I don't know if I will have the
>>> time or will to do all this work and frankly speaking I'm tired to be
>>> always a minority.
>>>
>>> Farewell my friends. It has been a nice journey. Thank you all for the
>>> amazing work.
>>>

>>> Sorry to see you leave and thank you for all the great contributions.
>>> Subsurface-mobile wouldn't be anywhere near where it is today if it wasn't
>>> for you.
>>>
>>> I'll admit that I completely tune out rebreather discussions - I assume
>>> that those who care about rebreathers will figure things out and will send
>>> me pull requests.
>>>
>>> Since I'd hate to see you go, is there actually something that we can do
>>> to fix this? Or are we (as in so many small odd corner cases) at a point
>>> where we just don't have the right person to work on something (like the
>>> FTDI download on Android)?
>>>
>>> /D
>>>
>>>
>>
> --
> from my phone.
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

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

[Dirk Hohndel]

As I said before, I can't seem to find that patch. No idea why. If someone 
sends it to me I'll be happy to add it. I said that before as well.
If hate to see Davide abandon Subsurface over this...

/D

On June 18, 2018 5:39:43 AM GMT+09:00, "Long, Martin"  
wrote:
>Dirk,
>
>I would say that Anton's patch would do it as an interim solution. Jef
>isn't keen, as he has a better solution, but doesn't have the time to
>work
>on it yet. However, it does remove the regression, and prevent further
>loss
>of data in imports, until the *ideal* solution can be added. Data is
>still
>being lost, which is frustrating - I can't seem my actual ppO2 from
>dives I
>did yesterday, and now I never will, for those dives.
>
>Rather take an imperfect patch, which works now, than leave it broken
>waiting for the perfect one (and no idea of how long it will take).
>
>On 17 June 2018 at 12:02, Dirk Hohndel  wrote:
>
>>
>> On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
>>
>> On Thu, Jun 14, 2018, 15:34 Long, Martin 
>wrote:
>>
>>> I'm in agreement with Davide that any interim solution we can get
>running
>>> is better than the way it is working now. It's a regression, and tbh
>if
>>> there isn't an interim solution then it ought to be reverted to the
>old
>>> behaviour. At the moment I'm having to use Shearwater desktop for
>reviewing
>>> all my logs.
>>>
>>
>> I had to stop using Subsurface for the time being. First time in so
>many
>> years.
>>
>> If the bug will be solved I would have to transfer and compile from
>> scratch more than 60 dives (until now). I don't know if I will have
>the
>> time or will to do all this work and frankly speaking I'm tired to be
>> always a minority.
>>
>> Farewell my friends. It has been a nice journey. Thank you all for
>the
>> amazing work.
>>
>>>
>> Sorry to see you leave and thank you for all the great contributions.
>> Subsurface-mobile wouldn't be anywhere near where it is today if it
>wasn't
>> for you.
>>
>> I'll admit that I completely tune out rebreather discussions - I
>assume
>> that those who care about rebreathers will figure things out and will
>send
>> me pull requests.
>>
>> Since I'd hate to see you go, is there actually something that we can
>do
>> to fix this? Or are we (as in so many small odd corner cases) at a
>point
>> where we just don't have the right person to work on something (like
>the
>> FTDI download on Android)?
>>
>> /D
>>
>>

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

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

[Aaron Scheiner]

In the attached screenshot the green line is the voted PO2 from the DC (I
changed the colours because... messing around. They're not colour blindness
friendly). On my JJ the reported PO2 from the dive computer (Petrel 2) is
slightly lower than the uncalibrated sensor values.

I've tested saving/loading from XML and saving/loading from git, which work.

In a nutshell I've added an additional field in both libdivecomputer and
Subsurface. If the additional field is populated, Subsurface will use that
instead of trying to average/calculate the PO2.

I still need to test what it does on Android. I still need to clean up
stuff. There's probably a better way of implementing this functionality.

Aaron

On Sun, Jun 17, 2018 at 5:18 PM, Aaron Scheiner  wrote:

> I'm in the same boat and last week I started working on adding an
> additional field to both subsurface and libdivecomputer (I called it voted
> PO2). I managed to get the import and display of it working before I got
> interrupted by other stuff. It has subsequently occurred to me that this
> may not be the best approach.
>
> I'll have a look at it again and try and come up with a better way.
>
> Aaron
>
> On Sun, Jun 17, 2018, 11:53 Davide DB  wrote:
>
>> On Thu, Jun 14, 2018, 15:34 Long, Martin  wrote:
>>
>>> I'm in agreement with Davide that any interim solution we can get
>>> running is better than the way it is working now. It's a regression, and
>>> tbh if there isn't an interim solution then it ought to be reverted to the
>>> old behaviour. At the moment I'm having to use Shearwater desktop for
>>> reviewing all my logs.
>>>
>>
>> I had to stop using Subsurface for the time being. First time in so many
>> years.
>>
>> If the bug will be solved I would have to transfer and compile from
>> scratch more than 60 dives (until now). I don't know if I will have the
>> time or will to do all this work and frankly speaking I'm tired to be
>> always a minority.
>>
>> Farewell my friends. It has been a nice journey. Thank you all for the
>> amazing work.
>>
>>>
>>
>> davide@mobile
>>
>>
>>
>>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>
diff --git a/core/color.cpp b/core/color.cpp
index c0b8a4643..0a959ab92 100644
--- a/core/color.cpp
+++ b/core/color.cpp
@@ -29,9 +29,10 @@ void fill_profile_color()
 	profile_color[PHE] = COLOR(PEANUT, BLACK1_LOW_TRANS, PEANUT);
 	profile_color[PHE_ALERT] = COLOR(RED1, BLACK1_LOW_TRANS, RED1);
 	profile_color[O2SETPOINT] = COLOR(PIRATEGOLD1_MED_TRANS, BLACK1_LOW_TRANS, PIRATEGOLD1_MED_TRANS);
-	profile_color[CCRSENSOR1] = COLOR(TUNDORA1_MED_TRANS, BLACK1_LOW_TRANS, TUNDORA1_MED_TRANS);
-	profile_color[CCRSENSOR2] = COLOR(ROYALBLUE2_LOW_TRANS, BLACK1_LOW_TRANS, ROYALBLUE2_LOW_TRANS);
-	profile_color[CCRSENSOR3] = COLOR(PEANUT, BLACK1_LOW_TRANS, PEANUT);
+	profile_color[CCRSENSOR1] = COLOR(RED1, BLACK1_LOW_TRANS, RED1);
+	profile_color[CCRSENSOR2] = COLOR(NITROX_YELLOW, BLACK1_LOW_TRANS, NITROX_YELLOW);
+	profile_color[CCRSENSOR3] = COLOR(ROYALBLUE2, BLACK1_LOW_TRANS, ROYALBLUE2);
+	profile_color[CCRVOTEDSENSOR] = COLOR(BLACK1_HIGH_TRANS,BLACK1_HIGH_TRANS,BLACK1_HIGH_TRANS);
 	profile_color[SCR_OCPO2] = COLOR(PIRATEGOLD1_MED_TRANS, BLACK1_LOW_TRANS, PIRATEGOLD1_MED_TRANS);
 
 	profile_color[PP_LINES] = COLOR(BLACK1_HIGH_TRANS, BLACK1_LOW_TRANS, BLACK1_HIGH_TRANS);
diff --git a/core/color.h b/core/color.h
index bf2f1ddcb..7ac269bfd 100644
--- a/core/color.h
+++ b/core/color.h
@@ -103,6 +103,7 @@ typedef enum {
 	CCRSENSOR1,
 	CCRSENSOR2,
 	CCRSENSOR3,
+	CCRVOTEDSENSOR,
 	SCR_OCPO2,
 	PP_LINES,
 
diff --git a/core/dive.h b/core/dive.h
index 5c7b74395..16b0ce2d4 100644
--- a/core/dive.h
+++ b/core/dive.h
@@ -174,6 +174,7 @@ struct sample // BASE TYPE BYTES  UNITSRANGE
 	pressure_t pressure[MAX_SENSORS]; // int32_t4mbar   (0-2 Mbar) cylinder pressures (main and CCR o2)
 	o2pressure_t setpoint;// uint16_t   2mbar   (0-65 bar) O2 partial pressure (will be setpoint)
 	o2pressure_t o2sensor[3]; // uint16_t   6mbar   (0-65 bar) Up to 3 PO2 sensor values (rebreather)
+	o2pressure_t votedpo2;// uint16_t   2mbar   (0-65 bar) O2 partial pressure (as displayed by DC)
 	bearing_t bearing;// int16_t2  degrees  (-1 no val, 0-360 deg) compass bearing
 	uint8_t sensor[MAX_SENSORS];  // uint8_t1  sensorID (0-255)ID of cylinder pressure sensor
 	uint16_t cns; // uint16_t   1 % (0-64k %)  cns% accumulated
diff --git a/core/libdivecomputer.c b/core/libdivecomputer.c
index 3443886b6..7f54ac079 100644
--- a/core/libdivecomputer.c
+++ b/core/libdivecomputer.c
@@ -403,6 +403,9 @@ sample_cb(dc_sample_type_t type, dc_sample_value_t value, void *userdata)
 		if (nsensor > dc->no_o2sensors)
 			

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

[Long, Martin]

Dirk,

I would say that Anton's patch would do it as an interim solution. Jef
isn't keen, as he has a better solution, but doesn't have the time to work
on it yet. However, it does remove the regression, and prevent further loss
of data in imports, until the *ideal* solution can be added. Data is still
being lost, which is frustrating - I can't seem my actual ppO2 from dives I
did yesterday, and now I never will, for those dives.

Rather take an imperfect patch, which works now, than leave it broken
waiting for the perfect one (and no idea of how long it will take).

On 17 June 2018 at 12:02, Dirk Hohndel  wrote:

>
> On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
>
> On Thu, Jun 14, 2018, 15:34 Long, Martin  wrote:
>
>> I'm in agreement with Davide that any interim solution we can get running
>> is better than the way it is working now. It's a regression, and tbh if
>> there isn't an interim solution then it ought to be reverted to the old
>> behaviour. At the moment I'm having to use Shearwater desktop for reviewing
>> all my logs.
>>
>
> I had to stop using Subsurface for the time being. First time in so many
> years.
>
> If the bug will be solved I would have to transfer and compile from
> scratch more than 60 dives (until now). I don't know if I will have the
> time or will to do all this work and frankly speaking I'm tired to be
> always a minority.
>
> Farewell my friends. It has been a nice journey. Thank you all for the
> amazing work.
>
>>
> Sorry to see you leave and thank you for all the great contributions.
> Subsurface-mobile wouldn't be anywhere near where it is today if it wasn't
> for you.
>
> I'll admit that I completely tune out rebreather discussions - I assume
> that those who care about rebreathers will figure things out and will send
> me pull requests.
>
> Since I'd hate to see you go, is there actually something that we can do
> to fix this? Or are we (as in so many small odd corner cases) at a point
> where we just don't have the right person to work on something (like the
> FTDI download on Android)?
>
> /D
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

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

[Aaron Scheiner]

I'm in the same boat and last week I started working on adding an
additional field to both subsurface and libdivecomputer (I called it voted
PO2). I managed to get the import and display of it working before I got
interrupted by other stuff. It has subsequently occurred to me that this
may not be the best approach.

I'll have a look at it again and try and come up with a better way.

Aaron

On Sun, Jun 17, 2018, 11:53 Davide DB  wrote:

> On Thu, Jun 14, 2018, 15:34 Long, Martin  wrote:
>
>> I'm in agreement with Davide that any interim solution we can get running
>> is better than the way it is working now. It's a regression, and tbh if
>> there isn't an interim solution then it ought to be reverted to the old
>> behaviour. At the moment I'm having to use Shearwater desktop for reviewing
>> all my logs.
>>
>
> I had to stop using Subsurface for the time being. First time in so many
> years.
>
> If the bug will be solved I would have to transfer and compile from
> scratch more than 60 dives (until now). I don't know if I will have the
> time or will to do all this work and frankly speaking I'm tired to be
> always a minority.
>
> Farewell my friends. It has been a nice journey. Thank you all for the
> amazing work.
>
>>
>
> davide@mobile
>
>
>
>> ___
> 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: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Dirk Hohndel]

> On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
> 
> On Thu, Jun 14, 2018, 15:34 Long, Martin  > wrote:
> I'm in agreement with Davide that any interim solution we can get running is 
> better than the way it is working now. It's a regression, and tbh if there 
> isn't an interim solution then it ought to be reverted to the old behaviour. 
> At the moment I'm having to use Shearwater desktop for reviewing all my logs. 
> 
> I had to stop using Subsurface for the time being. First time in so many 
> years.
> 
> If the bug will be solved I would have to transfer and compile from scratch 
> more than 60 dives (until now). I don't know if I will have the time or will 
> to do all this work and frankly speaking I'm tired to be always a minority.
> 
> Farewell my friends. It has been a nice journey. Thank you all for the 
> amazing work.

Sorry to see you leave and thank you for all the great contributions. 
Subsurface-mobile wouldn't be anywhere near where it is today if it wasn't for 
you.

I'll admit that I completely tune out rebreather discussions - I assume that 
those who care about rebreathers will figure things out and will send me pull 
requests.

Since I'd hate to see you go, is there actually something that we can do to fix 
this? Or are we (as in so many small odd corner cases) at a point where we just 
don't have the right person to work on something (like the FTDI download on 
Android)?

/D

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

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

[Davide DB]

On Thu, Jun 14, 2018, 15:34 Long, Martin  wrote:

> I'm in agreement with Davide that any interim solution we can get running
> is better than the way it is working now. It's a regression, and tbh if
> there isn't an interim solution then it ought to be reverted to the old
> behaviour. At the moment I'm having to use Shearwater desktop for reviewing
> all my logs.
>

I had to stop using Subsurface for the time being. First time in so many
years.

If the bug will be solved I would have to transfer and compile from scratch
more than 60 dives (until now). I don't know if I will have the time or
will to do all this work and frankly speaking I'm tired to be always a
minority.

Farewell my friends. It has been a nice journey. Thank you all for the
amazing work.

>

davide@mobile



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

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

[Long, Martin]

I'm in agreement with Davide that any interim solution we can get running
is better than the way it is working now. It's a regression, and tbh if
there isn't an interim solution then it ought to be reverted to the old
behaviour. At the moment I'm having to use Shearwater desktop for reviewing
all my logs.

On 11 June 2018 at 21:46, Anton Lundin  wrote:

> On 11 June, 2018 - Jef Driesen wrote:
>
> > On 11-06-18 20:21, Anton Lundin wrote:
> > >On 04 June, 2018 - Dirk Hohndel wrote:
> > >
> > >>I don't have an outstanding patch from you, so not sure what you are
> referring to.
> > >
> > >There was a diff a while back in this thread, in
> > >20180523144751.gc12...@hirohito.acc.umu.se , which made the code fall
> > >back to the voted/averaged ppo2 instead of reporting individual sensors
> > >if we couldn't find sane calibration values.
> > >
> > >
> > >Jef didn't like it, but I think its a step to a better place than where
> > >we're right now, and as far as I've read it, both Davide and Martin who
> > >is affected agrees.
> > >
> > >
> > >Anyway, now when I'm back on solid ground (I still feel the waves in my
> > >legs) I might get around to making up a commit message and formating it
> > >as a patch.
> >
> > It's not that I really disliked the patch. I just wanted to point
> > out that it introduces a possible disambiguity in the sense that in
> > the application you no longer know which type of ppo2 you are
> > getting (voted or sensor). I would rather go for a solution that
> > indicates the type. That's exactly what's on my (long) todo list.
> >
>
> Yes, that would have bin great to have, but we don't have it, and its
> mixed already. Some backends return voted/average/computed and some
> return sensor values.
>
> Return real mV values would be nice to.
>
> > But I'm fine with your patch as an interim solution as well. Btw, an
> > alternative could be to always deliver both the voted *and* the
> > sensor ppO2. Then you know for sure that the first value is always
> > the voted value, and the remaining ones (if present) are the sensor
> > ones.
>
> Would we then invent a averaged value for backends who doesn't have it,
> like the ostc3?
>
> This sounds like a even bigger mess to me.
>
> //Anton
>
> --
> Anton Lundin+46702-161604
> ___
> 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: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Anton Lundin]

On 11 June, 2018 - Jef Driesen wrote:

> On 11-06-18 20:21, Anton Lundin wrote:
> >On 04 June, 2018 - Dirk Hohndel wrote:
> >
> >>I don't have an outstanding patch from you, so not sure what you are 
> >>referring to.
> >
> >There was a diff a while back in this thread, in
> >20180523144751.gc12...@hirohito.acc.umu.se , which made the code fall
> >back to the voted/averaged ppo2 instead of reporting individual sensors
> >if we couldn't find sane calibration values.
> >
> >
> >Jef didn't like it, but I think its a step to a better place than where
> >we're right now, and as far as I've read it, both Davide and Martin who
> >is affected agrees.
> >
> >
> >Anyway, now when I'm back on solid ground (I still feel the waves in my
> >legs) I might get around to making up a commit message and formating it
> >as a patch.
> 
> It's not that I really disliked the patch. I just wanted to point
> out that it introduces a possible disambiguity in the sense that in
> the application you no longer know which type of ppo2 you are
> getting (voted or sensor). I would rather go for a solution that
> indicates the type. That's exactly what's on my (long) todo list.
> 

Yes, that would have bin great to have, but we don't have it, and its
mixed already. Some backends return voted/average/computed and some
return sensor values.

Return real mV values would be nice to.

> But I'm fine with your patch as an interim solution as well. Btw, an
> alternative could be to always deliver both the voted *and* the
> sensor ppO2. Then you know for sure that the first value is always
> the voted value, and the remaining ones (if present) are the sensor
> ones.

Would we then invent a averaged value for backends who doesn't have it,
like the ostc3?

This sounds like a even bigger mess to me.

//Anton

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

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

[Davide DB]

On Mon, 11 Jun 2018 at 20:21, Anton Lundin  wrote:
>
> On 04 June, 2018 - Dirk Hohndel wrote:
>
> > I don't have an outstanding patch from you, so not sure what you are 
> > referring to.
>
> There was a diff a while back in this thread, in
> 20180523144751.gc12...@hirohito.acc.umu.se , which made the code fall
> back to the voted/averaged ppo2 instead of reporting individual sensors
> if we couldn't find sane calibration values.

Diff is on Github issue too:
https://github.com/Subsurface-divelog/subsurface/issues/971#issuecomment-391630681


>
> Jef didn't like it, but I think its a step to a better place than where
> we're right now, and as far as I've read it, both Davide and Martin who
> is affected agrees.
>
>
> Anyway, now when I'm back on solid ground (I still feel the waves in my
> legs) I might get around to making up a commit message and formating it
> as a patch.
>

Hi guys,
This is really a big blocking issue for me. I lost data for my last 50 dives.
I tried to temporary overcome the problem downloading dives with
Shearwater desktop and then importing them in Subsurface via XML.
Even in this case there are errors:

- no pO2 samples
- average pO2 completely wrong: graph reports a bottom pO2 of 1,92 bar

I updated issue #971 with screenshots

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: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Jef Driesen]

On 11-06-18 20:21, Anton Lundin wrote:

On 04 June, 2018 - Dirk Hohndel wrote:


I don't have an outstanding patch from you, so not sure what you are referring 
to.


There was a diff a while back in this thread, in
20180523144751.gc12...@hirohito.acc.umu.se , which made the code fall
back to the voted/averaged ppo2 instead of reporting individual sensors
if we couldn't find sane calibration values.


Jef didn't like it, but I think its a step to a better place than where
we're right now, and as far as I've read it, both Davide and Martin who
is affected agrees.


Anyway, now when I'm back on solid ground (I still feel the waves in my
legs) I might get around to making up a commit message and formating it
as a patch.


It's not that I really disliked the patch. I just wanted to point out that it 
introduces a possible disambiguity in the sense that in the application you no 
longer know which type of ppo2 you are getting (voted or sensor). I would rather 
go for a solution that indicates the type. That's exactly what's on my (long) 
todo list.


But I'm fine with your patch as an interim solution as well. Btw, an alternative 
could be to always deliver both the voted *and* the sensor ppO2. Then you know 
for sure that the first value is always the voted value, and the remaining ones 
(if present) are the sensor ones.


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

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

[Anton Lundin]

On 04 June, 2018 - Dirk Hohndel wrote:

> I don't have an outstanding patch from you, so not sure what you are 
> referring to.

There was a diff a while back in this thread, in
20180523144751.gc12...@hirohito.acc.umu.se , which made the code fall
back to the voted/averaged ppo2 instead of reporting individual sensors
if we couldn't find sane calibration values.


Jef didn't like it, but I think its a step to a better place than where
we're right now, and as far as I've read it, both Davide and Martin who
is affected agrees.


Anyway, now when I'm back on solid ground (I still feel the waves in my
legs) I might get around to making up a commit message and formating it
as a patch.


//Anton

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

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

[Dirk Hohndel]

I don't have an outstanding patch from you, so not sure what you are referring 
to.

/D

> On Jun 4, 2018, at 6:46 AM, Anton Lundin  wrote:
> 
> If Dirk/Linus feels for it, hey can grab the diff and make up a commit 
> message and it will be in the next dev build.
> 
> I can't really do it because I'm on a diving trip in the baltic, in a storm, 
> making good head way on tonights target of getting hammered.
> 
> //Anton - skepp åhoj!
> 
> On June 4, 2018 9:13:45 AM GMT+02:00, Davide DB  wrote:
>> On Sun, Jun 3, 2018, 14:55 Martin Long  wrote:
>> 
>>> Davide,
>>> 
>>> I can confirm I also had this problem, and now I've got 6 months of
>> dives
>>> with missing data. The fallback solution looks ideal to me. I hope
>> we're
>>> able to get a build with these changes soon.
>>> 
>>> Martin
>>> 
>> 
>> 
>> Yes Martin.
>> 
>> I also suggest you to check previous dives against Shearwater desktop.
>> As I
>> wrote everything started noticing that po2 samples where completely
>> different. On a 6 meter deco I pushed pO2 at 1.5 /1.6 with an oxygen
>> flush
>> and Subsurface reported 1.7 /1.9 for most of the 6 meter stop.
>> So the problem in your logbook could be worst.
>> 
>> Bye
> ___
> 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: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Anton Lundin]

If Dirk/Linus feels for it, hey can grab the diff and make up a commit message 
and it will be in the next dev build.

I can't really do it because I'm on a diving trip in the baltic, in a storm, 
making good head way on tonights target of getting hammered.

//Anton - skepp åhoj!

On June 4, 2018 9:13:45 AM GMT+02:00, Davide DB  wrote:
>On Sun, Jun 3, 2018, 14:55 Martin Long  wrote:
>
>> Davide,
>>
>> I can confirm I also had this problem, and now I've got 6 months of
>dives
>> with missing data. The fallback solution looks ideal to me. I hope
>we're
>> able to get a build with these changes soon.
>>
>> Martin
>>
>
>
>Yes Martin.
>
>I also suggest you to check previous dives against Shearwater desktop.
>As I
>wrote everything started noticing that po2 samples where completely
>different. On a 6 meter deco I pushed pO2 at 1.5 /1.6 with an oxygen
>flush
>and Subsurface reported 1.7 /1.9 for most of the 6 meter stop.
>So the problem in your logbook could be worst.
>
>Bye
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

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

[Martin Long]

Davide,

I can confirm I also had this problem, and now I've got 6 months of dives
with missing data. The fallback solution looks ideal to me. I hope we're
able to get a build with these changes soon.

Martin

On Fri, 25 May 2018, 18:33 Anton Lundin,  wrote:

> On 25 May, 2018 - Jef Driesen wrote:
>
> > On 25-05-18 16:35, Willem Ferguson wrote:
> > >On 25/05/2018 15:55, Jef Driesen wrote:
> > >>The main disadvantage is that you'll no longer know which type of ppO2
> > >>(sensor or voted/average) you are getting. Especially if you only have
> > >>one sensor.
> > >
> > >I would agree, but at least one gets the calculated pO2 as perceived by
> > >the machine at the time, even though there is no idea about sensor
> > >problems during the dive. It is so much better than having no pO2 data
> > >to evaluate after a dive. This pO2  would still correspond to the data
> > >in the pO2 graph of the Shearwater Desktop software.
> > >
> > >I do not quite get the argument about one sensor? For one sensor there
> > >is no averaging or voting?? I'm not seeing something, so please spell it
> > >out?
> >
> > The average ppO2 is always a single value. But there is often more
> > than one sensor. So you could assume that if you get more than one
> > ppO2 value that they are values from a sensor. But in the case of a
> > single sensor, that doesn't work, and you won't be able to tell
> > which value you got.
> >
> > I'm not sure if the average ppO2 is always equal to the sensor ppO2
> > for the single sensor case. Maybe the dive computer does averaging
> > over several measurements to ignore outliers? (Is simply don't
> > know.)
>
> Any way, its better that we get A value, than no value.
>
> It would be dead simple to emit a SAMPLE_EVENT_STRING, or a
> DC_FIELD_STRING just saying, "hey, these are not the raw ppO2 values you
> where looking for, but the next best thing", if you would have taken
> those patches.
>
>
> //Anton
>
>
> --
> Anton Lundin+46702-161604
> ___
> 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: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Anton Lundin]

On 25 May, 2018 - Jef Driesen wrote:

> On 25-05-18 16:35, Willem Ferguson wrote:
> >On 25/05/2018 15:55, Jef Driesen wrote:
> >>The main disadvantage is that you'll no longer know which type of ppO2
> >>(sensor or voted/average) you are getting. Especially if you only have
> >>one sensor.
> >
> >I would agree, but at least one gets the calculated pO2 as perceived by
> >the machine at the time, even though there is no idea about sensor
> >problems during the dive. It is so much better than having no pO2 data
> >to evaluate after a dive. This pO2  would still correspond to the data
> >in the pO2 graph of the Shearwater Desktop software.
> >
> >I do not quite get the argument about one sensor? For one sensor there
> >is no averaging or voting?? I'm not seeing something, so please spell it
> >out?
> 
> The average ppO2 is always a single value. But there is often more
> than one sensor. So you could assume that if you get more than one
> ppO2 value that they are values from a sensor. But in the case of a
> single sensor, that doesn't work, and you won't be able to tell
> which value you got.
> 
> I'm not sure if the average ppO2 is always equal to the sensor ppO2
> for the single sensor case. Maybe the dive computer does averaging
> over several measurements to ignore outliers? (Is simply don't
> know.)

Any way, its better that we get A value, than no value.

It would be dead simple to emit a SAMPLE_EVENT_STRING, or a
DC_FIELD_STRING just saying, "hey, these are not the raw ppO2 values you
where looking for, but the next best thing", if you would have taken
those patches.


//Anton


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

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

[Jef Driesen]

On 25-05-18 16:35, Willem Ferguson wrote:

On 25/05/2018 15:55, Jef Driesen wrote:

The main disadvantage is that you'll no longer know which type of ppO2
(sensor or voted/average) you are getting. Especially if you only have
one sensor.


I would agree, but at least one gets the calculated pO2 as perceived by
the machine at the time, even though there is no idea about sensor
problems during the dive. It is so much better than having no pO2 data
to evaluate after a dive. This pO2  would still correspond to the data
in the pO2 graph of the Shearwater Desktop software.

I do not quite get the argument about one sensor? For one sensor there
is no averaging or voting?? I'm not seeing something, so please spell it
out?


The average ppO2 is always a single value. But there is often more than one 
sensor. So you could assume that if you get more than one ppO2 value that they 
are values from a sensor. But in the case of a single sensor, that doesn't work, 
and you won't be able to tell which value you got.


I'm not sure if the average ppO2 is always equal to the sensor ppO2 for the 
single sensor case. Maybe the dive computer does averaging over several 
measurements to ignore outliers? (Is simply don't know.)


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

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

[Davide DB]

On Fri, 25 May 2018 at 16:36, Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

> I do not quite get the argument about one sensor? For one sensor there
> is no averaging or voting?? I'm not seeing something, so please spell it
> out?


Me too.
I used to have a pSCR with one sensor and a Petrel handset used as simple
monitor.

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

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

[Willem Ferguson]

On 25/05/2018 15:55, Jef Driesen wrote:

On 2018-05-23 16:47, Anton Lundin wrote:

On 23 May, 2018 - Anton Lundin wrote:
The simple solution is to just emit the average/voted ppO2 when we 
can't

find the calibration values.

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

It should be simple to write.




The main disadvantage is that you'll no longer know which type of ppO2 
(sensor or voted/average) you are getting. Especially if you only have 
one sensor.


Jef
_


I would agree, but at least one gets the calculated pO2 as perceived by 
the machine at the time, even though there is no idea about sensor 
problems during the dive. It is so much better than having no pO2 data 
to evaluate after a dive. This pO2  would still correspond to the data 
in the pO2 graph of the Shearwater Desktop software.


I do not quite get the argument about one sensor? For one sensor there 
is no averaging or voting?? I'm not seeing something, so please spell it 
out?


Kind regards,
willem


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

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

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

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

[Jef Driesen]

On 2018-05-23 16:47, Anton Lundin wrote:

On 23 May, 2018 - Anton Lundin wrote:
The simple solution is to just emit the average/voted ppO2 when we 
can't

find the calibration values.

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

It should be simple to write.


Something simple like:

diff --git i/src/shearwater_predator_parser.c 
w/src/shearwater_predator_parser.c

index dda042c..e5194e8 100644
--- i/src/shearwater_predator_parser.c
+++ w/src/shearwater_predator_parser.c
@@ -669,19 +669,19 @@ shearwater_predator_parser_samples_foreach
(dc_parser_t *abstract, dc_sample_cal
if ((status & OC) == 0) {
// PPO2
if ((status & PPO2_EXTERNAL) == 0) {
-#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->calibration[0];
-   if (callback && (parser->calibrated &
0x01)) callback (DC_SAMPLE_PPO2, sample, userdata);
-
-   sample.ppo2 = data[offset + 14] *
parser->calibration[1];
-   if (callback && (parser->calibrated &
0x02)) callback (DC_SAMPLE_PPO2, sample, userdata);
-
-   sample.ppo2 = data[offset + 15] *
parser->calibration[2];
-   if (callback && (parser->calibrated &
0x04)) callback (DC_SAMPLE_PPO2, sample, userdata);
-#endif
+   if (!parser->calibrated & 0x07) {
+   sample.ppo2 = data[offset + 6] 
/ 100.0;

+   if (callback) callback
(DC_SAMPLE_PPO2, sample, userdata);
+   } else {
+   sample.ppo2 = data[offset +
12] * parser->calibration[0];
+   if (callback &&
(parser->calibrated & 0x01)) callback (DC_SAMPLE_PPO2, sample,
userdata);
+
+   sample.ppo2 = data[offset +
14] * parser->calibration[1];
+   if (callback &&
(parser->calibrated & 0x02)) callback (DC_SAMPLE_PPO2, sample,
userdata);
+
+   sample.ppo2 = data[offset +
15] * parser->calibration[2];
+   if (callback &&
(parser->calibrated & 0x04)) callback (DC_SAMPLE_PPO2, sample,
userdata);
+   }
}

// Setpoint

Should be enough.


The main disadvantage is that you'll no longer know which type of ppO2 
(sensor or voted/average) you are getting. Especially if you only have 
one sensor.


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

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

[Davide DB]

For the records, I updated the original Github issue with the new problema
and latest findings

https://github.com/Subsurface-divelog/subsurface/issues/971

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: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Davide DB]

On Wed, 23 May 2018 at 19:24, Aaron Scheiner  wrote:

> I just tried re-downloading logs from my Petrel 2 using both the current
beta Android app and the current Windows application available for download
(4.7.8) and neither downloaded the PO2 samples.

> So I'm experiencing the same bug :D .

> Aaron

> The libdivecomputer log file ends with the following :
> INFO: Write: size=6, data=FF01020037C0
> INFO: Read: size=1, data=01
> INFO: Read: size=1, data=FF
> INFO: Read: size=1, data=03
> INFO: Read: size=1, data=00
> INFO: Read: size=1, data=77
> INFO: Read: size=1, data=00
> INFO: Read: size=1, data=C0
> INFO: Shearwater log version 7

> WARNING: Disabled all O2 sensors due to a default calibration value. [in
/home/travis/build/Subsurface-divelog/subsurface/libdivecomputer/src/shearwater_predator_parser.c:503
(shearwater_predator_parser_cache)]
> INFO: Write: size=9, data=FF0105002E902000C0

Ok, thanks!

So I'm not the only one.

Regardless of Anton's solution which is fine, Don't you have a contact at
Shearwater to shed some light on this?

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: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Aaron Scheiner]

I just tried re-downloading logs from my Petrel 2 using both the current
beta Android app and the current Windows application available for download
(4.7.8) and neither downloaded the PO2 samples.

So I'm experiencing the same bug :D .

Aaron

The libdivecomputer log file

ends with the following :
INFO: Write: size=6, data=FF01020037C0
INFO: Read: size=1, data=01
INFO: Read: size=1, data=FF
INFO: Read: size=1, data=03
INFO: Read: size=1, data=00
INFO: Read: size=1, data=77
INFO: Read: size=1, data=00
INFO: Read: size=1, data=C0
INFO: Shearwater log version 7

WARNING: Disabled all O2 sensors due to a default calibration value. [in
/home/travis/build/Subsurface-divelog/subsurface/libdivecomputer/src/
shearwater_predator_parser.c:503 (shearwater_predator_parser_cache)]
INFO: Write: size=9, data=FF0105002E902000C0


On Wed, May 23, 2018 at 5:01 PM, Davide DB  wrote:

> Cool, thanks!
> On Wed, 23 May 2018 at 16:58, Aaron Scheiner  wrote:
>
> > Yes, all three sensor values are rendered and they tend towards the set
> point, which is also rendered. They show on both the desktop and Android
> apps (for me).
>
> > I'll be home soon, I'll try downloading them into a clean profile with
> the absolute latest software and see what happens.
>
> > On Wed, May 23, 2018, 16:51 Davide DB  wrote:
>
> >> On Wed, 23 May 2018 at 16:37, Aaron Scheiner 
> wrote:
>
> >> > I have a JJ CCR (2017 CE model) with a Petrel 2 DiveCAN computer
> attached.
>
> >> > I do all my downloads using the Android app (I'm on the beta channel)
> and
> >> I mostly view the data on Linux. I never use the Shearwater desktop
> >> application. I haven't noticed any discrepancies in the data so far.
>
> >> > I'm hoping to dive this weekend, I'll revert back with additional
> >> feedback once I've dived.
>
>
> >> So, regardless of their correctness,  do you confirm that you see pO2
> >> samples in Subsurface?
>
> >> Thanks
>
>
>
> --
> Davide
> https://vimeo.com/bocio/videos
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

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

[Davide DB]

Cool, thanks!
On Wed, 23 May 2018 at 16:58, Aaron Scheiner  wrote:

> Yes, all three sensor values are rendered and they tend towards the set
point, which is also rendered. They show on both the desktop and Android
apps (for me).

> I'll be home soon, I'll try downloading them into a clean profile with
the absolute latest software and see what happens.

> On Wed, May 23, 2018, 16:51 Davide DB  wrote:

>> On Wed, 23 May 2018 at 16:37, Aaron Scheiner  wrote:

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

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

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


>> So, regardless of their correctness,  do you confirm that you see pO2
>> samples in Subsurface?

>> Thanks



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

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

[Aaron Scheiner]

Yes, all three sensor values are rendered and they tend towards the set
point, which is also rendered. They show on both the desktop and Android
apps (for me).

I'll be home soon, I'll try downloading them into a clean profile with the
absolute latest software and see what happens.

On Wed, May 23, 2018, 16:51 Davide DB  wrote:

> On Wed, 23 May 2018 at 16:37, Aaron Scheiner  wrote:
>
> > I have a JJ CCR (2017 CE model) with a Petrel 2 DiveCAN computer
> attached.
>
> > I do all my downloads using the Android app (I'm on the beta channel) and
> I mostly view the data on Linux. I never use the Shearwater desktop
> application. I haven't noticed any discrepancies in the data so far.
>
> > I'm hoping to dive this weekend, I'll revert back with additional
> feedback once I've dived.
>
>
> So, regardless of their correctness,  do you confirm that you see pO2
> samples in Subsurface?
>
> Thanks
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

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

[Davide DB]

On Wed, 23 May 2018 at 16:37, Aaron Scheiner  wrote:

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

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

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


So, regardless of their correctness,  do you confirm that you see pO2
samples in Subsurface?

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

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

[Davide DB]

On Wed, 23 May 2018 at 16:22, Jef Driesen  wrote:

> On 2018-05-23 14:58, Davide DB wrote:
> > On Wed, May 23, 2018, 12:08 Willem Ferguson
> > 
> > wrote:
> >> If this is the case, then the problem should in principle be solvable
> >> and it possibly means that the coding in the dive log is slightly
> >> different from that of the standard Petrel and the Fischer Petrel 2.
> >> The
> >> most knowledgeable person to approach is Jef Driesen but he would need
> >> some specific information from your download. A first approach is to
> >> inspect the .bin dumpfile generated for debug in Subsurface. Then use
> >> his dctool executable (If I remember correctly it can do Bluetooth and
> >> it is extremely flexible) and see if you can trace the pO2 values.
> >>
> >> I am not sure this is what you may want to hear, but assume that (if
> >> you
> >> want the problem solved) you need to take the initiative. You may
> >> possibly be the only person in this circle which has a divecan Petrel
> >> so
> >> you are in the best position to address the problem.
> >>
> >
> > While I do not pretend anything (of course), regarding your questions I
> > can
> > assure you that I made everything I could as end user. I gave
> > - Shearwater desktop screenshots
> > - Shearwater xml exported logs
> > - Subsurface xml logs
> > - Subsurface bin dumps
> > - dctool dump files
> >
> > My only fault was not filing a bug report on Github to resume
> > everything in
> > one place.
> > I even asked on the list if someone else was using a Shearwater Petrel
> > ECCR
> > controller and, maybe experiencing the same behavior. No reply. So I
> > don't
> > know if it's my specific unit or not.
> > BTW I recently updated Petrel firmware to the latest version without
> > results. While it's possible I'm the only Shearwater ccr user on this
> > list,
> > we are speaking of the most common eccr controller on the market
> > nowadays.
> > It's used on countless rebreathers not an obscure dive computer
> > implementation.
> >
> > Everything started months ago when I discovered that pO2 samples
> > reported
> > by Subsurface were completely different (and wrong) from Shearwater
> > desktop.
> > There was a long email thread in which AFAIK no solution was found: my
> > Petrel is strange.
> > Maybe I missed something and Jef or Anton modified something. I don't
> > know
> > but at some point pO2 samples disappeared from Subsurface hence I
> > opened
> > this thread but I'm failing to understand what "default calibration"
> > means
> > and why in my logbook I find the same device listed with random number
> > of
> > sensors.
> > I asked again today because because even a "guy you must die!" reply
> > it's
> > ok but I got no replies at all.

> Sorry for the lack of response, but for the last few weeks, I was just
> too busy with non-libdivecomputer related things.

> Anyway, the problem is as follows. The shearwater devices record two
> different things:

>  1. The average/voted ppO2.

>  2. The value from each O2 sensor. Unfortunately this value is not the
> ppO2 value, but the raw millivolt measurement from the sensor. In order
> to convert this value to a ppO2 value, we need to take into account the
> calibration values.

> Last time I checked, shearwater desktop only shows the average/voted
> ppO2 (#1). It doesn't show the individual ppO2 from each sensor (#2) at
> all (e.g. no millivolt values nor the converted ppO2).

> Now, originally libdivecomputer only reported the average/vote ppO2.
> Later on we figured out how the sensor calibration worked, and this was
> replaced with the ppO2 value from the individual sensors. But afterwards
> we also discovered that some devices (like the one from Davide) don't
> seem to store the calibration values correctly, and leave them at their
> default values (2100). I have no idea why this happens. Anyway, because
> applying those calibration values produces incorrect ppO2 values, I
> added some code to detect this case and disable the ppO2 from the
> sensors. Since the average/voted ppO2 was already disabled earlier, that
> also means you won't get any ppO2 values at all anymore.

> For those bogus default calibration values, there is not much we can do
> about that. Without the (correct) calibration values, we simply can't
> calculate the ppO2 values. So unless the calibration values are for some
> reason stored elsewhere, and we just don't know about this, we're simply
> stuck here. Shearwater desktop doesn't show this info, so it's difficult
> to tell what's going on.

> The only part that we can do something about, is restoring the
> average/voted ppO2 again. That's already on my todo list. But right now
> the libdivecomputer api doesn't have a way to indicate the type of the
> ppO2 value (e.g. average/voted or from an individual sensor), so that
> would cause confusing. So this will require some (backwards
> incompatible) changes, and that's why 

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

[Anton Lundin]

On 23 May, 2018 - Anton Lundin wrote:

> On 23 May, 2018 - Jef Driesen wrote:
> 
> > On 2018-05-23 14:58, Davide DB wrote:
> > >On Wed, May 23, 2018, 12:08 Willem Ferguson
> > >
> > >wrote:
> > >>If this is the case, then the problem should in principle be solvable
> > >>and it possibly means that the coding in the dive log is slightly
> > >>different from that of the standard Petrel and the Fischer
> > >>Petrel 2. The
> > >>most knowledgeable person to approach is Jef Driesen but he would need
> > >>some specific information from your download. A first approach is to
> > >>inspect the .bin dumpfile generated for debug in Subsurface. Then use
> > >>his dctool executable (If I remember correctly it can do Bluetooth and
> > >>it is extremely flexible) and see if you can trace the pO2 values.
> > >>
> > >>I am not sure this is what you may want to hear, but assume that
> > >>(if you
> > >>want the problem solved) you need to take the initiative. You may
> > >>possibly be the only person in this circle which has a divecan
> > >>Petrel so
> > >>you are in the best position to address the problem.
> > >>
> > >
> > >While I do not pretend anything (of course), regarding your
> > >questions I can
> > >assure you that I made everything I could as end user. I gave
> > >- Shearwater desktop screenshots
> > >- Shearwater xml exported logs
> > >- Subsurface xml logs
> > >- Subsurface bin dumps
> > >- dctool dump files
> > >
> > >My only fault was not filing a bug report on Github to resume
> > >everything in
> > >one place.
> > >I even asked on the list if someone else was using a Shearwater
> > >Petrel ECCR
> > >controller and, maybe experiencing the same behavior. No reply. So
> > >I don't
> > >know if it's my specific unit or not.
> > >BTW I recently updated Petrel firmware to the latest version without
> > >results. While it's possible I'm the only Shearwater ccr user on
> > >this list,
> > >we are speaking of the most common eccr controller on the market
> > >nowadays.
> > >It's used on countless rebreathers not an obscure dive computer
> > >implementation.
> > >
> > >Everything started months ago when I discovered that pO2 samples
> > >reported
> > >by Subsurface were completely different (and wrong) from
> > >Shearwater desktop.
> > >There was a long email thread in which AFAIK no solution was found: my
> > >Petrel is strange.
> > >Maybe I missed something and Jef or Anton modified something. I
> > >don't know
> > >but at some point pO2 samples disappeared from Subsurface hence I
> > >opened
> > >this thread but I'm failing to understand what "default
> > >calibration" means
> > >and why in my logbook I find the same device listed with random
> > >number of
> > >sensors.
> > >I asked again today because because even a "guy you must die!"
> > >reply  it's
> > >ok but I got no replies at all.
> > 
> > Sorry for the lack of response, but for the last few weeks, I was
> > just too busy with non-libdivecomputer related things.
> > 
> > Anyway, the problem is as follows. The shearwater devices record two
> > different things:
> > 
> >1. The average/voted ppO2.
> > 
> >2. The value from each O2 sensor. Unfortunately this value is not
> > the ppO2 value, but the raw millivolt measurement from the sensor.
> > In order to convert this value to a ppO2 value, we need to take into
> > account the calibration values.
> > 
> > Last time I checked, shearwater desktop only shows the average/voted
> > ppO2 (#1). It doesn't show the individual ppO2 from each sensor (#2)
> > at all (e.g. no millivolt values nor the converted ppO2).
> > 
> > Now, originally libdivecomputer only reported the average/vote ppO2.
> > Later on we figured out how the sensor calibration worked, and this
> > was replaced with the ppO2 value from the individual sensors. But
> > afterwards we also discovered that some devices (like the one from
> > Davide) don't seem to store the calibration values correctly, and
> > leave them at their default values (2100). I have no idea why this
> > happens. Anyway, because applying those calibration values produces
> > incorrect ppO2 values, I added some code to detect this case and
> > disable the ppO2 from the sensors. Since the average/voted ppO2 was
> > already disabled earlier, that also means you won't get any ppO2
> > values at all anymore.
> > 
> > For those bogus default calibration values, there is not much we can
> > do about that. Without the (correct) calibration values, we simply
> > can't calculate the ppO2 values. So unless the calibration values
> > are for some reason stored elsewhere, and we just don't know about
> > this, we're simply stuck here. Shearwater desktop doesn't show this
> > info, so it's difficult to tell what's going on.
> > 
> > The only part that we can do something about, is restoring the
> > average/voted ppO2 again. That's already on my todo list. But right
> > now the libdivecomputer api doesn't have a way to indicate the type
> > of the 

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

[Anton Lundin]

On 23 May, 2018 - Jef Driesen wrote:

> On 2018-05-23 14:58, Davide DB wrote:
> >On Wed, May 23, 2018, 12:08 Willem Ferguson
> >
> >wrote:
> >>If this is the case, then the problem should in principle be solvable
> >>and it possibly means that the coding in the dive log is slightly
> >>different from that of the standard Petrel and the Fischer
> >>Petrel 2. The
> >>most knowledgeable person to approach is Jef Driesen but he would need
> >>some specific information from your download. A first approach is to
> >>inspect the .bin dumpfile generated for debug in Subsurface. Then use
> >>his dctool executable (If I remember correctly it can do Bluetooth and
> >>it is extremely flexible) and see if you can trace the pO2 values.
> >>
> >>I am not sure this is what you may want to hear, but assume that
> >>(if you
> >>want the problem solved) you need to take the initiative. You may
> >>possibly be the only person in this circle which has a divecan
> >>Petrel so
> >>you are in the best position to address the problem.
> >>
> >
> >While I do not pretend anything (of course), regarding your
> >questions I can
> >assure you that I made everything I could as end user. I gave
> >- Shearwater desktop screenshots
> >- Shearwater xml exported logs
> >- Subsurface xml logs
> >- Subsurface bin dumps
> >- dctool dump files
> >
> >My only fault was not filing a bug report on Github to resume
> >everything in
> >one place.
> >I even asked on the list if someone else was using a Shearwater
> >Petrel ECCR
> >controller and, maybe experiencing the same behavior. No reply. So
> >I don't
> >know if it's my specific unit or not.
> >BTW I recently updated Petrel firmware to the latest version without
> >results. While it's possible I'm the only Shearwater ccr user on
> >this list,
> >we are speaking of the most common eccr controller on the market
> >nowadays.
> >It's used on countless rebreathers not an obscure dive computer
> >implementation.
> >
> >Everything started months ago when I discovered that pO2 samples
> >reported
> >by Subsurface were completely different (and wrong) from
> >Shearwater desktop.
> >There was a long email thread in which AFAIK no solution was found: my
> >Petrel is strange.
> >Maybe I missed something and Jef or Anton modified something. I
> >don't know
> >but at some point pO2 samples disappeared from Subsurface hence I
> >opened
> >this thread but I'm failing to understand what "default
> >calibration" means
> >and why in my logbook I find the same device listed with random
> >number of
> >sensors.
> >I asked again today because because even a "guy you must die!"
> >reply  it's
> >ok but I got no replies at all.
> 
> Sorry for the lack of response, but for the last few weeks, I was
> just too busy with non-libdivecomputer related things.
> 
> Anyway, the problem is as follows. The shearwater devices record two
> different things:
> 
>1. The average/voted ppO2.
> 
>2. The value from each O2 sensor. Unfortunately this value is not
> the ppO2 value, but the raw millivolt measurement from the sensor.
> In order to convert this value to a ppO2 value, we need to take into
> account the calibration values.
> 
> Last time I checked, shearwater desktop only shows the average/voted
> ppO2 (#1). It doesn't show the individual ppO2 from each sensor (#2)
> at all (e.g. no millivolt values nor the converted ppO2).
> 
> Now, originally libdivecomputer only reported the average/vote ppO2.
> Later on we figured out how the sensor calibration worked, and this
> was replaced with the ppO2 value from the individual sensors. But
> afterwards we also discovered that some devices (like the one from
> Davide) don't seem to store the calibration values correctly, and
> leave them at their default values (2100). I have no idea why this
> happens. Anyway, because applying those calibration values produces
> incorrect ppO2 values, I added some code to detect this case and
> disable the ppO2 from the sensors. Since the average/voted ppO2 was
> already disabled earlier, that also means you won't get any ppO2
> values at all anymore.
> 
> For those bogus default calibration values, there is not much we can
> do about that. Without the (correct) calibration values, we simply
> can't calculate the ppO2 values. So unless the calibration values
> are for some reason stored elsewhere, and we just don't know about
> this, we're simply stuck here. Shearwater desktop doesn't show this
> info, so it's difficult to tell what's going on.
> 
> The only part that we can do something about, is restoring the
> average/voted ppO2 again. That's already on my todo list. But right
> now the libdivecomputer api doesn't have a way to indicate the type
> of the ppO2 value (e.g. average/voted or from an individual sensor),
> so that would cause confusing. So this will require some (backwards
> incompatible) changes, and that's why it's not done yet.

The simple solution is to just emit the average/voted ppO2 when 

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

[Aaron Scheiner]

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

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

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

Sorry for not responding sooner.

Aaron


On Wed, May 23, 2018 at 4:22 PM, Jef Driesen 
wrote:

> On 2018-05-23 14:58, Davide DB wrote:
>
>> On Wed, May 23, 2018, 12:08 Willem Ferguson <
>> willemfergu...@zoology.up.ac.za>
>> wrote:
>>
>>> If this is the case, then the problem should in principle be solvable
>>> and it possibly means that the coding in the dive log is slightly
>>> different from that of the standard Petrel and the Fischer Petrel 2. The
>>> most knowledgeable person to approach is Jef Driesen but he would need
>>> some specific information from your download. A first approach is to
>>> inspect the .bin dumpfile generated for debug in Subsurface. Then use
>>> his dctool executable (If I remember correctly it can do Bluetooth and
>>> it is extremely flexible) and see if you can trace the pO2 values.
>>>
>>> I am not sure this is what you may want to hear, but assume that (if you
>>> want the problem solved) you need to take the initiative. You may
>>> possibly be the only person in this circle which has a divecan Petrel so
>>> you are in the best position to address the problem.
>>>
>>>
>> While I do not pretend anything (of course), regarding your questions I
>> can
>> assure you that I made everything I could as end user. I gave
>> - Shearwater desktop screenshots
>> - Shearwater xml exported logs
>> - Subsurface xml logs
>> - Subsurface bin dumps
>> - dctool dump files
>>
>> My only fault was not filing a bug report on Github to resume everything
>> in
>> one place.
>> I even asked on the list if someone else was using a Shearwater Petrel
>> ECCR
>> controller and, maybe experiencing the same behavior. No reply. So I don't
>> know if it's my specific unit or not.
>> BTW I recently updated Petrel firmware to the latest version without
>> results. While it's possible I'm the only Shearwater ccr user on this
>> list,
>> we are speaking of the most common eccr controller on the market nowadays.
>> It's used on countless rebreathers not an obscure dive computer
>> implementation.
>>
>> Everything started months ago when I discovered that pO2 samples reported
>> by Subsurface were completely different (and wrong) from Shearwater
>> desktop.
>> There was a long email thread in which AFAIK no solution was found: my
>> Petrel is strange.
>> Maybe I missed something and Jef or Anton modified something. I don't know
>> but at some point pO2 samples disappeared from Subsurface hence I opened
>> this thread but I'm failing to understand what "default calibration" means
>> and why in my logbook I find the same device listed with random number of
>> sensors.
>> I asked again today because because even a "guy you must die!" reply  it's
>> ok but I got no replies at all.
>>
>
> Sorry for the lack of response, but for the last few weeks, I was just too
> busy with non-libdivecomputer related things.
>
> Anyway, the problem is as follows. The shearwater devices record two
> different things:
>
>1. The average/voted ppO2.
>
>2. The value from each O2 sensor. Unfortunately this value is not the
> ppO2 value, but the raw millivolt measurement from the sensor. In order to
> convert this value to a ppO2 value, we need to take into account the
> calibration values.
>
> Last time I checked, shearwater desktop only shows the average/voted ppO2
> (#1). It doesn't show the individual ppO2 from each sensor (#2) at all
> (e.g. no millivolt values nor the converted ppO2).
>
> Now, originally libdivecomputer only reported the average/vote ppO2. Later
> on we figured out how the sensor calibration worked, and this was replaced
> with the ppO2 value from the individual sensors. But afterwards we also
> discovered that some devices (like the one from Davide) don't seem to store
> the calibration values correctly, and leave them at their default values
> (2100). I have no idea why this happens. Anyway, because applying those
> calibration values produces incorrect ppO2 values, I added some code to
> detect this case and disable the ppO2 from the sensors. Since the
> average/voted ppO2 was already disabled earlier, that also means you won't
> get any ppO2 values at all anymore.
>
> For those bogus default calibration values, there is not much we can do
> about that. Without the (correct) calibration values, we simply can't
> calculate the ppO2 values. So unless the calibration values are for some
> reason stored elsewhere, and we just don't know about this, we're simply
> stuck here. Shearwater desktop doesn't show this info, so it's difficult to
> tell what's going on.
>
> The only part that we can do something about, 

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

[Jef Driesen]

On 2018-05-23 14:58, Davide DB wrote:
On Wed, May 23, 2018, 12:08 Willem Ferguson 


wrote:

If this is the case, then the problem should in principle be solvable
and it possibly means that the coding in the dive log is slightly
different from that of the standard Petrel and the Fischer Petrel 2. 
The

most knowledgeable person to approach is Jef Driesen but he would need
some specific information from your download. A first approach is to
inspect the .bin dumpfile generated for debug in Subsurface. Then use
his dctool executable (If I remember correctly it can do Bluetooth and
it is extremely flexible) and see if you can trace the pO2 values.

I am not sure this is what you may want to hear, but assume that (if 
you

want the problem solved) you need to take the initiative. You may
possibly be the only person in this circle which has a divecan Petrel 
so

you are in the best position to address the problem.



While I do not pretend anything (of course), regarding your questions I 
can

assure you that I made everything I could as end user. I gave
- Shearwater desktop screenshots
- Shearwater xml exported logs
- Subsurface xml logs
- Subsurface bin dumps
- dctool dump files

My only fault was not filing a bug report on Github to resume 
everything in

one place.
I even asked on the list if someone else was using a Shearwater Petrel 
ECCR
controller and, maybe experiencing the same behavior. No reply. So I 
don't

know if it's my specific unit or not.
BTW I recently updated Petrel firmware to the latest version without
results. While it's possible I'm the only Shearwater ccr user on this 
list,
we are speaking of the most common eccr controller on the market 
nowadays.

It's used on countless rebreathers not an obscure dive computer
implementation.

Everything started months ago when I discovered that pO2 samples 
reported
by Subsurface were completely different (and wrong) from Shearwater 
desktop.

There was a long email thread in which AFAIK no solution was found: my
Petrel is strange.
Maybe I missed something and Jef or Anton modified something. I don't 
know
but at some point pO2 samples disappeared from Subsurface hence I 
opened
this thread but I'm failing to understand what "default calibration" 
means
and why in my logbook I find the same device listed with random number 
of

sensors.
I asked again today because because even a "guy you must die!" reply  
it's

ok but I got no replies at all.


Sorry for the lack of response, but for the last few weeks, I was just 
too busy with non-libdivecomputer related things.


Anyway, the problem is as follows. The shearwater devices record two 
different things:


   1. The average/voted ppO2.

   2. The value from each O2 sensor. Unfortunately this value is not the 
ppO2 value, but the raw millivolt measurement from the sensor. In order 
to convert this value to a ppO2 value, we need to take into account the 
calibration values.


Last time I checked, shearwater desktop only shows the average/voted 
ppO2 (#1). It doesn't show the individual ppO2 from each sensor (#2) at 
all (e.g. no millivolt values nor the converted ppO2).


Now, originally libdivecomputer only reported the average/vote ppO2. 
Later on we figured out how the sensor calibration worked, and this was 
replaced with the ppO2 value from the individual sensors. But afterwards 
we also discovered that some devices (like the one from Davide) don't 
seem to store the calibration values correctly, and leave them at their 
default values (2100). I have no idea why this happens. Anyway, because 
applying those calibration values produces incorrect ppO2 values, I 
added some code to detect this case and disable the ppO2 from the 
sensors. Since the average/voted ppO2 was already disabled earlier, that 
also means you won't get any ppO2 values at all anymore.


For those bogus default calibration values, there is not much we can do 
about that. Without the (correct) calibration values, we simply can't 
calculate the ppO2 values. So unless the calibration values are for some 
reason stored elsewhere, and we just don't know about this, we're simply 
stuck here. Shearwater desktop doesn't show this info, so it's difficult 
to tell what's going on.


The only part that we can do something about, is restoring the 
average/voted ppO2 again. That's already on my todo list. But right now 
the libdivecomputer api doesn't have a way to indicate the type of the 
ppO2 value (e.g. average/voted or from an individual sensor), so that 
would cause confusing. So this will require some (backwards 
incompatible) changes, and that's why it's not done yet.


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

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

[Davide DB]

On Wed, May 23, 2018, 12:08 Willem Ferguson 
wrote:

Hi Willem,

Thank you for the kind reply. I will try to explain me again


> Davide,
>
> Does the correct pO2 show on the Shearwater download software (i.e. the
> Shearwater Desktop)?. This means that the data are correctly reported,
> not a default calibration value as currently with Subsurface.
>
>
Yes,
Everything is ok using the Shearwater software to download dives.
pO2 samples are there and they are correct. I know it for sure because in a
couple of dives I had the time to make oxygen and diluent flushes during my
long deco taking note of dive time and values.
Later I could find those values on Shearwater desktop.


> If this is the case, then the problem should in principle be solvable
> and it possibly means that the coding in the dive log is slightly
> different from that of the standard Petrel and the Fischer Petrel 2. The
> most knowledgeable person to approach is Jef Driesen but he would need
> some specific information from your download. A first approach is to
> inspect the .bin dumpfile generated for debug in Subsurface. Then use
> his dctool executable (If I remember correctly it can do Bluetooth and
> it is extremely flexible) and see if you can trace the pO2 values.
>
> I am not sure this is what you may want to hear, but assume that (if you
> want the problem solved) you need to take the initiative. You may
> possibly be the only person in this circle which has a divecan Petrel so
> you are in the best position to address the problem.
>

While I do not pretend anything (of course), regarding your questions I can
assure you that I made everything I could as end user. I gave
- Shearwater desktop screenshots
- Shearwater xml exported logs
- Subsurface xml logs
- Subsurface bin dumps
- dctool dump files

My only fault was not filing a bug report on Github to resume everything in
one place.
I even asked on the list if someone else was using a Shearwater Petrel ECCR
controller and, maybe experiencing the same behavior. No reply. So I don't
know if it's my specific unit or not.
BTW I recently updated Petrel firmware to the latest version without
results. While it's possible I'm the only Shearwater ccr user on this list,
we are speaking of the most common eccr controller on the market nowadays.
It's used on countless rebreathers not an obscure dive computer
implementation.

Everything started months ago when I discovered that pO2 samples reported
by Subsurface were completely different (and wrong) from Shearwater desktop.
There was a long email thread in which AFAIK no solution was found: my
Petrel is strange.
Maybe I missed something and Jef or Anton modified something. I don't know
but at some point pO2 samples disappeared from Subsurface hence I opened
this thread but I'm failing to understand what "default calibration" means
and why in my logbook I find the same device listed with random number of
sensors.
I asked again today because because even a "guy you must die!" reply  it's
ok but I got no replies at all.

Bye

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

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

[Willem Ferguson]

Davide,

I forgot to mention that my understanding is that the Petrel provides a 
voltage, not a pO2 value and that this voltage is converted to a pO2 
value in the Shearwater Desktop or in Subsurface. You possibly may have 
to find the calibration value(s) as well as the voltages in order to 
calulate the pO2.

Kind regards,
willem


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

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

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

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

[Willem Ferguson]

On 23/05/2018 11:01, Davide DB wrote:

Hi guys,

Is there any chance that one day it will be possible to see O2 sample on a
CCR dive?

--
Davide


Davide,

Does the correct pO2 show on the Shearwater download software (i.e. the 
Shearwater Desktop)?. This means that the data are correctly reported, 
not a default calibration value as currently with Subsurface.


If this is the case, then the problem should in principle be solvable 
and it possibly means that the coding in the dive log is slightly 
different from that of the standard Petrel and the Fischer Petrel 2. The 
most knowledgeable person to approach is Jef Driesen but he would need 
some specific information from your download. A first approach is to 
inspect the .bin dumpfile generated for debug in Subsurface. Then use 
his dctool executable (If I remember correctly it can do Bluetooth and 
it is extremely flexible) and see if you can trace the pO2 values.


I am not sure this is what you may want to hear, but assume that (if you 
want the problem solved) you need to take the initiative. You may 
possibly be the only person in this circle which has a divecan Petrel so 
you are in the best position to address the problem.


Kind regards,

willem



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

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

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

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

[Davide DB]

Hi guys,

Is there any chance that one day it will be possible to see O2 sample on a
CCR dive?
On Thu, 10 May 2018 at 22:48, Davide DB  wrote:

> On Thu, 3 May 2018 at 21:39, Davide DB  wrote:

> > On Thu, 3 May 2018 at 18:52, Anton Lundin  wrote:

> >> On 03 May, 2018 - Davide DB wrote:

> >> > On Thu, 3 May 2018 at 13:15, Anton Lundin  wrote:
> >> >
> >> > > On 03 May, 2018 - Davide DB wrote:
> >> > >
> >> > > > On Wed, 2 May 2018 at 11:04, Anton Lundin 
> wrote:
> >> > > >
> >> > > > >
> >> > > > > Try to download them into a fresh logbook with the current
> desktop
> >> > > > > version, to see what's happens then.
> >> > > > >
> >> > > >
> >> > > > I've just downloaded my dives on a fresh Win10 4.7.8
installation.
> >> > > > As usual after few dives my Petrel quits with "error sending
packet
> >> > > error".
> >> > > > I saved some of them anyway and PO2 values are missing.
> >> > > > This is how the petrel controller is recognized. File is
attached.
> >> > > >
> >> > > >  >> > > > diveid='2e7067fb' dctype='CCR'>
> >> > > >
> >> > > > There's no mention of O2 sensor.
> >> > > >
> >> > > > These are all different pertel descriptions of the very same dive
> >> > > computer
> >> > > > I found in my original logbook
> >> > > >
> >> > > >  >> > > > diveid='3db7eb77' dctype='CCR' no_o2sensors='1'>
> >> > > >  >> > > > diveid='52d4ba3e' dctype='CCR' no_o2sensors='3'>
> >> > > >  >> > > > diveid='a6e05a10' dctype='CCR'>
> >> > > >  >> > > > diveid='3db24900' dctype='CCR'>
> >> > > >
> >> > > > Were pO2 samples download removed?
> >> > >
> >> > > This is probably because we can't find any calibration values in
your
> >> > > computer. Did you get a warning:
> >> > > "Disabled all O2 sensors due to a default calibration value." ?
> >> > >
> >> > > I think the code should fall back to the sensor average po2 when we
> >> > > won't get calibration values for the sensors, but we're not doing
> that
> >> > > right now.
> >> > >
> >> >
> >> > Anton,
> >> >
> >> > I'm not crazy enough to dive a rebreather without a proper
calibration.
> >> > Everything is ok on my unit. Cells are new and get calibrated before
> every
> >> > dive.

> >> Shure. The computer is probably properly calibrated, but the
> >> calibration values found in the memory of the computer are the default
> >> ones. Without those we can't convert the mV values to po2 values.

> >> The cal values might be there somewhere, but we don't know where.

> >> We can't emit the raw mV values, because neither libdivecomputer nor
> >> subsurface supports mV values.

> >> > I tried to download again from Shearwater desktop and everything is
> there:
> >> > pO2 and mV samples. I've never updated my Petrel since we found that
> >> > Subsurface pO2 values were completely wrong so I guess it should be
> some
> >> > bug arose lately.
> >> > It's sad nobody else (ccr users) replied to my feedback request when
I
> >> > noted the pO2 discrepancy. I cannot believe I'm the only one on this
> list
> >> > using a ccr unit whit a divecan shearwater controller.
> >> >  When I realized pO2 were missing I thought it was something related
> to the
> >> > mobile download but it's not.
> >> >
> >> > I would do a full Subsurface download but I drained another battery
> but I
> >> > do not have a new one around ATM.

> >> We should at least emit the per sample average, when we can't emit the
> >> individual sensor values.

> >> Best would be if we could emit both the "true" average po2 and the
> >> individual sensor values. Unfortunately the interface doesn't support
> >> that distinction.


> > I changed battery and downloaded again with subsurface 4.7.8 desktop
> saving the libdivecomputer log file.
> > I quit the download before getting errors and draining my battery.
> > At the end of the libdivecomputer file I find:

> > WARNING: Disabled all O2 sensors due to a default calibration value. [in

/home/travis/build/Subsurface-divelog/subsurface/libdivecomputer/src/shearwater_predator_parser.c:503
> (shearwater_predator_parser_cache)]
> > INFO: Write: size=9, data=FF0105002E902000C0

> > Exactly the problem mentioned by Anton.

> > Could someone explain me what does it means?
> > Is it a way to avoid displaying wrong pO2 samples due to the previous
> problem?
> > What can I do? Is it my fault? Is my Petrel defective?

> > Why in my logbook I find 4 different computer names with different
> attributes if my unit is always the same?

> > 
> diveid='3db7eb77' dctype='CCR' no_o2sensors='1'>
> > 
> diveid='52d4ba3e' dctype='CCR' no_o2sensors='3'>
> > 
> diveid='a6e05a10' dctype='CCR'>
> > 
> diveid='3db24900' dctype='CCR'>

> > Are those differences due to subsurface history reason?

> > Thank you in advance

> > --
> > Davide
> > https://vimeo.com/bocio/videos



> Thank you guys

> --
> Davide



-- 
Davide
https://vimeo.com/bocio/videos
___

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

[Davide DB]

On Thu, 3 May 2018 at 18:52, Anton Lundin  wrote:

> On 03 May, 2018 - Davide DB wrote:
>
> > On Thu, 3 May 2018 at 13:15, Anton Lundin  wrote:
> >
> > > On 03 May, 2018 - Davide DB wrote:
> > >
> > > > On Wed, 2 May 2018 at 11:04, Anton Lundin  wrote:
> > > >
> > > > >
> > > > > Try to download them into a fresh logbook with the current desktop
> > > > > version, to see what's happens then.
> > > > >
> > > >
> > > > I've just downloaded my dives on a fresh Win10 4.7.8 installation.
> > > > As usual after few dives my Petrel quits with "error sending packet
> > > error".
> > > > I saved some of them anyway and PO2 values are missing.
> > > > This is how the petrel controller is recognized. File is attached.
> > > >
> > > >  > > > diveid='2e7067fb' dctype='CCR'>
> > > >
> > > > There's no mention of O2 sensor.
> > > >
> > > > These are all different pertel descriptions of the very same dive
> > > computer
> > > > I found in my original logbook
> > > >
> > > >  > > > diveid='3db7eb77' dctype='CCR' no_o2sensors='1'>
> > > >  > > > diveid='52d4ba3e' dctype='CCR' no_o2sensors='3'>
> > > >  > > > diveid='a6e05a10' dctype='CCR'>
> > > >  > > > diveid='3db24900' dctype='CCR'>
> > > >
> > > > Were pO2 samples download removed?
> > >
> > > This is probably because we can't find any calibration values in your
> > > computer. Did you get a warning:
> > > "Disabled all O2 sensors due to a default calibration value." ?
> > >
> > > I think the code should fall back to the sensor average po2 when we
> > > won't get calibration values for the sensors, but we're not doing that
> > > right now.
> > >
> >
> > Anton,
> >
> > I'm not crazy enough to dive a rebreather without a proper calibration.
> > Everything is ok on my unit. Cells are new and get calibrated before
> every
> > dive.
>
> Shure. The computer is probably properly calibrated, but the
> calibration values found in the memory of the computer are the default
> ones. Without those we can't convert the mV values to po2 values.
>
> The cal values might be there somewhere, but we don't know where.
>
> We can't emit the raw mV values, because neither libdivecomputer nor
> subsurface supports mV values.
>
> > I tried to download again from Shearwater desktop and everything is
> there:
> > pO2 and mV samples. I've never updated my Petrel since we found that
> > Subsurface pO2 values were completely wrong so I guess it should be some
> > bug arose lately.
> > It's sad nobody else (ccr users) replied to my feedback request when I
> > noted the pO2 discrepancy. I cannot believe I'm the only one on this list
> > using a ccr unit whit a divecan shearwater controller.
> >  When I realized pO2 were missing I thought it was something related to
> the
> > mobile download but it's not.
> >
> > I would do a full Subsurface download but I drained another battery but I
> > do not have a new one around ATM.
>
> We should at least emit the per sample average, when we can't emit the
> individual sensor values.
>
> Best would be if we could emit both the "true" average po2 and the
> individual sensor values. Unfortunately the interface doesn't support
> that distinction.
>
>
I changed battery and downloaded again with subsurface 4.7.8 desktop saving
the libdivecomputer log file.
I quit the download before getting errors and draining my battery.
At the end of the libdivecomputer file I find:

WARNING: Disabled all O2 sensors due to a default calibration value. [in
/home/travis/build/Subsurface-divelog/subsurface/libdivecomputer/src/shearwater_predator_parser.c:503
(shearwater_predator_parser_cache)]
INFO: Write: size=9, data=FF0105002E902000C0

Exactly the problem mentioned by Anton.

Could someone explain me what does it means?
Is it a way to avoid displaying wrong pO2 samples due to the previous
problem?
What can I do? Is it my fault? Is my Petrel defective?

Why in my logbook I find 4 different computer names with different
attributes if my unit is always the same?


diveid='3db7eb77' dctype='CCR' no_o2sensors='1'>

diveid='52d4ba3e' dctype='CCR' no_o2sensors='3'>

diveid='a6e05a10' dctype='CCR'>

diveid='3db24900' dctype='CCR'>

Are those differences due to subsurface history reason?

Thank you in advance

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

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

[Anton Lundin]

On 03 May, 2018 - Davide DB wrote:

> On Thu, 3 May 2018 at 13:15, Anton Lundin  wrote:
> 
> > On 03 May, 2018 - Davide DB wrote:
> >
> > > On Wed, 2 May 2018 at 11:04, Anton Lundin  wrote:
> > >
> > > >
> > > > Try to download them into a fresh logbook with the current desktop
> > > > version, to see what's happens then.
> > > >
> > >
> > > I've just downloaded my dives on a fresh Win10 4.7.8 installation.
> > > As usual after few dives my Petrel quits with "error sending packet
> > error".
> > > I saved some of them anyway and PO2 values are missing.
> > > This is how the petrel controller is recognized. File is attached.
> > >
> > >  > > diveid='2e7067fb' dctype='CCR'>
> > >
> > > There's no mention of O2 sensor.
> > >
> > > These are all different pertel descriptions of the very same dive
> > computer
> > > I found in my original logbook
> > >
> > >  > > diveid='3db7eb77' dctype='CCR' no_o2sensors='1'>
> > >  > > diveid='52d4ba3e' dctype='CCR' no_o2sensors='3'>
> > >  > > diveid='a6e05a10' dctype='CCR'>
> > >  > > diveid='3db24900' dctype='CCR'>
> > >
> > > Were pO2 samples download removed?
> >
> > This is probably because we can't find any calibration values in your
> > computer. Did you get a warning:
> > "Disabled all O2 sensors due to a default calibration value." ?
> >
> > I think the code should fall back to the sensor average po2 when we
> > won't get calibration values for the sensors, but we're not doing that
> > right now.
> >
> 
> Anton,
> 
> I'm not crazy enough to dive a rebreather without a proper calibration.
> Everything is ok on my unit. Cells are new and get calibrated before every
> dive.

Shure. The computer is probably properly calibrated, but the
calibration values found in the memory of the computer are the default
ones. Without those we can't convert the mV values to po2 values.

The cal values might be there somewhere, but we don't know where.

We can't emit the raw mV values, because neither libdivecomputer nor
subsurface supports mV values.
 
> I tried to download again from Shearwater desktop and everything is there:
> pO2 and mV samples. I've never updated my Petrel since we found that
> Subsurface pO2 values were completely wrong so I guess it should be some
> bug arose lately.
> It's sad nobody else (ccr users) replied to my feedback request when I
> noted the pO2 discrepancy. I cannot believe I'm the only one on this list
> using a ccr unit whit a divecan shearwater controller.
>  When I realized pO2 were missing I thought it was something related to the
> mobile download but it's not.
> 
> I would do a full Subsurface download but I drained another battery but I
> do not have a new one around ATM.

We should at least emit the per sample average, when we can't emit the
individual sensor values.

Best would be if we could emit both the "true" average po2 and the
individual sensor values. Unfortunately the interface doesn't support
that distinction.


//Anton


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

Re: 4.7.8: a couple of questions

[Anton Lundin]

On 03 May, 2018 - Davide DB wrote:

> On Wed, 2 May 2018 at 11:04, Anton Lundin  wrote:
> 
> >
> > Try to download them into a fresh logbook with the current desktop
> > version, to see what's happens then.
> >
> 
> I've just downloaded my dives on a fresh Win10 4.7.8 installation.
> As usual after few dives my Petrel quits with "error sending packet error".
> I saved some of them anyway and PO2 values are missing.
> This is how the petrel controller is recognized. File is attached.
> 
>  diveid='2e7067fb' dctype='CCR'>
> 
> There's no mention of O2 sensor.
> 
> These are all different pertel descriptions of the very same dive computer
> I found in my original logbook
> 
>  diveid='3db7eb77' dctype='CCR' no_o2sensors='1'>
>  diveid='52d4ba3e' dctype='CCR' no_o2sensors='3'>
>  diveid='a6e05a10' dctype='CCR'>
>  diveid='3db24900' dctype='CCR'>
> 
> Were pO2 samples download removed?

This is probably because we can't find any calibration values in your
computer. Did you get a warning:
"Disabled all O2 sensors due to a default calibration value." ?

I think the code should fall back to the sensor average po2 when we
won't get calibration values for the sensors, but we're not doing that
right now.


//Anton


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

Re: 4.7.8: a couple of questions

[Davide DB]

On Wed, 2 May 2018 at 13:19, Anton Lundin  wrote:

> On 02 May, 2018 - Davide DB wrote:
>
> > On Wed, 2 May 2018 at 11:04, Anton Lundin  wrote:
> >
> > > > > What's happening when you're trying to merge them?
> > > > >
> > > >
> > > > The second dive (#175) disappear but the first dive remain
> unaffected (47
> > > > minutes).
> > >
> > > Can you export those two dives into a separate xml file and provide
> that
> > > for debugging?
> > >
> > > Are those two from the same dive computer, or are they from different?
> > > It might be that they get merged as two different dive computers on the
> > > same dive.
> > >
> >
> > Yes the same petrel controller of mine. A classic training session: dive
> -
> > quick debrief on the surface - dive again.
> > I exported them in this new file and I tried again with a Win desktop
> 4.7.8
> > and I get the same behaviour: the most recent dive disappears and the
> first
> > dive remains unaffected.
> > The file is attached.
> >
> > Thanks for looking into this.
>
> Ok, here's your problem:
>  serial='39117da9' firmware='38'/>
>  serial='39117da9' firmware='38'/>
>
>
> In one of the dives the computer is called "Shearwater Petrel" and in
> the other one its called "Shearwater Petrel 2". That causes the "merge"
> to be done as its two different computers that recorded the same dive.
>
> If i hack up the log file and change so both of them have the same name,
> they merge just fine.
>
>
> I guess that this name came from what model you selected during the
> download of the dives.
>
>
Ouch! Thanks.
I didn't notice the name because I was looking at deviceid instead. What's
the difference between model and id? Deviceid seems more reliable because
stays the same across the entire logbook.
Given that I miss pO2 samples too I will download everything from scratch
in one shot from desktop.

BTW this finding lead me to another question... I don't know if this could
be related to pO2 samples missing too.
During these months I made several download tests among BT legacy, BLE and
so on but I always had the same Petrel 2 since I bought my SF2 unit.
Looking into my logbook I find 4 different computers (deviceid it's the
same):






Where these differences originate from?
I even have a petrel 2 with one O2 sensor :(

Bye

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

Re: 4.7.8: a couple of questions

[Anton Lundin]

On 02 May, 2018 - Davide DB wrote:

> On Wed, 2 May 2018 at 11:04, Anton Lundin  wrote:
> 
> > > > What's happening when you're trying to merge them?
> > > >
> > >
> > > The second dive (#175) disappear but the first dive remain unaffected (47
> > > minutes).
> >
> > Can you export those two dives into a separate xml file and provide that
> > for debugging?
> >
> > Are those two from the same dive computer, or are they from different?
> > It might be that they get merged as two different dive computers on the
> > same dive.
> >
> 
> Yes the same petrel controller of mine. A classic training session: dive -
> quick debrief on the surface - dive again.
> I exported them in this new file and I tried again with a Win desktop 4.7.8
> and I get the same behaviour: the most recent dive disappears and the first
> dive remains unaffected.
> The file is attached.
> 
> Thanks for looking into this.

Ok, here's your problem:




In one of the dives the computer is called "Shearwater Petrel" and in
the other one its called "Shearwater Petrel 2". That causes the "merge"
to be done as its two different computers that recorded the same dive.

If i hack up the log file and change so both of them have the same name,
they merge just fine.


I guess that this name came from what model you selected during the
download of the dives.


//Anton


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

Re: 4.7.8: a couple of questions

[Davide DB]

On Wed, 2 May 2018 at 11:04, Anton Lundin  wrote:

>
> Try to download them into a fresh logbook with the current desktop
> version, to see what's happens then.
>

I will do tonight



> > > - I merged some dives made during a ccr training. I cannot merge two of
> > > > them. There are about 11 minutes between them. Is there a time limit
> for
> > > > merging?
> > >
> > > It's not 11 minutes between those two, its 58 minutes.
> > >
> > > There's a warning if you're trying to merge dives with more than 30
> > > minutes between them.
> > >
> >
> > If I'm correct the first dive last 47 minutes hence from 3:54 PM + 47' I
> > surfaced at 4:41 PM then after a briefing of 11 minutes I went down again
> > at 4:52 PM for 13 minutes.
>
> Sorry, I can't read today.
>
> > > What's happening when you're trying to merge them?
> > >
> >
> > The second dive (#175) disappear but the first dive remain unaffected (47
> > minutes).
>
> Can you export those two dives into a separate xml file and provide that
> for debugging?
>
> Are those two from the same dive computer, or are they from different?
> It might be that they get merged as two different dive computers on the
> same dive.
>

Yes the same petrel controller of mine. A classic training session: dive -
quick debrief on the surface - dive again.
I exported them in this new file and I tried again with a Win desktop 4.7.8
and I get the same behaviour: the most recent dive disappears and the first
dive remains unaffected.
The file is attached.

Thanks for looking into this.

-- 
Davide
https://vimeo.com/bocio/videos


dives-to-be-merged.ssrf
Description: Binary data
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.7.8: a couple of questions

[Anton Lundin]

On 02 May, 2018 - Davide DB wrote:

> On Wed, 2 May 2018 at 10:31, Anton Lundin  wrote:
> 
> > On 30 April, 2018 - Davide DB wrote:
> >
> > > Hi all,
> > >
> > > I was playing with 4.7.8 on Windows 7 and I noted a couple of things:
> > >
> > > - I cannot see anymore pO2 sensor from my Petrel controller. No average
> > pO2
> > > nor individual. On preference tab I have  individual and setpoint option
> > > checked nad the toolbar has O2 toggled
> > > The last time I saw them it was completely wrong. It seem I was the only
> > > one I reported this bug. Given that I changed my sensor I was curious to
> > > see if something changed...
> > >
> >
> > Hard to tell what's going on. The only thing I think we're seeing is
> > the setpoint of 0.7
> >
> > Can you export the dive as xml and post it here, for debugging and
> > analysis?
> >
> 
> Hi Anton,
> 
> Regarding the lacking of pO2 values...
> I saved my logbook to a local file and I gave it a quick look.
> My latest dives have no pO2 sample at all. Searching for computer type
> through the latest dives I found:
> 
> 137337 4:   diveid='220a811e' dctype='CCR' no_o2sensors='3'>
> 138227 4:   diveid='2e7067fb' dctype='CCR' no_o2sensors='3'>
> 141292 4:   diveid='5090ac0c' dctype='CCR'>
> 141392 4:   diveid='4a0f968a' dctype='CCR'>
> 141728 4:   diveid='4316ab17' dctype='CCR'>
> 142043 4:   diveid='57912a71' dctype='CCR'>
> 142596 4:   diveid='493f5552' dctype='CCR'>
> 143270 4:   diveid='3db24900' dctype='CCR'>
> 
> Of course the computer is always the same: my reb Petrel controller.
> I cannot remember which Subsurface version I used to download them but I'm
> pretty sure the last six dives were downloaded with the mobile version.

Try to download them into a fresh logbook with the current desktop
version, to see what's happens then.

You can open your git repo with a git client, and check what version you
used to download it with, as we write the version in the commit message.

> > - I merged some dives made during a ccr training. I cannot merge two of
> > > them. There are about 11 minutes between them. Is there a time limit for
> > > merging?
> >
> > It's not 11 minutes between those two, its 58 minutes.
> >
> > There's a warning if you're trying to merge dives with more than 30
> > minutes between them.
> >
> 
> If I'm correct the first dive last 47 minutes hence from 3:54 PM + 47' I
> surfaced at 4:41 PM then after a briefing of 11 minutes I went down again
> at 4:52 PM for 13 minutes.

Sorry, I can't read today.

> > What's happening when you're trying to merge them?
> >
> 
> The second dive (#175) disappear but the first dive remain unaffected (47
> minutes).

Can you export those two dives into a separate xml file and provide that
for debugging?

Are those two from the same dive computer, or are they from different?
It might be that they get merged as two different dive computers on the
same dive.


//Anton


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

Re: 4.7.8: a couple of questions

[Davide DB]

On Wed, 2 May 2018 at 10:31, Anton Lundin  wrote:

> On 30 April, 2018 - Davide DB wrote:
>
> > Hi all,
> >
> > I was playing with 4.7.8 on Windows 7 and I noted a couple of things:
> >
> > - I cannot see anymore pO2 sensor from my Petrel controller. No average
> pO2
> > nor individual. On preference tab I have  individual and setpoint option
> > checked nad the toolbar has O2 toggled
> > The last time I saw them it was completely wrong. It seem I was the only
> > one I reported this bug. Given that I changed my sensor I was curious to
> > see if something changed...
> >
>
> Hard to tell what's going on. The only thing I think we're seeing is
> the setpoint of 0.7
>
> Can you export the dive as xml and post it here, for debugging and
> analysis?
>

Hi Anton,

Regarding the lacking of pO2 values...
I saved my logbook to a local file and I gave it a quick look.
My latest dives have no pO2 sample at all. Searching for computer type
through the latest dives I found:

137337 4:  
138227 4:  
141292 4:  
141392 4:  
141728 4:  
142043 4:  
142596 4:  
143270 4:  

Of course the computer is always the same: my reb Petrel controller.
I cannot remember which Subsurface version I used to download them but I'm
pretty sure the last six dives were downloaded with the mobile version.

> - I merged some dives made during a ccr training. I cannot merge two of
> > them. There are about 11 minutes between them. Is there a time limit for
> > merging?
>
> It's not 11 minutes between those two, its 58 minutes.
>
> There's a warning if you're trying to merge dives with more than 30
> minutes between them.
>

If I'm correct the first dive last 47 minutes hence from 3:54 PM + 47' I
surfaced at 4:41 PM then after a briefing of 11 minutes I went down again
at 4:52 PM for 13 minutes.


> What's happening when you're trying to merge them?
>

The second dive (#175) disappear but the first dive remain unaffected (47
minutes).



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

Re: 4.7.8: a couple of questions

[Anton Lundin]

On 30 April, 2018 - Davide DB wrote:

> Hi all,
> 
> I was playing with 4.7.8 on Windows 7 and I noted a couple of things:
> 
> - I cannot see anymore pO2 sensor from my Petrel controller. No average pO2
> nor individual. On preference tab I have  individual and setpoint option
> checked nad the toolbar has O2 toggled
> The last time I saw them it was completely wrong. It seem I was the only
> one I reported this bug. Given that I changed my sensor I was curious to
> see if something changed...
> 

Hard to tell what's going on. The only thing I think we're seeing is
the setpoint of 0.7

Can you export the dive as xml and post it here, for debugging and
analysis?


> [image: subsurface-profile.JPG]
> 
> - I merged some dives made during a ccr training. I cannot merge two of
> them. There are about 11 minutes between them. Is there a time limit for
> merging?

It's not 11 minutes between those two, its 58 minutes.

There's a warning if you're trying to merge dives with more than 30
minutes between them.


What's happening when you're trying to merge them?


//Anton


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

Re: 4.7.8: a couple of questions

[Davide DB]

Hi all,

Is it my fault or should I file a issue on Github?

Thanks

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

4.7.8: a couple of questions

[Davide DB]

Hi all,

I was playing with 4.7.8 on Windows 7 and I noted a couple of things:

- I cannot see anymore pO2 sensor from my Petrel controller. No average pO2
nor individual. On preference tab I have  individual and setpoint option
checked nad the toolbar has O2 toggled
The last time I saw them it was completely wrong. It seem I was the only
one I reported this bug. Given that I changed my sensor I was curious to
see if something changed...

[image: subsurface-profile.JPG]

- I merged some dives made during a ccr training. I cannot merge two of
them. There are about 11 minutes between them. Is there a time limit for
merging?

[image: subsurface-merge.JPG]


Thank you in advance



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