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.
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.
Suunto's create those "mandatory safety stop" things fairly aggressively. You'll get them for fast ascents etc.
Dirk, Jeff, and the libdivecomputer mailing list added to the participants list of this mail.
Linus