On 14-05-15 18:47, Linus Torvalds wrote:

On Thu, May 14, 2015 at 8:51 AM, John Nevius john.nevius@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