On 2014-08-22 16:21, Dirk Hohndel wrote:
On Fri, Aug 22, 2014 at 03:53:05PM +0200, Jef Driesen wrote:
For the tank pressure, we certainly need support for multiple tanks, so my proposal is to add DC_FIELD_TANKPRESSURE along with a DC_FIELD_TANKPRESSURE_COUNT. That's consistent with what we already have for the gasmixes. For the corresponding data structure, I propose this:
typedef struct dc_tankpressure_t { double begin; double end; } dc_tankpressure_t;
That would be consistent with the data that is delivered in the samples (e.g. a pressure value with a tank id). The begin/end fields would simply correspond to the value of the first/last sample. So no attempt to add tank size (which not many dive computers support) or anything else.
Why not? You support at least one DC that does provide the data (Cobalt) and it would be easy enough to include the three values that dive computers may record:
typedef struct dc_tankdata_t { double begin; double end; double air_volume; // this is usually cuft double wet_volume; // this is in liter double working_pressure; // in bar like behin and end };
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. 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)
Jef