[PATCH] Added support for older Cochran models that have configurable sample intervals.

2017-05-26 Thread John Van Ostrand 
Corrected problem where dive profiles would include post dive
surface interval samples.

Added detection for corrupt dives.

Signed-off-by: John Van Ostrand 
---
 core/cochran.c | 65 +-
 core/cochran.h |  4 +++-
 2 files changed, 36 insertions(+), 33 deletions(-)

diff --git a/core/cochran.c b/core/cochran.c
index 430c3b4..243a659 100644
--- a/core/cochran.c
+++ b/core/cochran.c
@@ -257,14 +257,10 @@ static void cochran_parse_header(const unsigned char 
*decode, unsigned mod,
 static int cochran_predive_event_bytes(unsigned char code)
 {
int x = 0;
-   int gem_event_bytes[15][2] =  {{0x00, 10}, {0x02, 17}, {0x08, 18},
-  {0x09, 18}, {0x0c, 18}, {0x0d, 18},
-  {0x0e, 18},
-  {-1,  0}};
int cmdr_event_bytes[15][2] = {{0x00, 16}, {0x01, 20}, {0x02, 17},
   {0x03, 16}, {0x06, 18}, {0x07, 18},
   {0x08, 18}, {0x09, 18}, {0x0a, 18},
-  {0x0b, 20}, {0x0c, 18}, {0x0d, 18},
+  {0x0b, 18}, {0x0c, 18}, {0x0d, 18},
   {0x0e, 18}, {0x10, 20},
   {-1,  0}};
int emc_event_bytes[15][2] =  {{0x00, 18}, {0x01, 22}, {0x02, 19},
@@ -275,10 +271,6 @@ static int cochran_predive_event_bytes(unsigned char code)
 
switch (config.type) {
case TYPE_GEMINI:
-   while (gem_event_bytes[x][0] != code && gem_event_bytes[x][0] 
!= -1)
-   x++;
-   return gem_event_bytes[x][1];
-   break;
case TYPE_COMMANDER:
while (cmdr_event_bytes[x][0] != code && cmdr_event_bytes[x][0] 
!= -1)
x++;
@@ -478,22 +470,20 @@ static void cochran_parse_samples(struct dive *dive, 
const unsigned char *log,
 
// Skip past pre-dive events
unsigned int x = 0;
-   if (samples[x] != 0x40) {
-   unsigned int c;
-   while ((samples[x] & 0x80) == 0 && samples[x] != 0x40 && x < 
size) {
-   c = cochran_predive_event_bytes(samples[x]) + 1;
-#ifdef COCHRAN_DEBUG
-   printf("Predive event: ", samples[x]);
-   for (int y = 0; y < c; y++) printf("%02x ", samples[x + 
y]);
-   putchar('\n');
-#endif
+   unsigned int c;
+   while (x < size && (samples[x] & 0x80) == 0 && samples[x] != 0x40) {
+   c = cochran_predive_event_bytes(samples[x]) + 1;
+//#ifdef COCHRAN_DEBUG
+   printf("Predive event: ", samples[x]);
+   for (int y = 0; y < c && x + y < size; y++) printf("%02x ", 
samples[x + y]);
+   putchar('\n');
+//#endif
x += c;
-   }
}
 
// Now process samples
offset = x;
-   while (offset < size) {
+   while (offset + config.sample_size < size) {
s = samples + offset;
 
// Start with an empty sample
@@ -555,21 +545,25 @@ static void cochran_parse_samples(struct dive *dive, 
const unsigned char *log,
// Get NDL and deco information
switch (seconds % 24) {
case 20:
-   if (in_deco) {
-   // Fist stop time
-   //first_deco_time = (s[2] + s[5] * 256 
+ 1) * 60; // seconds
-   ndl = 0;
-   } else {
-   // NDL
-   ndl = (s[2] + s[5] * 256 + 1) * 60; // 
seconds
-   deco_time = 0;
+   if (offset + 5 < size) {
+   if (in_deco) {
+   // Fist stop time
+   //first_deco_time = (s[2] + 
s[5] * 256 + 1) * 60; // seconds
+   ndl = 0;
+   } else {
+   // NDL
+   ndl = (s[2] + s[5] * 256 + 1) * 
60; // seconds
+   deco_time = 0;
+   }
}
break;
case 22:
-   if (in_deco) {
-   // Total stop time
-   deco_time = (s[2] + s[5] * 256 + 1) * 
60; // seconds
-   ndl = 0;
+   if (offset + 5 < size) {
+

Re: Initial crash in MacOS Sierra

2017-05-26 Thread Thiago Macieira 
On sexta-feira, 26 de maio de 2017 12:53:54 PDT Thiago Macieira wrote:
> On segunda-feira, 15 de maio de 2017 01:55:33 PDT Robert Helling wrote:
> > Thiago,
> > 
> > could you please have a look at this:
> > https://github.com/Subsurface-divelog/subsurface/issues/398#issuecomment-3
> > 0
> > 1407498
> > 
> > User reports Subsurface crashing on start up and it seems it is in the
> > intial network operation where it determines if it is the latest version.
> > Somehow it seems Qt-networking is calling into CoreFoundations with an
> > illegal nil argument.
> > 
> > Needless to say, I cannot reproduce this problem here.
> 
> Hi Robert
> 
> I haven't yet got Subsurface to build on my Mac, so I couldn't debug yet.
> I'm trying to fight CMake so that it will find OpenSSL properly: my Mac is
> a little unusual in that I didn't install the Xcode Command Line tools, but
> instead I added
> 
>   /Applications/Xcode.app/Contents/Developer/Toolchains/
> XcodeDefault.xctoolchain/usr/bin
> 
> to $PATH instead. So I keep getting now:
> 
>  ld: library not found for -lssl
> 
> The older SDKs (for macOS 10.8 through 10.10) had libssl.dylib, but the
> newest Xcode only carries the 10.12 SDK and that doesn't have libssl.dylib.

That was easy to fix: just drop -lssl -lcrypto from the command-line. Then it 
links without errors.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

Re: Initial crash in MacOS Sierra

2017-05-26 Thread Thiago Macieira 
On segunda-feira, 15 de maio de 2017 01:55:33 PDT Robert Helling wrote:
> Thiago,
> 
> could you please have a look at this:
> https://github.com/Subsurface-divelog/subsurface/issues/398#issuecomment-30
> 1407498
> 
> User reports Subsurface crashing on start up and it seems it is in the
> intial network operation where it determines if it is the latest version.
> Somehow it seems Qt-networking is calling into CoreFoundations with an
> illegal nil argument.
> 
> Needless to say, I cannot reproduce this problem here.

Hi Robert

I haven't yet got Subsurface to build on my Mac, so I couldn't debug yet. I'm 
trying to fight CMake so that it will find OpenSSL properly: my Mac is a little 
unusual in that I didn't install the Xcode Command Line tools, but instead I 
added 

  /Applications/Xcode.app/Contents/Developer/Toolchains/
XcodeDefault.xctoolchain/usr/bin

to $PATH instead. So I keep getting now:

 ld: library not found for -lssl

The older SDKs (for macOS 10.8 through 10.10) had libssl.dylib, but the newest 
Xcode only carries the 10.12 SDK and that doesn't have libssl.dylib.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

Re: Download dives from dive computer on mobile, status report.

2017-05-26 Thread Jan Mulder 

On 26-05-17 18:11, Tomaz Canabrava wrote:
Today I made  a breakthrougth and I can actually download the dives on 
the mobile version.
The code is 100% shared with the desktop version, so nothing new was 
written to support that, this means that I kept code written to a 
minimum (moving things around, creating some helper classes to deal 
with desktop and mobile), for instance.


Some points:
1 - the deviceName currently is hardcoded to "/tmp/ttyS1"
2 - I tested with the simulator since I don't have a BT hardware
3 - Bt is not done nor tested.
4 - The downloaded dives are not being save yet.

I'm going to the Opensuse Conf this weekend, so I'm not sure if I will 
have the time to hack on this on the weekend, but if you guys wanna 
help, my branch is in https://github.com:tcanabrava/subsurface.git / 
DiveComputerQml


picture to proof.

Tomaz


I have tried the following:
1) mobile on desktop, reading from the libdc simulator => working (as 
expected),
2) mobile on desktop,reading from OSTC3 over BT. For this, I hardcoded 
the BT address of my OSTC, and set the BT mode to true (obviously). The 
OSTC goes correctly in download mode, and stays there for multiple 
minutes. The console finally shows "Finishing the thread dives 
downloaded 125". So, the next breakthrough today :-) The first download 
over BT from a real dive computer :-) And most impressive, without 
changing any of the code from Tomaz. Obviously, there is something 
needed: a progress (toast) style thingy, or any other indication that it 
is downloading. Further, I was downloading in my normal logbook, so I 
did not expect any dives downloaded that were already downloaded 
(without looking to any code at this point).
3) mobile on mobile ... ok, this is not working yet. I verified that 
pairing is ok, and I can trigger a download over my mobile (using 
terminal input), so raw serial traffic. So the two devices can 
communicate. It seems that subsurface mobile is not attempting any 
communication.


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

Re: Download dives from dive computer on mobile, status report.

2017-05-26 Thread Willem Ferguson 

On 26/05/2017 19:24, Dirk Hohndel wrote:

On May 26, 2017, at 9:11 AM, Tomaz Canabrava  wrote:

Today I made  a breakthrougth and I can actually download the dives on the 
mobile version.
The code is 100% shared with the desktop version, so nothing new was written to 
support that, this means that I kept code written to a minimum (moving things 
around, creating some helper classes to deal with desktop and mobile), for 
instance.

Some points:
1 - the deviceName currently is hardcoded to "/tmp/ttyS1"
2 - I tested with the simulator since I don't have a BT hardware
3 - Bt is not done nor tested.
4 - The downloaded dives are not being save yet.

I'm going to the Opensuse Conf this weekend, so I'm not sure if I will have the 
time to hack on this on the weekend, but if you guys wanna help, my branch is 
in https://github.com:tcanabrava/subsurface.git / DiveComputerQml
Tomaz, I am especially impressed by the fact that you did it while 
sharing all the code with the desktop.

Kind regards,
willem

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

Re: Download dives from dive computer on mobile, status report.

2017-05-26 Thread Dirk Hohndel 

> On May 26, 2017, at 9:11 AM, Tomaz Canabrava  wrote:
> 
> Today I made  a breakthrougth and I can actually download the dives on the 
> mobile version.
> The code is 100% shared with the desktop version, so nothing new was written 
> to support that, this means that I kept code written to a minimum (moving 
> things around, creating some helper classes to deal with desktop and mobile), 
> for instance.
> 
> Some points:
> 1 - the deviceName currently is hardcoded to "/tmp/ttyS1"
> 2 - I tested with the simulator since I don't have a BT hardware
> 3 - Bt is not done nor tested.
> 4 - The downloaded dives are not being save yet.
> 
> I'm going to the Opensuse Conf this weekend, so I'm not sure if I will have 
> the time to hack on this on the weekend, but if you guys wanna help, my 
> branch is in https://github.com:tcanabrava/subsurface.git / DiveComputerQml

That looks extremely promising. Thank you, Tomaz.

I'll look at the code to see if we can already merge it. My #1 concern is of 
course 'make sure we don't break Subsurface' while adding this to 
Subsurface-mobile. But this looks really, really exciting :-)

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

Re: Building Subsurface-mobile for Android

2017-05-26 Thread Jan Mulder 

On 25-05-17 09:13, Willem Ferguson wrote:

I am attempting to build the Android version of Subsurface and get:

~/src
-- building with libftdi support
-- system name Android
-- Found Qt for Android: /home/willem/src/Qt/5.8/android_armv7
-- Found Android SDK: /home/willem/src/subsurface/../android-sdk-linux
-- Found Android NDK: /home/willem/src/subsurface/../android-ndk-r13b
-- Configuring done
CMake Error in CMakeLists.txt:
  No known features for CXX compiler

  "GNU"

  version 4.9.

Activating set(CMAKE_VERBOSE_MAKEFILE ON) does not give more information.

What could the problem be?

Kind regards,

willem


Willem, yes, cross-building for Android can be a real pain. it is very 
difficult to determine what the cause of your build problem is. I assume 
that you are trying to compile using the build.sh script in 
packaging/android? Yesterday, I ran into multiple build problems when 
trying to build myself. To be sure that all dependencies are compiled, I 
manually remove the *_arm directories, before running the 
packaging/android/build.sh. For the record, I do not use the 
android-build-wrapper.sh script. This just downloads NDK/SDK/Qt 
dependencies that I have already have on my system, so I just point the 
build.sh to the already installed NDK/SDK/Qt.


I added a pull request (yesterday) related to Android builds: see 
https://github.com/Subsurface-divelog/subsurface/pull/405. But I do not 
see how this can be related to your build issue.


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