Re: [PATCH] Poseidon MK6 import
On 27.10.2014, at 04:27, Dirk Hohndel d...@hohndel.org wrote: Good morning, Robert appears to have stepped up to help our Willem to get this right, but the more people work on this and help figure out what's the right way to do things, the better. indeed, more people needed here. I cannot say I have any sort of overview about the recently added CCR functionality. I have only only spent some time on debugging to make sure features that worked before got unbroken again. And of course, I don’t dive rebreathers myself (currently I am not diving anything unfortunately, stupid flu!) so all my knowledge is from hearsay anyway. Re the compression thing: I agree it should not be in memory, only when saving files. And then repeated values should be omitted rather than set to zero as zero has a special meaning: Zero set point indicates that we are on OC and shortcuts all CCR calculations. BTW, another thing that need some looking after (for which I did not have time, yet) is when we calculate SAC rates: For the PSCR code, that I submitted on Friday, the steady state value of pO2 depends (amongst other things) on the current SAC. But often enough (at least when I was testing) it had not yet been calculated so the pO2 calculation has to resort to the default value (see the first if() in the code). My impression is that in many cases, there should be enough data to have a SAC but we only calculate it later in the code path. This is particularly bad, since we have two different default values for SAC, one for bottom time and one for deco, except that for real dives (those downloaded from dive computers) this distinction does not make sense. 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
Re: [PATCH 0/9] fix some warnings
On 27 October 2014 05:18, Dirk Hohndel d...@hohndel.org wrote: On Sat, Oct 25, 2014 at 01:03:28PM +0300, Lubomir I. Ivanov wrote: please ignore anything in particular if you see fit. i'm not really advocating any of these. [PATCH 1/9] MainWindow: prevent a possible crash on re-plan [PATCH 2/9] configuredivecomputerdialog.ui: fix a UIC warning [PATCH 3/9] globe.cpp: fix a NO_MARBLE warning [PATCH 4/9] divelogexportdialog.cpp: fix a 'uninitialized variable' [PATCH 5/9] divelogexportdialog.cpp: attempt to fix a 'unsigned / [PATCH 6/9] deco.c: remove unused variables in add_segment() [PATCH 7/9] profile.c: remove unused variables in [PATCH 8/9] profile.c: remove a variable which is set but not used [PATCH 9/9] divelistview.cpp: move a variable in a Q_OS_MAC branch Maybe this was caused by the mailing list issues, but I only appear to have 3, 4, 6, 7, 8 hello, here are all patches as attachments, rebased against master. lubomir -- 0006-deco.c-remove-unused-variables-in-add_segment.patch Description: Binary data 0007-profile.c-remove-unused-variables-in-calculate_ccr_p.patch Description: Binary data 0008-profile.c-remove-a-variable-which-is-set-but-not-use.patch Description: Binary data 0009-divelistview.cpp-move-a-variable-in-a-Q_OS_MAC-branc.patch Description: Binary data 0001-MainWindow-prevent-a-possible-crash-on-re-plan.patch Description: Binary data 0002-configuredivecomputerdialog.ui-fix-a-UIC-warning.patch Description: Binary data 0003-globe.cpp-fix-a-NO_MARBLE-warning.patch Description: Binary data 0004-divelogexportdialog.cpp-fix-a-uninitialized-variable.patch Description: Binary data 0005-divelogexportdialog.cpp-attempt-to-fix-a-unsigned-si.patch Description: Binary data ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Poseidon MK6 import
Good morning... On Mon, Oct 27, 2014 at 08:42:12AM +0100, Robert Helling wrote: Robert appears to have stepped up to help our Willem to get this right, but the more people work on this and help figure out what's the right way to do things, the better. indeed, more people needed here. I cannot say I have any sort of overview about the recently added CCR functionality. I have only only spent some time on debugging to make sure features that worked before got unbroken again. And of course, I don’t dive rebreathers myself (currently I am not diving anything unfortunately, stupid flu!) so all my knowledge is from hearsay anyway. So who are the rebreather divers besides Willem who are helping to get this right and are especially testing this as thoroughly as possible. I'd hate to release 4.3 and announve rebreather support and then have to say never mind... Re the compression thing: I agree it should not be in memory, only when saving files. And then repeated values should be omitted rather than set to zero as zero has a special meaning: Zero set point indicates that we are on OC and shortcuts all CCR calculations. Exactly. I need to go through the recent patches again and figure out where this was added. I was definitely too relaxed accepting rebreather changes, but I figured this was the best way to get stuff in and get people to start testing, given the challenges we had to get patches to work in the first place. BTW, another thing that need some looking after (for which I did not have time, yet) is when we calculate SAC rates: For the PSCR code, that I submitted on Friday, the steady state value of pO2 depends (amongst other things) on the current SAC. But often enough (at least when I was testing) it had not yet been calculated so the pO2 calculation has to resort to the default value (see the first if() in the code). My impression is that in many cases, there should be enough data to have a SAC but we only calculate it later in the code path. This is particularly bad, since we have two different default values for SAC, one for bottom time and one for deco, except that for real dives (those downloaded from dive computers) this distinction does not make sense. I'm still unclear how we are calculating the SAC in the PSCR case. So I can't quite tell you where this should be done. I repeat my question from above - who else on this list dives rebreather, understands the logic behind all this and can help get this right? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On Mon, Oct 27, 2014 at 12:37 PM, William Perry wmpe...@kadath.us wrote: I just finished by CCR training down in Bonaire last week so I don’t have a lot of experience, but I did find that minor depth changes did not impact the loop volume enough for me to feel the need to add diluent. My inhale was cut very slightly short (I was diving with the auto-diluent-valve off after the initial big descent). This would be equivalent to the occasional mask clear at depth. If you are doing a ton of 10 meter ascents/descents in a cave system as it winds around then those will add up quickly, but 1-2 footers is noise. Bill, I agree: 1/2 foot is noise, 10 m is significant. What value do you think we should use as limit? I just proposed 1 m on my previous email to Robert but I'm not sure if this value is big enough. What do you think? Would tracking only the size of the counter lungs be sufficient? I don't think any of this is necessary, neither counter lungs volume nor loop volume as I mentioned on my previous email. Regards, Rodrigo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Poseidon MK6 import
I can probably get my instructor to run a download against a bunch of shearwaters or Nitek Qs with the 4th cell monitoring if we need test data for subsurface or libdivecomputer. Maybe I can convince my wife that I need to buy the rebreather a bit earlier than planned so I can help… :) -bill On Oct 27, 2014, at 11:23 AM, Paul Sargent paul.lions...@icloud.com wrote: On Oct 27, 2014, at 03:34 PM, Dirk Hohndel d...@hohndel.org wrote: Good morning... On Mon, Oct 27, 2014 at 08:42:12AM +0100, Robert Helling wrote: Robert appears to have stepped up to help our Willem to get this right, but the more people work on this and help figure out what's the right way to do things, the better. indeed, more people needed here. I cannot say I have any sort of overview about the recently added CCR functionality. I have only only spent some time on debugging to make sure features that worked before got unbroken again. And of course, I don’t dive rebreathers myself (currently I am not diving anything unfortunately, stupid flu!) so all my knowledge is from hearsay anyway. So who are the rebreather divers besides Willem who are helping to get this right and are especially testing this as thoroughly as possible. I'd hate to release 4.3 and announve rebreather support and then have to say never mind... I'm certainly happy to look over as much as I can, but it's limited by what I can exercise from my dive data. As far as I can tell a number of the patches recently deal with utilising ppO2 data from the sensors, and the only unit we can import ppO2 data from is a MkVI. I don't dive a MkVI, so whilst I can test planning CCR dives, or imported constant ppO2 CCR dives from an OSTC, I can't exercise everything. Let me know what you'd like me to attack ;-) Paul ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On Oct 27, 2014, at 10:42 AM, Rodrigo Severo rodr...@fabricadeideias.com wrote: On Mon, Oct 27, 2014 at 12:37 PM, William Perry wmpe...@kadath.us wrote: I just finished by CCR training down in Bonaire last week so I don’t have a lot of experience, but I did find that minor depth changes did not impact the loop volume enough for me to feel the need to add diluent. My inhale was cut very slightly short (I was diving with the auto-diluent-valve off after the initial big descent). This would be equivalent to the occasional mask clear at depth. If you are doing a ton of 10 meter ascents/descents in a cave system as it winds around then those will add up quickly, but 1-2 footers is noise. Bill, I agree: 1/2 foot is noise, 10 m is significant. What value do you think we should use as limit? I just proposed 1 m on my previous email to Robert but I'm not sure if this value is big enough. What do you think? Maybe start tracking it if they stay at the new depth for more than a certain # of samples? If I just drop down quickly to look at something I’m not going to mind a short breath or two but if I am following the contour of the reef and stay at that depth for 5-10 minutes I will probably squirt in some diluent. I’m generally not a fan of heuristics like that though. Would tracking only the size of the counter lungs be sufficient? I don't think any of this is necessary, neither counter lungs volume nor loop volume as I mentioned on my previous email. Yes, if we are just worrying about determining a SAC rate after the fact. Would some indication of loop volume help for planning these dives though? -bill ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On Oct 27, 2014, at 03:42 PM, Rodrigo Severo rodr...@fabricadeideias.com wrote: Bill, I agree: 1/2 foot is noise, 10 m is significant. What value do you think we should use as limit? I just proposed 1 m on my previous email to Robert but I'm not sure if this value is big enough. What do you think? It'd be interesting to put some code together, run it on real dive data and see how the predicted number compared with the measured one. Until you do I think it'd be difficult to know where the noise filter level needs to be set. Would tracking only the size of the counter lungs be sufficient? I don't think any of this is necessary, neither counter lungs volume nor loop volume as I mentioned on my previous email. Without knowing has much gas is in the loop (note: not counter lung size, which is part of the maximum loop volume) you can't know how much diluent to add to maintain it*. Example: 5l of gas in the loop. Decend from surface to 10m (2bar). I need to double the mass of gas in the loop to maintain volume, hence I need to add 5l (surface equivalent mass**). Counter lung (maximum) volume is irrelevent, because divers try not to run maximum volume. In fact they try to run minimum volume (i.e. 1 human lung full) because doing so uses less gas and is easier to control (buoyancy). You probably need to work out an average of what this diver tends to do (like SAC) and use that in predictions. Paul * Similarly, You can't know how much O2 to add to raise the ppO2 by some amount without knowing how much gas is in the loop. Hence ascents are tricky too ** Terminology when talking about amounts of gas under pressure is hard. Really we should talk about masses of gas, but we don't. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Poseidon MK6 import
On Oct 27, 2014, at 04:26 PM, William Perry wmpe...@kadath.us wrote: I can probably get my instructor to run a download against a bunch of shearwaters or Nitek Qs with the 4th cell monitoring if we need test data for subsurface or libdivecomputer. I've got tons of Shearwater data. Can probably get Inspiration data really easily as well. Paul ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Poseidon MK6 import
On Mon, Oct 27, 2014 at 03:23:11PM +, Paul Sargent wrote: So who are the rebreather divers besides Willem who are helping to get this right and are especially testing this as thoroughly as possible. I'd hate to release 4.3 and announve rebreather support and then have to say never mind... I'm certainly happy to look over as much as I can, but it's limited by what I can exercise from my dive data. As far as I can tell a number of the patches recently deal with utilising ppO2 data from the sensors, and the only unit we can import ppO2 data from is a MkVI. I don't dive a MkVI, so whilst I can test planning CCR dives, or imported constant ppO2 CCR dives from an OSTC, I can't exercise everything. And that's fine. Let me know what you'd like me to attack ;-) Everything that you CAN use. So for the dives that you import, do the things that we show make sense? Is there a way they could (should?) make more sense? Does the planning seem right? Pieces missing? I simply notice that almost every time I do something that I usually don't play much with, I quickly find little bugs. And I worry that that's the experience for a lot of our users as well. And especially since tech divers appear to be a reasonably big part of our user base, I want to make sure we get this right :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Poseidon MK6 import
On Mon, Oct 27, 2014 at 11:26:52AM -0400, William Perry wrote: I can probably get my instructor to run a download against a bunch of shearwaters or Nitek Qs with the 4th cell monitoring if we need test data for subsurface or libdivecomputer. I'll leave this to the experts to ask for the data that would help them. I simply don't know. Usually my response is the more test data, the better, but I don't even know what to ask for :-/ Maybe I can convince my wife that I need to buy the rebreather a bit earlier than planned so I can help… :) That seems totally reasonable to me... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On Mon, Oct 27, 2014 at 11:29:47AM -0400, William Perry wrote: I just finished by CCR training down in Bonaire last week so I don’t have a lot of experience, but I did find that minor depth changes did not impact the loop volume enough for me to feel the need to add diluent. My inhale was cut very slightly short (I was diving with the auto-diluent-valve off after the initial big descent). This would be equivalent to the occasional mask clear at depth. If you are doing a ton of 10 meter ascents/descents in a cave system as it winds around then those will add up quickly, but 1-2 footers is noise. I agree: 1/2 foot is noise, 10 m is significant. What value do you think we should use as limit? I just proposed 1 m on my previous email to Robert but I'm not sure if this value is big enough. What do you think? Maybe start tracking it if they stay at the new depth for more than a certain # of samples? If I just drop down quickly to look at something I’m not going to mind a short breath or two but if I am following the contour of the reef and stay at that depth for 5-10 minutes I will probably squirt in some diluent. I’m generally not a fan of heuristics like that though. With the benefit of absolutely know subject matter expertize, I think what would make sense is to smooth out the depth graph. Something like a gliding average across one minute - that should remove jitter and the quick pop down to look at things that you describe, at the same time it should be reasonably close to what I would call the perceived depth during a dive - and I think that's what people will tend to base their change to the counter lung content on... Again, just running my mouth (errr, fingers) and making things up here :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH 1/2] Do not zero setpoint value when duplicate
We cannot zero setpoint value upon import if the current and previous
values are zero. This is because on setpoint context a value of 0 means
open circuit.
Signed-off-by: Miika Turkia miika.tur...@gmail.com
---
dive.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/dive.c b/dive.c
index 92637fe..9395c93 100644
--- a/dive.c
+++ b/dive.c
@@ -1092,7 +1092,7 @@ static void fixup_dive_dc(struct dive *dive, struct
divecomputer *dc)
int maxdepth = dc-maxdepth.mm;
int mintemp = 0;
int lastdepth = 0;
- int lasto2val[3] = { 0, 0, 0 }, lasto2setpoint = 0;
+ int lasto2val[3] = { 0, 0, 0 };
int lasttemp = 0, lastpressure = 0, lastdiluentpressure = 0;
int pressure_delta[MAX_CYLINDERS] = { INT_MAX, };
@@ -1166,15 +1166,6 @@ static void fixup_dive_dc(struct dive *dive, struct
divecomputer *dc)
}
}
- // If there are consecutive identical CCR O2 setpoint readings,
throw away the redundant ones.
- o2val = sample-setpoint.mbar;
- if (o2val) {
- if (lasto2setpoint == o2val)
- sample-setpoint.mbar = 0;
- else
- lasto2setpoint = o2val;
- }
-
update_min_max_temperatures(dive, sample-temperature);
depthtime += (time - lasttime) * (lastdepth + depth) / 2;
--
1.9.1
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Poseidon MK6 import
Ok, I'll try to put some time aside over the next couple of days to have a play. On Oct 27, 2014, at 05:05 PM, Dirk Hohndel d...@hohndel.org wrote: On Mon, Oct 27, 2014 at 03:23:11PM +, Paul Sargent wrote: So who are the rebreather divers besides Willem who are helping to get this right and are especially testing this as thoroughly as possible. I'd hate to release 4.3 and announve rebreather support and then have to say never mind... I'm certainly happy to look over as much as I can, but it's limited by what I can exercise from my dive data. As far as I can tell a number of the patches recently deal with utilising ppO2 data from the sensors, and the only unit we can import ppO2 data from is a MkVI. I don't dive a MkVI, so whilst I can test planning CCR dives, or imported constant ppO2 CCR dives from an OSTC, I can't exercise everything. And that's fine. Let me know what you'd like me to attack ;-) Everything that you CAN use. So for the dives that you import, do the things that we show make sense? Is there a way they could (should?) make more sense? Does the planning seem right? Pieces missing? I simply notice that almost every time I do something that I usually don't play much with, I quickly find little bugs. And I worry that that's the experience for a lot of our users as well. And especially since tech divers appear to be a reasonably big part of our user base, I want to make sure we get this right :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
towards 4.3
A few notes... - I would like to have a first beta released no later than Nov 10. - I have fixed the script that created the daily builds. It was still uploading them to the old site. :facepalm: - I will make a go/no-go decision on some of the features in a week or so; what that means is that some things that are not in a reasonable state may end up getting disabled for 4.3, to be continued once 4.3 is out Translations: I will push the latest strings in the next hour or two Documentation / User Manual / Manual Translations: let's wait for Willem to be back (I think he said he'd be back on the 28th, but I may be making this up) and figure out how we want to do that. With Tomaz out I assume the multi-filter will be delayed to 4.4. The current filters are marginally useful, I'll have to play with them some more to understand if I want to keep them or if the things I hate about them are beyond my ability to fix. Can you guys get the CCR stuff into a reasonably clean state in the next couple of weeks? Or should we disable this? What other things are partly done and likely / unlikely to be finished in the next two weeks? Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On Mon, Oct 27, 2014 at 2:10 PM, Dirk Hohndel d...@hohndel.org wrote: With the benefit of absolutely know subject matter expertize, I think what would make sense is to smooth out the depth graph. Something like a gliding average across one minute - that should remove jitter and the quick pop down to look at things that you describe, at the same time it should be reasonably close to what I would call the perceived depth during a dive - and I think that's what people will tend to base their change to the counter lung content on... I believe this gliding average could be a really good solution for this issue. Could it be used for anything else or would it be used just for SAC calculation of diluent on CCR dives? Rodrigo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: towards 4.3
On Mon, Oct 27, 2014 at 01:34:37PM -0400, John Van Ostrand wrote: What other things are partly done and likely / unlikely to be finished in the next two weeks? Any chance the Cochran import can make it in? That's more a libdivecomputer question. Or are there Subsurface patches as well that I have ignored? I have been chatting with Jef a bit and he has been crazy busy the last few weeks and while he is thrilled that people are contributing (I did the A300CS, you did Cochran, Linus did the Suunto Eon Steel) that has only added to the workload. I know, this sounds backwards, but I know exactly how Jef feels. Working with contributors takes time. In the big picture it saves time if more people continue to contribute, but initially there is this extra effort... From a Subsurface point of view, I'll wait to see what Jef thinks is reasonable. In the past he has done heroic efforts to get things integrated in time for our releases. If Jef says sorry guys, I won't be able to get any of this integrated in the next two weeks (which is always possible, life comes first) I might be talked into doing a custom built (i.e., a temporary fork) in order to add support for those three dive computers to Subsurface 4.3 (actually, I think it's more than three - how many different devices do your patches cover? two? three?), but I really would prefer not to have to do so. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH 2/6] Set a max value for the custom text in OSTC3
The device supports a up to 60 chars custom text. This limits the LineEdit to that amount, so users see when they reach the max limit. Signed-off-by: Anton Lundin gla...@acc.umu.se --- qt-ui/configuredivecomputerdialog.ui | 3 +++ 1 file changed, 3 insertions(+) diff --git a/qt-ui/configuredivecomputerdialog.ui b/qt-ui/configuredivecomputerdialog.ui index 1b3a781..17e83fd 100644 --- a/qt-ui/configuredivecomputerdialog.ui +++ b/qt-ui/configuredivecomputerdialog.ui @@ -264,6 +264,9 @@ verstretch0/verstretch /sizepolicy /property + property name=maxLength + number60/number + /property /widget /item item row=1 column=3 -- 1.9.1 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH 6/6] Cleanup syntax and styling in Configure DC
This cleans up some styling and syntax in the Configure Dive Computer
code path.
Signed-off-by: Anton Lundin gla...@acc.umu.se
---
configuredivecomputerthreads.cpp | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/configuredivecomputerthreads.cpp b/configuredivecomputerthreads.cpp
index bb6e903..ca29dff 100644
--- a/configuredivecomputerthreads.cpp
+++ b/configuredivecomputerthreads.cpp
@@ -197,7 +197,7 @@ void ReadSettingsThread::run()
m_deviceDetails-setAlarmDepth(depth);
}
emit devicedetails(m_deviceDetails);
-break;
+ break;
}
#if DC_VERSION_CHECK(0, 5, 0)
case DC_FAMILY_HW_OSTC3: {
@@ -433,16 +433,15 @@ void ReadSettingsThread::run()
supported = false;
break;
}
+ } else {
+ lastError = tr(Could not a establish connection to the dive
computer.);
+ emit error(lastError);
+ }
unsupported_dc_error:
- dc_device_close(m_data-device);
+ dc_device_close(m_data-device);
- if (!supported) {
- lastError = tr(This feature is not yet available for
the selected dive computer.);
- emit error(lastError);
- }
- }
- else {
- lastError = tr(Could not a establish connection to the dive
computer.);
+ if (!supported) {
+ lastError = tr(This feature is not yet available for the
selected dive computer.);
emit error(lastError);
}
}
@@ -500,8 +499,7 @@ void WriteSettingsThread::run()
dc_device_write(m_data-device,
SUUNTO_VYPER_ALARM_DEPTH, data2, 2);
break;
#if DC_VERSION_CHECK(0,5,0)
- case DC_FAMILY_HW_OSTC3:
- {
+ case DC_FAMILY_HW_OSTC3: {
supported = true;
//write gas values
unsigned char gas1Data[4] =
{m_deviceDetails-gas1().oxygen,
--
1.9.1
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH 2/8] Change the OSTC3 copied ui to be sane for OSTC
The OSTC supports a bit different functionalities than the OSTC3 does.
The unsupported bits are
setBrightness
setCalibrationGas
setCompassGain
setDiveMode - Bult into setDecoType (OC/CCR)
setDiveModeColor - Lots of different colors
setFlipScreen
setLanguage - Controlled via flashing different firmwares
setPressureSensorOffset
setUnits
setSetPointFallback
setCcrMode - there are some ppO2 reading functionality in the fist gen
OSTC that we don't care about, and the rest is controlled
via choosing a CCR deco algorithm
Also the OSTC have a notion of number of dives it has done, so this adds
ui for that value.
There are also differences in how some values are handled. Ex the OSTC
don't have fixed samplerates that you can choose between. You can rather
just set your sample rate to X seconds.
Signed-off-by: Anton Lundin gla...@acc.umu.se
---
qt-ui/configuredivecomputerdialog.cpp | 43 ++-
qt-ui/configuredivecomputerdialog.ui | 597 ++
2 files changed, 188 insertions(+), 452 deletions(-)
diff --git a/qt-ui/configuredivecomputerdialog.cpp
b/qt-ui/configuredivecomputerdialog.cpp
index ed044f2..dbd2ea1 100644
--- a/qt-ui/configuredivecomputerdialog.cpp
+++ b/qt-ui/configuredivecomputerdialog.cpp
@@ -345,34 +345,23 @@ void
ConfigureDiveComputerDialog::populateDeviceDetailsOSTC3()
void ConfigureDiveComputerDialog::populateDeviceDetailsOSTC()
{
deviceDetails-setCustomText(ui.customTextLlineEdit_3-text());
- deviceDetails-setDiveMode(ui.diveModeComboBox_3-currentIndex());
deviceDetails-setSaturation(ui.saturationSpinBox_3-value());
deviceDetails-setDesaturation(ui.desaturationSpinBox_3-value());
deviceDetails-setLastDeco(ui.lastDecoSpinBox_3-value());
- deviceDetails-setBrightness(ui.brightnessComboBox_3-currentIndex());
- deviceDetails-setUnits(ui.unitsComboBox_3-currentIndex());
-
deviceDetails-setSamplingRate(ui.samplingRateComboBox_3-currentIndex());
+ deviceDetails-setSamplingRate(ui.samplingRateSpinBox_3-value());
deviceDetails-setSalinity(ui.salinitySpinBox_3-value());
- deviceDetails-setDiveModeColor(ui.diveModeColour_3-currentIndex());
- deviceDetails-setLanguage(ui.languageComboBox_3-currentIndex());
deviceDetails-setDateFormat(ui.dateFormatComboBox_3-currentIndex());
- deviceDetails-setCompassGain(ui.compassGainComboBox_3-currentIndex());
deviceDetails-setSyncTime(ui.dateTimeSyncCheckBox_3-isChecked());
deviceDetails-setSafetyStop(ui.safetyStopCheckBox_3-isChecked());
deviceDetails-setGfHigh(ui.gfHighSpinBox_3-value());
deviceDetails-setGfLow(ui.gfLowSpinBox_3-value());
-
deviceDetails-setPressureSensorOffset(ui.pressureSensorOffsetSpinBox_3-value());
deviceDetails-setPpO2Min(ui.ppO2MinSpinBox_3-value());
deviceDetails-setPpO2Max(ui.ppO2MaxSpinBox_3-value());
deviceDetails-setFutureTTS(ui.futureTTSSpinBox_3-value());
- deviceDetails-setCcrMode(ui.ccrModeComboBox_3-currentIndex());
deviceDetails-setDecoType(ui.decoTypeComboBox_3-currentIndex());
deviceDetails-setAGFSelectable(ui.aGFSelectableCheckBox_3-isChecked());
deviceDetails-setAGFHigh(ui.aGFHighSpinBox_3-value());
deviceDetails-setAGFLow(ui.aGFLowSpinBox_3-value());
- deviceDetails-setCalibrationGas(ui.calibrationGasSpinBox_3-value());
- deviceDetails-setFlipScreen(ui.flipScreenCheckBox_3-isChecked());
-
deviceDetails-setSetPointFallback(ui.setPointFallbackCheckBox_3-isChecked());
//set gas values
gas gas1;
@@ -695,36 +684,42 @@ void ConfigureDiveComputerDialog::reloadValuesOSTC3()
void ConfigureDiveComputerDialog::reloadValuesOSTC()
{
+/*
+# Not in OSTC
+setBrightness
+setCalibrationGas
+setCompassGain
+setDiveMode - Bult into setDecoType
+setDiveModeColor - Lots of different colors
+setFlipScreen
+setLanguage
+setPressureSensorOffset
+setUnits
+setSetPointFallback
+setCcrMode
+# Not in OSTC3
+setNumberOfDives
+*/
ui.serialNoLineEdit_3-setText(deviceDetails-serialNo());
ui.firmwareVersionLineEdit_3-setText(deviceDetails-firmwareVersion());
ui.customTextLlineEdit_3-setText(deviceDetails-customText());
- ui.diveModeComboBox_3-setCurrentIndex(deviceDetails-diveMode());
ui.saturationSpinBox_3-setValue(deviceDetails-saturation());
ui.desaturationSpinBox_3-setValue(deviceDetails-desaturation());
ui.lastDecoSpinBox_3-setValue(deviceDetails-lastDeco());
- ui.brightnessComboBox_3-setCurrentIndex(deviceDetails-brightness());
- ui.unitsComboBox_3-setCurrentIndex(deviceDetails-units());
-
ui.samplingRateComboBox_3-setCurrentIndex(deviceDetails-samplingRate());
+ ui.samplingRateSpinBox_3-setValue(deviceDetails-samplingRate());
ui.salinitySpinBox_3-setValue(deviceDetails-salinity());
- ui.diveModeColour_3-setCurrentIndex(deviceDetails-diveModeColor());
-
[PATCH 5/8] Decode configuration data from OSTC
This adds code to decode the configuration blocks from the OSTC.
Signed-off-by: Anton Lundin gla...@acc.umu.se
---
configuredivecomputerthreads.cpp | 250 +++
1 file changed, 250 insertions(+)
diff --git a/configuredivecomputerthreads.cpp b/configuredivecomputerthreads.cpp
index b112bdf..e960033 100644
--- a/configuredivecomputerthreads.cpp
+++ b/configuredivecomputerthreads.cpp
@@ -479,24 +479,274 @@ void ReadSettingsThread::run()
case DC_FAMILY_HW_OSTC: {
supported = true;
unsigned char data[256] = {};
+ unsigned char max_CF = 0;
rc = hw_ostc_device_eeprom_read(m_data-device, 0,
data, sizeof(data));
if (rc == DC_STATUS_SUCCESS) {
+
m_deviceDetails-setSerialNo(QString::number(data[1] 8 ^ data[0]));
+ m_deviceDetails-setNumberOfDives(data[3] 8
^ data[2]);
+ //Byte5-6:
+ //Gas 1 default (%O2=21, %He=0)
+ gas gas1;
+ gas1.oxygen = data[6];
+ gas1.helium = data[7];
+ //Byte9-10:
+ //Gas 2 default (%O2=21, %He=0)
+ gas gas2;
+ gas2.oxygen = data[10];
+ gas2.helium = data[11];
+ //Byte13-14:
+ //Gas 3 default (%O2=21, %He=0)
+ gas gas3;
+ gas3.oxygen = data[14];
+ gas3.helium = data[15];
+ //Byte17-18:
+ //Gas 4 default (%O2=21, %He=0)
+ gas gas4;
+ gas4.oxygen = data[18];
+ gas4.helium = data[19];
+ //Byte21-22:
+ //Gas 5 default (%O2=21, %He=0)
+ gas gas5;
+ gas5.oxygen = data[22];
+ gas5.helium = data[23];
+ //Byte25-26:
+ //Gas 6 current (%O2, %He)
+ m_deviceDetails-setSalinity(data[26]);
+ // Active Gas Flag Register
+ gas1.type = data[27] 0x01;
+ gas2.type = (data[27] 0x02) 1;
+ gas3.type = (data[27] 0x04) 2;
+ gas4.type = (data[27] 0x08) 3;
+ gas5.type = (data[27] 0x10) 4;
+
+ gas1.depth = data[28];
+ gas2.depth = data[29];
+ gas3.depth = data[30];
+ gas4.depth = data[31];
+ gas5.depth = data[32];
+ // 33 which gas is Fist gas
+ switch(data[33]) {
+ case 1:
+ gas1.type = 2;
+ break;
+ case 2:
+ gas2.type = 2;
+ break;
+ case 3:
+ gas3.type = 2;
+ break;
+ case 4:
+ gas4.type = 2;
+ break;
+ case 5:
+ gas5.type = 2;
+ break;
+ default:
+ //Error?
+ break;
+ }
+ // Data filled up, set the gases.
+ m_deviceDetails-setGas1(gas1);
+ m_deviceDetails-setGas2(gas2);
+ m_deviceDetails-setGas3(gas3);
+ m_deviceDetails-setGas4(gas4);
+ m_deviceDetails-setGas5(gas5);
+ m_deviceDetails-setDecoType(data[34]);
+ //Byte36:
+ //Use O2 Sensor Module in CC Modes (0= OFF, 1=
ON) (Only available in old OSTC1 - unused for OSTC Mk.2/2N)
+ //m_deviceDetails-setCcrMode(data[35]);
+
[PATCH 7/8] Debug code for OSTC CF
This code is to debug the rest of the existing CF's, so we can look at
the rest of the values.
Signed-off-by: Anton Lundin gla...@acc.umu.se
---
configuredivecomputerthreads.cpp | 17 +
1 file changed, 17 insertions(+)
diff --git a/configuredivecomputerthreads.cpp b/configuredivecomputerthreads.cpp
index dc03597..0be3a72 100644
--- a/configuredivecomputerthreads.cpp
+++ b/configuredivecomputerthreads.cpp
@@ -492,7 +492,9 @@ void ReadSettingsThread::run()
case DC_FAMILY_HW_OSTC: {
supported = true;
unsigned char data[256] = {};
+#ifdef DEBUG_OSTC_CF
unsigned char max_CF = 0;
+#endif
rc = hw_ostc_device_eeprom_read(m_data-device, 0,
data, sizeof(data));
if (rc == DC_STATUS_SUCCESS) {
m_deviceDetails-setSerialNo(QString::number(data[1] 8 ^ data[0]));
@@ -641,7 +643,9 @@ void ReadSettingsThread::run()
m_deviceDetails-setDateFormat(data[91]);
// Byte93:
// Total number of CF used in installed firmware
+#ifdef DEBUG_OSTC_CF
max_CF = data[92];
+#endif
// Byte94:
// Last selected view for customview area in
surface mode
// Byte95:
@@ -726,6 +730,11 @@ void ReadSettingsThread::run()
m_deviceDetails-setSamplingRate(read_ostc_cf(data, 20));
// CF29: Depth of last decompression stop
m_deviceDetails-setLastDeco(read_ostc_cf(data,
29));
+
+#ifdef DEBUG_OSTC_CF
+ for(int cf = 0; cf = 31 cf = max_CF; cf++)
+ printf(CF %d: %d\n, cf,
read_ostc_cf(data, cf));
+#endif
#ifdef DEBUG_OSTC
local_hw_ostc_device_eeprom_write(m_data-device, 0, data, sizeof(data));
#endif
@@ -753,6 +762,10 @@ void ReadSettingsThread::run()
m_deviceDetails-setGfHigh(read_ostc_cf(data,
33));
// CF58: Future time to surface setFutureTTS
m_deviceDetails-setFutureTTS(read_ostc_cf(data, 58));
+#ifdef DEBUG_OSTC_CF
+ for(int cf = 32; cf = 63 cf = max_CF; cf++)
+ printf(CF %d: %d\n, cf,
read_ostc_cf(data, cf));
+#endif
#ifdef DEBUG_OSTC
local_hw_ostc_device_eeprom_write(m_data-device, 1, data, sizeof(data));
#endif
@@ -775,6 +788,10 @@ void ReadSettingsThread::run()
m_deviceDetails-setAGFHigh(read_ostc_cf(data,
68));
// CF69: Allow Gradient Factor change
m_deviceDetails-setAGFSelectable(read_ostc_cf(data, 69));
+#ifdef DEBUG_OSTC_CF
+ for(int cf = 64; cf = 95 cf = max_CF; cf++)
+ printf(CF %d: %d\n, cf,
read_ostc_cf(data, cf));
+#endif
#ifdef DEBUG_OSTC
local_hw_ostc_device_eeprom_write(m_data-device, 2, data, sizeof(data));
#endif
--
1.9.1
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH 6/8] Decode CF configuration data from OSTC
This adds code to decode the custom functions data.
We only decode the relevant CF's. The relevant ones are chosen by which
ones have corresponding settings in the OSTC3.
Signed-off-by: Anton Lundin gla...@acc.umu.se
---
configuredivecomputerthreads.cpp | 57 +++-
1 file changed, 45 insertions(+), 12 deletions(-)
diff --git a/configuredivecomputerthreads.cpp b/configuredivecomputerthreads.cpp
index e960033..dc03597 100644
--- a/configuredivecomputerthreads.cpp
+++ b/configuredivecomputerthreads.cpp
@@ -112,6 +112,19 @@ ReadSettingsThread::ReadSettingsThread(QObject *parent,
device_data_t *data)
}
+static int read_ostc_cf(unsigned char data[], unsigned char cf) {
+ return data[128 + (cf % 32) * 4 + 3] 8 ^ data[128 + (cf % 32) * 4 +
2];
+}
+
+static void write_ostc_cf(unsigned char data[], unsigned char cf, unsigned
char max_CF, unsigned int value) {
+ // Only write settings supported by this firmware.
+ if (cf max_CF)
+ return;
+
+ data[128 + (cf % 32) * 4 + 3] = (value 0xff00) 8;
+ data[128 + (cf % 32) * 4 + 2] = (value 0x00ff);
+}
+
void ReadSettingsThread::run()
{
bool supported = false;
@@ -699,10 +712,20 @@ void ReadSettingsThread::run()
// not used/reserved
// Byte129-256:
// 32 custom Functions (CF0-CF31)
- // The custom functions are stored in the
internal EEPROM after 0x080
- // Any custom function occupies 4 byte:
- // 2 byte (low:high) store the default value,
reset from menu reset (Will be overwritten by hard-coded defaults if reset in
the unit!)
- // 2 byte (low:high) store the actual value
+
+ // Decode the relevant ones
+ // CF11: Factor for saturation processes
+
m_deviceDetails-setSaturation(read_ostc_cf(data, 11));
+ // CF12: Factor for desaturation processes
+
m_deviceDetails-setDesaturation(read_ostc_cf(data, 12));
+ // CF17: Lower threshold for ppO2 warning
+ m_deviceDetails-setPpO2Min(read_ostc_cf(data,
17));
+ // CF18: Upper threshold for ppO2 warning
+ m_deviceDetails-setPpO2Max(read_ostc_cf(data,
18));
+ // CF20: Depth sampling rate for Profile storage
+
m_deviceDetails-setSamplingRate(read_ostc_cf(data, 20));
+ // CF29: Depth of last decompression stop
+ m_deviceDetails-setLastDeco(read_ostc_cf(data,
29));
#ifdef DEBUG_OSTC
local_hw_ostc_device_eeprom_write(m_data-device, 0, data, sizeof(data));
#endif
@@ -722,10 +745,14 @@ void ReadSettingsThread::run()
// not used/reserved
// Byte129-256:
// 32 custom Functions (CF 32-63)
- // The custom functions are stored in the
internal EEPROM after 0x180
- // Any custom function occupies 4 byte:
- // 2 byte (low:high) store the default value,
reset from menu reset (Will be overwritten by hard-coded defaults if reset in
the unit!)
- // 2 byte (low:high) store the actual value
+
+ // Decode the relevant ones
+ // CF32: Gradient Factor low
+ m_deviceDetails-setGfLow(read_ostc_cf(data,
32));
+ // CF33: Gradient Factor high
+ m_deviceDetails-setGfHigh(read_ostc_cf(data,
33));
+ // CF58: Future time to surface setFutureTTS
+
m_deviceDetails-setFutureTTS(read_ostc_cf(data, 58));
#ifdef DEBUG_OSTC
local_hw_ostc_device_eeprom_write(m_data-device, 1, data, sizeof(data));
#endif
@@ -738,10 +765,16 @@ void ReadSettingsThread::run()
// not used/reserved
// Byte129-256:
// 32 custom Functions (CF 64-95)
- // The custom functions are stored in the
internal EEPROM after 0x280
- // Any custom function occupies 4 byte:
- // 2 byte (low:high) store the default value,
reset from menu reset (Will be overwritten by hard-coded defaults if reset in
the unit!)
- // 2 byte (low:high) store the actual value
+
+ // Decode
[PATCH 3/8] Change the salinity setting for OSTC
On the OSTC's the salinity is in kg/l and is stored as kg/l * 100 Signed-off-by: Anton Lundin gla...@acc.umu.se --- qt-ui/configuredivecomputerdialog.cpp | 4 ++-- qt-ui/configuredivecomputerdialog.ui | 11 +++ 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/qt-ui/configuredivecomputerdialog.cpp b/qt-ui/configuredivecomputerdialog.cpp index dbd2ea1..a97d1db 100644 --- a/qt-ui/configuredivecomputerdialog.cpp +++ b/qt-ui/configuredivecomputerdialog.cpp @@ -349,7 +349,7 @@ void ConfigureDiveComputerDialog::populateDeviceDetailsOSTC() deviceDetails-setDesaturation(ui.desaturationSpinBox_3-value()); deviceDetails-setLastDeco(ui.lastDecoSpinBox_3-value()); deviceDetails-setSamplingRate(ui.samplingRateSpinBox_3-value()); - deviceDetails-setSalinity(ui.salinitySpinBox_3-value()); + deviceDetails-setSalinity(ui.salinityDoubleSpinBox_3-value() * 100); deviceDetails-setDateFormat(ui.dateFormatComboBox_3-currentIndex()); deviceDetails-setSyncTime(ui.dateTimeSyncCheckBox_3-isChecked()); deviceDetails-setSafetyStop(ui.safetyStopCheckBox_3-isChecked()); @@ -707,7 +707,7 @@ setNumberOfDives ui.desaturationSpinBox_3-setValue(deviceDetails-desaturation()); ui.lastDecoSpinBox_3-setValue(deviceDetails-lastDeco()); ui.samplingRateSpinBox_3-setValue(deviceDetails-samplingRate()); - ui.salinitySpinBox_3-setValue(deviceDetails-salinity()); + ui.salinityDoubleSpinBox_3-setValue((double) deviceDetails-salinity() / 100.0); ui.dateFormatComboBox_3-setCurrentIndex(deviceDetails-dateFormat()); ui.safetyStopCheckBox_3-setChecked(deviceDetails-safetyStop()); ui.gfHighSpinBox_3-setValue(deviceDetails-gfHigh()); diff --git a/qt-ui/configuredivecomputerdialog.ui b/qt-ui/configuredivecomputerdialog.ui index f39c514..6571837 100644 --- a/qt-ui/configuredivecomputerdialog.ui +++ b/qt-ui/configuredivecomputerdialog.ui @@ -1621,7 +1621,7 @@ item row=5 column=3 widget class=QLabel name=label_45 property name=text - stringSalinity (0-5%)/string + stringSalinity/string /property property name=buddy cstringsalinitySpinBox/cstring @@ -1692,12 +1692,15 @@ /widget /item item row=5 column=4 - widget class=QSpinBox name=salinitySpinBox_3 + widget class=QDoubleSpinBox name=salinityDoubleSpinBox_3 property name=suffix - string%/string + stringkg/l/string + /property + property name=minimum + double1.000/double /property property name=maximum - number5/number + double1.040/double /property property name=singleStep double0.010/double -- 1.9.1 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH 0/9] fix some warnings
On 27 October 2014 22:44, Robert Helling hell...@atdotde.de wrote: On 27 Oct 2014, at 21:03, Lubomir I. Ivanov neolit...@gmail.com wrote: this is Robert's code (CC) so perhaps he or others have some ideas. on a brief look, DiveLogExportDialog::export_depths() would not always produce a correct depth value (depth.mm). given the times will not be that large for a realistic dive, s-time.seconds *should* be auto-converted to int32_t by the compiler, but also the pictures with negative offsets will be ignored as sample times are always positive. i don't exactly understand what the function does, but i think the comparison should consider the dive-when, which is what both samples and pictures are based upon?. I am sorry that so many of your recent patches had to fix code that I had submitted. In this case, I would say that the comparison should be made with signed values (cast the duration to a signed int) as negative image time offsets are possible (pictures on the boat before the dive) while dives longer than 17 years are not. That while loop tries to find the last sample before the image was taken and use its depth as the depth of the image. If the time offset of the image is negative, this condition is never true and the initial depth of 0 is used. So, my shot at this problem would be in the present patch. thanks for the explanation - it makes better sense to me now. the explicit cast to int32_t fixes the warning. ack. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH 2/2] Create a delegate for depth and gas components
This creates a delegate to simplify the handling of gas components and
the change depth.
Signed-off-by: Anton Lundin gla...@acc.umu.se
---
qt-ui/configuredivecomputerdialog.cpp | 44 +++
qt-ui/configuredivecomputerdialog.h | 20
2 files changed, 64 insertions(+)
diff --git a/qt-ui/configuredivecomputerdialog.cpp
b/qt-ui/configuredivecomputerdialog.cpp
index c2da244..4b66499 100644
--- a/qt-ui/configuredivecomputerdialog.cpp
+++ b/qt-ui/configuredivecomputerdialog.cpp
@@ -28,6 +28,42 @@ struct mydescriptor {
unsigned int model;
};
+GasSpinBoxItemDelegate::GasSpinBoxItemDelegate(QObject *parent, column_type
type) : QStyledItemDelegate(parent), type(type) { }
+GasSpinBoxItemDelegate::~GasSpinBoxItemDelegate() { }
+
+QWidget* GasSpinBoxItemDelegate::createEditor(QWidget *parent, const
QStyleOptionViewItem option, const QModelIndex index) const
+{
+ // Create the spinbox and give it it's settings
+ QSpinBox *sb = new QSpinBox(parent);
+ if (type == PERCENT) {
+ sb-setMinimum(0);
+ sb-setMaximum(100);
+ sb-setSuffix(%);
+ } else if (type == DEPTH) {
+ sb-setMinimum(0);
+ sb-setMaximum(255);
+ sb-setSuffix(m);
+ }
+ return sb;
+}
+
+void GasSpinBoxItemDelegate::setEditorData(QWidget *editor, const QModelIndex
index) const
+{
+ if(QSpinBox *sb = qobject_castQSpinBox *(editor))
+ sb-setValue(index.data(Qt::EditRole).toInt());
+ else
+ QStyledItemDelegate::setEditorData(editor, index);
+}
+
+
+void GasSpinBoxItemDelegate::setModelData(QWidget *editor, QAbstractItemModel
*model, const QModelIndex index) const
+{
+ if(QSpinBox *sb = qobject_castQSpinBox *(editor))
+ model-setData(index, sb-value(), Qt::EditRole);
+ else
+ QStyledItemDelegate::setModelData(editor, model, index);
+}
+
GasTypeComboBoxItemDelegate::GasTypeComboBoxItemDelegate(QObject *parent,
computer_type type) : QStyledItemDelegate(parent), type(type) { }
GasTypeComboBoxItemDelegate::~GasTypeComboBoxItemDelegate() { }
@@ -89,10 +125,18 @@
ConfigureDiveComputerDialog::ConfigureDiveComputerDialog(QWidget *parent) :
ui.DiveComputerList-setCurrentRow(0);
on_DiveComputerList_currentRowChanged(0);
+ ui.ostc3GasTable-setItemDelegateForColumn(1, new
GasSpinBoxItemDelegate(this, GasSpinBoxItemDelegate::PERCENT));
+ ui.ostc3GasTable-setItemDelegateForColumn(2, new
GasSpinBoxItemDelegate(this, GasSpinBoxItemDelegate::PERCENT));
ui.ostc3GasTable-setItemDelegateForColumn(3, new
GasTypeComboBoxItemDelegate(this, GasTypeComboBoxItemDelegate::OSTC3));
+ ui.ostc3GasTable-setItemDelegateForColumn(4, new
GasSpinBoxItemDelegate(this, GasSpinBoxItemDelegate::DEPTH));
ui.ostc3DilTable-setItemDelegateForColumn(3, new
GasTypeComboBoxItemDelegate(this, GasTypeComboBoxItemDelegate::OSTC3));
+ ui.ostc3DilTable-setItemDelegateForColumn(4, new
GasSpinBoxItemDelegate(this, GasSpinBoxItemDelegate::DEPTH));
+ ui.ostcGasTable-setItemDelegateForColumn(1, new
GasSpinBoxItemDelegate(this, GasSpinBoxItemDelegate::PERCENT));
+ ui.ostcGasTable-setItemDelegateForColumn(2, new
GasSpinBoxItemDelegate(this, GasSpinBoxItemDelegate::PERCENT));
ui.ostcGasTable-setItemDelegateForColumn(3, new
GasTypeComboBoxItemDelegate(this, GasTypeComboBoxItemDelegate::OSTC));
+ ui.ostcGasTable-setItemDelegateForColumn(4, new
GasSpinBoxItemDelegate(this, GasSpinBoxItemDelegate::DEPTH));
ui.ostcDilTable-setItemDelegateForColumn(3, new
GasTypeComboBoxItemDelegate(this, GasTypeComboBoxItemDelegate::OSTC));
+ ui.ostcDilTable-setItemDelegateForColumn(4, new
GasSpinBoxItemDelegate(this, GasSpinBoxItemDelegate::DEPTH));
QSettings settings;
settings.beginGroup(ConfigureDiveComputerDialog);
diff --git a/qt-ui/configuredivecomputerdialog.h
b/qt-ui/configuredivecomputerdialog.h
index 84c2540..89efee6 100644
--- a/qt-ui/configuredivecomputerdialog.h
+++ b/qt-ui/configuredivecomputerdialog.h
@@ -8,6 +8,26 @@
#include configuredivecomputer.h
#include QStyledItemDelegate
+class GasSpinBoxItemDelegate : public QStyledItemDelegate
+{
+ Q_OBJECT
+
+public:
+ enum column_type {
+ PERCENT,
+ DEPTH,
+ };
+
+ GasSpinBoxItemDelegate(QObject *parent = 0, column_type type = PERCENT);
+ ~GasSpinBoxItemDelegate();
+
+ virtual QWidget *createEditor(QWidget *parent, const
QStyleOptionViewItem option, const QModelIndex index) const;
+ virtual void setEditorData(QWidget *editor, const QModelIndex index)
const;
+ virtual void setModelData(QWidget *editor, QAbstractItemModel *model,
const QModelIndex index) const;
+private:
+ column_type type;
+};
+
class GasTypeComboBoxItemDelegate : public QStyledItemDelegate
{
Q_OBJECT
--
1.9.1
Re: [PATCH 3/6] Change the OSTC3 macros to have a ; in the end
On Mon, Oct 27, 2014 at 12:37 PM, Anton Lundin gla...@acc.umu.se wrote:
-#define READ_SETTING(_OSTC3_SETTING, _DEVICE_DETAIL) \
+#define READ_SETTING(_OSTC3_SETTING, _DEVICE_DETAIL); \
That extra ';' as the first token in the macro definition seems entirely broken.
rc = hw_ostc3_device_config_read(m_data-device,
_OSTC3_SETTING, uData, sizeof(uData)); \
if (rc == DC_STATUS_SUCCESS) \
m_deviceDetails-_DEVICE_DETAIL(uData[0]);
I'd also suggest enclosing it all in a do { } while (0) (*without* a
semicolon at the end - the final semicolon should come from the user),
because otherwise
if (x)
READ_SETTING(..)
else
READ_SETTING(..);
ends up parsing cleanly by the compiler, but doing completely bogus
crap (the else ends up pairing with the if inside the macro,
instead of the if in the code).
Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH 3/6] Change the OSTC3 macros to have a ; in the end
On Mon, Oct 27, 2014 at 02:13:54PM -0700, Linus Torvalds wrote:
On Mon, Oct 27, 2014 at 12:37 PM, Anton Lundin gla...@acc.umu.se wrote:
-#define READ_SETTING(_OSTC3_SETTING, _DEVICE_DETAIL) \
+#define READ_SETTING(_OSTC3_SETTING, _DEVICE_DETAIL); \
That extra ';' as the first token in the macro definition seems entirely
broken.
rc = hw_ostc3_device_config_read(m_data-device,
_OSTC3_SETTING, uData, sizeof(uData)); \
if (rc == DC_STATUS_SUCCESS) \
m_deviceDetails-_DEVICE_DETAIL(uData[0]);
I'd also suggest enclosing it all in a do { } while (0) (*without* a
semicolon at the end - the final semicolon should come from the user),
because otherwise
if (x)
READ_SETTING(..)
else
READ_SETTING(..);
ends up parsing cleanly by the compiler, but doing completely bogus
crap (the else ends up pairing with the if inside the macro,
instead of the if in the code).
Needless to say, I agree with both statements. What the heck is that first
semicolon for, Anton?
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OSTC Configuration
On Mon, Oct 27, 2014 at 10:04:57PM +0100, Anton Lundin wrote: On 27 October, 2014 - Anton Lundin wrote: Here is the results of my last little project. This stack of patches adds support for reading and writing the config blocks of the OSTC devices. All this bit magic was a bit tricky to get right so i wrote some simulator code for tis to actually be able to test read/write. There are some blocks in this code that ain't pretty. I kinda ran out of ideas to try to make it less ugly, so please, if anyone have some suggestion of sane pattern we could use I'm all ears(eyes?). There is also some cases where we should care about errors from libdivecomputer and show them propperly, but thats actually needed for all the config parts, so i thought i send out these ones and attack that later. And yes, if anyone wonders, the code is tested against a real device. All and every corner isn't tested that thoroughly, but it looks like i actually got it right =) I'll need to get my OSTC 2N and my OSTC 3 out and do a - backup - write random settings - restore - backup cycle and check that the two backups are identical... I am obviously rather nervous about this code. A prior instantiation ended up getting my OSTC3 into a state (with earlier firmware, thanks to Matthias this couldn't happen anymore with the latest version) where it no longer calculated any deco / ndl... which is kinda the point of a dive computer. And of course, what's still missing is the firmware update :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Create delegates for Config gas tables
On Mon, Oct 27, 2014 at 10:12:44PM +0100, Anton Lundin wrote: These patches was as far as i manage to get in my delegate handling. These ones looks ok, but the ComboBox one would be better if it saved the string value instead of the numeric value after you clicked on it, and you managed to translate that to the numeric value somehow in the populateDeviceDetails-methods. Yeah, this looks funny. Maybe one of the Qt experts can tell us what's missing to always show the string representation in the table. Oh, and I still think the way the tables are laid out is kinda goofy... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On Mon, Oct 27, 2014 at 08:14:44PM +0100, Anton Lundin wrote: On 27 October, 2014 - Gaetan Bisson wrote: [2014-10-24 16:48:34 +0200] Robert Helling: what happened to Gaetan’s attempts at coming up with a UI implementation? I wanted to do something basic and Anton convinced me that would be a shame and something much better should be done instead. Since GUIs are the complete opposite to my area of expertise, I just stopped thinking about this. Something is always better then nothing. Give it a try! +1 -- if we have something then we can talk about what should be differently and make that happen. If we have nothing it's really hard for the UI experts to start working. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Patches to add basic support for the Suunto EON Steel
On Mon, Oct 27, 2014 at 3:57 PM, Jef Driesen j...@libdivecomputer.org wrote:
On 23-10-14 00:34, Linus Torvalds wrote:
Both the windows and non-libusb builds are broken.
I have no sane way to test the windows build issues. But I fixed the
non-libusb build by moving the ifdef around a bit, and I renamed
error() to report_error() to hopefully get the Windows build
fixed.
Can you mention the actual broken casts? This is my #1 C++ is a
broken piece opf shit moment, though, since I really hate how *wrong*
C++ got the whole void * thing (not just NULL, absolutely
_everything_ is broken wrt type handling of void * in C++).
But even the mingw (gcc) build fails. It
fails on the ERROR macros with error: called object '0' is not a function.
Not sure why.
It sounds like the mingw header files use some odd kind of error
#define. Worked around by making it be report_error()
The directory_entry structure with it's zero length array is most likely
also not very portable. C99 has flexible arrays, but I'm not sure what msvc
supports.
Changed to a one-byte array - it's going to waste a few bytes of
memory per entry, but it's not a big deal. (That's not due to the 1
- that could be easily fixed - but due to then also aligning the thing
up for sizeof()).
Better integration with the existing libdivecomputer infrastructure. We
already have logging functions, array_uint{16,24,32}_{be,le} helper
functions for dealing with endianness, dynamic memory buffers (dc_buffer_t),
etc. There is no need to re-implement any of those.
Quite frankly, your logging functions suck, because they don't return
any value. So you can't use return ERROR(), which is the sane common
use.
Plus they need that context thing which makes no sense and isn't
even available except at open time.
It's not just open that wants to log things.
So no, I can't use that horrible thing. For example, even ignoring the
brokenness of the context thing, something like:
if (badness)
return report_error(badness %d happened, badness);
compared to:
if (badness) {
ERROR(context, Badness %d happened, badness);
return DC_STATUS_WHATEVER;
}
is the difference between I can bother to make reasonable error
reporting and f*ck this, I'll not bother logging the reason at all.
So then I'd just do
if (badness)
return DC_STATUS_FAIL;
so now there's no logging at all - just because your interface is bad.
But I can't even use that DC_STATUS_FAIL kind of thing. See later.
As to the array_uint() functions - you have no writing functions,
and you're lacking a u8. And your types are wrong, not allowing
void *. And they are insanely verbose. But whatever. I converted the
ones you had.
Out of memory error handling. I know the arguments for calling exit very
well, but for libdivecomputer I made the choice to handle out of memory
differently. Please stick to this pattern.
I made it use the dc_buffer_t, and just ignore out-of-memory cases.
They don't happen, and if they did, they'd just result it empty
buffers now.
Many functions return -1 in the case of an error. Can you rework this as
dc_status_t values? BTW, if you want to use goto style error handling,
that's fine.
No, I cannot use dc_status_t values, because they make it impossible
to return an error *and* a value.
There is a very good reason why UNIX calling conventions are return
-1 on error.
That reason is the *non-error* case. Think of a simple function like
read(). Ask yourself what it returns on error, and what it returns
on success.
Yes, I have used things like DC_STATUS_SUCCESS. I used VMS for some
time. It's horrible. Suddenly you have to first check for success, and
then have another interface to return the result size etc.
The whole negative means error, zero or positive is success is
really powerful. It means that you can return how many bytes you read,
and easily test whether there was something wrong, *without* having to
have some pass return size value as a pointer model.
So please realize that my send_receive() function works like
read() - it returns negative on error, and the number of bytes
received on success.
I can't do that with DC_STATUS_XYZ.
For the name of the backend, I prefer a single word like eonsteel or just
steel instead of eon_steel. This is just to follow the existing practice
in libdivecomputer were backends are named DC_FAMILY_VENDOR_PRODUCT. So no
underscores in the product part.
Did it for DC_FAMILY_SUUNTO_EONSTEEL.
Main structures (struct eon_steel, eon_parser) and all entry point functions
(public or through the vtable) get the same backend prefix.
I *really* don't want to do this, though. The public ones are
suunto_eon_steel() because they are visible to others. But I really
object to writing that long name out for internal helper functions
that are static. Why write that horribly long name for no gain?
The parser logic is a bit hard to follow without having some example data to
look at. Can you share some data
[PATCH] Commented out section waiting on commit from libdivecomputer. It relied on DC_EVENT_BATTERY.
Signed-off-by: John Van Ostrand j...@vanostrand.com --- cochran.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cochran.c b/cochran.c index 9e31f55..7651441 100644 --- a/cochran.c +++ b/cochran.c @@ -351,11 +351,13 @@ int cochran_dive_event(struct divecomputer *dc, const unsigned char *s, SAMPLE_FLAGS_BEGIN, 0, QT_TRANSLATE_NOOP(gettextFromC, ascent)); break; +/* waiting for libdivecomputer patch case 0xC2: // Low battery warning add_event(dc, seconds, SAMPLE_EVENT_BATTERY, SAMPLE_FLAGS_NONE, 0, QT_TRANSLATE_NOOP(gettextFromC, battery)); break; +*/ case 0xC3: // CNS warning add_event(dc, seconds, SAMPLE_EVENT_OLF, SAMPLE_FLAGS_BEGIN, 0, -- 1.8.3.1 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Commented out section waiting on commit from libdivecomputer. It relied on DC_EVENT_BATTERY.
On Mon, Oct 27, 2014 at 5:51 PM, John Van Ostrand j...@vanostrand.com wrote: +/* waiting for libdivecomputer patch case 0xC2: // Low battery warning add_event(dc, seconds, SAMPLE_EVENT_BATTERY, SAMPLE_FLAGS_NONE, 0, QT_TRANSLATE_NOOP(gettextFromC, battery)); break; +*/ Please change your libdivecomputer patch to do what I did with some EON Steel infrastructure: add a #define SAMPLE_EVENT_BATTERY SAMPLE_EVENT_BATTERY define in the header file that declares that thing, and then users can just do #ifdef SAMPLE_EVENT_BATTERY ... #endif and it will automatically pick up on whether the libdivecomputer you are building against supports this or not. Anything else is broken. Checking versions is insane (and doesn't work in between releases). The whole check if it's defined is the sane and clean way to do these things, and the self-define is the way to handle things that are actually declared other ways (ie as enum's as in this case, or just function declarations etc for new support functions). Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] Removed dependence on not yet released libdivecomputer code.
Signed-off-by: John Van Ostrand j...@vanosrand.com --- cochran.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cochran.c b/cochran.c index 9e31f55..b3ba7b4 100644 --- a/cochran.c +++ b/cochran.c @@ -351,11 +351,13 @@ int cochran_dive_event(struct divecomputer *dc, const unsigned char *s, SAMPLE_FLAGS_BEGIN, 0, QT_TRANSLATE_NOOP(gettextFromC, ascent)); break; +#ifdef SAMPLE_EVENT_BATTERY case 0xC2: // Low battery warning add_event(dc, seconds, SAMPLE_EVENT_BATTERY, SAMPLE_FLAGS_NONE, 0, QT_TRANSLATE_NOOP(gettextFromC, battery)); break; +#endif case 0xC3: // CNS warning add_event(dc, seconds, SAMPLE_EVENT_OLF, SAMPLE_FLAGS_BEGIN, 0, -- 1.8.3.1 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Removed dependence on not yet released libdivecomputer code.
BTW, did you check git master…? :-) /D On Oct 27, 2014, at 7:02 PM, John Van Ostrand j...@vanostrand.com wrote: Signed-off-by: John Van Ostrand j...@vanosrand.com --- cochran.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cochran.c b/cochran.c index 9e31f55..b3ba7b4 100644 --- a/cochran.c +++ b/cochran.c @@ -351,11 +351,13 @@ int cochran_dive_event(struct divecomputer *dc, const unsigned char *s, SAMPLE_FLAGS_BEGIN, 0, QT_TRANSLATE_NOOP(gettextFromC, ascent)); break; +#ifdef SAMPLE_EVENT_BATTERY case 0xC2: // Low battery warning add_event(dc, seconds, SAMPLE_EVENT_BATTERY, SAMPLE_FLAGS_NONE, 0, QT_TRANSLATE_NOOP(gettextFromC, battery)); break; +#endif case 0xC3: // CNS warning add_event(dc, seconds, SAMPLE_EVENT_OLF, SAMPLE_FLAGS_BEGIN, 0, -- 1.8.3.1 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
