On 2014-10-16 20:06, Dirk Hohndel wrote:
On Thu, Oct 16, 2014 at 03:43:11PM +0000, wrob311@gmail.com wrote:
On Thu Oct 16 2014 16:09:06 GMT+0100 (IST), Jef Driesen wrote: [...]
+typedef enum dc_deco_alg_t {
I'm not really in love with the "deco_alg" abbreviation. But "deco_algorithm" becomes pretty long. Maybe just "algorithm", or "decomodel"? Other suggestions are welcome too.
While 'algorithm' is used quite often, the 'model' is more correct, IMHO. Quite often a simple change to deco model parameters causes its name change i.e. ZHL-16B vs. ZHL-16C. Calling them two different algorithms does not make sense.
Yeah, I like dc_deco_model_t
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, };
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.
- DC_DECO_ALG_BZH, /* Buehlmann ZH, no GF */
- DC_DECO_ALG_BZHGF, /* Buehlmann ZH, with GF */
The BZH name sounds a bit cryptic to me. How about naming it BUHLMANN instead?
If I am not mistaken Buhlmann was calling his models ZHL-XY, i.e. ZHL-16C. There are Buhlmann models with different number of tissue compatments than 16...
I thought about that - but given how incredibly sloppy many of the implementations are (often due to limited processing power), it seems that even if the vendor were to tell you exactly which model they use (as some do), there is very limited benefit in knowing that. More importantly, I believe in most cases we don't know which exact model has been implemented. Some don't even tell you if they use gradient factors (and which ones).
See my other email.
DC_FIELD_DECO_INFO
and
struct dc_deco_information_t { unsigned int algo; unsigned int param1; /* e.g. GFhigh or GFS */ unsigned int param2; /* e.g. GFlow */ unsigned int param3; /* currently unused */ };
I'm not really sure what would be the best solution here. Are there any other algorithms besides the GF that have parameters that make sense to support? One concern is that with an integrated structure, we can't add new parameters if that's ever necessary. I'm not really in love with placeholder fields either. While with a separate DC_FIELD_DECOPARAMS type, we can introduce different data structures for each deco algorithm. For example:
struct dc_decoparams_gf_t { unsigned int low; /* e.g. GFhigh or GFS */ unsigned int high; /* e.g. GFlow */ };
You are basically opening a can of worms. :) Manufacturers like to add their own parameters it seems. Look at OSTC custom functions where ZHL-16C is extended with desaturation/saturation multipliers ( note: non-GF version).
Both versions, I believe.
Also there are parameters which I find hard to classify. Is calculating your deco 1m deeper than you are part of deco model extension or a safety feature? And these are probably specific to a dive computer manufacturer.
And most of those are not really well specified or documented.
I get specific requests from tech divers to show the gradient factor used by their dive computer on specific dives - I think that's because Subsurface shows the GF we use for our own deco calculations and people want to be able to compare. I have not received any other requests for paramters. I simply made this somewhat more generic when I saw in the Shearwater documentation that they have the fused VPM-GSF where they basically take the lower ceiling of VPM or Buehlmann with that parameter as surface GF (so basically GFhigh).
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 :-)
Jef
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
-
Dirk Hohndel -
Jef Driesen