Re: Shearwater upload problems

[Jan Mulder]

On 05-02-18 18:49, Dirk Hohndel wrote:

Willem,

Since you are building from source, can you see if Jef's analysis is correct 
and it is the simplification that I had implemented in libdivecomputer that 
causes the problem?

cd ~/src/subsurface/libdivecomputer
git revert 8ea8ceb
cd build
make && make install
cd ../../build
make

and then try that freshly built Subsurface to see if that fixes the problem?



As I had my libdc simulator still running with Willems dataset I did the 
test. And yes, the dive time is correct now (so that is fixed by the 
revert).


But the 2nd issue (po2 graph) is different. I see a flat po2 line, 
obviously coming from setpoint data. And that is weird, as Willem said 
that it was a pSCR dive (that has no notion of setpoint). Changing the 
dive type to pSCR shows a more realistic po2 graph, but pretty shure 
that that is a Sbbsurface calculated po2, and not the measured one from 
the single sensor.


--jan






On Feb 5, 2018, at 5:44 AM, Jef Driesen  wrote:

On 2018-02-05 14:00, Anton Lundin wrote:

On 05 February, 2018 - Willem Ferguson wrote:

This weekend I used a Shearwater predator dive computer. Connecting
via Bluetooth no problem, had to force it to classical bt as it
defaulted to LE. However, downloading the dive to Subsurface
provides two problems:
1) The duration for each dive is exactly half of what it was in real
life. So there is a problem with setting up the correct time
increments for successive samples.

This might be due to the parser by some reason parsing it as petrel
data. The petrel sample size is twice the sample size of the predator.
Are you sure you did pick "predator" ?


The predator doesn't support the newer petrel protocol. So I assume Willem did indeed 
select "Predator", otherwise the download would have failed.

But you are pointing in the right direction. The subsurface branch introduced a bug with 
commit 8ea8cebb4e6c3d86b9ceb2291caa077dabd2a3f7. There, the "petrel" parameter 
was removed and replaced with the model number. But the purpose of that parameter is to 
indicate whether the data came from the petrel or the predator backend. And because the 
model number appears to be stored incorrect in Willem's data (zero instead of 2), the 
data gets indeed parsed using the petrel format.

Jef

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

Re: Shearwater upload problems

[Willem Ferguson]

On 05/02/2018 19:49, Dirk Hohndel wrote:

Willem,

Since you are building from source, can you see if Jef's analysis is correct 
and it is the simplification that I had implemented in libdivecomputer that 
causes the problem?

cd ~/src/subsurface/libdivecomputer
git revert 8ea8ceb
cd build
make && make install
cd ../../build
make

and then try that freshly built Subsurface to see if that fixes the problem?

Thanks

/D
This sounds like a super suggestion. Unfortunately I do not have the 
Shearwater here with me. Any way to route to the .bin file?

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: Shearwater upload problems

[Dirk Hohndel]

Willem,

Since you are building from source, can you see if Jef's analysis is correct 
and it is the simplification that I had implemented in libdivecomputer that 
causes the problem?

cd ~/src/subsurface/libdivecomputer
git revert 8ea8ceb
cd build
make && make install
cd ../../build
make

and then try that freshly built Subsurface to see if that fixes the problem?

Thanks

/D

> On Feb 5, 2018, at 5:44 AM, Jef Driesen  wrote:
> 
> On 2018-02-05 14:00, Anton Lundin wrote:
>> On 05 February, 2018 - Willem Ferguson wrote:
>>> This weekend I used a Shearwater predator dive computer. Connecting
>>> via Bluetooth no problem, had to force it to classical bt as it
>>> defaulted to LE. However, downloading the dive to Subsurface
>>> provides two problems:
>>> 1) The duration for each dive is exactly half of what it was in real
>>> life. So there is a problem with setting up the correct time
>>> increments for successive samples.
>> This might be due to the parser by some reason parsing it as petrel
>> data. The petrel sample size is twice the sample size of the predator.
>> Are you sure you did pick "predator" ?
> 
> The predator doesn't support the newer petrel protocol. So I assume Willem 
> did indeed select "Predator", otherwise the download would have failed.
> 
> But you are pointing in the right direction. The subsurface branch introduced 
> a bug with commit 8ea8cebb4e6c3d86b9ceb2291caa077dabd2a3f7. There, the 
> "petrel" parameter was removed and replaced with the model number. But the 
> purpose of that parameter is to indicate whether the data came from the 
> petrel or the predator backend. And because the model number appears to be 
> stored incorrect in Willem's data (zero instead of 2), the data gets indeed 
> parsed using the petrel format.
> 
> Jef
> ___
> 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

Fwd: Re: Shearwater upload problems

[Willem Ferguson]

On 05/02/2018 17:16, Jef Driesen wrote:

On 2018-02-05 15:42, Willem Ferguson wrote:

I definitely did pick the Predator option, both in the Linux OS
Bluetooth setup and within Subsurface. The O2 sensor on the computer
was calibrated using oxygen in the way specified in the user manual
and it performed very well. I have no idea how this relates to the
calibration bit and calibration value.


The dive header contains the number of sensors, and for each sensor a 
bit to indicate whether it was calibrated, and the calibration value. 
But your data only contains the number of sensors (1). Both the 
calibrated bit and the calibration value are zero. That's not what I 
expected to see.



The temperature data are ok. There are issues with the deco ceiling
calculated in Subsurface, but since deco is time-bound and we have an
erroneous time scale, it remains to be seen if the deco effects are
genuine or an artifact of the time scale problem.


I meant the data that came from the dive computer, and not some info 
that is calculated by subsurface. The fact that some of your data 
looks wrong, made me wonder whether there is some sort of data 
corruption. Hence my question whether some other data (depth, 
temperature, etc) looks wrong or not. If other data is clearly wrong 
too, then data corruption might indeed be the cause.


Do you happen to have memory dumps downloaded in the past?

Jef


Attached an image of the 2nd last dive, generated using the Shearwater
software. Everything is perfect, as it should be. Apologies for
annotations. We were testing equipment. The download to Shearwater was
within minutes after download to Subsurface.

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: Shearwater upload problems

[Willem Ferguson]

On 05/02/2018 17:16, Jef Driesen wrote:

On 2018-02-05 15:42, Willem Ferguson wrote:

I definitely did pick the Predator option, both in the Linux OS
Bluetooth setup and within Subsurface. The O2 sensor on the computer
was calibrated using oxygen in the way specified in the user manual
and it performed very well. I have no idea how this relates to the
calibration bit and calibration value.


The dive header contains the number of sensors, and for each sensor a 
bit to indicate whether it was calibrated, and the calibration value. 
But your data only contains the number of sensors (1). Both the 
calibrated bit and the calibration value are zero. That's not what I 
expected to see.



The temperature data are ok. There are issues with the deco ceiling
calculated in Subsurface, but since deco is time-bound and we have an
erroneous time scale, it remains to be seen if the deco effects are
genuine or an artifact of the time scale problem.


I meant the data that came from the dive computer, and not some info 
that is calculated by subsurface. The fact that some of your data 
looks wrong, made me wonder whether there is some sort of data 
corruption. Hence my question whether some other data (depth, 
temperature, etc) looks wrong or not. If other data is clearly wrong 
too, then data corruption might indeed be the cause.


Do you happen to have memory dumps downloaded in the past?

Jef

Attached an image of the 2nd last dive, generated using the Shearwater 
software. Everything is perfect, as it should be. Apologies for 
annotations. We were testing equipment. The download to Shearwater was 
within minutes after download to Subsurface.


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: Shearwater upload problems

[Jef Driesen]

On 2018-02-05 15:42, Willem Ferguson wrote:

I definitely did pick the Predator option, both in the Linux OS
Bluetooth setup and within Subsurface. The O2 sensor on the computer
was calibrated using oxygen in the way specified in the user manual
and it performed very well. I have no idea how this relates to the
calibration bit and calibration value.


The dive header contains the number of sensors, and for each sensor a 
bit to indicate whether it was calibrated, and the calibration value. 
But your data only contains the number of sensors (1). Both the 
calibrated bit and the calibration value are zero. That's not what I 
expected to see.



The temperature data are ok. There are issues with the deco ceiling
calculated in Subsurface, but since deco is time-bound and we have an
erroneous time scale, it remains to be seen if the deco effects are
genuine or an artifact of the time scale problem.


I meant the data that came from the dive computer, and not some info 
that is calculated by subsurface. The fact that some of your data looks 
wrong, made me wonder whether there is some sort of data corruption. 
Hence my question whether some other data (depth, temperature, etc) 
looks wrong or not. If other data is clearly wrong too, then data 
corruption might indeed be the cause.


Do you happen to have memory dumps downloaded in the past?

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

Re: Shearwater upload problems

[Davide DB]

On 5 February 2018 at 16:05, Jef Driesen  wrote:

> Sorry, I forgot to notify you about the change.
>
> Jef
>

No problem.

Thank you


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

Re: Shearwater upload problems

[Jef Driesen]

On 2018-02-05 15:35, Davide DB wrote:
On 5 February 2018 at 13:49, Jef Driesen  
wrote:

Last week, I merged a change to disable the ppO2 samples if all
(calibrated) sensors have the factory default calibration value 
(2100). If

you happen to have a unit that doesn't store the calibration values
properly, then this could explain why you are no longer seeing ppO2 
samples

with the latest libdivecomputer.


Should this solve the problem on my graph?

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


Yes and no. The fix disables the ppO2 samples. So you'll no longer get 
bogus ppO2 values. But of course that doesn't really fix the underlying 
problem (the missing calibration values).


Sorry, I forgot to notify you about the change.

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

Re: Shearwater upload problems

[Willem Ferguson]

On 05/02/2018 15:44, Jef Driesen wrote:

This might be due to the parser by some reason parsing it as petrel
data. The petrel sample size is twice the sample size of the predator.

Are you sure you did pick "predator" ?


The predator doesn't support the newer petrel protocol. So I assume 
Willem did indeed select "Predator", otherwise the download would have 
failed.


But you are pointing in the right direction. The subsurface branch 
introduced a bug with commit 8ea8cebb4e6c3d86b9ceb2291caa077dabd2a3f7. 
There, the "petrel" parameter was removed and replaced with the model 
number. But the purpose of that parameter is to indicate whether the 
data came from the petrel or the predator backend. And because the 
model number appears to be stored incorrect in Willem's data (zero 
instead of 2), the data gets indeed parsed using the petrel format.


There is something strange with this data. The model number is zero, 
while it's supposed to be 2 for the Predator. The number of sensors is 
1, but none of the three sensors has its calibrated bit set, and all 
three calibration values are also zero.


Does the rest of the data looks good, or are there other errors as well?

Jef

I definitely did pick the Predator option, both in the Linux OS 
Bluetooth setup and within Subsurface. The O2 sensor on the computer was 
calibrated using oxygen in the way specified in the user manual and it 
performed very well. I have no idea how this relates to the calibration 
bit and calibration value.


The temperature data are ok. There are issues with the deco ceiling 
calculated in Subsurface, but since deco is time-bound and we have an 
erroneous time scale, it remains to be seen if the deco effects are 
genuine or an artifact of the time scale 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: Shearwater upload problems

[Davide DB]

On 5 February 2018 at 13:49, Jef Driesen  wrote:

>
> Last week, I merged a change to disable the ppO2 samples if all
> (calibrated) sensors have the factory default calibration value (2100). If
> you happen to have a unit that doesn't store the calibration values
> properly, then this could explain why you are no longer seeing ppO2 samples
> with the latest libdivecomputer.


Should this solve the problem on my graph?


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


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

Re: Shearwater upload problems

[Jef Driesen]

On 2018-02-05 14:00, Anton Lundin wrote:

On 05 February, 2018 - Willem Ferguson wrote:


This weekend I used a Shearwater predator dive computer. Connecting
via Bluetooth no problem, had to force it to classical bt as it
defaulted to LE. However, downloading the dive to Subsurface
provides two problems:

1) The duration for each dive is exactly half of what it was in real
life. So there is a problem with setting up the correct time
increments for successive samples.


This might be due to the parser by some reason parsing it as petrel
data. The petrel sample size is twice the sample size of the predator.

Are you sure you did pick "predator" ?


The predator doesn't support the newer petrel protocol. So I assume 
Willem did indeed select "Predator", otherwise the download would have 
failed.


But you are pointing in the right direction. The subsurface branch 
introduced a bug with commit 8ea8cebb4e6c3d86b9ceb2291caa077dabd2a3f7. 
There, the "petrel" parameter was removed and replaced with the model 
number. But the purpose of that parameter is to indicate whether the 
data came from the petrel or the predator backend. And because the model 
number appears to be stored incorrect in Willem's data (zero instead of 
2), the data gets indeed parsed using the petrel format.


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

Re: Shearwater upload problems

[Anton Lundin]

On 05 February, 2018 - Willem Ferguson wrote:

> This weekend I used a Shearwater predator dive computer. Connecting
> via Bluetooth no problem, had to force it to classical bt as it
> defaulted to LE. However, downloading the dive to Subsurface
> provides two problems:
> 
> 1) The duration for each dive is exactly half of what it was in real
> life. So there is a problem with setting up the correct time
> increments for successive samples.

This might be due to the parser by some reason parsing it as petrel
data. The petrel sample size is twice the sample size of the predator.


Are you sure you did pick "predator" ?


//Anton


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

Re: Shearwater upload problems

[Jef Driesen]

On 2018-02-05 11:31, Willem Ferguson wrote:

This weekend I used a Shearwater predator dive computer. Connecting
via Bluetooth no problem, had to force it to classical bt as it
defaulted to LE. However, downloading the dive to Subsurface provides
two problems:

1) The duration for each dive is exactly half of what it was in real
life. So there is a problem with setting up the correct time
increments for successive samples.


The shearwater sample rate is hardcoded to 10 seconds. So I don't see 
how that can produce unexpected results. Or are you referring to the 
reported dive time?



2) I had an oxygen sensor connected to the Shearwater. The oxygen
values are not shown in the downloaded log.


Last week, I merged a change to disable the ppO2 samples if all 
(calibrated) sensors have the factory default calibration value (2100). 
If you happen to have a unit that doesn't store the calibration values 
properly, then this could explain why you are no longer seeing ppO2 
samples with the latest libdivecomputer.



Below is a dropbox link to the Subsurface log and bin dumps of the
download. I am hoping someone can provide more information.

https://www.dropbox.com/sh/jiogq7li1bwpysl/AADZNPVfDhFlHXM6ZbpYMp3ja?dl=0


There is something strange with this data. The model number is zero, 
while it's supposed to be 2 for the Predator. The number of sensors is 
1, but none of the three sensors has its calibrated bit set, and all 
three calibration values are also zero.


Does the rest of the data looks good, or are there other errors as well?

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

Re: Shearwater upload problems

[Willem Ferguson]

On 05/02/2018 13:19, Jan Mulder wrote:
And just curious. The divetype is CCR, but I see a lot of gas change 
events. Why is this?


--jan

Most of the dives in that log are CCR (APD Inspo). The last seven or so 
dives are pSCR (RB80) which, by its very nature, is dependent on gas 
changes, and bailout to OC.


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: Shearwater upload problems

[Jan Mulder]

On 05-02-18 11:31, Willem Ferguson wrote:
This weekend I used a Shearwater predator dive computer. Connecting via 
Bluetooth no problem, had to force it to classical bt as it defaulted to 
LE. However, downloading the dive to Subsurface provides two problems:


1) The duration for each dive is exactly half of what it was in real 
life. So there is a problem with setting up the correct time increments 
for successive samples.
2) I had an oxygen sensor connected to the Shearwater. The oxygen values 
are not shown in the downloaded log.


Below is a dropbox link to the Subsurface log and bin dumps of the 
download. I am hoping someone can provide more information.


First quick test using 4.7.6-2. Same problems, so does not seem related 
to recent libdivecomputer merge. But, another test with 4.6.1 shows both 
O2 sensor data and correct dive time.


So, @Dirk, something seems very wrong, and I would say, a show stopper 
for 4.7.7. Will try to bisect this asap.


And just curious. The divetype is CCR, but I see a lot of gas change 
events. Why is this?


--jan

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

Shearwater upload problems

[Willem Ferguson]

This weekend I used a Shearwater predator dive computer. Connecting via 
Bluetooth no problem, had to force it to classical bt as it defaulted to 
LE. However, downloading the dive to Subsurface provides two problems:


1) The duration for each dive is exactly half of what it was in real 
life. So there is a problem with setting up the correct time increments 
for successive samples.
2) I had an oxygen sensor connected to the Shearwater. The oxygen values 
are not shown in the downloaded log.


Below is a dropbox link to the Subsurface log and bin dumps of the 
download. I am hoping someone can provide more information.


https://www.dropbox.com/sh/jiogq7li1bwpysl/AADZNPVfDhFlHXM6ZbpYMp3ja?dl=0

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