[PATCH] Consistent read and write of CCR data to and from XML

[Willem Ferguson]

On 11/11/2014 22:55, Robert C. Helling wrote:
>
> All deco and ceiling calculations have to know at some point the ppO2 to determine the breathing gas. If there is sensor data, great, then use the value from that (using voting logic) otherwise the set point is the best guess (assuming the rebreather works as designed). The current code (at least before your patch) uses the variable sample.setpoint as this best effort value for ppO2 (admittedly the name might not be optimal). So even, when use user had a set point, this variable eventually gets overwritten by the sensor data.
>
> So with your patch, that makes a distinction, the sensor data does not reach the deco/ceiling calculations anymore. It is not sufficient to set the variables when reading from files, you also have to make sure, that the values reach other points in code where they are expected.
>
> Also note that code at different places tests for CCR character of that segment (as we said, CCR is a property of a segment, not the dive as in bail out) against 0. This (or a replacement) has to work after you separate set point and sensor data.
>
> There are several ways I see possible to achieve this (all involve Qt Creator functions):
>
> 1) You refactor/rename the old sample.setpoint back to sample.ppo2 and make sure it gets initialised properly from sensor data (as done in fill_o2_values()) and lacking that set point information. (simpler I guess)
>
> 2) You go through the list of “Find usages” of sample.setpoint and update the code there accordingly.
>
> This patch as it is breaks stuff.
>
> Best
> Robert
>
>
> -
Robert,

I am quite dumb because I struggle to understand the real detail of what 
you are saying. I get the broad message but not the precise implication. 
After reading your message a few times here is what I understand against 
the context of what I know from the code. It is about the use of 
variables plot_data->po2 and plot_data->setpoint. I am insistent that 
setpoint should mean the setpoint given to the dive computer and not 
anything else. To store a setpoint value in a variable called ppo2 just 
destroys the understandability of the code to anyone else.

Let's talk about xml input. there is no sample->po2 variable. So, when 
reading a "PO2='1.22' " attribute from xml, there is not a direct 
variable against which to store that. So when we encounter "PO2=.." in 
xml what should we do about this? If one wishes to keep the PO2 xml 
attribute at all, there is only one logical way to treat it, and that is 
as a po2 measurement (therefore store it in sample->sensor[0]), do not 
treat it as a setpoint. I agree that the best way to check for a CCR 
point on the dive profile is by checking for a setpoint. But then the 
PO2 attribute is possibly not a good place to get that setpoint 
information and the setpoint attribute is a better place for reading 
that information.

Now, while the sample structure has no PO2 member, the plot_data 
structure does have. We are free to translate the sample information in 
any way when we transfer from samples to plot_data. My feeling is that 
one should be fairly specific in reading and storing the raw dive data 
in xml. If we want to set up a way to preliminarily store setpoint data 
into the sensor values (to provide for the case when there are no sensor 
data), then the proper way to do this translation is surely while 
populating the plot_data structure and not while reading the raw xml 
samples?

I suspect that you deal with equipment that stores setpoint values that 
are reported in xml as "PO2=..". is this correct? If this is the case 
then there is only one option and this is to keep compatability with 
whatever xml that equipment produces. But this would be a critical bit 
of information that I am not aware of at the moment.

Please spell out the issue a bit more, would you?? Please comment on 
each of my paragraphs above. I am insistent in getting totally into your 
frame of reference to really understand this.
Kind regards,
willem