Tissue Saturation Graph not showing on second dive

[Humberto Hassey]

Hello, I am using Sub Surface 4.5.6 on Debian. On my log book my dives show the tissue saturation graph but only for the first dive of the day, on second or more no graph shows. Is this normal or a bug?

Dive Computer Oceanic Pro Plus 3

[Robert C. Helling]

Hi,

Would you mind mailing an example file that shows this behavior to me? hel...@atdotde.de Then I could have a look.

Best
Robert

[Dirk Hohndel]

On Jan 2, 2017, at 10:24 PM, Humberto Hassey <hha...@gmail.com> wrote:

Hello, I am using Sub Surface 4.5.6 on Debian. On my log book my dives show the tissue saturation graph but only for the first dive of the day, on second or more no graph shows. Is this normal or a bug?

I'm not quite sure what you mean by this, to be honest. Which graph are you referring to?

As an aside, we are getting closer to releasing Subsurface 4.6, so it might be a good idea to test Subsurface 4.6 Beta 2 which was released yesterday: 

https://subsurface-divelog.org/2017/01/announcing-subsurface-4-6-beta-2/

Thanks

/D

[Alan M]

I suspect this is something along the lines of what is shown in the attached images.

The second dive shows no ceiling when logged separately even though it would show a ceiling if it is merged with the previous dive. 

[Dirk Hohndel]

That's fascinating... with Bühlman, I get no ceiling on the second dive, even if I merge the two:

Yet when I switch to VPM-B I can reproduce what you show in your screenshot

Robert, my guess is this stems from the way we pick the deepest spot during the

dive and where VPM-B starts calculating the deco for the ascent? Or is there

another explanation why the surface interval doesn't appear to desat the diver

at all?

/D

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To post to this group, send email to subsurfac...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/91cd36fd-27cb-4bdf-819f-640a8018580a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<merged diving day 2017-01-04.PNG><unmerged dive.PNG>

[Robert C. Helling]

Am Donnerstag, 5. Januar 2017 16:15:36 UTC+1 schrieb Dirk:

Robert, my guess is this stems from the way we pick the deepest spot during the

dive and where VPM-B starts calculating the deco for the ascent? Or is there

another explanation why the surface interval doesn't appear to desat the diver

at all?

640a8018580a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
<merged diving day 2017-01-04.PNG><unmerged dive.PNG>

My short answer would be that VPM-B is weird. So I am not really surprised. It tries to spread a total amount of off-gasing over the ascent and in the case of merged dives, the surface interval between the dives and and the whole second dive constitute the ascent. So the tolerance for over saturation could well be much smaller and thus more restrictive ceilings.

What worries me, is that for me (who has set deco mode by default to Buehlmann), when opening the file with the two dives and merging them, I get ceilings on both. Then I switch to VPM-B I get what you describe and then I switch back to Buehlmann the ceiling on dive two disappears. This should not happen. I will investigate this.

Best

Robert

[Robert Helling]

Hi,

On 05 Jan 2017, at 16:26, 'Robert C. Helling' via Subsurface Divelog <subsurfac...@googlegroups.com> wrote:

What worries me, is that for me (who has set deco mode by default to Buehlmann), when opening the file with the two dives and merging them, I get ceilings on both. Then I switch to VPM-B I get what you describe and then I switch back to Buehlmann the ceiling on dive two disappears. This should not happen. I will investigate this.

a little bit of further debugging showed that in SettingsObjectWrapper::load() prefs.deco_mode gets a value 2 at startup. I have no clue why that is the case. My preferences („Buehlmann“) should get save but apparently aren’t. But I also have no clue how this SettingsObjectWrapper things is supposed to behave, so…

PAGING Tomaz….

Robert

[Robert Helling]

Hi,

On 05 Jan 2017, at 16:43, Robert Helling <hel...@atdotde.de> wrote:

a little bit of further debugging showed that in SettingsObjectWrapper::load() prefs.deco_mode gets a value 2 at startup. I have no clue why that is the case. My preferences („Buehlmann“) should get save but apparently aren’t. But I also have no clue how this SettingsObjectWrapper things is supposed to behave, so…

PAGING Tomaz….

or to be more specific: It seems to me that SettingsObjectWrapper::sync() never gets called. And the reason for that might be that there is no call for it anywhere in the code…

Robert

[Robert Helling]

Hi,

On 05 Jan 2017, at 16:48, Robert Helling <hel...@atdotde.de> wrote:

or to be more specific: It seems to me that SettingsObjectWrapper::sync() never gets called. And the reason for that might be that there is no call for it anywhere in the code…

and there is another problem: There seems to be a total confusion between

prefs.deco_mode

and

prefs.display_deco_mode.

The current state is utter non-sense. Tomas, (according to git blame you introduced the latter) could you please explain the meaning of the two and in particular their difference?

Here is my guess: There are two, because one is set in the preferences while the other is a planner parameter. They do the same thing but when chaining the value in the planner, the display of logged dives should not be affected.

So my suggestion would be to resolve this as follows: Rename deco_mode to planner_deco_mode. In all the code, when we need to inquire the current deco mode, we replace the access to the value by a getter that essentially does

currentState == PLAN ? prefs.planner_deco_mode : prefs.display_deco_mode;

What do you think?

Best

Robert

[Dirk Hohndel]

On Jan 5, 2017, at 8:00 AM, Robert Helling <hel...@atdotde.de> wrote:

Hi,

On 05 Jan 2017, at 16:48, Robert Helling <hel...@atdotde.de> wrote:

or to be more specific: It seems to me that SettingsObjectWrapper::sync() never gets called. And the reason for that might be that there is no call for it anywhere in the code…

and there is another problem: There seems to be a total confusion between

prefs.deco_mode

and

prefs.display_deco_mode.

The current state is utter non-sense. Tomas, (according to git blame you introduced the latter) could you please explain the meaning of the two and in particular their difference?

Here is my guess: There are two, because one is set in the preferences while the other is a planner parameter. They do the same thing but when chaining the value in the planner, the display of logged dives should not be affected.

Yes, that was indeed the logic.

So my suggestion would be to resolve this as follows: Rename deco_mode to planner_deco_mode. In all the code, when we need to inquire the current deco mode, we replace the access to the value by a getter that essentially does

currentState == PLAN ? prefs.planner_deco_mode : prefs.display_deco_mode;

What do you think?

I think this makes sense.

/D

[Tomaz Canabrava]

Answering on the phone.

Robert, the difference on the preferences for deco mode is what you described - one is for the planner and other is for the display. I tougth id fixed the issue you described to me in your house - and I think I did, but in the end I created another issue. The getter idea seems correct, sorry for the confusion.

Btw - sync and load are being called because your preferences are saved and restored :)

--


You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.


To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.


To post to this group, send email to subsurfac...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/57EF1A4A-0883-4475-9E84-0618CA72EBAF%40hohndel.org.

[Robert Helling]

Hi,

On 05 Jan 2017, at 21:04, Tomaz Canabrava <tcana...@kde.org> wrote:

Robert, the difference on the preferences for deco mode is what you described - one is for the planner and other is for the display. I tougth id fixed the issue you described to me in your house - and I think I did, but in the end I created another issue. The getter idea seems correct, sorry for the confusion.

Before I start coding, I have a question (which shows how little C++ I understand): What exactly does 

		ProfileWidget2 *view = qobject_cast<ProfileWidget2*>(scene()->views().first());

(this is line 266 of divetooltipitem.cpp)?

How much overhead does this have? I hope, it does not create and initialise a whole ProfileWidget2, because all we need to do is 

view->currentState == ProfileWidget2::PLAN

And we would do that (unless I somehow store the value somewhere) a lot of times (namely whenever the code differs between deco models).

Btw - sync and load are being called because your preferences are saved and restored :)

Where is the call to sync? I placed a debugging message there and that was never printed.

Best

Robert

[Dirk Hohndel]

On Jan 5, 2017, at 1:57 PM, Robert Helling <hel...@atdotde.de> wrote:

Hi,

On 05 Jan 2017, at 21:04, Tomaz Canabrava <tcana...@kde.org> wrote:

Robert, the difference on the preferences for deco mode is what you described - one is for the planner and other is for the display. I tougth id fixed the issue you described to me in your house - and I think I did, but in the end I created another issue. The getter idea seems correct, sorry for the confusion.

Before I start coding, I have a question (which shows how little C++ I understand): What exactly does 

		ProfileWidget2 *view = qobject_cast<ProfileWidget2*>(scene()->views().first());

(this is line 266 of divetooltipitem.cpp)?

How much overhead does this have? I hope, it does not create and initialise a whole ProfileWidget2, because all we need to do is 

That's literally just a pointer cast, applied to the first element in a scene. So the overhead shouldn't be dramatic.

/D