Subsurface + Suunto Vyper Air

[Jef Driesen]

On 14-05-15 18:47, Linus Torvalds wrote:
> On Thu, May 14, 2015 at 8:51 AM, John Nevius <john.nevius at gmail.com> wrote:
>> "in deco" shows in the 'pop-up' box that shows when you fly the cursor over
>> the dive profile.  First dive of the series, so there was no prior nitrogen
>> loading and I forgot to mention I was diving EAN32
>>
>> What is best way to share the dive profile?
>
> You could just save that single dive as an xml file (select the
> dive(s) you want to export, go to File->Export and export selected
> dives as "Subsurface XML"), we'd see it from that.
>
> That said, I don't think you need to do that. The "in deco" in your
> profile info window does indeed mean that subsurface thinks we have a
> deco obligation from the dive computer. So libdivecomputer gave us a
> DC_SAMPLE_DECO sample that is either DC_DECO_DECOSTOP or
> DC_DECO_DEEPSTOP.
>
> And I think it's that "DC_DECO_DEEPSTOP" that confuses subsurface. I
> don't think we should set in_deco because of a deepstop.
>
> Dirk, this goes back a long time to commit e3ab1c0701fc "Update deco handling".
>
> But fixing that probably wouldn't even fix your issue. The whole
> libdivecomputer deco handling is a bit odd, and it turns out that
> libdivecomputer considers a "Mandatory safety stop" to be something
> that triggers "in deco" through DC_DECO_DECOSTOP, and the most likely
> reason you got that was indeed that mandatory safety stop thing.

Yeah, a mandatory safety stop is indeed an odd concept.

Normally, you're either within the no-deco limits (DC_DECO_NDL) or you have 
decompression stops (DC_DECO_DECOSTOP). Libdivecomputer adds the safety stop 
(DC_DECO_SAFETYSTOP) and deep stop (DC_DECO_DEEPSTOP) for those dive computers 
that support this:

A safety stop is basically a special case of NDL. It's certainly not a real 
decompression stop, precisely because it's optional. If it wasn't optional, then 
it would become a normal deco stop, right? So I guess that's why Dirk mapped 
Suunto's "mandatory safety stop" to DC_DECO_DECOSTOP and not DC_DECO_SAFETYSTOP. 
For me that makes sense, but I have no idea what's really the difference between 
Suunto's mandatory and voluntary safety stop. It's kind of a contradictory.

Most deep stops are a special case of the normal deco stop. Many dive computers 
don't even bother to label them different, but some do. (For example the 
Buhlmann GF algorithm, can generate deep stops with the right parameters, but 
they are no different than the regular deco stops.) There are also the Pyle 
style deepstops. They are indeed optional, but that's usually because they are 
typically used in combination with a dive computer that don't support deep 
stops, and you want to do deep stops anyway. But in that scenario, they won't 
show up in your dive profile (as downloaded from the dive computer).

So for libdivecomputer, I consider a DC_DECO_DEEPSTOP a mandatory stop. The 
difference with a normal deco stop is only a different label given by the dive 
computer. Do you suggest we should change this semantics, and reserve the 
DC_DECO_DEEPSTOP type for a more Pyle style deepstop: a voluntary type of stop, 
and thus more similar in nature to a safety stop?

> Dirk, at least for the Suunto D9, the actual "deco" event seems to be
>
>     DC_SAMPLE_EVENT + SAMPLE_EVENT_DECOSTOP
>
> not that "DC_SAMPLE_DECO + (DC_DECO_DECOSTOP | DC_DECO_DEEPSTOP)"
>
> Of course, that makes no sense.  We shouldn't have to parse random
> events when libdivecomputer has that "SAMPLE_DECO" thing. So arguably
> this is more of a libdivecomputer issue. I do not think that suunto
> deepstops or mandatory safety stops  should cause DC_SAMPLE_DECO
> events.

The DC_SAMPLE_DECO sample is supposed to replace the SAMPLE_EVENT_DECOSTOP 
event. So you shouldn't be using those. They are only kept to maintain backwards 
compatibility for now, but they will be removed in the future.

Mosts backends have already been ported to DC_SAMPLE_DECO, but there are still a 
few that are not. Let me add that to my todo list.

> Suunto's create those "mandatory safety stop" things fairly
> aggressively. You'll get them for fast ascents etc.

If those odd "mandatory safety stops" are closer to a safety stop then a real 
deco stop, then I certainly don't mind mapping those to DC_DECO_SAFETYSTOP.

Jef