Saving air temperature

Dirk Hohndel dirk at hohndel.org
Thu Feb 14 09:50:28 PST 2013


Dirk Hohndel <dirk at hohndel.org> writes:

> On Feb 14, 2013, at 7:40 AM, Lubomir I. Ivanov wrote:
>
>> On 14 February 2013 16:31, Sergey Starosek <sergey.starosek at gmail.com> wrote:
>>> Hi,
>>> 
>>> Seems that air temperature saving is broken. If you edit the dive, modify
>>> air temp, press Ok, and the reopen for edit, one can see these changes.
>>> But it's neither shown on the 'Dive Info' tab, nor saved to the XML. If this
>>> information is supposed to be downloaded from DC, then editing air temp
>>> should not modify dive (or better disable this edit box).
>>> 
>> 
>> i've just sent a patch for this named:
>> [PATCH] Store user entered 'airtemp' values in the 'divecomputer' struct
>> 
>> but i'm not sure if this is desired, as currently there are couple of
>> places to store air temp.
>> i'm guessing that the 'dc' airtemp is a value that can be retrived
>> from a DC, and perhaps the
>> user value should only be stored directly in the dive struct. then
>> again save-xml.c and statistics.c
>> seem to be only interested in the DC value. some additional logic may
>> be required here.
>
> save-xml.c needs to be updated to save the value.
> more interestingly, statistics.c at this point only displays the air temperature 
> that we get from the divecomputer that is currently displayed. I mentioned
> last week that we need a way to display the "best information we have" kind
> of summary somewhere - but we don't at this point.
>
> Maybe I'll have statistics.c display the data in the dive structure if it was 
> manually set to override what's in the divecomputer…

Oh this is so not fun. I clearly didn't think this through.

How can I tell that the value was set by the user? Seems obvious: if the
calculated value in fixup_airtemp is different from what is in
dive->airtemp, right?

So let's go with that. If dive->airtemp is different it gets saved. Next
time the dive is loaded, fixup_airtemp is called. Now there already is a
value in dive->airtemp, so we can use that as indication that the user
has edited things and not over-write it with the average of the values
from the divecomputers. Easy.

Now lets download from your second divecomputer and merge the
dives. Oops - right now the edited value is not merged. Let's fix that
and merge those values [*].

Fixup_airtemp is called again. If the value in dive->airtemp doesn't
match the average of the values in the divecomputers - is that because
it was changed by the user, or was this because a new divecomputer got
added?

Can you see the problem?

[*] so the trick is in how we merge those values. I solved the problem
by zeroing out any automatically calculated airtemp value right before
merging and then merge with MERGE_NONZERO.

That still leaves the problem of where (outside of printing) is this
shown? For now I decided to showa dive->airtemp value whenever there is
no dc->airtemp value. That still is not really nice if you have multiple
divecomputers where some have an airtemp, some don't, and you edited the
airtemp manually. And then depending on which divecomputer is shown you
see different values. And editing the airtemp changes some of them but
not others.

It's all consistent and can be explained. But I'm not excited about the
logic we have ended up with.

For 3.1 I really want to add this "best summary view" in addition to the
individual dive computers; so only one view if you have just one DC, but
n+1 views if you have n>1 divecomputers. And the 1st view shown is that
summary mode that shows the best known value (the fixed up ones from all
the DCs or something that was edited), and the n other ones show ONLY
what's in the divecomputer that is shown...

/D


More information about the subsurface mailing list