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 <jef at libdivecomputer.org> 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