On 12/11/2014 10:16, Robert C. Helling wrote:
Of course, I agree that po2 and the set point are two different things. But the
origin of the confusion is that lacking sensor data the set point is our best
guess for po2. And only the Poseidon CCR provides us with sensor data, so in
the _bulk_ of the CCR cases they are effectively the same. And by introducing
the more sophisticated case of having sensor data you should take care not to
break that majority of cases. So when you want to differentiate the two
variables again, make sure they contain the same values when sensor data is not
available.
So feel free to rename the o2setpoint variable to anything (just make sure you
rename it everywhere in the codebsae, “Refactor/rename” is an easy way to do
that) for example po2. This way unless sensor data is available it get’s filled
by the set point value for all other rebreathers than the Poseidon. Then for
the Poseidon you can differentiate between sensor data and set-point setting
and introduce code that sets the variable that you just renamed accordingly.
Just make sure that for other rebreathers the set-point setting is used as best
guess for po2.
Best
Robert
--
Robert,
The historical perspective really helps, because I could never
understand what use the po2 member has. What would happen if, when
transfering the data from sample into plot_info (i.e. in
populate_plot_entries()), one simply copies the value of
sample->setpoint into both plot_data->po2 as well as into
plot_data->setpoint? The pressures structure (itself part of plot_data)
is filled with calculated values only after the rest of the plot_data
structure is initialised. In create_plot_info_new() all the deco
calculations take place after populate_plot_entries(). Would that solve
the immediate problem?
In the longer term we need to resolve the two-variable situation, in my
opinion to use setpoint rather than po2. But let's solve the immediate
problem first before worrying about the longer term.
Secondly, if one does import CCR logs from equipment without o2 sensors,
as you described above, how would the data currently be represented in
the sample structures? I do not have access to such logs. Looks to me
like one needs to ensure an accurate flow from the CSV import, then
getting the data stored as samples and finally representing them
correctly in plot_info.
Kind regards,
willem
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
