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. That would make sense as my workflow had changed for the most recent downloads. Normally I would download from the petrel (connected to cells), then the ix3m-reb (fixed setpoint) then the ostc3+ (also fixed setpoint). Now because the ix3m-reb download is/was not working then I skipped that and went straight to the ostc. So previously I guess with that bug then it may have picked up the correct fixed setpoint from the previously downloaded dive (ix3m and the ostc were set with the same fixed setpoint). Steve _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
