Re: Import data from Scubapro Aladin Sport Matrix

[Linus Torvalds]

On Wed, Nov 1, 2017 at 2:44 AM, Berthold Stoeger
 wrote:
>> @Linus: patch attached. Sorry about that.
>
> Forgot to commit one file...

Thanks, applied.

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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

> @Linus: patch attached. Sorry about that.

Forgot to commit one file...

Berthold
>From 27562a715bdd4955f665d376d2103efc2e236142 Mon Sep 17 00:00:00 2001
From: Berthold Stoeger 
Date: Wed, 1 Nov 2017 10:16:51 +0100
Subject: [PATCH] Fix model number of the Scubapro Aladin Sport Matrix.

The model number was wrong. Mea culpa.

Signed-off-by: Berthold Stoeger 
---
 src/descriptor.c  | 2 +-
 src/scubapro_g2.c | 2 +-
 src/uwatec_smart_parser.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/descriptor.c b/src/descriptor.c
index b1b6dd1..0df6ca0 100644
--- a/src/descriptor.c
+++ b/src/descriptor.c
@@ -140,7 +140,7 @@ static const dc_descriptor_t g_descriptors[] = {
 	/* Scubapro G2 */
 #ifdef USBHID
 	{"Scubapro", "G2",  DC_FAMILY_UWATEC_G2, 0x32},  // BLE
-	{"Scubapro", "Aladin Sport Matrix", DC_FAMILY_UWATEC_G2, 0xa5},  // BLE
+	{"Scubapro", "Aladin Sport Matrix", DC_FAMILY_UWATEC_G2, 0x17},  // BLE
 #endif
 	/* Reefnet */
 	{"Reefnet", "Sensus",   DC_FAMILY_REEFNET_SENSUS, 1},
diff --git a/src/scubapro_g2.c b/src/scubapro_g2.c
index dc1d221..04a83a2 100644
--- a/src/scubapro_g2.c
+++ b/src/scubapro_g2.c
@@ -35,7 +35,7 @@
 #define RX_PACKET_SIZE 64
 #define TX_PACKET_SIZE 32
 
-#define ALADINSPORTMATRIX 0xa5
+#define ALADINSPORTMATRIX 0x17
 
 typedef struct scubapro_g2_device_t {
 	dc_device_t base;
diff --git a/src/uwatec_smart_parser.c b/src/uwatec_smart_parser.c
index 95a28fa..e0726e4 100644
--- a/src/uwatec_smart_parser.c
+++ b/src/uwatec_smart_parser.c
@@ -41,6 +41,7 @@
 #define ALADINTEC2G   0x13
 #define SMARTCOM  0x14
 #define ALADIN2G  0x15
+#define ALADINSPORTMATRIX 0x17
 #define SMARTTEC  0x18
 #define GALILEOTRIMIX 0x19
 #define SMARTZ0x1C
@@ -48,7 +49,6 @@
 #define CHROMIS   0x24
 #define MANTIS2   0x26
 #define G20x32
-#define ALADINSPORTMATRIX 0xa5
 
 #define UNSUPPORTED 0x
 
-- 
2.14.1

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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

On Mittwoch, 1. November 2017 09:42:04 CET Jef Driesen wrote:
> On 31-10-17 23:35, Berthold Stoeger wrote:
> > On Dienstag, 31. Oktober 2017 11:29:00 CET Jef Driesen wrote:
> >> I believe you have the model number wrong. I think it should be 0x17,
> > 
> >> and your test seems to confirm that:
> > Well, I put a printf directly after "rc = scubapro_g2_transfer (device,
> > cmd_model, sizeof (cmd_model), model, sizeof (model));" and guess what?
> > I got both, 0x17 *and* 0xa5 (the latter much more commonly). There seems
> > to be some race. Will investigate further - tomorrow.
> > 
> > But when manually sending 0x10 manually with my test program, I
> > consistently get a 0x17, which therefore seems to be the correct model.
> > Sigh.
> 
> That's indeed strange. Probably something is still wrong. Can you share the
> logs? Maybe we can spot something?

Nothing wrong - turns out the culprit was my own "inject dive data" code (a5 
is the start of a new dive). That's what you get for trying to be clever. :(

The correct model number is 0x17 - I will send you logs later.

@Linus: patch attached. Sorry about that.

Berthold>From 808b84b5b56feeff7920f8de0e011bb910724485 Mon Sep 17 00:00:00 2001
From: Berthold Stoeger 
Date: Wed, 1 Nov 2017 10:16:51 +0100
Subject: [PATCH] Fix model number of the Scubapro Aladin Sport Matrix.

The model number was wrong. Mea culpa.

Signed-off-by: Berthold Stoeger 
---
 src/descriptor.c  | 2 +-
 src/uwatec_smart_parser.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/descriptor.c b/src/descriptor.c
index b1b6dd1..0df6ca0 100644
--- a/src/descriptor.c
+++ b/src/descriptor.c
@@ -140,7 +140,7 @@ static const dc_descriptor_t g_descriptors[] = {
 	/* Scubapro G2 */
 #ifdef USBHID
 	{"Scubapro", "G2",  DC_FAMILY_UWATEC_G2, 0x32},  // BLE
-	{"Scubapro", "Aladin Sport Matrix", DC_FAMILY_UWATEC_G2, 0xa5},  // BLE
+	{"Scubapro", "Aladin Sport Matrix", DC_FAMILY_UWATEC_G2, 0x17},  // BLE
 #endif
 	/* Reefnet */
 	{"Reefnet", "Sensus",   DC_FAMILY_REEFNET_SENSUS, 1},
diff --git a/src/uwatec_smart_parser.c b/src/uwatec_smart_parser.c
index 95a28fa..e0726e4 100644
--- a/src/uwatec_smart_parser.c
+++ b/src/uwatec_smart_parser.c
@@ -41,6 +41,7 @@
 #define ALADINTEC2G   0x13
 #define SMARTCOM  0x14
 #define ALADIN2G  0x15
+#define ALADINSPORTMATRIX 0x17
 #define SMARTTEC  0x18
 #define GALILEOTRIMIX 0x19
 #define SMARTZ0x1C
@@ -48,7 +49,6 @@
 #define CHROMIS   0x24
 #define MANTIS2   0x26
 #define G20x32
-#define ALADINSPORTMATRIX 0xa5
 
 #define UNSUPPORTED 0x
 
-- 
2.14.1

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

Re: Import data from Scubapro Aladin Sport Matrix

[Jef Driesen]

On 31-10-17 23:35, Berthold Stoeger wrote:

On Dienstag, 31. Oktober 2017 11:29:00 CET Jef Driesen wrote:


I believe you have the model number wrong. I think it should be 0x17,
and your test seems to confirm that:


Well, I put a printf directly after "rc = scubapro_g2_transfer (device,
cmd_model, sizeof (cmd_model), model, sizeof (model));" and guess what?
I got both, 0x17 *and* 0xa5 (the latter much more commonly). There seems to be
some race. Will investigate further - tomorrow.

But when manually sending 0x10 manually with my test program, I consistently
get a 0x17, which therefore seems to be the correct model. Sigh.


That's indeed strange. Probably something is still wrong. Can you share the 
logs? Maybe we can spot something?


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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

On Dienstag, 31. Oktober 2017 11:29:00 CET Jef Driesen wrote:

> I believe you have the model number wrong. I think it should be 0x17,
> and your test seems to confirm that:

Well, I put a printf directly after "rc = scubapro_g2_transfer (device, 
cmd_model, sizeof (cmd_model), model, sizeof (model));" and guess what?
I got both, 0x17 *and* 0xa5 (the latter much more commonly). There seems to be 
some race. Will investigate further - tomorrow.

But when manually sending 0x10 manually with my test program, I consistently 
get a 0x17, which therefore seems to be the correct model. Sigh.

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

Re: Import data from Scubapro Aladin Sport Matrix

[Jef Driesen]

On 2017-10-31 12:12, Berthold Stoeger wrote:

Hi Jef,

On Dienstag, 31. Oktober 2017 11:29:00 CET Jef Driesen wrote:

On 2017-10-23 00:55, Berthold Stoeger wrote:
> On Sonntag, 22. Oktober 2017 04:31:39 CEST Linus Torvalds wrote:
>> so you literally *could* try to claim it's a G2 and try to see how far
>> it downloads.
>
> The handshake is different. The G2 client sends 1b and 1c1027 and
> expects
> 01 as the answer twice. The Aladin Sport returns 00 in both cases.
> Since
> LogTrak doesn't do any handshake, I just removed the call to
> scubapro_g2_handshake().

Am I right you only tested downloading over bluetooth (BLE)? Can you
also try over USB? I suspect that logtrak still does the handshaking
when downloading over USB. If that's correct, then omitting the
handshaking is not specific to the Sport Matrix, but the underlying
transport.


To my knowledge the Sport Matrix does only support BLE! At least that's 
how I

read
https://ww2.scubapro.com/en-GB/SWE/instruments/computers/products/aladin-sport-matrix.aspx:

| For PCs and Macs that are not equipped with built-in Bluetooth Low 
Energy
| technology, the end user will have to buy a Bluetooth Low Energy USB 
dongle

| which is available on the market.


I simply assumed it was similar to the G2, which supports both.

That's why I feel that dc_descriptor_get_transport() should return 
flags, not

enums. You want to differentiate between USB, BT, USB+BT, don't you?


Indeed! Such a change is already on my todo list :-)

Because it breaks backwards compatibility, I will introduce it together 
with some other non-backwards compatible changes, like the I/O 
factoring. That way applications only have to be updated once.



But yes, doing handshakes based on transport not model is a good idea.


The less "if (model == X)" code we need, the better!

Note that in most cases the exact model number is communicated by the 
device during the download. Needing the model number up front breaks 
this auto-detection mechanism. (You would be surprised how many users 
don't know exactly which model they have. For some dive computers, the 
naming can indeed be confusing.)


I don't have access to the computer right know and will answer to your 
other

remarks later.


Excellent!

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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

Hi Jef,

On Dienstag, 31. Oktober 2017 11:29:00 CET Jef Driesen wrote:
> On 2017-10-23 00:55, Berthold Stoeger wrote:
> > On Sonntag, 22. Oktober 2017 04:31:39 CEST Linus Torvalds wrote:
> >> so you literally *could* try to claim it's a G2 and try to see how far
> >> it downloads.
> > 
> > The handshake is different. The G2 client sends 1b and 1c1027 and
> > expects
> > 01 as the answer twice. The Aladin Sport returns 00 in both cases.
> > Since
> > LogTrak doesn't do any handshake, I just removed the call to
> > scubapro_g2_handshake().
> 
> Am I right you only tested downloading over bluetooth (BLE)? Can you
> also try over USB? I suspect that logtrak still does the handshaking
> when downloading over USB. If that's correct, then omitting the
> handshaking is not specific to the Sport Matrix, but the underlying
> transport.

To my knowledge the Sport Matrix does only support BLE! At least that's how I 
read 
https://ww2.scubapro.com/en-GB/SWE/instruments/computers/products/aladin-sport-matrix.aspx:

| For PCs and Macs that are not equipped with built-in Bluetooth Low Energy
| technology, the end user will have to buy a Bluetooth Low Energy USB dongle
| which is available on the market.

That's why I feel that dc_descriptor_get_transport() should return flags, not 
enums. You want to differentiate between USB, BT, USB+BT, don't you?

But yes, doing handshakes based on transport not model is a good idea.

I don't have access to the computer right know and will answer to your other 
remarks later.

Thanks,

Berthold



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

Re: Import data from Scubapro Aladin Sport Matrix

[Jef Driesen]

On 2017-10-23 00:55, Berthold Stoeger wrote:

On Sonntag, 22. Oktober 2017 04:31:39 CEST Linus Torvalds wrote:


so you literally *could* try to claim it's a G2 and try to see how far
it downloads.


The handshake is different. The G2 client sends 1b and 1c1027 and 
expects
01 as the answer twice. The Aladin Sport returns 00 in both cases. 
Since

LogTrak doesn't do any handshake, I just removed the call to
scubapro_g2_handshake().


Am I right you only tested downloading over bluetooth (BLE)? Can you 
also try over USB? I suspect that logtrak still does the handshaking 
when downloading over USB. If that's correct, then omitting the 
handshaking is not specific to the Sport Matrix, but the underlying 
transport.


Note that logtrak also supports a second variant of the handshaking 
(0xF4), in case the other two (0x1B and 0x1C) return zero, but I have 
never seen that so far. Maybe the Sport Matrix is in this category?


Apart from that - you were right - it seems to be compatible with the 
G2! Only
the dates are incorrect - I will try to figure out what is going on. 
All I had
to do was adding a case in the switch in uwatec_smart_parser_create(). 
The id
of the Aladin Sport Matrix is 0xa5, by the way. And it works! Thank you 
very

much for your support!


I believe you have the model number wrong. I think it should be 0x17, 
and your test seems to confirm that:


Command: 0110
Output : 0117

Do you mind sending me a libdivecomputer memory dump and logfile?

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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

On Sonntag, 29. Oktober 2017 15:23:42 CET Linus Torvalds wrote:

> I've merged this, and also merged Jef's patch to fix the date handling
> problem I noticed on the trip. So current libdivecomputer should
> handle the Aladin Sport Matrix correctly, and also fix the date
> downloading problems you had when your clock got confused.

Great, I can confirm that it now gets the timestamps right. Thank you!

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

Re: Import data from Scubapro Aladin Sport Matrix

[Linus Torvalds]

On Mon, Oct 23, 2017 at 12:39 PM, Berthold Stoeger
 wrote:
>
> Nevertheless, in the attachments is my attempt at making the Aladin Sport
> Matrix work.

Ok, I'm back home, and going through old emails.

I've merged this, and also merged Jef's patch to fix the date handling
problem I noticed on the trip. So current libdivecomputer should
handle the Aladin Sport Matrix correctly, and also fix the date
downloading problems you had when your clock got confused.

Of course, nothing will fix things if you actually do the _dive_ with
the dive computer clock set incorrectly, but now at least the download
should work fine even if you then screwed up the time on the dive
computer after the dive.

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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

On Montag, 16. Oktober 2017 08:06:55 CEST Berthold Stoeger wrote:
> Dear all,
> 
> On Sonntag, 15. Oktober 2017 22:08:52 CEST Berthold Stoeger wrote:
> > By the way, there seems to be a strange bug(?): for the first failed
> > download I get an information window. For each subsequent retry there is
> > an
> > additional window. E.g. for the 5th failed download it opens 5 information
> > windows at once.
> 
> Answering to myself here: The issue seems to be the
>   connect(, SIGNAL(finished()), ...);
> call in on_downloadCancelRetryButton_clicked(), which apparently is
> accumulative. Moving this call to the constructor solves the "problem".
> That being said, I don't understand anything of that Qt SIGNAL/SLOT
> business. Moreover, there is a second connect call, which perhaps should
> also be called only once.

Related minor issue: by not clearing the error string of the thread a 
successful download after a failed download would still show an error message. 
Trivial patch attached. Not exactly sure where to put the error.clear() 
though.

Berthold>From 76933018a81750d04ad8a05a2676e3476022d455 Mon Sep 17 00:00:00 2001
From: Berthold Stoeger 
Date: Tue, 24 Oct 2017 00:27:52 +0200
Subject: [PATCH] Clear error string when starting dive computer download.

The error string of the download-from-divecomputer thread was not
cleared. Thus, if an error occured an error message was also shown
on subsequent successful downloads.

Signed-off-by: Berthold Stoeger 
---
 core/downloadfromdcthread.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/core/downloadfromdcthread.cpp b/core/downloadfromdcthread.cpp
index 2e6493d3..70b21489 100644
--- a/core/downloadfromdcthread.cpp
+++ b/core/downloadfromdcthread.cpp
@@ -43,6 +43,7 @@ void DownloadThread::run()
 	Q_ASSERT(internalData->download_table != nullptr);
 	const char *errorText;
 	import_thread_cancelled = false;
+	error.clear();
 	if (!strcmp(internalData->vendor, "Uemis"))
 		errorText = do_uemis_import(internalData);
 	else
-- 
2.14.1

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

Re: Import data from Scubapro Aladin Sport Matrix

[Linus Torvalds]

On Oct 23, 2017 15:39, "Berthold Stoeger" 
wrote:


> Only the dates are incorrect - I will try to figure out what is going on.

Sigh. This was probably also me sending random commands. :( It somehow reset
the date to 1.1.2000 and I think this messed with the dive timestamps.


Yes, there is a known issue with the Uwatec dive date handling, and it gets
confused if the time or timezone is off. A patch exists, this will be fixed
shortly.

The internet here in Bonaire is acting up again, so I'm not going to try to
do any libdivecomputer work from here, but I'll take a look at your patch
when I get better internet tomorrow.

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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

On Montag, 23. Oktober 2017 00:55:37 CEST Berthold Stoeger wrote:

> Only the dates are incorrect - I will try to figure out what is going on.

Sigh. This was probably also me sending random commands. :( It somehow reset 
the date to 1.1.2000 and I think this messed with the dive timestamps. In my 
dump I have e.g. 1119425450 for what should be 18.09.2017 1:32 GMT, but it 
returns 1515890085[*] for current time (after I reset to correct date). So I'm 
not going to look closer into this for now. Perhaps I'll try to do a factory 
reset later.

Nevertheless, in the attachments is my attempt at making the Aladin Sport 
Matrix work.

Disclaimer 1: I don't own a G2, therefore I couldn't test if it still works.
Disclaimer 2: Since I reset the ringbuffer, I could only test the "no dives" 
case for the patch as is. To test the import I had to inject my dump.
Disclaimer 3: Obviously cargo-culting here.

Berthold

[*] Yes, this is the future according to the unix epoch.>From 5e9bada206aac445652d8dd80a9eefbe571103b8 Mon Sep 17 00:00:00 2001
From: Berthold Stoeger 
Date: Mon, 23 Oct 2017 20:55:19 +0200
Subject: [PATCH] Support for the Scubapro Aladin Sport Matrix.

The protocol is identical to the G2 protocol, with the exception of a
missing handshake.

Signed-off-by: Berthold Stoeger 
---
 src/descriptor.c  |  3 ++-
 src/device.c  |  2 +-
 src/scubapro_g2.c | 13 ++---
 src/scubapro_g2.h |  2 +-
 src/uwatec_smart_parser.c | 32 +---
 5 files changed, 31 insertions(+), 21 deletions(-)

diff --git a/src/descriptor.c b/src/descriptor.c
index a1fa965..b1b6dd1 100644
--- a/src/descriptor.c
+++ b/src/descriptor.c
@@ -139,7 +139,8 @@ static const dc_descriptor_t g_descriptors[] = {
 	{"Scubapro", "Mantis 2",DC_FAMILY_UWATEC_MERIDIAN, 0x26},
 	/* Scubapro G2 */
 #ifdef USBHID
-	{"Scubapro", "G2",  DC_FAMILY_UWATEC_G2, 0x32},	// BLE
+	{"Scubapro", "G2",  DC_FAMILY_UWATEC_G2, 0x32},  // BLE
+	{"Scubapro", "Aladin Sport Matrix", DC_FAMILY_UWATEC_G2, 0xa5},  // BLE
 #endif
 	/* Reefnet */
 	{"Reefnet", "Sensus",   DC_FAMILY_REEFNET_SENSUS, 1},
diff --git a/src/device.c b/src/device.c
index 0a9e2ba..35e0951 100644
--- a/src/device.c
+++ b/src/device.c
@@ -140,7 +140,7 @@ dc_device_open (dc_device_t **out, dc_context_t *context, dc_descriptor_t *descr
 		rc = uwatec_meridian_device_open (, context, name);
 		break;
 	case DC_FAMILY_UWATEC_G2:
-		rc = scubapro_g2_device_open (, context, name);
+		rc = scubapro_g2_device_open (, context, name, dc_descriptor_get_model (descriptor));
 		break;
 	case DC_FAMILY_REEFNET_SENSUS:
 		rc = reefnet_sensus_device_open (, context, name);
diff --git a/src/scubapro_g2.c b/src/scubapro_g2.c
index 6351b69..dc1d221 100644
--- a/src/scubapro_g2.c
+++ b/src/scubapro_g2.c
@@ -35,6 +35,8 @@
 #define RX_PACKET_SIZE 64
 #define TX_PACKET_SIZE 32
 
+#define ALADINSPORTMATRIX 0xa5
+
 typedef struct scubapro_g2_device_t {
 	dc_device_t base;
 	unsigned int timestamp;
@@ -149,7 +151,7 @@ scubapro_g2_transfer(scubapro_g2_device_t *g2, const unsigned char command[], un
 
 
 static dc_status_t
-scubapro_g2_handshake (scubapro_g2_device_t *device)
+scubapro_g2_handshake (scubapro_g2_device_t *device, unsigned int model)
 {
 	dc_device_t *abstract = (dc_device_t *) device;
 
@@ -157,6 +159,11 @@ scubapro_g2_handshake (scubapro_g2_device_t *device)
 	unsigned char answer[1] = {0};
 	unsigned char command[5] = {0x00, 0x10, 0x27, 0, 0};
 
+	// The vendor software does not do a handshake for the Aladin Sport Matrix,
+	// so let's not do any either.
+	if (model == ALADINSPORTMATRIX)
+		return DC_STATUS_SUCCESS;
+
 	// Handshake (stage 1).
 	command[0] = 0x1B;
 	dc_status_t rc = scubapro_g2_transfer (device, command, 1, answer, 1);
@@ -186,7 +193,7 @@ scubapro_g2_handshake (scubapro_g2_device_t *device)
 
 
 dc_status_t
-scubapro_g2_device_open(dc_device_t **out, dc_context_t *context, const char *name)
+scubapro_g2_device_open(dc_device_t **out, dc_context_t *context, const char *name, unsigned int model)
 {
 	dc_status_t status = DC_STATUS_SUCCESS;
 	scubapro_g2_device_t *device = NULL;
@@ -219,7 +226,7 @@ scubapro_g2_device_open(dc_device_t **out, dc_context_t *context, const char *na
 	}
 
 	// Perform the handshaking.
-	status = scubapro_g2_handshake(device);
+	status = scubapro_g2_handshake(device, model);
 	if (status != DC_STATUS_SUCCESS) {
 		ERROR (context, "Failed to handshake with the device.");
 		goto error_close;
diff --git a/src/scubapro_g2.h b/src/scubapro_g2.h
index 43f007a..f960e55 100644
--- a/src/scubapro_g2.h
+++ b/src/scubapro_g2.h
@@ -31,7 +31,7 @@ extern "C" {
 #endif /* __cplusplus */
 
 dc_status_t
-scubapro_g2_device_open (dc_device_t **device, dc_context_t *context, const char *name);
+scubapro_g2_device_open (dc_device_t **device, dc_context_t *context, const char *name, unsigned int model);
 
 #ifdef __cplusplus
 }
diff --git 

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

On Sonntag, 22. Oktober 2017 04:31:39 CEST Linus Torvalds wrote:

> so you literally *could* try to claim it's a G2 and try to see how far
> it downloads.

The handshake is different. The G2 client sends 1b and 1c1027 and expects 
01 as the answer twice. The Aladin Sport returns 00 in both cases. Since 
LogTrak doesn't do any handshake, I just removed the call to 
scubapro_g2_handshake().

Apart from that - you were right - it seems to be compatible with the G2! Only 
the dates are incorrect - I will try to figure out what is going on. All I had 
to do was adding a case in the switch in uwatec_smart_parser_create(). The id 
of the Aladin Sport Matrix is 0xa5, by the way. And it works! Thank you very 
much for your support!

[Unimportant side story: The way there was a bit rugged - my "send all 
commands" experiment was stupid - it reset the ring buffer and now it always 
returns 0 bytes. But thanks to the c7 command I could dump all 128 K of memory 
and the location of the dives were very obvious. So I just injected them 
manually.]

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

Re: Import data from Scubapro Aladin Sport Matrix

[Linus Torvalds]

On Sat, Oct 21, 2017 at 7:56 PM, Berthold Stoeger
 wrote:
>
> Fetch newest dives does (I: to divecomputer O: from divecomputer)
> I: 09c69a32b9421027
> O: 04

That actually looks like the Scubapro G2 protocol. Same model of
9-byte command with a 0xC6 command byte and then a 4-byte timestamp
and then 0x10 0x27. From src/scubapro_g2.c:

// Command template.
unsigned char command[9] = {0x00,
(device->timestamp  ) & 0xFF,
(device->timestamp >> 8 ) & 0xFF,
(device->timestamp >> 16) & 0xFF,
(device->timestamp >> 24) & 0xFF,
0x10,
0x27,
0,
0};

// Data Length.
command[0] = 0xC6;
unsigned char answer[4] = {0};
rc = scubapro_g2_transfer (device, command, sizeof (command),
answer, sizeof (answer));

so you literally *could* try to claim it's a G2 and try to see how far
it downloads.

> So does this ring a bell or should I try to investigate further?

I think you might want to investigate further - have you looked at the
libdivecomputer source code at all?

There are various minor differences in the details of the Uwatec
protocol, so there might be differences. So maybe it might download
like a G2, but then need parsing as some older Uwatec thing (ie I'd
not be surprised if they just replaced the old nasty IRdA crud with
bluetooth).

See src/scubapro_g2.c for the downloading part, but  notice how it
uses the src/uwatec_smart_parser.c parsing. It might just parse the
same was as the old Uwatec Aladin..

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

Re: Import data from Scubapro Aladin Sport Matrix

[Linus Torvalds]

On Thu, Oct 19, 2017 at 5:51 PM, Berthold Stoeger
 wrote:
>
> Sorry, I confused dec 18 with hex 18. The second characteristic is notify and
> read. This is clearly a read/write pair.

So that looks very regular, and the existing code in core/qt-ble.cpp
should hopefully "just work" for the communication side.

The question is mainly what the protocol is. We have had cases where
the bluetooth packets are literally just a direct translation of a
previous serial line protocol, and then the serial emulation code
should just work. But honestly, that's the exception rather than the
rule. Usually there is some packetization and quoting layer, even if
it might be trivial.

If you have an android phone that has a vendor appliction to download
dives, you can try to generate a bluetooth snoop log. Google for
"bluetooth snoop android" - you'll need to enable a developer option
(and not every phone necessarily allows that) and then get the
resulting log out of the phone (which can be another problem spot).
And then maybe we can figure things out.

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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

On Donnerstag, 19. Oktober 2017 00:45:37 CEST Berthold Stoeger wrote:
> 
> On the Aladin Sport there is a single non-standard "service"
> {fdcdeaaa-295d-470e-bf15-04217b7aa0a0}.
> This service has two "characteristics":
> 1) {a188b7dd-debb-449a-852d-c243d46b4b1a} with property "write".
> 2) {aa0c68f0-ea9c-493d-8112-62879e72af68} with properties "notify" and
> "write".

Sorry, I confused dec 18 with hex 18. The second characteristic is notify and 
read. This is clearly a read/write pair.

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

Re: Import data from Scubapro Aladin Sport Matrix

[Dirk Hohndel]

> On Oct 18, 2017, at 6:45 PM, Berthold Stoeger  
> wrote:
> 
> Unrelated point: Perhaps I'm missing something obvious, but I think the code 
> in qt-ble.cpp leaks resources. Is it worth noting such things, or is this 
> work-in-progress so don't bother?

Always worth reporting. Some times we allow small leaks to keep code sane, but 
in
general we try to do good housekeeping.

> Example:
> In line 333 a BLEObject is generated, but it seems not to be destroyed if one 
> of the two subsequent error conditions (l. 347, 362) happen.
> 
> On the other hand, in the standard case, it's not obvious where the 
> controller 
> is destroyed.
> 
> Or in line 132, a QLowEnergyService is generated (Qt documentation: the 
> caller 
> takes ownership) and the pointer stuffed in a list, but it doesn't seem to be 
> destroyed anywhere.

All good points that need investigating.

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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

On Sonntag, 15. Oktober 2017 18:31:34 CEST Linus Torvalds wrote:

> So I think you have two issues that make it but work for you.
> 
> The first and more fundamental is that we haven't done the BLE support for
> the Aladin Sport at all yet, unless somebody did it without me even
> noticing.
> 
> Because sadly, Bluetooth LE is a complete disaster from a standards
> standpoint. There is no standard way of doing a simple serial thing, every
> dive computer manufacturer had to make up their own thing. The Bluetooth
> SIG is incompetent, I feel.
> 
> So we need to have somebody with access to that dive computer figure out
> how it ends up implementing the protocol over BLE. It might be a trivial
> packetized serial version of existing protocols, and it might have extra
> encapsulation.

Alright, I tried to understand what is going on in core/qt-ble.cpp. All this 
callback with libdivecomputer is scary, but I think I roughly get the idea.

What I got so far:

On the Aladin Sport there is a single non-standard "service" 
{fdcdeaaa-295d-470e-bf15-04217b7aa0a0}.
This service has two "characteristics":
1) {a188b7dd-debb-449a-852d-c243d46b4b1a} with property "write".
2) {aa0c68f0-ea9c-493d-8112-62879e72af68} with properties "notify" and 
"write".

Writing 0x01 0x00 to the CCC of 2) gives a descriptorWritten signal. This 
should turn on "notification".

But then I'm stuck. Writing a few random bytes to the characteristic 1) gives 
a characteristicWritten signal. But nothing else happens. Writing anything to 
characteristic 2) does not even give a signal. Nothing at all happens.

Any ideas?

Unrelated point: Perhaps I'm missing something obvious, but I think the code 
in qt-ble.cpp leaks resources. Is it worth noting such things, or is this 
work-in-progress so don't bother?

Example:
In line 333 a BLEObject is generated, but it seems not to be destroyed if one 
of the two subsequent error conditions (l. 347, 362) happen.

On the other hand, in the standard case, it's not obvious where the controller 
is destroyed.

Or in line 132, a QLowEnergyService is generated (Qt documentation: the caller 
takes ownership) and the pointer stuffed in a list, but it doesn't seem to be 
destroyed anywhere.

Thank you,

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

Re: Import data from Scubapro Aladin Sport Matrix

[Dirk Hohndel]

> On Oct 16, 2017, at 7:41 AM, Berthold Stoeger  
> wrote:
>> 
>> Would you be able to create a commit with "Signed-off-by" line?
>> Or even a GitHub pull request?
> 
> I tried, but I have no idea what I'm doing:
> https://github.com/Subsurface-divelog/subsurface/pull/670

Excellent. I love getting new developers involved. I'll take a look right now 
:-)

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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

Hi Dirk,

On Montag, 16. Oktober 2017 11:05:49 CEST you wrote:
> > On Oct 16, 2017, at 2:06 AM, Berthold Stoeger 
> > wrote:
> > Answering to myself here: The issue seems to be the
> > 
> >  connect(, SIGNAL(finished()), ...);
> > 
> > call in on_downloadCancelRetryButton_clicked(), which apparently is
> > accumulative. Moving this call to the constructor solves the "problem".
> > That being said, I don't understand anything of that Qt SIGNAL/SLOT
> > business. Moreover, there is a second connect call, which perhaps should
> > also be called only once.
> 
> That makes sense.
> 
> Would you be able to create a commit with "Signed-off-by" line?
> Or even a GitHub pull request?

I tried, but I have no idea what I'm doing:
https://github.com/Subsurface-divelog/subsurface/pull/670

Berthold


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

Re: Import data from Scubapro Aladin Sport Matrix

[Dirk Hohndel]

> On Oct 16, 2017, at 2:06 AM, Berthold Stoeger  
> wrote:
> 
> Dear all,
> 
> On Sonntag, 15. Oktober 2017 22:08:52 CEST Berthold Stoeger wrote:
> 
>> By the way, there seems to be a strange bug(?): for the first failed
>> download I get an information window. For each subsequent retry there is an
>> additional window. E.g. for the 5th failed download it opens 5 information
>> windows at once.

I had noticed this myself a while ago but then never followed up...
there always seems more important stuff to do :-(

> Answering to myself here: The issue seems to be the
>  connect(, SIGNAL(finished()), ...);
> call in on_downloadCancelRetryButton_clicked(), which apparently is
> accumulative. Moving this call to the constructor solves the "problem".
> That being said, I don't understand anything of that Qt SIGNAL/SLOT
> business. Moreover, there is a second connect call, which perhaps should
> also be called only once.

That makes sense.

Would you be able to create a commit with "Signed-off-by" line?
Or even a GitHub pull request?

Thanks

/D

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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

Dear all,

On Sonntag, 15. Oktober 2017 22:08:52 CEST Berthold Stoeger wrote:

> By the way, there seems to be a strange bug(?): for the first failed
> download I get an information window. For each subsequent retry there is an
> additional window. E.g. for the 5th failed download it opens 5 information
> windows at once.

Answering to myself here: The issue seems to be the
  connect(, SIGNAL(finished()), ...);
call in on_downloadCancelRetryButton_clicked(), which apparently is
accumulative. Moving this call to the constructor solves the "problem".
That being said, I don't understand anything of that Qt SIGNAL/SLOT
business. Moreover, there is a second connect call, which perhaps should
also be called only once.

diff --git a/desktop-widgets/downloadfromdivecomputer.cpp b/desktop-widgets/
downloadfromdivecomputer.cpp 
index 424cf277..efd414af 100644 
--- a/desktop-widgets/downloadfromdivecomputer.cpp 
+++ b/desktop-widgets/downloadfromdivecomputer.cpp 
@@ -71,6 +71,9 @@ DownloadFromDCWidget::DownloadFromDCWidget(QWidget *parent, 
Qt::WindowFlags f) : 
   connect(close, SIGNAL(activated()), this, SLOT(close())); 
   connect(quit, SIGNAL(activated()), parent, SLOT(close())); 
 
+   connect(, SIGNAL(finished()), 
+   this, SLOT(onDownloadThreadFinished()), Qt::QueuedConnection); 
+ 
   auto dc = SettingsObjectWrapper::instance()->dive_computer_settings; 
   if (!dc->dc_vendor().isEmpty()) { 
   ui.vendor->setCurrentIndex(ui.vendor->findText(dc-
>dc_vendor())); 
@@ -330,9 +333,6 @@ void 
DownloadFromDCWidget::on_downloadCancelRetryButton_clicked() 
   dc->setDownloadMode(ui.bluetoothMode->isChecked() ? 
DC_TRANSPORT_BLUETOOTH : DC_TRANSPORT_SERIAL); 
#endif 
 
-   connect(, SIGNAL(finished()), 
-   this, SLOT(onDownloadThreadFinished()), Qt::QueuedConnection); 
- 
   //TODO: Don't call mainwindow. 
   MainWindow *w = MainWindow::instance(); 
   connect(, SIGNAL(finished()), w, SLOT(refreshDisplay()));


Berthold

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

Re: Import data from Scubapro Aladin Sport Matrix

[Berthold Stoeger]

Dear Linus,

On Sonntag, 15. Oktober 2017 18:31:34 CEST Linus Torvalds wrote:

> So I think you have two issues that make it but work for you.
> 
> The first and more fundamental is that we haven't done the BLE support for
> the Aladin Sport at all yet, unless somebody did it without me even
> noticing.
> 
> Because sadly, Bluetooth LE is a complete disaster from a standards
> standpoint. There is no standard way of doing a simple serial thing, every
> dive computer manufacturer had to make up their own thing. The Bluetooth
> SIG is incompetent, I feel.
> 
> So we need to have somebody with access to that dive computer figure out
> how it ends up implementing the protocol over BLE. It might be a trivial
> packetized serial version of existing protocols, and it might have extra
> encapsulation.
> 
> But even if had the code, Qt-5.7.1 is not recent enough to work with BLE
> devices on Linux. As you can see from the EBUSY error, the qt ble stack
> just ends up fighting over the device with bluez, and can't access it.

Understood. I installed the beta of Kubuntu 17.10 and it seems to come with a 
reasonably recent Qt (5.9.1). Now it does not fail immediately. Still, as you 
correctly predicted, there seem to be communication problems. The -vv output 
is at the end of this mail, in case it is of use (pure gibberish to me). The 
"needs authentication - permissions" line makes me nervous - did it lose the 
PIN I entered in bluetoothctl?

By the way, there seems to be a strange bug(?): for the first failed download I 
get an information window. For each subsequent retry there is an additional 
window. E.g. for the 5th failed download it opens 5 information windows at 
once.

Berthold

**

qrc:/MapWidget.qml:21: Error: Cannot assign [undefined] to 
QDeclarativeGeoMapType*

File locations:

Unable to get local git directory
Cloud URL: 
Image hashes: /home/bs/.subsurface/hashes
Local picture directory: /home/bs/.subsurface/picturedata/

build with Qt Version 5.9.1, runtime from Qt Version 5.9.1
qt.bluetooth.bluez: Bluez 5 detected.
qt.bluetooth.bluez: Missing CAP_NET_ADMIN permission. Cannot determine whether 
a found address is of random or public type.
qt.bluetooth.bluez: Creating QtBluezDiscoveryManager
qt.bluetooth.bluez: Discovered:  "00:13:43:40:6E:9C" "Aladin Sport" Num UUIDs 
6 total device 0 cached RSSI -62 Class 0
qt.bluetooth.bluez: Discovered:  "00:1D:DF:70:85:F4" "OnBeat aWake" Num UUIDs 
4 total device 1 cached RSSI -76 Class 2360320
qt.bluetooth.bluez: void QBluetoothDeviceDiscoveryAgentPrivate::stop()

kf5.kio.core: Invalid URL: QUrl("subsurface.log")
kf5.kio.core: KSambaShare: Could not find smb.conf!
INFO: FTDI disabled
qt.bluetooth.bluez: Enabling GATT request timeout behavior 2
qt.bluetooth.bluez: Cannot connect due to pending active LE connections
qt.bluetooth.bluez: HCI event triggered, type: f
qt.bluetooth.bluez: RemoteDeviceManager finished attempting to close external 
connections
qt.bluetooth.bluez: addresstypeToUse: "Public"
qt.bluetooth.bluez: No settings found for peer device.
qt.bluetooth.bluez: HCI event triggered, type: 5
qt.bluetooth.bluez: HCI event triggered, type: e
qt.bluetooth.bluez: HCI event triggered, type: e
qt.bluetooth.bluez: HCI event triggered, type: e
qt.bluetooth.bluez: HCI event triggered, type: f
qt.bluetooth.bluez: HCI event triggered, type: f
qt.bluetooth.bluez: Current l2cp sec level: 1
qt.bluetooth.bluez: Exchanging MTU
qt.bluetooth.bluez: Sending read_by_group_type request, startHandle: 1 
endHandle:  2800
qt.bluetooth.bluez: Received size: 3 data: "031700"
qt.bluetooth.bluez: Server MTU: 23 resulting mtu: 23
qt.bluetooth.bluez: Received size: 20 data: 
"1106010009180c000f00011810002a18"
qt.bluetooth.bluez: Found uuid: "{1800--1000-8000-00805f9b34fb}" start 
handle: 1 end handle: 9
qt.bluetooth.bluez: Found uuid: "{1801--1000-8000-00805f9b34fb}" start 
handle: c end handle: f
qt.bluetooth.bluez: Found uuid: "{180a--1000-8000-00805f9b34fb}" start 
handle: 10 end handle: 20
qt.bluetooth.bluez: Sending read_by_group_type request, startHandle: 21 
endHandle:  2800
qt.bluetooth.bluez: Received size: 14 data: "1106210024000f18250034001a18"
qt.bluetooth.bluez: Found uuid: "{180f--1000-8000-00805f9b34fb}" start 
handle: 21 end handle: 24
qt.bluetooth.bluez: Found uuid: "{181a--1000-8000-00805f9b34fb}" start 
handle: 25 end handle: 34
qt.bluetooth.bluez: Sending read_by_group_type request, startHandle: 35 
endHandle:  2800
qt.bluetooth.bluez: Received size: 22 data: 
"111435003a00a0a07a7b210415bf0e475d29aaeacdfd"
qt.bluetooth.bluez: Found uuid: "{fdcdeaaa-295d-470e-bf15-04217b7aa0a0}" start 
handle: 35 end handle: 3a
qt.bluetooth.bluez: Sending read_by_type request, startHandle: 35 endHandle: 
3a type: 2802 packet: "0835003a000228"
qt.bluetooth.bluez: Sending read_by_group_type request, startHandle: 3b 
endHandle:  2800
qt.bluetooth.bluez: Received size: 5 data: "010835000a"

Re: Import data from Scubapro Aladin Sport Matrix

[Linus Torvalds]

On Oct 15, 2017 05:28, "Berthold Stoeger" 
wrote:



I'm trying to import dive logs from a Scubapro Aladin Sport Matrix
according to the manual. This is on Kubuntu 17.04 and subsurface compiled
from source.


So I think you have two issues that make it but work for you.

The first and more fundamental is that we haven't done the BLE support for
the Aladin Sport at all yet, unless somebody did it without me even
noticing.

Because sadly, Bluetooth LE is a complete disaster from a standards
standpoint. There is no standard way of doing a simple serial thing, every
dive computer manufacturer had to make up their own thing. The Bluetooth
SIG is incompetent, I feel.

So we need to have somebody with access to that dive computer figure out
how it ends up implementing the protocol over BLE. It might be a trivial
packetized serial version of existing protocols, and it might have extra
encapsulation.

But even if had the code, Qt-5.7.1 is not recent enough to work with BLE
devices on Linux. As you can see from the EBUSY error, the qt ble stack
just ends up fighting over the device with bluez, and can't access it.

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