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

Dirk Hohndel dirk at hohndel.org
Mon Aug 25 09:06:16 PDT 2014


On Mon, Aug 25, 2014 at 04:58:52PM +0200, Jef Driesen wrote:
> >Even having just one backend that today fills these values makes things
> >more useful for applications - and as more dive computers provide this you
> >have no need for yet another API.
> >
> >Today Subsurface extracts this information from raw data - we can of
> >course continue to do so but I'd much prefer if this was in the official
> >API.
> 
> My criteria for including new features has always been that it has to be
> reasonable generic AND supported by at least a few dive computers. And that
> last criteria does not apply here. If we ignore the Uemis, which is rather
> special because it has a complete built-in logbook of its own, the Cobalt is
> basically the only dive computer which gives us the tank size.
> 
> You can argue that we need this anyway, because future dive computer will
> provide this information too, but I'm not really convinced that will happen.
> The reason behind that statement is very simple. A dive computer doesn't
> need this kind of information to do its job. For gas consumption estimations
> (e.g. How long before I'll run out of gas?), your dive computer doesn't need
> to know the tank size. The existing air integrated dive computer are the
> perfect proof of that. So why would a manufacturer bother adding this? It's
> a bit like adding a knob that isn't hooked up to anything.
> 
> About the only use-case that's left for the tank volume is the gas
> consumption calculation in the logbook application (e.g. How much gas did I
> consume on my dive). If the dive computer supplies the tank size, then you
> no longer have to enter this manually, but that's about it.

And the dive computer can show you your SAC rate during the dive. The
Uemis does that.

> However, unless
> you are always diving with the same size of tank, I think it's far more
> convenient to enter this information in the logbook application than the
> dive computer UI. I have a Cobalt and use it in combination with different
> tanks (6L 300bar, 10L 300bar, 12L 200bar, 15L 200bar), but I no longer
> bother adjusting the tank size in the Cobalt. It's too annoying to change it
> every time, and usually I just forget to do that anyway. I think it's far
> more user friendly to setup the tanks in the application, and assign them to
> your dives there. If you always dive with the same tank, then you can easily
> setup a default tank that automatically gets assigned to new dives, and then
> the user experience is exactly the same. Even better, because it also works
> for devices which don't provide the tank size!
> 
> And then I haven't even talked about the different systems to specify the
> tank volume (e.g. air vs wet volume). There is a reason why libdivecomputer
> always uses metric units. Mixing different units is only confusing and
> asking for trouble. I wouldn't mind if I can leave that mess to the
> applications :-) Luckily there are only a few small countries that hold on
> to their crazy imperial units :-) (me runs away now)

Humor aside, I continue to be puzzled by this argument. There are a couple
of divecomputers that provide these data and there is a clear use case.
Whether you use it on your dive computer frankly doesn't matter (and just
for the record, I tend to always adjust the tank size on my Uemis). What
matters is that there are data that could reasonably be provided by
libdivecomputer at zero incremental cost for all the dive computers that
don't have it, though for the past two years whenever the conversation
comes up you explain why it's not needed.

I agree, gasoline cars work and most cars have a gasoline engine. There
are only a few electric car makers out there. Yet as the owner of two such
cars I think it would be useful if gas stations and hotels provided a way
to charge cars. Oh, and they use different charging ports. One that's a
bit awkward but very popular, the other that's better and used by the rest
of the world. Smart gas stations and hotels will support both...

But I digress. It's your project. I continue to be too lazy to fork it so
I will continue to just work around the parts where you don't see that you
continue to go the wrong direction.

/D


More information about the devel mailing list