RFC: New api for gas changes

Jef Driesen jef at libdivecomputer.org
Mon Jun 8 14:36:23 PDT 2015


On 03-06-15 17:41, Linus Torvalds wrote:
> On Fri, May 22, 2015 at 7:34 AM, Jef Driesen <jef at libdivecomputer.org> wrote:
>>
>> I have been working on a new api for gas changes. The idea is that old gas
>> change events (SAMPLE_EVENT_GASCHANGE and SAMPLE_EVENT_GASCHANGE2) will be
>> replaced with a new DC_SAMPLE_GASMIX sample. The corresponding sample data
>> is an integer with the index of the gas mix.
>
> Side note: did you consider just doing both gasmix and index? Document
> that either (or both) will be set, and make "index=-1" be the "I don't
> have an index".
>
> We end up doing that in subsurface anyway. Now, it's mostly
> historical: because we had the gasmix, that's what we want in some
> places, but then we _also_ want the index for disambiguation.
>
> But it turns out having both actually has some advantages, even though
> it sounds redundant.

No, I didn't consider this. I think it will only complicates the api for no good 
reason.

> For example, on some dive computers, you might not *get* an index
> (because the dive computer fundamentally just reports O2 percentage in
> the event). So then it would be better to say "I don't know the index"
> than basically make up a possibly ambiguous cylinder.

Many dive computers store the gasmix index internally. That makes sense, because 
it requires fewer bytes (or even bits) compared to storing the o2/he 
percentages. The only exception to the rule are divesystem, suunto and 
shearwater. In that case we lookup the index of the gasmix.

If a dive computer lets you configure multiple identical gas mixes, and refers 
to them by their o2/he content instead of an index, then that's just stupid. 
There is no way to tell which mix was used, so why even bother to setup 
identical mixes? That makes no sense at all.

That's why for example the Shearwater doesn't even support this, and refuses to 
add a duplicate mix.

But you are referring to an ambiguous cylinder. That's a completely different 
thing. The DC_SAMPLE_GASMIX is about changes in the gasmix, and not the tank. If 
you have a dive computer that has no knowledge about tanks (e.g. a non air 
integrated model) and you use identical gas mixes as a substitute for tracking 
tank switches (e.g. sidemount), then you're out of luck if your dive computer 
doesn't store the index.

> And I think some others (Petrel?) allow you to change the mix during
> the dive for a special cylinder (perhaps you set your mixes wrong, or
> perhaps you're breathing a buddy gas). Sure, you can give the index
> for the special cylinder, but what happens if the user changed the
> gasmix twice? I'm not sure what the dive computer reports, but from a
> abstraction standpoint it would be good to give both index and mix -
> at least there's no dropped information, even if it might also confuse
> some user of libdivecomputer.

I'm not sure whether the Petrel supports this, but the OSTC certainly does. 
There are 5 pre-configured mixes and a 6th mix which can be changed during the 
dive. In libdivecomputer I parse the profile and add an new mix whenever this 
6th mix is changed. So it's no problem if it's changed multiple times, and those 
extra mixes have an index as well.

Jef


More information about the devel mailing list