RFC: support for deco algorith and parameter fields

[Dirk Hohndel]

On Fri, Oct 17, 2014 at 10:13:27AM +0200, Jef Driesen wrote:
> 
> I'm fine with that too. Thus to summarize we now have something like:
> 
> DC_FIELD_DECO_MODEL
> DC_FIELD_DECO_PARAMS
> 
> enum dc_deco_model_t {
>     DC_DECO_MODEL_NONE,
>     DC_DECO_MODEL_BUHLMANN,
>     DC_DECO_MODEL_BUHLMANN_GF,
>     DC_DECO_MODEL_VPM,
>     DC_DECO_MODEL_VPM_GFS,
>     DC_DECO_MODEL_DSAT,
>     DC_DECO_MODEL_RGBM,
> };

I was going to add "DC_DECO_MODEL_UNKNOWN" - you'd set that in a backend
when you KNOW it's in regular dive mode (no gauge, freedive, etc), but you
don't know which model it uses. That's different from "none", right?

> struct dc_deco_params_gf_t {
>     unsigned int low;
>     unsigned int high;
> };
> 
> For the GF extension, we could also consider to re-use the base enum value
> (e.g. DC_DECO_MODEL_BUHLMANN), and then get the actual GF values through the
> params. For pure Buhlmann we can then return 100/100 as GF's. Then we don't
> need an explicit DC_DECO_MODEL_BUHLMANN_GF variant. Just an idea.

Either works. Instinctively I'd shy away from it. E.g., Aeris A300CS tells
me it's using "Buehlmann ZF" - the deco I see in my dive makes me guess
it's something like 30/85, but I'd need a lot more data to verify that. It
definitely is not 100/100 (I wouldn't have gone into deco at all on
100/100).
So this feels to me like "falls precision". When all we know is that it's
"some sort of Buehlmann", then claiming that it's GF 100/100 pretends to
know more than we actually do.

> Well, I think that we should stick to those parameters which are a defacto
> standard (like GF's), and ignore everything else. All highly manufacturer
> specific stuff is basically out of scope for libdivecomputer. At least
> that's my opinion. So we leave the can of worms closed :-)

You will be shocked to hear that I actually agree with you. I'm a huge fan
of getting as much data as possible from the dive computer. But I am
slowly learning to appreciate your push towards doing things that are
common among at least some backends. That's why, when submitting my RFC, I
implemented this for four backends.

The sat/desat is actually interesting, but unless we see the same logic
from multiple vendors, it's out of scope.

/D