[PATCH] Correct bug: setpoint handling of Poseidon CCR dive logs

Willem Ferguson 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
>> variables?
> 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.
>
> /D
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
I apologise for a long reply.

Ok, so here is how I understand the code as it is at present. It all 
happens in
fixup_dive_dc() in dive.c and in fill_o2_values in profile.c.

fixup_dive_dc():

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 
plotdata.

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.
Kind regards,
willem






More information about the subsurface mailing list