CCR testing and other observations

[Jan Mulder]

On 24-05-17 14:34, Jan Mulder wrote:
> Let me focus on the OSTC3 fixed setpoint issue.
>
> On 24-05-17 12:30, Steve wrote:
>> Using the latest 4.6.4 on Windows 10
>>
>> See attached screen capture: subsurface-OSTC3+ccr-o2.jpg
>>
>> I did update the firmware to the latest 2.15 so that may (or not) be 
>> causing
>> it to report incorrectly.
>> Downloading from my OSTC3+ diving with fixed setpoint (no connection to
>> actual o2 cells) in ccr mode.
>> It picks up that it is a ccr dive but the red setpoint line in the 
>> bottom of
>> the profile is at 0 and the green o2 line follows depth when it 
>> should be
>> table flat.
>> It also make all the deco and tissue heatmap calcs all incorrect.
>> In the past it picked up my fixed setpoint correctly and the red 
>> setpoint
>> and green o2 line was drawn correctly as a constant flat line and the 
>> deco
>> and tissue heatmap calcs were correct.
>
> Yes, I can reproduce the issue on Windows 4.6.4. I dive a (Kiss) mCCR 
> and combining it with an OSTC3 (not sure what the exact difference 
> between OCTC3 and 3+ is; I am using a Bluetooth version, so I assume 
> 3+,). As Steve, I run the OSTC3 in fixed setpoint mode. Recently, I 
> fixed some issues related to the fixed setpoint use of the OSTC3 
> (which involves both Subsurface code, as well as libdivecomputer 
> code). So, it it supposed to work, but I can confirm that it does not. 
> That is: on Windows only, as it is working fine on Linux.
>
> So, my question for Dirk: are you sure that the correct 
> libdivecomputer code is packaged with the Windows version of 4.6.4? I 
> cannot help thinking of the recent build issue we had related to that 
> Shearwater buffer overrun problem.
>
> --jan

Hmm. I was a little confused here. I see that the 4.6.4. tag in the 
(ssrf) libdc is before my change in libdc, so the fixed setpoint stuff 
for the OSTC3 is not supposed to work in 4.6.4. The good news is that it 
will be fixed in 4.6.5.

The remark of Steve "In the past it picked up my fixed setpoint 
correctly" is a little difficult to verify, but 
https://github.com/Subsurface-divelog/subsurface/pull/343 can be related 
to this. That (very obvious) error did cause transferal of po2 values 
from one dive to the next (during one import session from the dive 
computer), so, this can give the impression that a setpoint is taken 
from the OSTC3, but was in fact a setpoint form a previous dive.

--jan.