Re: Import dives from Cressi Cartesio

[Martin de Weger]

That sort of sucks. :(

I’m happy with the fact I can download the dives using USB on my Mac now, so 
that is a win… ;) Thanks for the help so far! I have been looking into finding 
the BLE packet, but am not able to find a way to do so.



Kind regards,

Martin De Weger

> Op 18 feb. 2020, om 22:57 heeft Linus Torvalds 
>  het volgende geschreven:
> 
> On Tue, Feb 18, 2020 at 1:43 PM Linus Torvalds
>  wrote:
>> 
>> There's two possibilities:
>> 
>> (a) the Cressi protocol isn't the same on BLE as it is on a regular serial 
>> line
>> 
>> (b) the Nordic UART service needs more setup for the other end (tell
>> it baud-rate etc)
> 
> Ugh. A quick look at some Nordic docs seems to imply that _both_ of
> these will be true.
> 
> Not only does Nordic have a APP_UART_FIFO_INIT() thing in their UART
> SDK, there's also magic for reading buttons and setting LED lights
> etc. So it looks like there is a lot more than just "transfer data".
> 
> It also looks like the buffering done by the UART->BLE end is line-based:
> 
>  "Received characters are buffered into a string until a new line
> character is received or the size of the string exceeds the limit
> defined by NUS_MAX_DATA_LENGTH"
> 
> which means that I wouldn't be surprised if Cressi might have added
> newlines to the protocol just to get that UART->BLE side to flush in a
> timely manner.
> 
> So ouch. This looks more complex than most BLE things have been.
> 
>Linus

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Tue, Feb 18, 2020 at 1:43 PM Linus Torvalds
 wrote:
>
> There's two possibilities:
>
>  (a) the Cressi protocol isn't the same on BLE as it is on a regular serial 
> line
>
>  (b) the Nordic UART service needs more setup for the other end (tell
> it baud-rate etc)

Ugh. A quick look at some Nordic docs seems to imply that _both_ of
these will be true.

Not only does Nordic have a APP_UART_FIFO_INIT() thing in their UART
SDK, there's also magic for reading buttons and setting LED lights
etc. So it looks like there is a lot more than just "transfer data".

It also looks like the buffering done by the UART->BLE end is line-based:

  "Received characters are buffered into a string until a new line
character is received or the size of the string exceeds the limit
defined by NUS_MAX_DATA_LENGTH"

which means that I wouldn't be surprised if Cressi might have added
newlines to the protocol just to get that UART->BLE side to flush in a
timely manner.

So ouch. This looks more complex than most BLE things have been.

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Tue, Feb 18, 2020 at 1:36 PM Martin de Weger  wrote:
>
> With the -v parameter, the logfile is as attached.

Yup, with that I see the version in the logs too. We'll try to
remember to ask people to do "-v" next time.

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Tue, Feb 18, 2020 at 1:33 PM Martin de Weger  wrote:
>
> I gave it a number of tries (and checked the save logfile option).

Ok, I see the several tries, and I also see the lack of replies.

Oh well.

There's two possibilities:

 (a) the Cressi protocol isn't the same on BLE as it is on a regular serial line

This is actually common issue. I think we've been about 50/50 on dive
computers so far on this. BLE is reliable at a link level (as long as
it works at all ;) and there is packetization information too, so dive
computers don't need to do the quoting and error correcting etc.

 (b) the Nordic UART service needs more setup for the other end (tell
it baud-rate etc)

This is generally unlikely (there really isn't any reason for it when
the defaults should just be set up for the dive computer), but we've
seen that case before when the bluetooth thing was entirely external
to the dive computer like it is here.

I'll go look at the Nordic docs to see what it says.

But if it's (a), then I'd need a BLE packet log from a good download
from the Cressi app. Which I don't even know how to do on iOS at all
(and which is admittedly not fun on Android either). Because I can't
even begin to guess what the BLE protocol differences are if they
exist.

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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

With the -v parameter, the logfile is as attached.

log
Description: Binary data

Kind regards,Martin De Weger


Op 18 feb. 2020, om 22:32 heeft Martin de Weger  het volgende geschreven:I haven’t deleted anything from the log, I ran the command "Subsurface.app/Contents/MacOS/Subsurface > log 2>&1" per previous instruction. The -v parameter was not given. Can I enter “Subsurface.app/Contents/MacOS/Subsurface -v > log 2>&1”?
Kind regards,Martin De Weger


Op 18 feb. 2020, om 22:29 heeft Dirk Hohndel  het volgende geschreven:On Feb 18, 2020, at 12:39 PM, Dirk Hohndel  wrote:On Feb 18, 2020, at 12:36 PM, Linus Torvalds  wrote:And we definitely should add our version string to the log outputs sothat we can see that it matches the right version. Dirk?I can add this...Just FYI - Martin must have manually removed this from the log. When starting Subsurface with '-v' we already print the full version number with SHA. Like this:$ ./Subsurface.app/Contents/MacOS/Subsurface  -vSubsurface v4.9.3-981-g2589bfd50869,built with libdivecomputer v0.7.0-devel-Subsurface-NG (f2f775b9aaec76abf9a534b9385dfd2d5fe5058d)built with Qt Version 5.14.0, runtime from Qt Version 5.14.0built with libgit2 0.26.0/D___subsurface mailing listsubsurface@subsurface-divelog.orghttp://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: Import dives from Cressi Cartesio

[Martin de Weger]

I gave it a number of tries (and checked the save logfile option).The Cartesio was in PC mode, so should be able to download.

subsurface.log
Description: Binary data


log
Description: Binary data
Hope this will help. 
Kind regards,Martin De Weger


Op 18 feb. 2020, om 22:24 heeft Linus Torvalds  het volgende geschreven:On Tue, Feb 18, 2020 at 1:17 PM Martin de Weger  wrote:The result looks the same in de UI... but the log looks different.Now you have  Using service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}" as preferred servicewhich is the correct Nordic UART service.So my patch did what it was supposed to do.Except it still doesn't answer or seem to work.Damn.It looked so very promising.Humor me: try downloading a few times, making sure that the Cartesiois in download mode etc.In the meantime I'll try to see if I see anything else in the logs,and I guess I'll go and try to find the Nordic docs too, and see ifthat UART service needs some kind of setup code too.  Linus___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Import dives from Cressi Cartesio

[Martin de Weger]

I haven’t deleted anything from the log, I ran the command 
"Subsurface.app/Contents/MacOS/Subsurface > log 2>&1" per previous instruction. 
The -v parameter was not given. Can I enter 
“Subsurface.app/Contents/MacOS/Subsurface -v > log 2>&1”?



Kind regards,

Martin De Weger

> Op 18 feb. 2020, om 22:29 heeft Dirk Hohndel  het volgende 
> geschreven:
> 
> 
> 
>> On Feb 18, 2020, at 12:39 PM, Dirk Hohndel > > wrote:
>> 
>>> On Feb 18, 2020, at 12:36 PM, Linus Torvalds >> > wrote:
>>> And we definitely should add our version string to the log outputs so
>>> that we can see that it matches the right version. Dirk?
>> 
>> I can add this...
> 
> Just FYI - Martin must have manually removed this from the log. When starting 
> Subsurface 
> with '-v' we already print the full version number with SHA. Like this:
> 
> $ ./Subsurface.app/Contents/MacOS/Subsurface  -v
> Subsurface v4.9.3-981-g2589bfd50869,
> built with libdivecomputer v0.7.0-devel-Subsurface-NG 
> (f2f775b9aaec76abf9a534b9385dfd2d5fe5058d)
> built with Qt Version 5.14.0, runtime from Qt Version 5.14.0
> built with libgit2 0.26.0
> 
> 
> /D

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

Re: Import dives from Cressi Cartesio

[Dirk Hohndel]

> On Feb 18, 2020, at 12:39 PM, Dirk Hohndel  wrote:
> 
>> On Feb 18, 2020, at 12:36 PM, Linus Torvalds  
>> wrote:
>> And we definitely should add our version string to the log outputs so
>> that we can see that it matches the right version. Dirk?
> 
> I can add this...

Just FYI - Martin must have manually removed this from the log. When starting 
Subsurface 
with '-v' we already print the full version number with SHA. Like this:

$ ./Subsurface.app/Contents/MacOS/Subsurface  -v
Subsurface v4.9.3-981-g2589bfd50869,
built with libdivecomputer v0.7.0-devel-Subsurface-NG 
(f2f775b9aaec76abf9a534b9385dfd2d5fe5058d)
built with Qt Version 5.14.0, runtime from Qt Version 5.14.0
built with libgit2 0.26.0


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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Tue, Feb 18, 2020 at 1:17 PM Martin de Weger  wrote:
>
> The result looks the same in de UI.

.. but the log looks different.

Now you have

  Using service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}" as preferred service

which is the correct Nordic UART service.

So my patch did what it was supposed to do.

Except it still doesn't answer or seem to work.

Damn.

It looked so very promising.

Humor me: try downloading a few times, making sure that the Cartesio
is in download mode etc.

In the meantime I'll try to see if I see anything else in the logs,
and I guess I'll go and try to find the Nordic docs too, and see if
that UART service needs some kind of setup code too.

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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

I’m afraid it still doesn’t work. 



Kind regards,

Martin De Weger

> Op 18 feb. 2020, om 22:17 heeft Linus Torvalds 
>  het volgende geschreven:
> 
> Good, that's the right one. 
> 
> Let me know if that works now. And if it does, I'll just merge it into 
> mainline and we'll have a real build soon.
> 
> And if not, I'll take a new log-file and go back to the drawing board..
> 
> Linus
> 
> On Tue, Feb 18, 2020 at 1:15 PM Martin de Weger  > wrote:
> I might have solved this. Let me test again.
> 
> I’m testing with:
> 
> 
> ___
> 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: Import dives from Cressi Cartesio

[Linus Torvalds]

Good, that's the right one.

Let me know if that works now. And if it does, I'll just merge it into
mainline and we'll have a real build soon.

And if not, I'll take a new log-file and go back to the drawing board..

Linus

On Tue, Feb 18, 2020 at 1:15 PM Martin de Weger  wrote:

> I might have solved this. Let me test again.
>
> I’m testing with:
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Import dives from Cressi Cartesio

[Dirk Hohndel]

Running the Artifacts that GitHub creates on a Mac is really painful.
That's why for master I create DMGs on my system. If you can't get this to 
work, I can create a one-off binary for you

/D

> On Feb 18, 2020, at 1:10 PM, Martin de Weger  wrote:
> 
> I have downloaded Subsurface-4.9.3-976-gc6f73ae14456.dmg from 
> https://github.com/Subsurface-divelog/subsurface/releases/tag/ci-release 
> . 
> 
> I did download the app from the GitHub location (I’m not familiair with 
> GitHub, so I need the explanation / Walkthrough you provided) and tested it 
> again.
> 
> The signing issue is acting up:
> 
> The default interactive shell is now zsh.
> To update your account to use zsh, please run `chsh -s /bin/zsh`.
> For more details, please visit https://support.apple.com/kb/HT208050 
> .
> MacBook-Pro:~ martinw$ /Users/martinw/Software/Contents/MacOS/Subsurface ; 
> exit;dyld: Library not loaded: @loader_path/../Frameworks/libgit2.28.dylib
>   Referenced from: /Users/martinw/Software/Contents/MacOS/Subsurface
>   Reason: no suitable image found.  Did find:
>   /Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: 
> code signature in 
> (/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib) not 
> valid for use in process using Library Validation: library load disallowed by 
> system policy
>   /Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: 
> code signature in 
> (/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib) not 
> valid for use in process using Library Validation: library load disallowed by 
> system policy
>   /Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: 
> stat() failed with errno=1
> Abort trap: 6
> logout
> Saving session...
> ...copying shared history...
> ...saving history...truncating history files...
> ...completed.
> Deleting expired sessions...4 completed.
> 
> [Proces voltooid]
> 
> ibhidapi.0.dylib and QtWebKitWidgets.framework cannot be openend.
> 
> 
> 
> 
> Kind regards,
> 
> Martin De Weger
> 
>> Op 18 feb. 2020, om 21:36 heeft Linus Torvalds 
>> mailto:torva...@linux-foundation.org>> het 
>> volgende geschreven:
>> 
>> On Tue, Feb 18, 2020 at 12:20 PM Martin de Weger > > wrote:
>>> 
>>> I’ve downloaded the new version and retried to download the dives. The 
>>> logfile is attached.
>> 
>> Damn. No change. It still tries the other service.
>> 
>> I wonder what went wrong.  I see that
>> 
>>  Found service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}" "Unknown Service"
>> 
>> that we _should_ have preferred, but then I see
>> 
>>  Using service "{6e41-b5a3-f393-e0a9-e50e24dc10b8}" as preferred service
>> 
>> (notice the small difference at the end - they look the same if you
>> check quickly, but they aren't.
>> 
>> My patch is _so_ simple that I would have expected it to trivially
>> pick the right one.
>> 
>> I wonder if you re-downloaded the old App. How did you download it?
>> Because it was only done as a pull request, the normal CI pages won't
>> get it.
>> 
>> We don't seem to put the git SHA1 commit ID in our normal logs, so I
>> can't verify. But the _right_ App image should be reachable from:
>> 
>>https://github.com/Subsurface-divelog/subsurface/pull/2628 
>> 
>> 
>> and then you have to Click "Details" on the Mac build:
>> 
>>
>> https://github.com/Subsurface-divelog/subsurface/pull/2628/checks?check_run_id=451424356
>>  
>> 
>> 
>> and then you have to download it by clicking that "Artifacts" thing in
>> the upper right hand corner of the build frame, which should get you a
>> download thing that looks something like
>> 
>>   Download artifacts
>>Subsurface.app279 MB
>> 
>> and now that "Subsurface.app" is the one you want.
>> 
>> If you got it from any other page, it won't contain my little fixlet
>> for the Cressi Cartesio.
>> 
>> And we definitely should add our version string to the log outputs so
>> that we can see that it matches the right version. Dirk?
>> 
>> In the meantime, you can check that manually by clicking "Help" and
>> then "About Subsurface", and you should see the version string.
>> 
>> For that test-build, the version string *should* be
>> 
>>Subsurface  4.9.3-959-gaa80ecc77ee9
>> 
>> and if it isn't, you're not testing with my Cressi hack in place.
>> 
>> Linus
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org 
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> 

___
subsurface mailing list
subsurface@subsurface-divelog.org

Re: Import dives from Cressi Cartesio

[Martin de Weger]

The result looks the same in de UI.

log
Description: Binary data

Kind regards,Martin De Weger


Op 18 feb. 2020, om 22:10 heeft Martin de Weger  het volgende geschreven:I have downloaded Subsurface-4.9.3-976-gc6f73ae14456.dmg from https://github.com/Subsurface-divelog/subsurface/releases/tag/ci-release. I did download the app from the GitHub location (I’m not familiair with GitHub, so I need the explanation / Walkthrough you provided) and tested it again.The signing issue is acting up:The default interactive shell is now zsh.To update your account to use zsh, please run `chsh -s /bin/zsh`.For more details, please visit https://support.apple.com/kb/HT208050.MacBook-Pro:~ martinw$ /Users/martinw/Software/Contents/MacOS/Subsurface ; exit;dyld: Library not loaded: @loader_path/../Frameworks/libgit2.28.dylib  Referenced from: /Users/martinw/Software/Contents/MacOS/Subsurface  Reason: no suitable image found.  Did find:	/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: code signature in (/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib) not valid for use in process using Library Validation: library load disallowed by system policy	/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: code signature in (/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib) not valid for use in process using Library Validation: library load disallowed by system policy	/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: stat() failed with errno=1Abort trap: 6logoutSaving session..copying shared history..saving history...truncating history files..completed.Deleting expired sessions...4 completed.[Proces voltooid]ibhidapi.0.dylib and QtWebKitWidgets.framework cannot be openend.
Kind regards,Martin De Weger


Op 18 feb. 2020, om 21:36 heeft Linus Torvalds  het volgende geschreven:On Tue, Feb 18, 2020 at 12:20 PM Martin de Weger  wrote:I’ve downloaded the new version and retried to download the dives. The logfile is attached.Damn. No change. It still tries the other service.I wonder what went wrong.  I see that  Found service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}" "Unknown Service"that we _should_ have preferred, but then I see  Using service "{6e41-b5a3-f393-e0a9-e50e24dc10b8}" as preferred service(notice the small difference at the end - they look the same if youcheck quickly, but they aren't.My patch is _so_ simple that I would have expected it to triviallypick the right one.I wonder if you re-downloaded the old App. How did you download it?Because it was only done as a pull request, the normal CI pages won'tget it.We don't seem to put the git SHA1 commit ID in our normal logs, so Ican't verify. But the _right_ App image should be reachable from:    https://github.com/Subsurface-divelog/subsurface/pull/2628and then you have to Click "Details" on the Mac build:    https://github.com/Subsurface-divelog/subsurface/pull/2628/checks?check_run_id=451424356and then you have to download it by clicking that "Artifacts" thing inthe upper right hand corner of the build frame, which should get you adownload thing that looks something like   Download artifacts    Subsurface.app    279 MBand now that "Subsurface.app" is the one you want.If you got it from any other page, it won't contain my little fixletfor the Cressi Cartesio.And we definitely should add our version string to the log outputs sothat we can see that it matches the right version. Dirk?In the meantime, you can check that manually by clicking "Help" andthen "About Subsurface", and you should see the version string.For that test-build, the version string *should* be    Subsurface  4.9.3-959-gaa80ecc77ee9and if it isn't, you're not testing with my Cressi hack in place. Linus___subsurface mailing listsubsurface@subsurface-divelog.orghttp://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface___subsurface mailing listsubsurface@subsurface-divelog.orghttp://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: Import dives from Cressi Cartesio

[Martin de Weger]

I might have solved this. Let me test again.

I’m testing with:





Kind regards,

Martin De Weger

> Op 18 feb. 2020, om 22:10 heeft Martin de Weger  het 
> volgende geschreven:
> 
> I have downloaded Subsurface-4.9.3-976-gc6f73ae14456.dmg from 
> https://github.com/Subsurface-divelog/subsurface/releases/tag/ci-release 
> . 
> 
> I did download the app from the GitHub location (I’m not familiair with 
> GitHub, so I need the explanation / Walkthrough you provided) and tested it 
> again.
> 
> The signing issue is acting up:
> 
> The default interactive shell is now zsh.
> To update your account to use zsh, please run `chsh -s /bin/zsh`.
> For more details, please visit https://support.apple.com/kb/HT208050 
> .
> MacBook-Pro:~ martinw$ /Users/martinw/Software/Contents/MacOS/Subsurface ; 
> exit;dyld: Library not loaded: @loader_path/../Frameworks/libgit2.28.dylib
>   Referenced from: /Users/martinw/Software/Contents/MacOS/Subsurface
>   Reason: no suitable image found.  Did find:
>   /Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: 
> code signature in 
> (/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib) not 
> valid for use in process using Library Validation: library load disallowed by 
> system policy
>   /Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: 
> code signature in 
> (/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib) not 
> valid for use in process using Library Validation: library load disallowed by 
> system policy
>   /Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: 
> stat() failed with errno=1
> Abort trap: 6
> logout
> Saving session...
> ...copying shared history...
> ...saving history...truncating history files...
> ...completed.
> Deleting expired sessions...4 completed.
> 
> [Proces voltooid]
> 
> ibhidapi.0.dylib and QtWebKitWidgets.framework cannot be openend.
> 
> 
> 
> 
> Kind regards,
> 
> Martin De Weger
> 
>> Op 18 feb. 2020, om 21:36 heeft Linus Torvalds 
>> mailto:torva...@linux-foundation.org>> het 
>> volgende geschreven:
>> 
>> On Tue, Feb 18, 2020 at 12:20 PM Martin de Weger > > wrote:
>>> 
>>> I’ve downloaded the new version and retried to download the dives. The 
>>> logfile is attached.
>> 
>> Damn. No change. It still tries the other service.
>> 
>> I wonder what went wrong.  I see that
>> 
>>  Found service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}" "Unknown Service"
>> 
>> that we _should_ have preferred, but then I see
>> 
>>  Using service "{6e41-b5a3-f393-e0a9-e50e24dc10b8}" as preferred service
>> 
>> (notice the small difference at the end - they look the same if you
>> check quickly, but they aren't.
>> 
>> My patch is _so_ simple that I would have expected it to trivially
>> pick the right one.
>> 
>> I wonder if you re-downloaded the old App. How did you download it?
>> Because it was only done as a pull request, the normal CI pages won't
>> get it.
>> 
>> We don't seem to put the git SHA1 commit ID in our normal logs, so I
>> can't verify. But the _right_ App image should be reachable from:
>> 
>>https://github.com/Subsurface-divelog/subsurface/pull/2628 
>> 
>> 
>> and then you have to Click "Details" on the Mac build:
>> 
>>
>> https://github.com/Subsurface-divelog/subsurface/pull/2628/checks?check_run_id=451424356
>>  
>> 
>> 
>> and then you have to download it by clicking that "Artifacts" thing in
>> the upper right hand corner of the build frame, which should get you a
>> download thing that looks something like
>> 
>>   Download artifacts
>>Subsurface.app279 MB
>> 
>> and now that "Subsurface.app" is the one you want.
>> 
>> If you got it from any other page, it won't contain my little fixlet
>> for the Cressi Cartesio.
>> 
>> And we definitely should add our version string to the log outputs so
>> that we can see that it matches the right version. Dirk?
>> 
>> In the meantime, you can check that manually by clicking "Help" and
>> then "About Subsurface", and you should see the version string.
>> 
>> For that test-build, the version string *should* be
>> 
>>Subsurface  4.9.3-959-gaa80ecc77ee9
>> 
>> and if it isn't, you're not testing with my Cressi hack in place.
>> 
>> Linus
>> ___
>> 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: Import dives from Cressi Cartesio

[Martin de Weger]

I have downloaded Subsurface-4.9.3-976-gc6f73ae14456.dmg from 
https://github.com/Subsurface-divelog/subsurface/releases/tag/ci-release 
. 

I did download the app from the GitHub location (I’m not familiair with GitHub, 
so I need the explanation / Walkthrough you provided) and tested it again.

The signing issue is acting up:

The default interactive shell is now zsh.
To update your account to use zsh, please run `chsh -s /bin/zsh`.
For more details, please visit https://support.apple.com/kb/HT208050.
MacBook-Pro:~ martinw$ /Users/martinw/Software/Contents/MacOS/Subsurface ; 
exit;dyld: Library not loaded: @loader_path/../Frameworks/libgit2.28.dylib
  Referenced from: /Users/martinw/Software/Contents/MacOS/Subsurface
  Reason: no suitable image found.  Did find:
/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: 
code signature in 
(/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib) not 
valid for use in process using Library Validation: library load disallowed by 
system policy
/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: 
code signature in 
(/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib) not 
valid for use in process using Library Validation: library load disallowed by 
system policy
/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: 
stat() failed with errno=1
Abort trap: 6
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.
Deleting expired sessions...4 completed.

[Proces voltooid]

ibhidapi.0.dylib and QtWebKitWidgets.framework cannot be openend.




Kind regards,

Martin De Weger

> Op 18 feb. 2020, om 21:36 heeft Linus Torvalds 
>  het volgende geschreven:
> 
> On Tue, Feb 18, 2020 at 12:20 PM Martin de Weger  wrote:
>> 
>> I’ve downloaded the new version and retried to download the dives. The 
>> logfile is attached.
> 
> Damn. No change. It still tries the other service.
> 
> I wonder what went wrong.  I see that
> 
>  Found service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}" "Unknown Service"
> 
> that we _should_ have preferred, but then I see
> 
>  Using service "{6e41-b5a3-f393-e0a9-e50e24dc10b8}" as preferred service
> 
> (notice the small difference at the end - they look the same if you
> check quickly, but they aren't.
> 
> My patch is _so_ simple that I would have expected it to trivially
> pick the right one.
> 
> I wonder if you re-downloaded the old App. How did you download it?
> Because it was only done as a pull request, the normal CI pages won't
> get it.
> 
> We don't seem to put the git SHA1 commit ID in our normal logs, so I
> can't verify. But the _right_ App image should be reachable from:
> 
>https://github.com/Subsurface-divelog/subsurface/pull/2628
> 
> and then you have to Click "Details" on the Mac build:
> 
>
> https://github.com/Subsurface-divelog/subsurface/pull/2628/checks?check_run_id=451424356
> 
> and then you have to download it by clicking that "Artifacts" thing in
> the upper right hand corner of the build frame, which should get you a
> download thing that looks something like
> 
>   Download artifacts
>Subsurface.app279 MB
> 
> and now that "Subsurface.app" is the one you want.
> 
> If you got it from any other page, it won't contain my little fixlet
> for the Cressi Cartesio.
> 
> And we definitely should add our version string to the log outputs so
> that we can see that it matches the right version. Dirk?
> 
> In the meantime, you can check that manually by clicking "Help" and
> then "About Subsurface", and you should see the version string.
> 
> For that test-build, the version string *should* be
> 
>Subsurface  4.9.3-959-gaa80ecc77ee9
> 
> and if it isn't, you're not testing with my Cressi hack in place.
> 
> Linus
> ___
> 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: Import dives from Cressi Cartesio

[Linus Torvalds]

On Tue, Feb 18, 2020 at 12:36 PM Linus Torvalds
 wrote:
>
> For that test-build, the version string *should* be
>
> Subsurface  4.9.3-959-gaa80ecc77ee9
>
> and if it isn't, you're not testing with my Cressi hack in place.

Actually, I take that back. The build server did a merge commit, so it
turns out what it built had a different git SHA.

Judging by the build logs, it did this:

HEAD is now at 760854685 Merge
aa80ecc77ee91447a2a6bdb355e5de0b2c776ac2 into
d6c47ad362f4f92cd6c89e5432163ac4124e0ba5

so the version string will look something like

  Subsurface  4.9.3-xyz-g760854685xxx

instead. Sorry for the confusion.

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

Re: Import dives from Cressi Cartesio

[Dirk Hohndel]

> On Feb 18, 2020, at 12:36 PM, Linus Torvalds  
> wrote:
> And we definitely should add our version string to the log outputs so
> that we can see that it matches the right version. Dirk?

I can add this...

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Tue, Feb 18, 2020 at 12:20 PM Martin de Weger  wrote:
>
> I’ve downloaded the new version and retried to download the dives. The 
> logfile is attached.

Damn. No change. It still tries the other service.

I wonder what went wrong.  I see that

  Found service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}" "Unknown Service"

that we _should_ have preferred, but then I see

  Using service "{6e41-b5a3-f393-e0a9-e50e24dc10b8}" as preferred service

(notice the small difference at the end - they look the same if you
check quickly, but they aren't.

My patch is _so_ simple that I would have expected it to trivially
pick the right one.

I wonder if you re-downloaded the old App. How did you download it?
Because it was only done as a pull request, the normal CI pages won't
get it.

We don't seem to put the git SHA1 commit ID in our normal logs, so I
can't verify. But the _right_ App image should be reachable from:

https://github.com/Subsurface-divelog/subsurface/pull/2628

and then you have to Click "Details" on the Mac build:


https://github.com/Subsurface-divelog/subsurface/pull/2628/checks?check_run_id=451424356

and then you have to download it by clicking that "Artifacts" thing in
the upper right hand corner of the build frame, which should get you a
download thing that looks something like

   Download artifacts
Subsurface.app279 MB

and now that "Subsurface.app" is the one you want.

If you got it from any other page, it won't contain my little fixlet
for the Cressi Cartesio.

And we definitely should add our version string to the log outputs so
that we can see that it matches the right version. Dirk?

In the meantime, you can check that manually by clicking "Help" and
then "About Subsurface", and you should see the version string.

For that test-build, the version string *should* be

Subsurface  4.9.3-959-gaa80ecc77ee9

and if it isn't, you're not testing with my Cressi hack in place.

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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

log
Description: Binary data
Hi Linus,I’ve downloaded the new version and retried to download the dives. The logfile is attached.
Kind regards,Martin De Weger


Op 17 feb. 2020, om 22:18 heeft Martin de Weger  het volgende geschreven:I’ll save your head from more injuries tonight. In my part of the woods it’s way past bed time... 浪I’ll try tomorrow after work. Thanks again,MartinOp 17 feb. 2020 om 22:11 heeft Linus Torvalds  het volgende geschreven:On Mon, Feb 17, 2020 at 1:09 PM Linus Torvalds wrote:and once the OS X build has finished, you should be able to pick upthe (unsigned) App from there (look for the "Mac / desktopBuild"thing, once it is complete and successful, you should find a downloadlink when you press it).And btw, whether it works or not, I'd love to see a new log from you.If it works, I'd like to see all the comm details.And if it doesn't work, I'll need the new log to figure out why itdidn't work after all, so that I can continue to hit my head againstthe wall.   Linus___subsurface mailing listsubsurface@subsurface-divelog.orghttp://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: Import dives from Cressi Cartesio

[Martin de Weger]

I’ll save your head from more injuries tonight. In my part of the woods it’s 
way past bed time... 浪

I’ll try tomorrow after work. 

Thanks again,

Martin


> Op 17 feb. 2020 om 22:11 heeft Linus Torvalds  
> het volgende geschreven:
> 
> On Mon, Feb 17, 2020 at 1:09 PM Linus Torvalds
>  wrote:
>> 
>> and once the OS X build has finished, you should be able to pick up
>> the (unsigned) App from there (look for the "Mac / desktopBuild"
>> thing, once it is complete and successful, you should find a download
>> link when you press it).
> 
> And btw, whether it works or not, I'd love to see a new log from you.
> 
> If it works, I'd like to see all the comm details.
> 
> And if it doesn't work, I'll need the new log to figure out why it
> didn't work after all, so that I can continue to hit my head against
> the wall.
> 
>Linus

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Mon, Feb 17, 2020 at 1:09 PM Linus Torvalds
 wrote:
>
> and once the OS X build has finished, you should be able to pick up
> the (unsigned) App from there (look for the "Mac / desktopBuild"
> thing, once it is complete and successful, you should find a download
> link when you press it).

And btw, whether it works or not, I'd love to see a new log from you.

If it works, I'd like to see all the comm details.

And if it doesn't work, I'll need the new log to figure out why it
didn't work after all, so that I can continue to hit my head against
the wall.

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Mon, Feb 17, 2020 at 12:58 PM Martin de Weger  wrote:
>
> I’m glad you can make sense out of this. ;)

Trust me, you don't want to understand BLE GATT protocol and the odd
service names etc. I've spent more time than is healthy on figuring it
out. I'd rather not know, but nobody else wanted to deal with this
stuff.

Anyway, I have a not-too-horrendous hack that should hopefully make things work.

It's pull request

https://github.com/Subsurface-divelog/subsurface/pull/2628

and once the OS X build has finished, you should be able to pick up
the (unsigned) App from there (look for the "Mac / desktopBuild"
thing, once it is complete and successful, you should find a download
link when you press it).

And if that works for you, then I guess I'll just merge it directly,
since it seems Dirk is ok with me messing around on his github
account.

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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

I’m glad you can make sense out of this. ;)



Kind regards,

Martin De Weger




> Op 17 feb. 2020, om 21:47 heeft Linus Torvalds 
>  het volgende geschreven:
> 
> On Mon, Feb 17, 2020 at 12:08 PM Martin de Weger  wrote:
>> 
>> It looks like it is not recognized as dive computer.
> 
> No, that part is ok. But the logs look a bit garbled, but that is just
> an artifact of the asynchronous device discovery.
> 
> So there's a few random
> 
>  Found new device: "" "LE:{8fac5ff0-c2cb-4478-a931-92e8d02dc56a}"
>  Not recognized as dive computer
> 
> sprinkled around, but they are just other devices.
> 
> For the Cartesio, we're doing this:
> 
>  qt_ble_open( {b3c70fef-954e-457d-bc92-ba8c819c3bf9} )
>  trying to connect
> ...
>  F ound new device: "Cartesio" "LE:{b3c70fef-954e-457d-bc92-ba8c819c3bf9}"
>  "this could be a Cressi Cartesio"
>  connected to the controller for device {b3c70fef-954e-457d-bc92-ba8c819c3bf9}
>.. discovering services
>  Found service "{180a--1000-8000-00805f9b34fb}"
>   .. ignoring standard service "{180a--1000-8000-00805f9b34fb}"
>  Found service "{180f--1000-8000-00805f9b34fb}"
>   .. ignoring standard service "{180f--1000-8000-00805f9b34fb}"
>  Found service "{fe59--1000-8000-00805f9b34fb}"
>   .. ignoring standard service "{fe59--1000-8000-00805f9b34fb}"
>  Found service "{6e41-b5a3-f393-e0a9-e50e24dc10b8}"
>   .. created service object QLowEnergyService(0x7fc2557cd310)
>  Found service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}"
>   .. created service object QLowEnergyService(0x7fc25665e640)
>   .. done discovering services
>  Found service "{6e41-b5a3-f393-e0a9-e50e24dc10b8}" "Unknown Service"
> c: "{6e41-b5a3-f393-e0a9-e50e24dc10b8}"
> c: "{6e42-b5a3-f393-e0a9-e50e24dc10b8}"
>  d: "{2902--1000-8000-00805f9b34fb}"
> c: "{6e43-b5a3-f393-e0a9-e50e24dc10b8}
> c: "{6e44-b5a3-f393-e0a9-e50e24dc10b8}"
> c: "{6e45-b5a3f393-e0a9-e50e24dc10b8}"
>  Found service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}" "Unknown Service"
> c: "{6e42-b5a3-f393-e0a9-e50e24dcca9e}"
> c: "{6e43-b5a3-f393-e0a9-e50e24dcca9e}"
>  d: "{2902--1000-8000-00805f9b34fb}"
>  Using service "{6e41-b5a3-f393-e0a9-e50e24dc10b8}" as preferred service
>   .. enabling notifications
>  Using read characteristic "{6e42-b5a3-f393-e0a9-e50e24dc10b8}"
>  now writing "0x0100" to the descriptor
> "{2902--1000-8000-00805f9b34fb}"
>  BLE write completed
>  ..
>  QTime("21:07:03.358") packet SEND "aa55"
>  QTime("21:07:03.358") packet WAIT
> 
> which all looks reasonable. That final "packet SEND" is us actually
> starting the communication, but then we don't get anything back.
> 
> But that is because we decide to use the wrong service. As mentioned
> earlier, BLE serial transmission isn't standardized, and the Cressi
> BLE dongle has a fairly complex set of services and characteristics.
> It has a number of standard services (for battery level etc), but it
> has _two_ nonstandard unknown services, and we pick the first one.
> 
> But it's the second one - the 6e41-b5a3-f393-e0a9-e50e24dcca9e
> service - that is the "Nordic UART service".
> 
> But while that is somethign that the Nordic Semi nRF app knows about
> (it's from your screenshots earlier), this is very much not something
> that subsurface knew about, so subsurface picked the first one of the
> two services.
> 
> So subsurface was trying to communicate with the wrong BLE service,
> and isn't getting any replies.
> 
> I just need to figure out a heuristic that goes "use this service for
> the Crssi case" without breaking the _other_ heuristics we have for
> other cases..
> 
> This is the kind of annoying thing that happens with random new BLE
> devices. We used to have it every time we saw a new BLE device, we've
> just been lucky that our heuristics got good enough that we haven't
> seen this in a while.
> 
>Linus

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Mon, Feb 17, 2020 at 12:08 PM Martin de Weger  wrote:
>
> It looks like it is not recognized as dive computer.

No, that part is ok. But the logs look a bit garbled, but that is just
an artifact of the asynchronous device discovery.

So there's a few random

  Found new device: "" "LE:{8fac5ff0-c2cb-4478-a931-92e8d02dc56a}"
  Not recognized as dive computer

sprinkled around, but they are just other devices.

For the Cartesio, we're doing this:

  qt_ble_open( {b3c70fef-954e-457d-bc92-ba8c819c3bf9} )
  trying to connect
 ...
  F ound new device: "Cartesio" "LE:{b3c70fef-954e-457d-bc92-ba8c819c3bf9}"
  "this could be a Cressi Cartesio"
  connected to the controller for device {b3c70fef-954e-457d-bc92-ba8c819c3bf9}
.. discovering services
  Found service "{180a--1000-8000-00805f9b34fb}"
   .. ignoring standard service "{180a--1000-8000-00805f9b34fb}"
  Found service "{180f--1000-8000-00805f9b34fb}"
   .. ignoring standard service "{180f--1000-8000-00805f9b34fb}"
  Found service "{fe59--1000-8000-00805f9b34fb}"
   .. ignoring standard service "{fe59--1000-8000-00805f9b34fb}"
  Found service "{6e41-b5a3-f393-e0a9-e50e24dc10b8}"
   .. created service object QLowEnergyService(0x7fc2557cd310)
  Found service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}"
   .. created service object QLowEnergyService(0x7fc25665e640)
   .. done discovering services
  Found service "{6e41-b5a3-f393-e0a9-e50e24dc10b8}" "Unknown Service"
 c: "{6e41-b5a3-f393-e0a9-e50e24dc10b8}"
 c: "{6e42-b5a3-f393-e0a9-e50e24dc10b8}"
  d: "{2902--1000-8000-00805f9b34fb}"
 c: "{6e43-b5a3-f393-e0a9-e50e24dc10b8}
 c: "{6e44-b5a3-f393-e0a9-e50e24dc10b8}"
 c: "{6e45-b5a3f393-e0a9-e50e24dc10b8}"
  Found service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}" "Unknown Service"
 c: "{6e42-b5a3-f393-e0a9-e50e24dcca9e}"
 c: "{6e43-b5a3-f393-e0a9-e50e24dcca9e}"
  d: "{2902--1000-8000-00805f9b34fb}"
  Using service "{6e41-b5a3-f393-e0a9-e50e24dc10b8}" as preferred service
   .. enabling notifications
  Using read characteristic "{6e42-b5a3-f393-e0a9-e50e24dc10b8}"
  now writing "0x0100" to the descriptor
"{2902--1000-8000-00805f9b34fb}"
  BLE write completed
  ..
  QTime("21:07:03.358") packet SEND "aa55"
  QTime("21:07:03.358") packet WAIT

which all looks reasonable. That final "packet SEND" is us actually
starting the communication, but then we don't get anything back.

But that is because we decide to use the wrong service. As mentioned
earlier, BLE serial transmission isn't standardized, and the Cressi
BLE dongle has a fairly complex set of services and characteristics.
It has a number of standard services (for battery level etc), but it
has _two_ nonstandard unknown services, and we pick the first one.

But it's the second one - the 6e41-b5a3-f393-e0a9-e50e24dcca9e
service - that is the "Nordic UART service".

But while that is somethign that the Nordic Semi nRF app knows about
(it's from your screenshots earlier), this is very much not something
that subsurface knew about, so subsurface picked the first one of the
two services.

So subsurface was trying to communicate with the wrong BLE service,
and isn't getting any replies.

I just need to figure out a heuristic that goes "use this service for
the Crssi case" without breaking the _other_ heuristics we have for
other cases..

This is the kind of annoying thing that happens with random new BLE
devices. We used to have it every time we saw a new BLE device, we've
just been lucky that our heuristics got good enough that we haven't
seen this in a while.

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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

It looks like it is not recognized as dive computer.



log
Description: Binary data


Kind regards,

Martin De Weger

> Op 16 feb. 2020, om 22:48 heeft Dirk Hohndel  het volgende 
> geschreven:
> 
> 
> 
>> On Feb 16, 2020, at 1:44 PM, Linus Torvalds  
>> wrote:
>> 
>> Hmm. I just realized that we've seem to have lost a lot of the Qt BLE
>> debugging output. The "libdivecomputer logfile" shows the actual
>> communication part, but you're not getting far enough for that to
>> matter.
>> 
>> Dirk, where does it go? We get the logs on mobile with the whole log
>> capture and "copy to clipboard", but I think the BLE debugging on the
>> desktop app just goes to stdout - but it's suppressed entirely by
>> default.
> 
> 
> You need to manually run the actual executable
> 
> .../Subsurface.app/Contents/MacOS/Subsurface > log 2>&1
> 
> and then send the log. That SHOULD include all of the debug output that Linus
> is looking for
> 
> /D
> ___
> 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: Import dives from Cressi Cartesio

[Dirk Hohndel]

> On Feb 16, 2020, at 1:44 PM, Linus Torvalds  
> wrote:
> 
> Hmm. I just realized that we've seem to have lost a lot of the Qt BLE
> debugging output. The "libdivecomputer logfile" shows the actual
> communication part, but you're not getting far enough for that to
> matter.
> 
> Dirk, where does it go? We get the logs on mobile with the whole log
> capture and "copy to clipboard", but I think the BLE debugging on the
> desktop app just goes to stdout - but it's suppressed entirely by
> default.


You need to manually run the actual executable

.../Subsurface.app/Contents/MacOS/Subsurface > log 2>&1

and then send the log. That SHOULD include all of the debug output that Linus
is looking for

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Sun, Feb 16, 2020 at 1:33 PM Martin de Weger  wrote:
>
> It does show the computer, but when I’m trying to download, it states 
> “unsupported operation”

Ok, not entirely surprising. We've had good luck with our
"pseudo-generic serial service over BLE" code, but BLE serial really
isn't standardized - because the bluetooth committees are broken - so
it's more a set of "these are common patterns" than anything else.

And the BLE descriptors in your screenshot looked less than promising,
simply because there's a lot going on. The good news is that the
serial part was Nordic Semi, which probably means that we can find
docs for it, but it also means that I'll need to figure out what they
do differently from the other serial-over-BLE chips we've seen.

>What logfiles do you need to look into this?

Hmm. I just realized that we've seem to have lost a lot of the Qt BLE
debugging output. The "libdivecomputer logfile" shows the actual
communication part, but you're not getting far enough for that to
matter.

Dirk, where does it go? We get the logs on mobile with the whole log
capture and "copy to clipboard", but I think the BLE debugging on the
desktop app just goes to stdout - but it's suppressed entirely by
default.

Interesting. We've been debugging BLE mostly on the mobile side
lately, so I didn't notice (even though I do all my _development_ on
the desktop).

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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

I did download from the site Dirk mentioned. It is unsigned though, but it runs 
(at least on my Mac).

And I forgot to thank you guys for the quick fix of the download issue!


Kind regards,

Martin De Weger

> Op 16 feb. 2020, om 22:39 heeft Dirk Hohndel  het volgende 
> geschreven:
> 
> 
> 
>> On Feb 16, 2020, at 12:59 PM, Linus Torvalds > > wrote:
>> 
>> On Sun, Feb 16, 2020 at 12:54 PM Dirk Hohndel > > wrote:
>>> 
>>> The CI should create working Windows and Mac builds as well as an AppImage.
>> 
>> I think Martin wanted it for iOS, but hopefully he should be able to
>> at least do the "see if it works, or send us logs" on his Mac.
>> 
>> Where do the builds show up? Is this the usable Mac app file for Martin to 
>> test?
>> 
>>   https://github.com/Subsurface-divelog/subsurface/actions/runs/40273093 
>> 
> 
> 
> That's the unsigned one that doesn't run on many Macs. The one that is closer 
> to
> what we ship as our releases is built on my own system locally and then pushed
> into the GitHub release by a little web hook. You can always find the latest 
> CI
> builds (including the Mac one) here:
> 
> https://github.com/Subsurface-divelog/subsurface/releases/tag/ci-release 
> 
> 
> /D

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

Re: Import dives from Cressi Cartesio

[Dirk Hohndel]

> On Feb 16, 2020, at 12:59 PM, Linus Torvalds  
> wrote:
> 
> On Sun, Feb 16, 2020 at 12:54 PM Dirk Hohndel  wrote:
>> 
>> The CI should create working Windows and Mac builds as well as an AppImage.
> 
> I think Martin wanted it for iOS, but hopefully he should be able to
> at least do the "see if it works, or send us logs" on his Mac.
> 
> Where do the builds show up? Is this the usable Mac app file for Martin to 
> test?
> 
>   https://github.com/Subsurface-divelog/subsurface/actions/runs/40273093


That's the unsigned one that doesn't run on many Macs. The one that is closer to
what we ship as our releases is built on my own system locally and then pushed
into the GitHub release by a little web hook. You can always find the latest CI
builds (including the Mac one) here:

https://github.com/Subsurface-divelog/subsurface/releases/tag/ci-release 


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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

It does show the computer, but when I’m trying to download, it states 
“unsupported operation”.What logfiles do you need to look into this?


Kind regards,

Martin De Weger

> Op 16 feb. 2020, om 21:54 heeft Dirk Hohndel  het volgende 
> geschreven:
> 
> 
> 
>> On Feb 16, 2020, at 9:07 AM, Linus Torvalds  
>> wrote:
>> 
>> On Sun, Feb 16, 2020 at 7:20 AM Martin de Weger  wrote:
>>> 
>>> Were the screenshots for the bluetooth of any help?
>> 
>> So now that the basic downloading works, let's try bluetooth.
>> 
>> I've created a pull request for just adding the BLE names and the
>> knowledge that "yes, we can try a BLE connection" at
>> 
>>   https://github.com/Subsurface-divelog/subsurface/pull/2624
>> 
>> but there is no guarantee at all that it will work.
> 
> It worked.
> And for the record, you can merge things like this yourself, no need to wait 
> for me.
> 
> The CI should create working Windows and Mac builds as well as an AppImage.
> The Android APK is unsigned which makes it more challenging to use, and for
> iOS we don't even try to create something installable (as you cannot install 
> anything
> that was built by a CI on iOS).
> 
> /D

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Sun, Feb 16, 2020 at 12:54 PM Dirk Hohndel  wrote:
>
> The CI should create working Windows and Mac builds as well as an AppImage.

I think Martin wanted it for iOS, but hopefully he should be able to
at least do the "see if it works, or send us logs" on his Mac.

Where do the builds show up? Is this the usable Mac app file for Martin to test?

   https://github.com/Subsurface-divelog/subsurface/actions/runs/40273093

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

Re: Import dives from Cressi Cartesio

[Dirk Hohndel]

> On Feb 16, 2020, at 9:07 AM, Linus Torvalds  
> wrote:
> 
> On Sun, Feb 16, 2020 at 7:20 AM Martin de Weger  wrote:
>> 
>> Were the screenshots for the bluetooth of any help?
> 
> So now that the basic downloading works, let's try bluetooth.
> 
> I've created a pull request for just adding the BLE names and the
> knowledge that "yes, we can try a BLE connection" at
> 
>https://github.com/Subsurface-divelog/subsurface/pull/2624
> 
> but there is no guarantee at all that it will work.

It worked.
And for the record, you can merge things like this yourself, no need to wait 
for me.

The CI should create working Windows and Mac builds as well as an AppImage.
The Android APK is unsigned which makes it more challenging to use, and for
iOS we don't even try to create something installable (as you cannot install 
anything
that was built by a CI on iOS).

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Sun, Feb 16, 2020 at 7:20 AM Martin de Weger  wrote:
>
> Were the screenshots for the bluetooth of any help?

So now that the basic downloading works, let's try bluetooth.

I've created a pull request for just adding the BLE names and the
knowledge that "yes, we can try a BLE connection" at

https://github.com/Subsurface-divelog/subsurface/pull/2624

but there is no guarantee at all that it will work.

But once that has been built and gets pushed out as an update, you
should at least be able to _try_ to download over BLE, and then the
resulting debug logs will be interesting.

Dirk, let's see if the "update libdivecomputer submodule" works for me
this time. It's had an about 50/50 success ratio so far, I think.

But the changes are trivial - no real new code, just "mark Cressi
Goa/Cartesio as supporting BLE" and adding the BLE name detection.

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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

Thanks for the help guys, this works like a charm.

Were the screenshots for the bluetooth of any help?


Kind regards,

Martin De Weger

> Op 15 feb. 2020, om 16:17 heeft Martin de Weger  het 
> volgende geschreven:
> 
> Thanks, will try tomorrow. 
> 
> Met vriendelijke groet,
> 
> Martin de Weger 
> 
>> Op 14 feb. 2020 om 19:31 heeft Dirk Hohndel  het volgende 
>> geschreven:
>> 
>> Mac binaries are usually included in the CI releases. The URL for those 
>> changes after every push,
>> the easiest way to get to them is to go to 
>> https://github.com/Subsurface-divelog/subsurface/releases/tag/ci-release 
>> 
>> and then download the DMG on that page. Right now as I write it that's 
>> https://github.com/Subsurface-divelog/subsurface/releases/download/ci-release/Subsurface-4.9.3-955-gf6260fff43ac.dmg
>>  
>> 
>> but the next PR merge or push to master will change the version number.
>> 
>> Please let us know if this fixes your issue.
>> 
>> /D
>> 
>>> On Feb 13, 2020, at 4:49 AM, Martin de Weger >> > wrote:
>>> 
>>> Thanks Jeff,
>>> 
>>> Where can I download the build for the Mac so I can test it?
>>> 
>>> I know there have been some issues with the daily build on the site. 
>>> 
>>> 
>>> Martin de Weger 
>>> 
 Op 13 feb. 2020 om 11:15 heeft Jef Driesen >>> > het volgende geschreven:
 
 On 2020-02-11 09:01, Martin de Weger wrote:
> It is correct. This was the first trip I’ve used this computer (as a
> backup computer), and I thought I did set up the gas mixture
> correctly.
 
 I have pushed a fix for the incorrect depth, and implemented the gas 
 switches too.
 
 Jef
 ___
 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
>> 

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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

Thanks, will try tomorrow. 

Met vriendelijke groet,

Martin de Weger 

> Op 14 feb. 2020 om 19:31 heeft Dirk Hohndel  het volgende 
> geschreven:
> 
> Mac binaries are usually included in the CI releases. The URL for those 
> changes after every push,
> the easiest way to get to them is to go to 
> https://github.com/Subsurface-divelog/subsurface/releases/tag/ci-release
> and then download the DMG on that page. Right now as I write it that's 
> https://github.com/Subsurface-divelog/subsurface/releases/download/ci-release/Subsurface-4.9.3-955-gf6260fff43ac.dmg
> but the next PR merge or push to master will change the version number.
> 
> Please let us know if this fixes your issue.
> 
> /D
> 
>> On Feb 13, 2020, at 4:49 AM, Martin de Weger  wrote:
>> 
>> Thanks Jeff,
>> 
>> Where can I download the build for the Mac so I can test it?
>> 
>> I know there have been some issues with the daily build on the site. 
>> 
>> 
>> Martin de Weger 
>> 
>>> Op 13 feb. 2020 om 11:15 heeft Jef Driesen  het 
>>> volgende geschreven:
>>> 
>>> On 2020-02-11 09:01, Martin de Weger wrote:
 It is correct. This was the first trip I’ve used this computer (as a
 backup computer), and I thought I did set up the gas mixture
 correctly.
>>> 
>>> I have pushed a fix for the incorrect depth, and implemented the gas 
>>> switches too.
>>> 
>>> Jef
>>> ___
>>> 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
> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Import dives from Cressi Cartesio

[Dirk Hohndel]

Mac binaries are usually included in the CI releases. The URL for those changes 
after every push,
the easiest way to get to them is to go to 
https://github.com/Subsurface-divelog/subsurface/releases/tag/ci-release 

and then download the DMG on that page. Right now as I write it that's 
https://github.com/Subsurface-divelog/subsurface/releases/download/ci-release/Subsurface-4.9.3-955-gf6260fff43ac.dmg
 

but the next PR merge or push to master will change the version number.

Please let us know if this fixes your issue.

/D

> On Feb 13, 2020, at 4:49 AM, Martin de Weger  wrote:
> 
> Thanks Jeff,
> 
> Where can I download the build for the Mac so I can test it?
> 
> I know there have been some issues with the daily build on the site. 
> 
> 
> Martin de Weger 
> 
>> Op 13 feb. 2020 om 11:15 heeft Jef Driesen  het 
>> volgende geschreven:
>> 
>> On 2020-02-11 09:01, Martin de Weger wrote:
>>> It is correct. This was the first trip I’ve used this computer (as a
>>> backup computer), and I thought I did set up the gas mixture
>>> correctly.
>> 
>> I have pushed a fix for the incorrect depth, and implemented the gas 
>> switches too.
>> 
>> Jef
>> ___
>> 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

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Thu, Feb 13, 2020 at 10:45 AM Linus Torvalds
 wrote:
>
> I started trying to generalize our "field cache" code (which includes
> the string interface code) so I'll try to finish that up first. But
> Jef's updates look simple to merge.

Ok, done, and pushed out.

I can't test Jef's changes, but they look trivially correct, and add a
few new IDs for a couple of new dive computers too.

And I did test my string parsing unification with the Cosmiq+ and the
Suunto EON Core. The Shearwater and Garmin conversions were just
syntactic.

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

Re: Import dives from Cressi Cartesio

[Linus Torvalds]

On Thu, Feb 13, 2020 at 8:10 AM Dirk Hohndel  wrote:
>
> Linus, would you please take a look and merge this into our branch?

Will do.

I started trying to generalize our "field cache" code (which includes
the string interface code) so I'll try to finish that up first. But
Jef's updates look simple to merge.

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

Re: Import dives from Cressi Cartesio

[Dirk Hohndel]

> On Feb 13, 2020, at 7:29 AM, Jef Driesen  wrote:
> 
> On 2020-02-13 12:49, Martin de Weger wrote:
>> Where can I download the build for the Mac so I can test it?
>> I know there have been some issues with the daily build on the site.
> 
> At the moment there is no build with the fix yet.

I see that this is in your master branch, Jef. Any changes needed beyond what's 
there?

Linus, would you please take a look and merge this into our branch?

Once we have that, creating a test build should only take a few minutes :-)

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

Re: Import dives from Cressi Cartesio

[Jef Driesen]

On 2020-02-13 12:49, Martin de Weger wrote:

Where can I download the build for the Mac so I can test it?

I know there have been some issues with the daily build on the site.


At the moment there is no build with the fix yet.

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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

Thanks Jeff,

Where can I download the build for the Mac so I can test it?

I know there have been some issues with the daily build on the site. 


Martin de Weger 

> Op 13 feb. 2020 om 11:15 heeft Jef Driesen  het 
> volgende geschreven:
> 
> On 2020-02-11 09:01, Martin de Weger wrote:
>> It is correct. This was the first trip I’ve used this computer (as a
>> backup computer), and I thought I did set up the gas mixture
>> correctly.
> 
> I have pushed a fix for the incorrect depth, and implemented the gas switches 
> too.
> 
> Jef
> ___
> 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: Import dives from Cressi Cartesio

[Jef Driesen]

On 2020-02-11 09:01, Martin de Weger wrote:

It is correct. This was the first trip I’ve used this computer (as a
backup computer), and I thought I did set up the gas mixture
correctly.


I have pushed a fix for the incorrect depth, and implemented the gas 
switches too.


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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

It is correct. This was the first trip I’ve used this computer (as a backup 
computer), and I thought I did set up the gas mixture correctly. 

Martin 

> Op 11 feb. 2020 om 08:58 heeft Jef Driesen  het 
> volgende geschreven:
> 
> On 2020-02-08 10:46, Martin de Weger wrote:
>> Yep, here it is.
> 
> It looks like there are gas switches in the dives that fail to parse. Is that 
> correct? Two of those dives are a bit unusual, so I want to double check with 
> you.
> 
> For example the dive on 2020-01-27 14:51:00 starts with Air. After 35 seconds 
> there is a switch to EAN32, which lasts for the rest of the dive.
> 
> The dive before (2020-01-26 16:14:00) shows the same with a switch from Air 
> to EAN32 after 90 seconds.
> 
> The dive on 2020-01-26 13:11:00 looks a bit more normal, with a switch from 
> air to EAN32 after 29:15.
> 
> Jef

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

Re: Import dives from Cressi Cartesio

[Jef Driesen]

On 2020-02-08 10:46, Martin de Weger wrote:

Yep, here it is.


It looks like there are gas switches in the dives that fail to parse. Is 
that correct? Two of those dives are a bit unusual, so I want to double 
check with you.


For example the dive on 2020-01-27 14:51:00 starts with Air. After 35 
seconds there is a switch to EAN32, which lasts for the rest of the 
dive.


The dive before (2020-01-26 16:14:00) shows the same with a switch from 
Air to EAN32 after 90 seconds.


The dive on 2020-01-26 13:11:00 looks a bit more normal, with a switch 
from air to EAN32 after 29:15.


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

Re: Import dives from Cressi Cartesio

[Jef Driesen]

On 5/02/2020 21:33, Martin de Weger wrote:
Here is the logfile and the print from the Cressi App. I also added screenshots 
from the nRF Connect app, hop this is what you wnt. The weird thing is, They 
iPhone is able to connect using BT, not the macbook (with the Cressi app)..


Can you export the data from the Cressi application? I see there is a 
backup/restore button in the screenshot. That might do the job.


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

Re: Import dives from Cressi Cartesio

[Jef Driesen]

On 2020-02-05 13:35, Martin de Weger wrote:

I’ll have a look. When using the dum-file option (in the Beta version
of subsurface) an error is thrown (something went wrong). I wanted to
install the stable version from the website, but that link is broken
(https://subsurface-divelog.org/download/Subsurface-4.9.3.dmg
). As
soon as I have the stable version up and running, I’ll give it another
try.


The Cressi Cartesio protocol doesn't support downloading memory dumps. 
As you already noticed, it will fail immediately with a 
DC_STATUS_UNSUPPORTED error. Instead of downloading a memory dump, do a 
normal download with the "Save libdivecomputer logfile" checkbox 
enabled, and send the log file.


I recommend to first create a new empty logbook file. This will force a 
full download, without messing up your real logbook. Afterwards you can 
discard the temporary logbook file again.


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

Re: Import dives from Cressi Cartesio

[Martin de Weger]

Hi Linus,

I’ll have a look. When using the dum-file option (in the Beta version of 
subsurface) an error is thrown (something went wrong). I wanted to install the 
stable version from the website, but that link is broken 
(https://subsurface-divelog.org/download/Subsurface-4.9.3.dmg 
). As soon as I 
have the stable version up and running, I’ll give it another try.

I’m using the Cartessio adapter 
(https://www.cressi.com/Catalogue/Details.asp?id=1166=1 
) for the download.


Met vriendelijke groeten,

Martin de Weger
E: mar...@reef-it.nl
T: + 31 6 10 48 63 58

> Op 5 feb. 2020, om 07:13 heeft Linus Torvalds  
> het volgende geschreven:
> 
> On Mon, Feb 3, 2020 at 6:57 PM Martin de Weger  wrote:
>> 
>> I’ve purchased a Cressi Cartesio with the (bluetooth enabled) interface. 
>> I’ve ran into a few issues with this setup on Subsurface:
>> 
>> I’m unable to download the dives on my Mac and on my iPhone using Bluetooth 
>> with Subsurface. When using the Cressi App, I’m able to download via 
>> Bluetooth;
>> When downloading on my Mac with an USB cable connection, some off the dives 
>> show a depth of 200+meters (over 600 feet) while my Shearwater shows a depth 
>> of maximal 32 meters. In the Cressi app the dives are shown as they actually 
>> were made.
>> 
>> What information you you guys need from me to look further into this issue?
> 
> A few basic things:
> 
> (1) When downloading using USB, check the "create libdivecomputer
> dumpfile" option - that will mean that no actual dives get downloaded,
> but you should get a memory dump that you can send to Jef:
> 
>Jef Driesen  
> 
> (2) Also send Jef the screenshot from the Cressi App of the profile
> and other information from the download, so that Jef sees what it
> *should* look like.
> 
> (3) Finally, can you use the "nRF Connect" app to look at the
> bluetooth details of that bluetooth dongle thing? I'm assuming you're
> using that HAL 9000 BT interface to download on the Cressi app? No
> promises, but if it looks like most other serial to BLE dongles, the
> BLE side might not be too painful to add.
> 
> But there's clearly something wrong with parsing, and that's the
> primary issue - downloading over bluetooth won't fix that.
> 
>Linus
> ___
> 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: Import dives from Cressi Cartesio

[Linus Torvalds]

On Mon, Feb 3, 2020 at 6:57 PM Martin de Weger  wrote:
>
> I’ve purchased a Cressi Cartesio with the (bluetooth enabled) interface. I’ve 
> ran into a few issues with this setup on Subsurface:
>
> I’m unable to download the dives on my Mac and on my iPhone using Bluetooth 
> with Subsurface. When using the Cressi App, I’m able to download via 
> Bluetooth;
> When downloading on my Mac with an USB cable connection, some off the dives 
> show a depth of 200+meters (over 600 feet) while my Shearwater shows a depth 
> of maximal 32 meters. In the Cressi app the dives are shown as they actually 
> were made.
>
> What information you you guys need from me to look further into this issue?

A few basic things:

 (1) When downloading using USB, check the "create libdivecomputer
dumpfile" option - that will mean that no actual dives get downloaded,
but you should get a memory dump that you can send to Jef:

Jef Driesen  

 (2) Also send Jef the screenshot from the Cressi App of the profile
and other information from the download, so that Jef sees what it
*should* look like.

 (3) Finally, can you use the "nRF Connect" app to look at the
bluetooth details of that bluetooth dongle thing? I'm assuming you're
using that HAL 9000 BT interface to download on the Cressi app? No
promises, but if it looks like most other serial to BLE dongles, the
BLE side might not be too painful to add.

But there's clearly something wrong with parsing, and that's the
primary issue - downloading over bluetooth won't fix that.

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

Import dives from Cressi Cartesio

[Martin de Weger]

Hi all,

I’ve purchased a Cressi Cartesio with the (bluetooth enabled) interface. I’ve 
ran into a few issues with this setup on Subsurface:

I’m unable to download the dives on my Mac and on my iPhone using Bluetooth 
with Subsurface. When using the Cressi App, I’m able to download via Bluetooth;
When downloading on my Mac with an USB cable connection, some off the dives 
show a depth of 200+meters (over 600 feet) while my Shearwater shows a depth of 
maximal 32 meters. In the Cressi app the dives are shown as they actually were 
made.

What information you you guys need from me to look further into this issue?


Kind regards,

Martin De Weger

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