Re: Poseidon CCR dives: Nitrogen loading

[Willem Ferguson]

On 05/11/2014 09:11, Miika Turkia wrote:
On Wed, Nov 5, 2014 at 3:02 PM, Willem Ferguson 
> wrote:


Robert,
Would you be prepared to look at the sample dive log in the dives
directory? There are two versions of the same dive, one in CSV,
another in XML. When importing the CSV version, NO nitrogen
loading is shown, however when loading the XML version, nitrogen
loading is indeed shown. Are you in a position at all to say what
causes this?


Isn't nitrogen loading toggled with the N_2 button? If so, I do see 
the nitrogen loading when importing the CSV (of course, I need to 
actually select the .txt file for import, to get the Poseidon parsing 
triggered).


miika
The N2 button toggles display of the nitrogen partial pressure. But it 
does not toggle the display of the ceiling and tissue compartment 
loading (this is controlled by another button on the dive profile panel, 
the one with the diver and the up-arrow). If the gradient factors are 
shown above the profile, then it means that display of the calculation 
of nitrogen loading at the tissue compartment level is switched on. On 
my machine, the NDL remains at the maximum level (120 min) throughout 
the dive, no ceiling appears and Robert's tissue loading display (at the 
bottom of the panel and in the information box) shows NO tissue loading 
at all. Yet, the XML dive log shows strong tissue loading and looks much 
more realistic to me. I suspect it is just a variable that needs to be 
set somewhere, but I am clueless.

Kind regards,
willem

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Poseidon CCR dives: Nitrogen loading

[Miika Turkia]

On Wed, Nov 5, 2014 at 3:02 PM, Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

> Robert,
> Would you be prepared to look at the sample dive log in the dives
> directory? There are two versions of the same dive, one in CSV, another in
> XML. When importing the CSV version, NO nitrogen loading is shown, however
> when loading the XML version, nitrogen loading is indeed shown. Are you in
> a position at all to say what causes this?
>

Isn't nitrogen loading toggled with the N2 button? If so, I do see the
nitrogen loading when importing the CSV (of course, I need to actually
select the .txt file for import, to get the Poseidon parsing triggered).

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Poseidon CCR CSV dive log imports: Cylinder assignments

[Miika Turkia]

On Wed, Nov 5, 2014 at 2:48 PM, Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

> Miika,
>
> A problem arises when importing several dive logs. It appears some of the
> cylinder storage assignments are not reset between consecutive imports. I
> attach three images of the cylinder table for each of three consecutive
> imports.
> Import_1.png: First import, all assignments correct.
> Import_2.png: Two new cylinders are created and pressure info stored
> there. Gas composition info stored correctly.
> Import_3.png: Third import. Yet two more new cylinders created into which
> pressure info is stored. But gas composition info stored correctly.
>
> I cannot see anything obvious in file.c. Could it be that some sync with
> the Qt code is required?
>

I suppose we need to re-set the cylinder counter to zero when parsing a new
log file. Will this patch do the trick for you?

miika
From 9d1c426184b5bc08c757f600264716fbcd3345c6 Mon Sep 17 00:00:00 2001
From: Miika Turkia 
Date: Wed, 5 Nov 2014 15:01:56 +0800
Subject: [PATCH 2/2] Reset cylinder index when importing new MK6 log

Signed-off-by: Miika Turkia 
---
 file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/file.c b/file.c
index 60b79f2..de2c0db 100644
--- a/file.c
+++ b/file.c
@@ -430,7 +430,6 @@ char *parse_mkvi_value(const char *haystack, const char *needle)
 	return ret;
 }
 
-static int cur_cylinder_index;
 int parse_txt_file(const char *filename, const char *csv)
 {
 	struct memblock memtxt, memcsv;
@@ -450,6 +449,7 @@ int parse_txt_file(const char *filename, const char *csv)
 		bool has_depth = false, has_setpoint = false;
 		char *lineptr;
 		static int diluent_pressure = 0, cylinder_pressure = 0;
+		int cur_cylinder_index = 0;
 
 		struct dive *dive;
 		struct divecomputer *dc;
-- 
2.1.0

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Poseidon CCR dives: Nitrogen loading

[Willem Ferguson]

Robert,
Would you be prepared to look at the sample dive log in the dives 
directory? There are two versions of the same dive, one in CSV, another 
in XML. When importing the CSV version, NO nitrogen loading is shown, 
however when loading the XML version, nitrogen loading is indeed shown. 
Are you in a position at all to say what causes this?

Kind regards,
willem

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Poseidon CCR CSV dive log imports: Cylinder assignments

[Willem Ferguson]

Miika,

A problem arises when importing several dive logs. It appears some of 
the cylinder storage assignments are not reset between consecutive 
imports. I attach three images of the cylinder table for each of three 
consecutive imports.

Import_1.png: First import, all assignments correct.
Import_2.png: Two new cylinders are created and pressure info stored 
there. Gas composition info stored correctly.
Import_3.png: Third import. Yet two more new cylinders created into 
which pressure info is stored. But gas composition info stored correctly.


I cannot see anything obvious in file.c. Could it be that some sync with 
the Qt code is required?

Kind regards,
willem

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: QNetworkAccessManager and changing ApplicationProxy

[Thiago Macieira]

On Tuesday 04 November 2014 11:23:22 Dirk Hohndel wrote:
> Thiago,
> 
> silly question. I'm trying to figure out bug #752. Brief summary of that
> bug:
> 
> Proxy password not used by the app if changed on the fly
> - Proxy password has expired
> - You try to download GPS point and you get "authentication error"
> - You update the password and save new setting but the new password is not
>   used by the GPS download feature but it was correctly saved.
> - Restart the application, everything works.
> 
> When trying to debug this it seems to me that we are indeed correctly
> resetting the ApplicationProxy - but that doesn't appear to be used once
> applied. So I'm wondering if this has something to do with the fact that
> our QNetworkAccessManager was created before the change and is kept
> around...

I don't think so. The proxy configuration is queried for each request that is 
sent. I think the problem is the credential cache that QNAM holds.

> Is there a way to inform the QNetworkAccessManager of the change in proxy
> settings? Is that necessary? Am I missing something else that we need to
> do to apply the proxy settings at runtime without a restart? Am I barking
> up the completely wrong tree?

It looks like a regular Qt bug. I haven't looked at this code for a while and 
it's quite different now from when I wrote it in 2007. I'll need to debug this 
to figure out what it is.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MOD, EAD etc calculations for CCR

[Willem Ferguson]

On 04/11/2014 20:51, Robert C. Helling wrote:

On 04 Nov 2014, at 18:16, Dirk Hohndel  wrote:

Dirk,


So should I or should I not want to take this patch?

I think you could. Maybe Willem could confirm that this is what he intended as 
well.


And if I should, could you resent against master?

Here you are.


Best
Robert

--

Man, it gives me great pleasure to see this plot slowly coming together.
Thank you, Robert.
wf

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

QNetworkAccessManager and changing ApplicationProxy

[Dirk Hohndel]

Thiago,

silly question. I'm trying to figure out bug #752. Brief summary of that
bug:

Proxy password not used by the app if changed on the fly
- Proxy password has expired
- You try to download GPS point and you get "authentication error"
- You update the password and save new setting but the new password is not
  used by the GPS download feature but it was correctly saved.
- Restart the application, everything works.

When trying to debug this it seems to me that we are indeed correctly
resetting the ApplicationProxy - but that doesn't appear to be used once
applied. So I'm wondering if this has something to do with the fact that
our QNetworkAccessManager was created before the change and is kept
around...

Is there a way to inform the QNetworkAccessManager of the change in proxy
settings? Is that necessary? Am I missing something else that we need to
do to apply the proxy settings at runtime without a restart? Am I barking
up the completely wrong tree?

Thanks

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MOD, EAD etc calculations for CCR

[Robert C. Helling]

On 04 Nov 2014, at 18:16, Dirk Hohndel  wrote:

Dirk,

> So should I or should I not want to take this patch?

I think you could. Maybe Willem could confirm that this is what he intended as 
well.

> And if I should, could you resent against master?

Here you are.



0001-Use-the-CCR-corrected-gases-for-EAD-and-END-calculat.patch
Description: Binary data


Best
Robert

--  
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO 
Robert C. Helling Elite Master Course Theoretical and Mathematical Physics  
  Scientific Coordinator   
  Ludwig Maximilians Universitaet Muenchen, Dept. Physik
print "Just another   Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339   
stupid .sig\n";   http://www.atdotde.de 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MOD, EAD etc calculations for CCR

[Dirk Hohndel]

On Tue, Nov 04, 2014 at 03:49:35PM +0100, Robert Helling wrote:
> 
> Willem,
> 
> > With respect to MOD you are not mistaken, and your argument is perfectly 
> > valid. Let's drop my dreaming and stick to the present situation.
> > With respect to EAD and the rest, may I look around that code and send you 
> > a proposal?
> 
> sorry, I read this too late. I already wrote a patch (attached).

So should I or should I not want to take this patch?
And if I should, could you resent against master?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Replan copy of a dive

[Dirk Hohndel]

On Tue, Nov 04, 2014 at 12:30:02PM +0100, Robert Helling wrote:
> Hi,
> 
> to support planning several versions of a dive, add the possibility to create 
> a new dive upon replan rather than override the old dive.
> 
> This took me several attempts to get it working, it was harder to get right 
> than I originally thought. But I think this works now.

The code looked fine but I haven't played with it much.
I wonder if we should pop up a warning when we have a dive AFTER the
multiple alternative dives that only the first one is taken into account.
Or at least a tool tip or something.

Or maybe I'm overthinking this?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Fwd: Two more rebreather patches

[Dirk Hohndel]

On Tue, Nov 04, 2014 at 10:01:05AM +0100, Robert Helling wrote:
> 
> I think these two patches have not yet been applied.

Sorry about that. I like the first one, the second one is marginal but it
should have no negative impact, so I took it. It didn't apply but was easy
to fix. Still, please double check.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Make disabled stars semi-transparent

[Dirk Hohndel]

On Tue, Nov 04, 2014 at 09:47:44AM +0100, Robert Helling wrote:
> 
> > Hate to disappoint your wife... but on Linux / KDE this looks positively
> > weird... the center of the unselected stars is now red for some reason.
> > 
> > Looking at the code I have not the slightest idea why it would do that...
> 
> this is weird. On Linux with gnome it is the selected grey stars (i.e. the 
> grey ones of the selected dives) which are red.
> 
> Here is another attempt at this without using the alpha channel.

Excellent. This one is looking really good.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MOD, EAD etc calculations for CCR

[Robert Helling]

On 04.11.2014, at 11:48, Willem Ferguson  wrote:Willem,
  

  
  


With respect to MOD you are not mistaken, and your argument is
perfectly valid. Let's drop my dreaming and stick to the present
situation.
With respect to EAD and the rest, may I look around that code and
send you a proposal?sorry, I read this too late. I already wrote a patch (attached).BestRobert

0001-Use-the-CCR-corrected-gases-for-EAD-and-END-calculat.patch
Description: Binary data

-- .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oORobert C. Helling     Elite Master Course Theoretical and Mathematical Physics                      Scientific Coordinator                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339                      http://www.atdotde.deEnhance your privacy, use cryptography! My PGP keys have fingerprintsA9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    andDCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Importing CCR data [was: CCR Testing]

[Paul Sargent]

On 3 Nov 2014, at 23:47, Anton Lundin  wrote:

>> (I’ve dropped off NDL, CNS, TTS, & pressure from the current list. CNS is 
>> calculable. NDL & TTS aren’t that important if you’ve got the ceiling IMHO. 
>> Pressure I assume is cylinder pressure - How many do you want? Possibly just 
>> 1, but no more)
>> 
> 
> I think those are quite interesting to look at, and to compare with what
> Subsurface calculates and what the DC reported. I use it as a sanity
> check between different DC's and Subsurface.

I’m not sure I explained myself very well. I wasn’t saying that we should lose 
any feature for a particular dive computer.

My thinking was that you select a CSV file, and then a box comes up asking you 
what format it is. It would just be a list of known schemes and one entry 
“Custom…”. Selecting custom takes you to the field setup (much like we already 
have). 

Known schemes would be "black boxes" to the user, not needing any 
configuration. Then the complexity behind any known scheme is unlimited, and it 
can import any and all weird and wonderful info. Once you’ve got that, the 
custom field setup can be simplified because it’s no longer trying to cover 
EVERYTHING.

> I think we should import as much data as possible from the different
> formats. If we can find a format that contains data that we currently
> can't import, I kinda enjoy hacking on such features =)

That’s great, but that then becomes a known format. We can have an entry for 
it, and hide the gory details (i.e. your hacking ;o) ). They way we’re free to 
do crazy stuff in the code for some specific dive computer, without needing to 
come up with a piece of GUI to switch it on. We just add it to the list.

> Hmm... Sane defaults and hiding some of the gory details is probably the
> right way to go, but why not just put those gory details in a "advanced"
> page or something? If you open a "advanced" page and get a ridiculous
> amounts of settings, nobody will be surprised.

Do you want to design that page? I don’t want to. Sounds complicated and boring.
(i.e. The main problem is someone has to design and maintain it.)

Anyway, I’m just throwing ideas around.

Paul






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Replan copy of a dive

[Robert Helling]

Hi,to support planning several versions of a dive, add the possibility to create a new dive upon replan rather than override the old dive.

0001-Offer-to-save-to-a-copy-in-replan-mode.patch
Description: Binary data
This took me several attempts to get it working, it was harder to get right than I originally thought. But I think this works now.BestRobert
-- .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oORobert C. Helling     Elite Master Course Theoretical and Mathematical Physics                      Scientific Coordinator                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339                      http://www.atdotde.deEnhance your privacy, use cryptography! My PGP keys have fingerprintsA9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    andDCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MOD, EAD etc calculations for CCR

[Willem Ferguson]

On 04/11/2014 12:27, Robert Helling wrote:


On 04.11.2014, at 11:17, Willem Ferguson 
> wrote:



On 04/11/2014 11:10, Robert Helling wrote:


On 04.11.2014, at 08:45, Willem Ferguson 
> wrote:


Willem,

The calculation of MOD, EAD and the like that happens in profile.c 
does not work for CCR because it is based on the gas mix info 
associated with individual cylinders. Function gas_mod in dive.h is 
a case in point. I was starting to mess around with these 
calculations to use dynamic fo2 values for each point on the dive 
profile (instead of fixed cylinder-specific fo2 values), but then I 
saw that this function is used in many places, including 
extensively in the planner.


I am not sure exactly what would be the meaning of MOD for a CCR 
given the dynamic O2 content. The only way I think this makes sense 
would be the MOD of the dillutant (since that sets the minimum fO2 
that the CCR can deliver and that determines the depth).


I was thinking that it would be useful that a diver could review a 
dive and see at a particular moment, how far he/she was from the MOD, 
given the gas composition at that moment in time. Let's the fo2 was 
35% at a particular moment and the diver was 30m deep. The diver 
should know that this was pretty close to the MOD for that particular 
gas combination. This might for instance affect decision making with 
respect to setpoints. Of course the dive computer should provide such 
facilities for decision making and/or automatic control during the 
dive, but for the review of a dive afterwards, this information might 
be useful.


Does the “how close relative to the current mix” really make sense for 
a CCR? Take for example a set-point of 1.3bar and use as your max pO2 
for calculating an MOD 1.6. Then the MOD will always be the depth 
corrspoding to an ambient pressure of


1.6/1.3 * ambeint_pressure

i.e. with 1.3 and 1.6 bar, your ambient pressure will always be 81% of 
the ambient pressure of the MOD if I am not mistaken. Is that what you 
wanted to calculate?


Indeed, gas_mod is used in various places but only the call in 
profile.c is about the current gas, in all other cases the MOD of an 
explicit cylinder is calculated (essentially to find the max depth 
to switch to it). What I would probably do is to leave everything as 
it is and only wrap the call in profile.c with an if(dc.dctype != 
CCR) { and in the else clause make sure the dillutant is used.


I guess the others EAD, END and EADD should be ok the way they are 
since they use the info from fill_pressures which takes CCR-ness 
into account.




At the moment it gives EAD of 0m throughout the dive and EADD of 
current_depth, but I have not looked at that code closely to explain 
that. However I note that fhe and fo2 are derived from 
cylinder-related data, using get_o2() and get_he().




I am currently knee-deep in debugging the replanting code. Will look 
into this once I am back.


Best
Robert
With respect to MOD you are not mistaken, and your argument is perfectly 
valid. Let's drop my dreaming and stick to the present situation.
With respect to EAD and the rest, may I look around that code and send 
you a proposal?

Kind regards,
willen

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MOD, EAD etc calculations for CCR

[Robert Helling]

On 04.11.2014, at 11:17, Willem Ferguson  
wrote:

> On 04/11/2014 11:10, Robert Helling wrote:
>> 
>> On 04.11.2014, at 08:45, Willem Ferguson  
>> wrote:
>> 
>> Willem,
>> 
>>> The calculation of MOD, EAD and the like that happens in profile.c does not 
>>> work for CCR because it is based on the gas mix info associated with 
>>> individual cylinders. Function gas_mod in dive.h is a case in point. I was 
>>> starting to mess around with these calculations to use dynamic fo2 values 
>>> for each point on the dive profile (instead of fixed cylinder-specific fo2 
>>> values), but then I saw that this function is used in many places, 
>>> including extensively in the planner.
>> 
>> 
>> I am not sure exactly what would be the meaning of MOD for a CCR given the 
>> dynamic O2 content. The only way I think this makes sense would be the MOD 
>> of the dillutant (since that sets the minimum fO2 that the CCR can deliver 
>> and that determines the depth).
>> 
> I was thinking that it would be useful that a diver could review a dive and 
> see at a particular moment, how far he/she was from the MOD, given the gas 
> composition at that moment in time. Let's the fo2 was 35% at a particular 
> moment and the diver was 30m deep. The diver should know that this was pretty 
> close to the MOD for that particular gas combination. This might for instance 
> affect decision making with respect to setpoints. Of course the dive computer 
> should provide such facilities for decision making and/or automatic control 
> during the dive, but for the review of a dive afterwards, this information 
> might be useful.

Does the “how close relative to the current mix” really make sense for a CCR? 
Take for example a set-point of 1.3bar and use as your max pO2 for calculating 
an MOD 1.6. Then the MOD will always be the depth corrspoding to an ambient 
pressure of

1.6/1.3 * ambeint_pressure 

i.e. with 1.3 and 1.6 bar, your ambient pressure will always be 81% of the 
ambient pressure of the MOD if I am not mistaken. Is that what you wanted to 
calculate?
> 
>> Indeed, gas_mod is used in various places but only the call in profile.c is 
>> about the current gas, in all other cases the MOD of an explicit cylinder is 
>> calculated (essentially to find the max depth to switch to it). What I would 
>> probably do is to leave everything as it is and only wrap the call in 
>> profile.c with an if(dc.dctype != CCR) { and in the else clause make sure 
>> the dillutant is used.
>> 
>> I guess the others EAD, END and EADD should be ok the way they are since 
>> they use the info from fill_pressures which takes CCR-ness into account.
>> 
> 
> At the moment it gives EAD of 0m throughout the dive and EADD of 
> current_depth, but I have not looked at that code closely to explain 
> that. However I note that fhe and fo2 are derived from cylinder-related data, 
> using get_o2() and get_he().
> 

I am currently knee-deep in debugging the replanting code. Will look into this 
once I am back.

Best
Robert


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MOD, EAD etc calculations for CCR

[Willem Ferguson]

On 04/11/2014 11:10, Robert Helling wrote:


On 04.11.2014, at 08:45, Willem Ferguson 
> wrote:


Willem,

The calculation of MOD, EAD and the like that happens in profile.c 
does not work for CCR because it is based on the gas mix info 
associated with individual cylinders. Function gas_mod in dive.h is a 
case in point. I was starting to mess around with these calculations 
to use dynamic fo2 values for each point on the dive profile (instead 
of fixed cylinder-specific fo2 values), but then I saw that this 
function is used in many places, including extensively in the planner.


I am not sure exactly what would be the meaning of MOD for a CCR given 
the dynamic O2 content. The only way I think this makes sense would be 
the MOD of the dillutant (since that sets the minimum fO2 that the CCR 
can deliver and that determines the depth).


I was thinking that it would be useful that a diver could review a dive 
and see at a particular moment, how far he/she was from the MOD, given 
the gas composition at that moment in time. Let's the fo2 was 35% at a 
particular moment and the diver was 30m deep. The diver should know that 
this was pretty close to the MOD for that particular gas combination. 
This might for instance affect decision making with respect to 
setpoints. Of course the dive computer should provide such facilities 
for decision making and/or automatic control during the dive, but for 
the review of a dive afterwards, this information might be useful.


Indeed, gas_mod is used in various places but only the call in 
profile.c is about the current gas, in all other cases the MOD of an 
explicit cylinder is calculated (essentially to find the max depth to 
switch to it). What I would probably do is to leave everything as it 
is and only wrap the call in profile.c with an if(dc.dctype != CCR) { 
and in the else clause make sure the dillutant is used.


I guess the others EAD, END and EADD should be ok the way they are 
since they use the info from fill_pressures which takes CCR-ness into 
account.




At the moment it gives EAD of 0m throughout the dive and EADD of 
current_depth, but I have not looked at that code closely to explain 
that. However I note that fhe and fo2 are derived from cylinder-related 
data, using get_o2() and get_he().



What do you think?

Best
Robert


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: MOD, EAD etc calculations for CCR

[Robert Helling]

On 04.11.2014, at 08:45, Willem Ferguson  
wrote:

Willem,

> The calculation of MOD, EAD and the like that happens in profile.c does not 
> work for CCR because it is based on the gas mix info associated with 
> individual cylinders. Function gas_mod in dive.h is a case in point. I was 
> starting to mess around with these calculations to use dynamic fo2 values for 
> each point on the dive profile (instead of fixed cylinder-specific fo2 
> values), but then I saw that this function is used in many places, including 
> extensively in the planner.


I am not sure exactly what would be the meaning of MOD for a CCR given the 
dynamic O2 content. The only way I think this makes sense would be the MOD of 
the dillutant (since that sets the minimum fO2 that the CCR can deliver and 
that determines the depth).

Indeed, gas_mod is used in various places but only the call in profile.c is 
about the current gas, in all other cases the MOD of an explicit cylinder is 
calculated (essentially to find the max depth to switch to it). What I would 
probably do is to leave everything as it is and only wrap the call in profile.c 
with an if(dc.dctype != CCR) { and in the else clause make sure the dillutant 
is used.

I guess the others EAD, END and EADD should be ok the way they are since they 
use the info from fill_pressures which takes CCR-ness into account.

What do you think?

Best
Robert

-- 
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling Elite Master Course Theoretical and Mathematical Physics
  Scientific Coordinator
  Ludwig Maximilians Universitaet Muenchen, Dept. Physik
  Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
  http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1Dand
DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Fwd: Two more rebreather patches

[Robert Helling]

Hi,I think these two patches have not yet been applied.BestRobertBegin forwarded message:From: Robert Helling Subject: Two more rebreather patchesDate: 24. Oktober 2014 16:48:34 MESZTo: subsurface@subsurface-divelog.orgHi,since we seem to be going towards planning for rebreathers as well (what happened to Gaetan’s attempts at coming up with a UI implementation?), here are two more patches:1) For the time being, simply pretend in CCR phases we don’t consume any gas (and warn about it in the notes). I guess the consensus was that the O2 consumption is basically only time and not depth dependent and the dillutent consumption is little and somewhat hard to calculate.2) Introduce (steady state) calculations for PSCR’s, so far without any UI and thus no way to actually do them.BestRobert

0001-Don-t-track-gas-consuption-on-CCR-legs.patch
Description: Binary data


0002-Prepare-for-PSCR-calculations.patch
Description: Binary data

-- .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oORobert C. Helling     Elite Master Course Theoretical and Mathematical Physics                      Scientific Coordinator                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339                      http://www.atdotde.deEnhance your privacy, use cryptography! My PGP keys have fingerprintsA9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    andDCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F


-- .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oORobert C. Helling     Elite Master Course Theoretical and Mathematical Physics                      Scientific Coordinator                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339                      http://www.atdotde.deEnhance your privacy, use cryptography! My PGP keys have fingerprintsA9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    andDCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Make disabled stars semi-transparent

[Robert Helling]

On 04.11.2014, at 00:02, Dirk Hohndel  wrote:Hi Dirk,Hate to disappoint your wife... but on Linux / KDE this looks positivelyweird... the center of the unselected stars is now red for some reason.Looking at the code I have not the slightest idea why it would do that...this is weird. On Linux with gnome it is the selected grey stars (i.e. the grey ones of the selected dives) which are red.Here is another attempt at this without using the alpha channel.BestRobert

0001-Replace-alpha-value-of-gray-star-with-lighter-gray.patch
Description: Binary data

-- .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oORobert C. Helling     Elite Master Course Theoretical and Mathematical Physics                      Scientific Coordinator                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339                      http://www.atdotde.deEnhance your privacy, use cryptography! My PGP keys have fingerprintsA9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    andDCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface