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