On Thu, May 25, 2017 at 11:35 AM, Jef Driesen jef@libdivecomputer.org wrote:

The explanation is in the commit message:

Note that the interpretation of the PPO2 status bit appears to be
reversed (0=external and 1=internal).

You mis-understand. It's not the particular status bit polarity I worry about. It's simply that whole "average PPO2 data" piece.

IOW, this code:

#ifdef SENSOR_AVERAGE sample.ppo2 = data[offset + 6] / 100.0; if (callback) callback (DC_SAMPLE_PPO2, sample, userdata); #else

fundamentally makes no sense as it is now.

There are two possibilities I see for that sample.ppo2 value:

(a) it too only exists for the internal sensor case

(b) it exists even when we have an external sensor, and then contains the single PPO2 value that the external sensor gives us.

but the code right now is wrong in *either* case.

So if it's case (a), then that whole #ifdef SENSOR_AVERAGE logic should be _inside_ the PPO2_EXTERNAL check.

And if it is case (b), then we should have an "else" case for that PPO2_EXTERNAL case, and give the user that single PPO2 value.

See what I'm saying? As it is, the code makes no sense and absolutely cannot be right.

Linus

------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ libdivecomputer-devel mailing list libdivecomputer-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel