[PATCH] Correct bug: setpoint handling of Poseidon CCR dive logs
willemferguson at zoology.up.ac.za
Wed Oct 29 23:29:18 PDT 2014
On 29/10/2014 22:35, Dirk Hohndel wrote:
> On Wed, Oct 29, 2014 at 10:10:56PM +0200, Willem Ferguson wrote:
>>> I think in memory we should NOT set anything to 0. When the setpoint
>>> switches to 0 that means we are bailing out to OC...
>> In fixup_dive_dc() there has always been some zeroing out from the
>> beginning, I m reasonably sure in the original code from Linus. But that
>> related to tank pressures and temperature, not oxygen values. In that
>> function I added some zeroing out of oxygen-related variables in an attempt
>> to be consistent. Your argument makes good sense. Should I only remove
>> zeroing out for the setpoint or should I do for all oxygen-related
> There should be no zeroing out. fixup_dive_dc() clears tank pressures if
> we switched away from that tank. That's the only thing it should do. If it
> does more than that, please point it out to me.
> subsurface mailing list
> subsurface at subsurface-divelog.org
I apologise for a long reply.
Ok, so here is how I understand the code as it is at present. It all
fixup_dive_dc() in dive.c and in fill_o2_values in profile.c.
While a particular cylinder is being used (i.e. while the index of the
cylinder *remains the same*), the duplicate gas pressure values are
zeroed out. This is pre-existing code, i.e it was there before any CCR
code was developed. I only added the zeroing out for diluent gas
pressures as well. [~line 1138 in dive.c].
The pre-existing code also zeroed out duplicate temperature values
[~line 1169]. You can see there that the style of the commenting for
that particular operation is different from my style of commenting.
Immediately below the temperature value manipulation I added code that
zeroes out the oxygen-related data. (o2 sensors and o2 setpoint).
Now where do all the zeroed data values get re-instated for profile
calculations? As follows:
1) Gas pressures:
In gaspressures.c the zeroed gas pressure values effectively get
replaced. This is code that originally comes from profile.c and that
code does *much* more than just re-instating the zeroed values. But,
amongst others, interpolated values (using raw data from structures of
sample) replace zeroed values in the appropriate places in structures of
2) Temperature values:
The temperature values are re-instated in populate_plot_entries() in
profile.c (~line 591). This is pre-existing code.
3) Oxygen values:
In function fill_o2_values() in profile.c the zeroed sensor data and
setpoint data are re-instated for plotting. As with the pressure
calculations mentioned above, this function does more than re-instating
zeroed oxygen values. It also triggers calculation of po2 values that
are stored in pressures.o2 contained within each structure of plotdata.
Towards a plan of action:
In the underlying data structures the memory space requirements are the
same, regardless of whether a zero is stored in a location or a measured
data value. My suggestion is that we do not touch the pressure values in
fixup_dive_dc but that we remove code that zeroes the oxygen-related
values. Similarly, fill_o2_values() in profile.c is reduced to a loop
that steps through the structures of plotdata, which corrects zero
values (that might have originated either from the insertion of events
along the dive profile or from glitches in the logging or download
process) and which triggers po2 calculation for each structure of
plotdata (i.e. each point on the dive profile).
I am not sure what to do about the zeroing and re-instatement of
temperature data but if we were consistent, the zeroing of temperature
data should also be removed.
I will assist in getting this right in whatever way you think is the
most rational and consistent.
More information about the subsurface