[PATCH] Added support for parsing temperature in the dive header

[Nick Shore]

Ultimately I think I would prefer a consistent api. That said, currently I have custom parsers as I extract a little extra info in most cases. The Cobalt tanks are a good example of that. So while I say a consistent api, I'm doing something completely different in practice. In a perfect world, the application wouldn't need to handle anything manufacturer/model specific. If you could query whether information was available for a certain brand or model, then that would help.

Certainly I get a lot of people asking why the manufacturer software shows X, and where is that in MacDive? I've seen the "fake" pressure graphs you're talking about, and that trips users up. This particular case I'd say is pointless at best, and misleading at worst. I think that information is best not displayed. I don't think that libdc should be trying to fake this information at all if it is ending up with data that is in no way accurate.

I do agree with you Dirk that if enough devices support a particular feature then perhaps it's worth adding. As long as there's a convenient way for an application to say "does this model include heart rate information?" then I think it can be included in a way that applications can handle it nicely. I guess I straddle the middle ground, as I do have custom parsers so that I can extract some info that isn't currently handled by libdc, but would ultimately like to not have to maintain them.

I trust that this has not helped in any way :)

-nick




On 03/09/2014, at 8:53, Dirk Hohndel <dirk at Hohndel.org> wrote:

> On Tue, Sep 02, 2014 at 10:04:01AM +0200, Jef Driesen wrote:
>> [Sorry for the slow response, but I've been busy with non libdivecomputer
>> related things.]
> 
> How dare you have a real life! :-) :-)
> 
> I actually took the last few days off myself and did a computer free trip
> into the mountains.
> 
>> Remember that adding features ad-hoc, based on what a certain manufacturer
>> (e.g. suunto, which happens to be the first supported devices) provides is
>> pretty much how the current libdivecomputer "design" evolved into what we
>> have now. Linus and you already complained several times about the current
>> libdivecomputer api. Don't get me wrong, I absolutely agree that many of
>> those concerns are indeed valid and should be addressed. But for the time
>> being, I just don't want to repeat those mistakes again. So yes, I'm a lot
>> more careful when it comes to adding new features now.
> 
> Which I think is a wise choice. Don't get me wrong, I am not advocating to
> add any random thing. I'd like at least a couple of dive computers from
> different vendors to provide the information. Which makes this a tricky
> one as the Uemis with its ass-backwards download approach isn't supported
> by libdivecomputer at all. And I'd like at least a vague "OK, this could
> be useful" check. The Uemis includes rather illdefined values for
> "cold_fact", "work_fact", and "bubble_fact" in every sample. I wouldn't
> suggest supporting something like that in libdivecomputer because even if
> the Uemis was supported... what the heck would you do with these?
> 
>> Also from an application point of view, I think it's more interesting to
>> have a rather limited set of features that is very well supported by the
>> majority of the backends, then having a large number of features that are
>> only supported by a few backends. That's basically why I have been spending
>> most of my time and energy on improving the existing features, and not
>> adding anything new.
> 
> I think we get at least as many "the vendor application supports this, why
> don't you" email as you do. And then we often go back and look and notice
> that the vendor application is actually making data up that isn't included
> in the download (I think you just helped us in one case where the vendor
> application shows a pressure graph but looking into the sample data it is
> clear that there isn't even enough space there to hide the pressure
> data...) - so it's just interpolated data. Same goes for deco information.
> Sadly very few vendors actually include that in the downloadable data -
> yet their applications show it by simply "re-doing the math".
> 
> But on the flip side - if a computer (or better, a couple of computers) do
> provide something that I can imagine being really useful (heart rate comes
> to mind, compass heading, ndl / deco status), then I'll argue to include
> it even if only a few DCs support it.
> 
>> But okay, maybe I went into the defensive corner too fast. So let's start
>> all over again, and assume we want to include the tank size too. Can you
>> explain me how you would use the dc_tankdata_t structure in the following
>> scenarios:
>> 
>> * No tank size available (e.g. just begin/end pressure): How do we indicate
>> that the tank size isn't available?
> 
> I see where you are going. The libdivecomputer design pattern would be to
> return an error when that piece of information isn't availble, yet here we
> have some data available and others not available.
> 
> We could fall back to saying "all values 0" means no data available. If we
> have neither compressed nor wet volume, we obviously don't know how big
> the tank is (i.e., while 0°C is a valid temperature, a volume of 0ml is
> NOT a valid tank volume).
> 
>> * Metric vs imperial tanks (e.g. water vs air capacity): How do we indicate
>> the difference? For imperial tanks, we'll certainly need the working
>> pressure. Metric tank also have a working pressure, and although it's not
>> needed for calculating the amount of gas, it may be available too. Do we
>> convert imperial units to metric units to be consistent with the rest of the
>> libdivecomputer api, or do we make an exception here?
> 
> With all due respect to my host country, the American way of defining
> cylinder capacity is beyond braindead. Yes, it seems to make intuitive
> sense when you tell someone "this is an 80cuft cylinder" (assuming you
> have wrapped your mind around the non-metric measurements), but of course
> this only makes sense if you actually know the correct working pressure -
> and as I frequently find out on dive boats it is not clear at all to a lot
> of divers that an HP119 and LP95 contain the same amount of gas at the
> same pressure...
> 
> So I would suggest that we have a member for the wet volume in mL.
> And a different member for the volume at working pressure - also in mL.
> And a third member for the working pressure - in mbar.
> (oops, I am assuming the Subsurface style "we prefer integers" approach -
> you can obviously use doubles and liter and bar - I like integer math
> better, but I'm fine either way).
> 
> Technically one of the three values should of course be redundant - but we
> have also learned the hard way that it actually isn't. Because the
> "marketing size" of many cylinders is incorrect. And apparently almost no
> one takes the compressibility factor into account (at 300bar a tank
> contains only about 270 times as much air as its wet volume).
> So if you have all three, give them. If you have only wet volume (or only
> gas volume and working pressure) set the others to 0.
> 
>> And then we can work out something from there.
> 
> Thanks Jef. Much appreciated.
> 
> Sven, Nick - any input on what would be useful for your apps?
> 
> /D
> _______________________________________________
> devel mailing list
> devel at libdivecomputer.org
> http://libdivecomputer.org/cgi-bin/mailman/listinfo/devel