Any brave dive computer download testers out there?

[Linus Torvalds]

So libdivecomputer has a new custom IO model, which allows us to drop
our home-made one.

However, that new model is fairly different from our old model, and
there were other updates too, so the changes are "flag-day" changes
where we switch over both libdivecomputer and subsurface together.

I have *TEST* branches for both, in case people want to help test.
Note! I only do source code, so this really only works for people who
can build their own subsurface binary, but if you are one of those
hardy souls, it realy would be good to get more cases tested.

I have verified and downloaded:

- Shearwater Perdix AI over BLE

- Suunto EON Core over USB

- Suunto Vyper Air over the Suunto USB serial line

so many of the transports have been tested. But I don't have any
rfcomm devices (ie old bluetooth) and I don't have any "direct USB"
devices (eg Atomics Aquatics Cobalt).

Also, I only tested on my Linux desktop, because that's how I roll.

Anyway, if you can build subsurface and libdivercomputer, and are
interested in testing, I have test branches for both:

https://github.com/torvalds/libdc-for-dirk.git Subsurface-NG

https://github.com/torvalds/subsurface-for-dirk.git libdivecomputer-NG

NOTE! I may end up rebasing those branches, so don't consider them stable.

NOTE 2! I have *not* set up that subsurface branch to have the
submodule link to my libdivecomputer branch, partly exactly because
these are unstable branches and I don't want to tie them together too
tightly. So you should pull the subsurface and libdivecomputer
subdirectories separately, and the usual "pull subsurface, then do
'git submodule update'" model will not work.

It may break things. I'd be surprised if it doesn't. So keep that in
mind. This is very much for people who are happy playing around and
helping get some coverage for early work.

Linus

[Jan Mulder]

On 18-04-18 05:35, Linus Torvalds wrote:
>
> I have *TEST* branches for both, in case people want to help test.
> Note! I only do source code, so this really only works for people who
> can build their own subsurface binary, but if you are one of those
> hardy souls, it realy would be good to get more cases tested.
>
> I have verified and downloaded:
>
> - Shearwater Perdix AI over BLE
>
> - Suunto EON Core over USB
>
> - Suunto Vyper Air over the Suunto USB serial line
>
> so many of the transports have been tested. But I don't have any
> rfcomm devices (ie old bluetooth) and I don't have any "direct USB"
> devices (eg Atomics Aquatics Cobalt).
>

Tested on Arch Linux with an OSTC3 (desktop only, so no
mobile-on-desktop, or Android).

- Successful download over BLE
- Cannot download over classic BT (it always goes to BLE, even in case
"force classic" in the UI is chosen). But unsure this is related to the
transport refactoring.

--jan

[Miika Turkia]

On Wed, Apr 18, 2018 at 12:29 PM, Jan Mulder <***@xs4all.nl> wrote:

> On 18-04-18 05:35, Linus Torvalds wrote:
>
>>
>> I have *TEST* branches for both, in case people want to help test.
>> Note! I only do source code, so this really only works for people who
>> can build their own subsurface binary, but if you are one of those
>> hardy souls, it realy would be good to get more cases tested.
>>
>> I have verified and downloaded:
>>
>> - Shearwater Perdix AI over BLE
>>
>> - Suunto EON Core over USB
>>
>> - Suunto Vyper Air over the Suunto USB serial line
>>
>> so many of the transports have been tested. But I don't have any
>> rfcomm devices (ie old bluetooth) and I don't have any "direct USB"
>> devices (eg Atomics Aquatics Cobalt).
>>
>>
> Tested on Arch Linux with an OSTC3 (desktop only, so no mobile-on-desktop,
> or Android).
>
> - Successful download over BLE
> - Cannot download over classic BT (it always goes to BLE, even in case
> "force classic" in the UI is chosen). But unsure this is related to the
> transport refactoring.


I failed with BT download (OSTC Sport). But my download fails also with the
release version of Subsurface. Unpairing-pairing works but no download with
subsurface on Linux desktop for me :(

miika

[Linus Torvalds]

On Wed, Apr 18, 2018 at 11:31 AM, Miika Turkia <***@gmail.com> wrote:
>
> I failed with BT download (OSTC Sport). But my download fails also with the
> release version of Subsurface. Unpairing-pairing works but no download with
> subsurface on Linux desktop for me :(

Is the OSTC sport a rfcomm (legacy BT) device?

I don't have any of those, so I couldn't test it.

I don't think Dirk tests it either, which may explain the "fails with
release version too". It may be that all his older ones are broken.

Ugh. The rfcomm case _looks_ trivial, but since I have never used it,
I can only go by the "changes since mainline".

And if mainline was broken too, then the fact that those changes look
sane obviously isn't meaningful.

Dirk is traveling, and I don't have an rfcomm dive computer, so it
would be great if somebody who likes debugging would look at this..

Linus

[Dirk Hohndel]

> On Apr 18, 2018, at 8:47 PM, Linus Torvalds <***@linux-foundation.org> wrote:
>
> On Wed, Apr 18, 2018 at 11:31 AM, Miika Turkia <***@gmail.com> wrote:
>>
>> I failed with BT download (OSTC Sport). But my download fails also with the
>> release version of Subsurface. Unpairing-pairing works but no download with
>> subsurface on Linux desktop for me :(
>
> Is the OSTC sport a rfcomm (legacy BT) device?
>
> I don't have any of those, so I couldn't test it.
>
> I don't think Dirk tests it either, which may explain the "fails with
> release version too". It may be that all his older ones are broken.

Yes - I have not a single working OSTC left. Which is kind of a shame because I
really like them.

> Ugh. The rfcomm case _looks_ trivial, but since I have never used it,
> I can only go by the "changes since mainline".
>
> And if mainline was broken too, then the fact that those changes look
> sane obviously isn't meaningful.
>
> Dirk is traveling, and I don't have an rfcomm dive computer, so it
> would be great if somebody who likes debugging would look at this..

I do have a BT only Shearwater at home. But there are quite a few people
on this list who have other dive computers they could test with.

Should we create test binaries with the branches that you have?

/D

[Federico Masias]

I've never been able to get a proper build on macOS (though I honestly
haven't been particularly motivated to do so lately) so I can't test Linus'
branch

I'd be able to test an i200 if you did a test binary, but I'm not sure the
effort is worth it for one person who can only test USB

On Wed, Apr 18, 2018 at 2:50 PM, Dirk Hohndel <***@hohndel.org> wrote:

>
> > On Apr 18, 2018, at 8:47 PM, Linus Torvalds <
> ***@linux-foundation.org> wrote:
> >
> > On Wed, Apr 18, 2018 at 11:31 AM, Miika Turkia <***@gmail.com>
> wrote:
> >>
> >> I failed with BT download (OSTC Sport). But my download fails also with
> the
> >> release version of Subsurface. Unpairing-pairing works but no download
> with
> >> subsurface on Linux desktop for me :(
> >
> > Is the OSTC sport a rfcomm (legacy BT) device?
> >
> > I don't have any of those, so I couldn't test it.
> >
> > I don't think Dirk tests it either, which may explain the "fails with
> > release version too". It may be that all his older ones are broken.
>
> Yes - I have not a single working OSTC left. Which is kind of a shame
> because I
> really like them.
>
> > Ugh. The rfcomm case _looks_ trivial, but since I have never used it,
> > I can only go by the "changes since mainline".
> >
> > And if mainline was broken too, then the fact that those changes look
> > sane obviously isn't meaningful.
> >
> > Dirk is traveling, and I don't have an rfcomm dive computer, so it
> > would be great if somebody who likes debugging would look at this..
>
> I do have a BT only Shearwater at home. But there are quite a few people
> on this list who have other dive computers they could test with.
>
> Should we create test binaries with the branches that you have?
>
> /D
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>

[Miika Turkia]

On Wed, Apr 18, 2018 at 9:47 PM, Linus Torvalds <
***@linux-foundation.org> wrote:

> On Wed, Apr 18, 2018 at 11:31 AM, Miika Turkia <***@gmail.com>
> wrote:
> >
> > I failed with BT download (OSTC Sport). But my download fails also with
> the
> > release version of Subsurface. Unpairing-pairing works but no download
> with
> > subsurface on Linux desktop for me :(
>
> Is the OSTC sport a rfcomm (legacy BT) device?
>
> I don't have any of those, so I couldn't test it.
>

Yep, good old fashioned fast bluetooth (when it works). I just tested with
some appimages that are laying around on my machine and it works with

Subsurface v4.7.4-3-g6addfe16605b,
built with libdivecomputer v0.6.0-devel-Subsurface-branch
(7de3a549ee588fef4702ee9d894e390aca43950d)

The latest appimage and normal binary are both not working. So the stuff
broke down some time between the 4.7.4 and 4.7.8, but I have currently no
idea when. I might have a change to look into this tomorrow, but after that
it'll be at least a week when I have no change of doing anything related.

miika

[Miika Turkia]

On Wed, Apr 18, 2018 at 10:12 PM, Miika Turkia <***@gmail.com>
wrote:

> On Wed, Apr 18, 2018 at 9:47 PM, Linus Torvalds <
> ***@linux-foundation.org> wrote:
>
>> On Wed, Apr 18, 2018 at 11:31 AM, Miika Turkia <***@gmail.com>
>> wrote:
>> >
>> > I failed with BT download (OSTC Sport). But my download fails also with
>> the
>> > release version of Subsurface. Unpairing-pairing works but no download
>> with
>> > subsurface on Linux desktop for me :(
>>
>> Is the OSTC sport a rfcomm (legacy BT) device?
>>
>> I don't have any of those, so I couldn't test it.
>>
>
> Yep, good old fashioned fast bluetooth (when it works). I just tested with
> some appimages that are laying around on my machine and it works with
>
> Subsurface v4.7.4-3-g6addfe16605b,
> built with libdivecomputer v0.6.0-devel-Subsurface-branch (
> 7de3a549ee588fef4702ee9d894e390aca43950d)
>
> The latest appimage and normal binary are both not working. So the stuff
> broke down some time between the 4.7.4 and 4.7.8, but I have currently no
> idea when. I might have a change to look into this tomorrow, but after that
> it'll be at least a week when I have no change of doing anything related.
>

When using Subsurface version 6addfe16605b0257f6c42b0adb75c8ae157626f5; BT
download with libdivecomputer 54f6bff9290906a62628c85e1adb3a74ca487722
works but with 8ae735a4d70307ebe2a42d315697f02ce71dbe88 does not. Running
out of time for now so have to leave at this.

miika

[Linus Torvalds]

On Wed, Apr 18, 2018 at 2:29 AM, Jan Mulder <***@xs4all.nl> wrote:
>
> Tested on Arch Linux with an OSTC3 (desktop only, so no mobile-on-desktop,
> or Android).

Thanks.

> - Successful download over BLE
> - Cannot download over classic BT (it always goes to BLE, even in case
> "force classic" in the UI is chosen). But unsure this is related to the
> transport refactoring.

Yeah, right now the logic is "if we support BLE, and the dive computer
supports BLE, then we'll use BLE".

We'll fall back to rfcomm only when libdivecomputer says that the
divecomputer only does legacy BT.

I realize that we have that "force BT/BLE" thing, but it sadly doesn't
actually set the "bluetooth_mode". That's a boolean, and is true for
both BT and BLE.

I think it does change the "devname", and I guess I could test that.

Linus

[Dirk Hohndel]

> On Apr 18, 2018, at 8:40 PM, Linus Torvalds <***@linux-foundation.org> wrote:
>
>> - Successful download over BLE
>> - Cannot download over classic BT (it always goes to BLE, even in case
>> "force classic" in the UI is chosen). But unsure this is related to the
>> transport refactoring.
>
> Yeah, right now the logic is "if we support BLE, and the dive computer
> supports BLE, then we'll use BLE".
>
> We'll fall back to rfcomm only when libdivecomputer says that the
> divecomputer only does legacy BT.

I think that's backwards. If the dive computer and the Subsurface version
both support BT, we should prefer that over BLE by default.

> I realize that we have that "force BT/BLE" thing, but it sadly doesn't
> actually set the "bluetooth_mode". That's a boolean, and is true for
> both BT and BLE.
>
> I think it does change the "devname", and I guess I could test that.

Yes, it uses the LE: prefix. And it might still make sense to keep this
but we really should prefer BT over BLE simply for speed reasons

/D

[Linus Torvalds]

On Wed, Apr 18, 2018 at 11:48 AM, Dirk Hohndel <***@hohndel.org> wrote:
>
> I think that's backwards. If the dive computer and the Subsurface version
> both support BT, we should prefer that over BLE by default.

Well, since it seems to be broken, I'm not sure that's a good idea.

I also definitely don't want to default to somethihng I can't even test.

Linus

[Dirk Hohndel]

> On Apr 18, 2018, at 8:56 PM, Linus Torvalds <***@linux-foundation.org> wrote:
>
> On Wed, Apr 18, 2018 at 11:48 AM, Dirk Hohndel <***@hohndel.org> wrote:
>>
>> I think that's backwards. If the dive computer and the Subsurface version
>> both support BT, we should prefer that over BLE by default.
>
> Well, since it seems to be broken, I'm not sure that's a good idea.

I think if it's broken we need to fix it :-)

(he says, while traveling without a dive computer to test with)

> I also definitely don't want to default to somethihng I can't even test.

That I agree with. You can pick up a BT dive computer at my house - just
talk to Karen when she's around.

/D

[Matt Thompson]

I don't have time to set up a build environment but if I can get a test
build for any of the supported OS's I can test with a Cobalt, Suunto D4i,
and Aqualung i750tc.

On Wed, Apr 18, 2018 at 2:04 PM, Dirk Hohndel <***@hohndel.org> wrote:

>
> > On Apr 18, 2018, at 8:56 PM, Linus Torvalds <
> ***@linux-foundation.org> wrote:
> >
> > On Wed, Apr 18, 2018 at 11:48 AM, Dirk Hohndel <***@hohndel.org> wrote:
> >>
> >> I think that's backwards. If the dive computer and the Subsurface
> version
> >> both support BT, we should prefer that over BLE by default.
> >
> > Well, since it seems to be broken, I'm not sure that's a good idea.
>
> I think if it's broken we need to fix it :-)
>
> (he says, while traveling without a dive computer to test with)
>
> > I also definitely don't want to default to somethihng I can't even test.
>
> That I agree with. You can pick up a BT dive computer at my house - just
> talk to Karen when she's around.
>
> /D
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>

[Dirk Hohndel]

> On Apr 18, 2018, at 9:17 PM, Matt Thompson <***@gmail.com> wrote:
>
> I don't have time to set up a build environment but if I can get a test build for any of the supported OS's I can test with a Cobalt, Suunto D4i, and Aqualung i750tc.

I'm trying to get Travis to do that for us.
Which OSs can you test? Travis creates an AppImage, Windows and an unsigned Mac .app - assuming the builds don't fail :-)

/D

[Matt Thompson]

I can test all three platforms. I have a Macbook and a dual boot PC and a
pile of computers with fresh dives from this weekend! :)

On Wed, Apr 18, 2018 at 2:28 PM, Dirk Hohndel <***@hohndel.org> wrote:

>
> > On Apr 18, 2018, at 9:17 PM, Matt Thompson <***@gmail.com> wrote:
> >
> > I don't have time to set up a build environment but if I can get a test
> build for any of the supported OS's I can test with a Cobalt, Suunto D4i,
> and Aqualung i750tc.
>
> I'm trying to get Travis to do that for us.
> Which OSs can you test? Travis creates an AppImage, Windows and an
> unsigned Mac .app - assuming the builds don't fail :-)
>
> /D

[Robert Helling]

Dirk,

> On 18. Apr 2018, at 21:28, Dirk Hohndel <***@hohndel.org> wrote:
>
> I'm trying to get Travis to do that for us.
> Which OSs can you test? Travis creates an AppImage, Windows and an unsigned Mac .app - assuming the builds don't fail :-)

please excuse my ignorance. It seems that the Mac build on Travis went thru. Where can I find the resulting binary?

Best
Robert

[Dirk Hohndel]

> On Apr 18, 2018, at 10:13 PM, Robert Helling <***@atdotde.de> wrote:
>
> Dirk,
>
>> On 18. Apr 2018, at 21:28, Dirk Hohndel <***@hohndel.org <mailto:***@hohndel.org>> wrote:
>>
>> I'm trying to get Travis to do that for us.
>> Which OSs can you test? Travis creates an AppImage, Windows and an unsigned Mac .app - assuming the builds don't fail :-)
>
> please excuse my ignorance. It seems that the Mac build on Travis went thru. Where can I find the resulting binary?

https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-NG/Subsurface-4.7.8-67-g9d57d23c72f2.app.zip <https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-NG/Subsurface-4.7.8-67-g9d57d23c72f2.app.zip>

this is unsigned, so may require some prodding to run on a Mac.

/D

[Dirk Hohndel]

We now have binaries for Windows, Mac, and Linux (AppImage only) available in order for people to test this.

https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous-NG <https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous-NG>

/D

[Salvador Cuñat]

Good night,

On Wed, Apr 18, 2018 at 11:01:28PM +0200, Dirk Hohndel wrote:
>
> We now have binaries for Windows, Mac, and Linux (AppImage only) available in order for people to test this.
>
AppImage works fine for USB download (on debian with an OSTC 2N device).

Best regards.

Salva.

[Robert Helling]

Hi,

> On 18. Apr 2018, at 23:01, Dirk Hohndel <***@hohndel.org> wrote:
>
> We now have binaries for Windows, Mac, and Linux (AppImage only) available in order for people to test this.
>
> https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous-NG <https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous-NG>

tested on Mac with OSTC Sport. BLE download worked, BL classic didn’t (but it’s always unreliable, so that does not mean much, but there is the error message about not being able to open the device). Couldn’t get the dive computer configuration to work either with BLE or classic.

Best
Robert

[Linus Torvalds]

On Wed, Apr 18, 2018 at 3:37 PM, Robert Helling <***@atdotde.de> wrote:
>
> Couldn’t get the dive computer configuration to work either with BLE or classic.

Did this work with the previous release (4.7.8 or whatever)?

I had been hoping that I got the config thing right, but I've never
used it or tested it (I'm not sure I even have any of the dive
computers that are supported), so that was purely a "it builds".

Linus

[Dirk Hohndel]

> On Apr 19, 2018, at 12:54 AM, Linus Torvalds <***@linux-foundation.org> wrote:
>
> On Wed, Apr 18, 2018 at 3:37 PM, Robert Helling <***@atdotde.de> wrote:
>>
>> Couldn’t get the dive computer configuration to work either with BLE or classic.
>
> Did this work with the previous release (4.7.8 or whatever)?
>
> I had been hoping that I got the config thing right, but I've never
> used it or tested it (I'm not sure I even have any of the dive
> computers that are supported), so that was purely a "it builds".

Didn't the config code support the Suunto Vyper Air?

Ideally we'd get Anton to make sure that this part of the code still works.

/D

[Anton Lundin]

On 19 April, 2018 - Dirk Hohndel wrote:

>
> > On Apr 19, 2018, at 12:54 AM, Linus Torvalds <***@linux-foundation.org> wrote:
> >
> > On Wed, Apr 18, 2018 at 3:37 PM, Robert Helling <***@atdotde.de> wrote:
> >>
> >> Couldn’t get the dive computer configuration to work either with BLE or classic.
> >
> > Did this work with the previous release (4.7.8 or whatever)?
> >
> > I had been hoping that I got the config thing right, but I've never
> > used it or tested it (I'm not sure I even have any of the dive
> > computers that are supported), so that was purely a "it builds".
>
> Didn't the config code support the Suunto Vyper Air?
>
> Ideally we'd get Anton to make sure that this part of the code still works.

The Suunto Vyper Air belongs do the vyper2 family of computers, which
isn't supported.

There aren't that many interesting setting figured out for the vyper2
family according to the reverse engineered documentation I've found.
(http://www.sarnau.com/posts/2003/suunto_d9/)

Its basically:
* metric vs. imperial
* owner name

And some values which might be interesting to read:
* Type of the dive computer, "D9", "D6" or "D4"
* Manufacturing date
* serial number / Production date
* max. depth
* total dive time
* total number of dives


And without a actual device to test it against, its sort of hard to
test the code, so I've never gotten around to actually writing it.


//Anton


--
Anton Lundin [phone]

[Robert Helling]

LInus,

> On 19. Apr 2018, at 00:54, Linus Torvalds <***@linux-foundation.org> wrote:
>
> Did this work with the previous release (4.7.8 or whatever)?
>
> I had been hoping that I got the config thing right, but I've never
> used it or tested it (I'm not sure I even have any of the dive
> computers that are supported), so that was purely a "it builds".


I double checked: In 4.7.8, I can connect with BT classic, in your branch I cannot. Also, in the release version I can change the settings in BLE while in your branch I get an „Unsupported operation“ error (BTW, we should show that error on the configure dive computer window not on the main window which is in the background
).

All this on Mac with OSTC Sport.

Best
Robert

[Robert Helling]

Hi,

> On 19. Apr 2018, at 08:01, Robert Helling <***@atdotde.de> wrote:
>
> I double checked: In 4.7.8, I can connect with BT classic, in your branch I cannot. Also, in the release version I can change the settings in BLE while in your branch I get an „Unsupported operation“ error (BTW, we should show that error on the configure dive computer window not on the main window which is in the background
).
>
> All this on Mac with OSTC Sport.

I finally managed to find a replacement battery for my Suunto Vyper, so I could try this as well (this is serial over USB). Turns out, doesn’t work: Download seems to start, LED on cable flashes but then stops with generic error message immediately. Dive computer config doesn’t even start.

Both works with 478 release.

Best
Robert

[tormento]

I will give a try to NG.

Where does the stable Subsurface save the configuration file with cloud
password etc? I'd like to make a backup.

2018-04-19 8:39 GMT+02:00 Robert Helling <***@atdotde.de>:

> Hi,
>
> On 19. Apr 2018, at 08:01, Robert Helling <***@atdotde.de> wrote:
>
> I double checked: In 4.7.8, I can connect with BT classic, in your branch
> I cannot. Also, in the release version I can change the settings in BLE
> while in your branch I get an „Unsupported operation“ error (BTW, we should
> show that error on the configure dive computer window not on the main
> window which is in the background
).
>
> All this on Mac with OSTC Sport.
>
>
> I finally managed to find a replacement battery for my Suunto Vyper, so I
> could try this as well (this is serial over USB). Turns out, doesn’t work:
> Download seems to start, LED on cable flashes but then stops with generic
> error message immediately. Dive computer config doesn’t even start.
>
> Both works with 478 release.
>
> Best
> Robert
>
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>

[Dirk Hohndel]

On Thu, Apr 19, 2018 at 09:25:19AM +0200, tormento wrote:
> I will give a try to NG.
>
> Where does the stable Subsurface save the configuration file with cloud
> password etc? I'd like to make a backup.

Depends on your OS. We rely on Qt to do that for us.
Look at http://doc.qt.io/qt-5/qsettings.html under Platform-Specific Notes

/D

[tormento]

Windows 10 x64, sorry.

Il giorno gio 19 apr 2018 alle 12:22 Dirk Hohndel <***@hohndel.org> ha
scritto:

> On Thu, Apr 19, 2018 at 09:25:19AM +0200, tormento wrote:
> > I will give a try to NG.
> >
> > Where does the stable Subsurface save the configuration file with cloud
> > password etc? I'd like to make a backup.
>
> Depends on your OS. We rely on Qt to do that for us.
> Look at http://doc.qt.io/qt-5/qsettings.html under Platform-Specific Notes
>
> /D
>

[Dirk Hohndel]

In Windows the settings are all stored in the registry. So no easy way (that I'm
aware of) of backing them up

/D

> On Apr 19, 2018, at 1:26 PM, tormento <***@gmail.com> wrote:
>
> Windows 10 x64, sorry.
>
> Il giorno gio 19 apr 2018 alle 12:22 Dirk Hohndel <***@hohndel.org <mailto:***@hohndel.org>> ha scritto:
> On Thu, Apr 19, 2018 at 09:25:19AM +0200, tormento wrote:
> > I will give a try to NG.
> >
> > Where does the stable Subsurface save the configuration file with cloud
> > password etc? I'd like to make a backup.
>
> Depends on your OS. We rely on Qt to do that for us.
> Look at http://doc.qt.io/qt-5/qsettings.html <http://doc.qt.io/qt-5/qsettings.html> under Platform-Specific Notes
>
> /D
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[tormento]

That's a pity.

Subsurface already creates its own directories in Local and Roaming. Let's
put settings there too...

Do you think it's feasable?

Alberto

2018-04-19 14:31 GMT+02:00 Dirk Hohndel <***@hohndel.org>:

> In Windows the settings are all stored in the registry. So no easy way
> (that I'm
> aware of) of backing them up
>
> /D
>
> On Apr 19, 2018, at 1:26 PM, tormento <***@gmail.com> wrote:
>
> Windows 10 x64, sorry.
>
> Il giorno gio 19 apr 2018 alle 12:22 Dirk Hohndel <***@hohndel.org> ha
> scritto:
>
>> On Thu, Apr 19, 2018 at 09:25:19AM +0200, tormento wrote:
>> > I will give a try to NG.
>> >
>> > Where does the stable Subsurface save the configuration file with cloud
>> > password etc? I'd like to make a backup.
>>
>> Depends on your OS. We rely on Qt to do that for us.
>> Look at http://doc.qt.io/qt-5/qsettings.html under Platform-Specific
>> Notes
>>
>> /D
>>
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
>

[Dirk Hohndel]

I'm sure that's feasible. For us using the Qt QSettings system is a major
convenience as it works on all of our target OSs. I haven't looked into
options to export the QSettings and being able to restore them.

One way to work around this is to start Subsurface with an option to run
it as a different user - as that will create a separate set of settings.

Start subsurface.exe with the --user=test flag (or some other user name)

/D

On Thu, Apr 19, 2018 at 04:58:44PM +0200, tormento wrote:
> That's a pity.
>
> Subsurface already creates its own directories in Local and Roaming. Let's
> put settings there too...
>
> Do you think it's feasable?
>
> Alberto
>
> 2018-04-19 14:31 GMT+02:00 Dirk Hohndel <***@hohndel.org>:
>
> > In Windows the settings are all stored in the registry. So no easy way
> > (that I'm
> > aware of) of backing them up
> >
> > /D
> >
> > On Apr 19, 2018, at 1:26 PM, tormento <***@gmail.com> wrote:
> >
> > Windows 10 x64, sorry.
> >
> > Il giorno gio 19 apr 2018 alle 12:22 Dirk Hohndel <***@hohndel.org> ha
> > scritto:
> >
> >> On Thu, Apr 19, 2018 at 09:25:19AM +0200, tormento wrote:
> >> > I will give a try to NG.
> >> >
> >> > Where does the stable Subsurface save the configuration file with cloud
> >> > password etc? I'd like to make a backup.
> >>
> >> Depends on your OS. We rely on Qt to do that for us.
> >> Look at http://doc.qt.io/qt-5/qsettings.html under Platform-Specific
> >> Notes
> >>
> >> /D
> >>
> > _______________________________________________
> > subsurface mailing list
> > ***@subsurface-divelog.org
> > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> >
> >
> >

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

[Anton Lundin]

On 18 April, 2018 - Linus Torvalds wrote:

> On Wed, Apr 18, 2018 at 3:37 PM, Robert Helling <***@atdotde.de> wrote:
> >
> > Couldn’t get the dive computer configuration to work either with BLE or classic.
>
> Did this work with the previous release (4.7.8 or whatever)?
>
> I had been hoping that I got the config thing right, but I've never
> used it or tested it (I'm not sure I even have any of the dive
> computers that are supported), so that was purely a "it builds".

I've tested it now, via the serial layer, libftdi layer, classic bt
layer, and with your latest patch BLE and they all work.

( I have a patch pending for fixing the ostc3 config code against firmware
2.97, that I should clean up and sed out to, any day now )


//Anton


--
Anton Lundin [phone]

[Linus Torvalds]

On Wed, Apr 25, 2018 at 10:38 AM, Anton Lundin <***@acc.umu.se> wrote:
>
> I've tested it now, via the serial layer, libftdi layer, classic bt
> layer, and with your latest patch BLE and they all work.

Ok, so for you the classic BT case now works too with that patch that
I sent out a couple of hours ago (the "supported transports" thing)?

This is the OSTC, I assume?

Now we just need somebody to test the Petrel 2. That's the one that I
hope that the patch from today finally fixes.

Linus

[Dirk Hohndel]

> On Apr 25, 2018, at 11:44 AM, Linus Torvalds <***@linux-foundation.org> wrote:
>
> On Wed, Apr 25, 2018 at 10:38 AM, Anton Lundin <***@acc.umu.se> wrote:
>>
>> I've tested it now, via the serial layer, libftdi layer, classic bt
>> layer, and with your latest patch BLE and they all work.
>
> Ok, so for you the classic BT case now works too with that patch that
> I sent out a couple of hours ago (the "supported transports" thing)?
>
> This is the OSTC, I assume?
>
> Now we just need somebody to test the Petrel 2. That's the one that I
> hope that the patch from today finally fixes.

I have a Petrel (single stack BT) and Petrel 2 (dual stack) and will test
those over lunch today. I'll try to test Mac and Android (embarrassingly,
I currently don't have a Linux laptop with working BLE...)

/D

[Willem Ferguson]

On 25/04/2018 20:51, Dirk Hohndel wrote:
>> On Apr 25, 2018, at 11:44 AM, Linus Torvalds <***@linux-foundation.org> wrote:
>>
>> On Wed, Apr 25, 2018 at 10:38 AM, Anton Lundin <***@acc.umu.se> wrote:
>>> I've tested it now, via the serial layer, libftdi layer, classic bt
>>> layer, and with your latest patch BLE and they all work.
>> Ok, so for you the classic BT case now works too with that patch that
>> I sent out a couple of hours ago (the "supported transports" thing)?
>>
>> This is the OSTC, I assume?
>>
>> Now we just need somebody to test the Petrel 2. That's the one that I
>> hope that the patch from today finally fixes.
> I have a Petrel (single stack BT) and Petrel 2 (dual stack) and will test
> those over lunch today. I'll try to test Mac and Android (embarrassingly,
> I currently don't have a Linux laptop with working BLE...)
>
> /D
This latest version appears not to be available on the download page
It says "last updated 6 days ago".

https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous-NG

Is this correct?

Kind regards,
willem


--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.

[Linus Torvalds]

On Wed, Apr 25, 2018 at 11:51 AM, Dirk Hohndel <***@hohndel.org> wrote:
>
> I have a Petrel (single stack BT) and Petrel 2 (dual stack) and will test
> those over lunch today. I'll try to test Mac and Android (embarrassingly,
> I currently don't have a Linux laptop with working BLE...)

Note that the magic channel/port number thing is Linux desktop-specific:

#if defined(Q_OS_LINUX) && !defined(Q_OS_ANDROID)

And it was literally the Petrel 2 that triggered that "try channel 5".

I have no idea how that is supposed to work, or what the crazy rules
about rfcomm ports even -are-. I'm just looking at the code, and going
"eww".

Also note that on Linux and Windows, we could just use the
libdivecomputer bluetooth backend that just uses the raw socket.

Also, Jef just uses port 0 for everything.

So the whole "port/channel" thing may be entirely pointless.

Linus

[Jef Driesen]

On 2018-04-25 22:12, Linus Torvalds wrote:
> On Wed, Apr 25, 2018 at 11:51 AM, Dirk Hohndel <***@hohndel.org>
> wrote:
>>
>> I have a Petrel (single stack BT) and Petrel 2 (dual stack) and will
>> test
>> those over lunch today. I'll try to test Mac and Android
>> (embarrassingly,
>> I currently don't have a Linux laptop with working BLE...)
>
> Note that the magic channel/port number thing is Linux
> desktop-specific:
>
> #if defined(Q_OS_LINUX) && !defined(Q_OS_ANDROID)
>
> And it was literally the Petrel 2 that triggered that "try channel 5".
>
> I have no idea how that is supposed to work, or what the crazy rules
> about rfcomm ports even -are-. I'm just looking at the code, and going
> "eww".
>
> Also note that on Linux and Windows, we could just use the
> libdivecomputer bluetooth backend that just uses the raw socket.
>
> Also, Jef just uses port 0 for everything.
>
> So the whole "port/channel" thing may be entirely pointless.

In the libdivecomputer rfcomm implementation, port 0 means
auto-detection. On linux it does an SDP discovery internally to find the
correct rfcomm port number, and on Windows it uses the rfcomm uuid
instead of the port number. That way, it should always just work. And on
the hardware I tested, it does indeed.

I also don't know the exact details on how these port numbers are
assigned. I guess it depends on the dive computer firmware and/or its
bluetooth stack. The valid range for rfcomm ports is 1-30 if I remember
correctly.

The Petrel is certainly not the only one which is using a different port
number. I'm currently testing the divecomputer.eu and it seems to use
port 6.

Jef

[Linus Torvalds]

On Thu, Apr 26, 2018 at 7:44 AM, Jef Driesen <***@libdivecomputer.org> wrote:
>
> I also don't know the exact details on how these port numbers are assigned.
> I guess it depends on the dive computer firmware and/or its bluetooth stack.
> The valid range for rfcomm ports is 1-30 if I remember correctly.
>
> The Petrel is certainly not the only one which is using a different port
> number. I'm currently testing the divecomputer.eu and it seems to use port
> 6.

Ok, sounds like we should use port 0 too.

And that really makes most of the special cases just go away. So a
patch like the attached.

Dirk? Anybody with an rfcomm device? Willing to test the attached
"remove all the crazy crud" patch?

Linus

[Willem Ferguson]

On 26/04/2018 18:21, Linus Torvalds wrote:
> On Thu, Apr 26, 2018 at 7:44 AM, Jef Driesen <***@libdivecomputer.org> wrote:
>> I also don't know the exact details on how these port numbers are assigned.
>> I guess it depends on the dive computer firmware and/or its bluetooth stack.
>> The valid range for rfcomm ports is 1-30 if I remember correctly.
>>
>> The Petrel is certainly not the only one which is using a different port
>> number. I'm currently testing the divecomputer.eu and it seems to use port
>> 6.
> Ok, sounds like we should use port 0 too.
>
> And that really makes most of the special cases just go away. So a
> patch like the attached.
>
> Dirk? Anybody with an rfcomm device? Willing to test the attached
> "remove all the crazy crud" patch?
>
> Linus
I tried this patch on V4.7.8-82

I get no download, errors.

Starting download from  BT
Starting the thread 0
Failed to connect to device  00:13:43:5B:8F:BE . Device state
QBluetoothSocket::UnconnectedState . Error:
QBluetoothSocket::UnknownSocketError
[4.755321] ERROR: No such file or directory (2) [in
../../src/serial_posix.c:295 (dc_serial_open)]
Finishing the thread Unable to open %s %s (%s) dives downloaded 0

Hope this helps to solve the rfcomm issue.

Kind regards,
willem


--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.

[Anton Lundin]

On 25 April, 2018 - Linus Torvalds wrote:

> On Wed, Apr 25, 2018 at 10:38 AM, Anton Lundin <***@acc.umu.se> wrote:
> >
> > I've tested it now, via the serial layer, libftdi layer, classic bt
> > layer, and with your latest patch BLE and they all work.
>
> Ok, so for you the classic BT case now works too with that patch that
> I sent out a couple of hours ago (the "supported transports" thing)?
>
> This is the OSTC, I assume?

The BT/BLE was tested against a dual stack OSTC4.


//Anton


--
Anton Lundin [phone]

[Chirana Gheorghita Eugeniu Theodor]

I would test but it seems that my tusa zen iq-900 isnot present in this
version of libdivecomputer (android)

On Thu, Apr 19, 2018, 00:01 Dirk Hohndel <***@hohndel.org> wrote:

>
> We now have binaries for Windows, Mac, and Linux (AppImage only) available
> in order for people to test this.
>
> https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous-NG
>
> /D
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>

[Dirk Hohndel]

On Thu, Apr 19, 2018 at 08:17:56AM +0000, Chirana Gheorghita Eugeniu Theodor wrote:
> I would test but it seems that my tusa zen iq-900 isnot present in this
> version of libdivecomputer (android)

That's odd. Which dive computers does it show as supported? Could you send
us the subsurface.log file (you can attach this to an email on your
Android device - it should be in the root of your storage device)

/D

[Chirana Gheorghita Eugeniu Theodor]

Here is it.

On Thu, Apr 19, 2018, 13:24 Dirk Hohndel <***@hohndel.org> wrote:

> On Thu, Apr 19, 2018 at 08:17:56AM +0000, Chirana Gheorghita Eugeniu
> Theodor wrote:
> > I would test but it seems that my tusa zen iq-900 isnot present in this
> > version of libdivecomputer (android)
>
> That's odd. Which dive computers does it show as supported? Could you send
> us the subsurface.log file (you can attach this to an email on your
> Android device - it should be in the root of your storage device)
>
> /D
>

[Dirk Hohndel]

> On Apr 19, 2018, at 1:42 PM, Chirana Gheorghita Eugeniu Theodor <***@adaptcom.ro> wrote:
>
> Here is it.

That's missing the listing of all the supported dive computers that we usually create at startup.
I'm confused. What else is new.

Let me investigate why that's the case...

/D

[Robert Helling]

Dirk,

> On 19. Apr 2018, at 14:34, Dirk Hohndel <***@hohndel.org> wrote:
>
> That's missing the listing of all the supported dive computers that we usually create at startup.
> I'm confused. What else is new.


isn’t this only logged in debug mode?

R.

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

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

[Dirk Hohndel]

> On Apr 19, 2018, at 3:31 PM, Robert Helling <***@atdotde.de> wrote:
>
> Dirk,
>
>> On 19. Apr 2018, at 14:34, Dirk Hohndel <***@hohndel.org <mailto:***@hohndel.org>> wrote:
>>
>> That's missing the listing of all the supported dive computers that we usually create at startup.
>> I'm confused. What else is new.
>
>
> isn’t this only logged in debug mode?

The way this is logged right now is broken. I just pushed a commit to the branch that hopefully fixes that.

/D

[Matt Thompson]

On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel <***@hohndel.org> wrote:

>
> We now have binaries for Windows, Mac, and Linux (AppImage only) available
> in order for people to test this.
>
> https://github.com/Subsurface-divelog/subsurface/releases/
> tag/continuous-NG
>
>
> I tested all three of my computers on Windows 10, macOS 10.13.4, and
Fedora 27.

My Aqualung i750TC worked correctly on all three platforms using the USB
cable.

My Atomic Cobalt2 worked on Windows and macOS but failed on Linux. I think
the failure on Linux is a configuration issue on my part but for
completeness I get the following in the console:
ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
(atomics_cobalt_device_open)]
INFO: dc_deveice_open error value of -6
I get that error on both Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
and Subsurface-4.7.8-x86_64.AppImage.

My Suunto D4i failed on all three platforms. It gave various errors on the
platforms:
Windows 10:
the red banner at the bottom of the main window with the message
"Unsupported operation"

Fedora: A message box with the message "Unable to open /dev/ttyUSB0" and a
message on the console "ERROR: Failed to receive the answer. [in
../../src/suunto_d9.c:253 (suunto_d9_device_packet)]

macOS: A message box with the message "Error downloading dive data"

[Jérémie Guichard]

Hey guys,

Just tried this build on Windows 10:
https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-NG/subsurface-4.7.8-73-ga12ea13d51f5.exe

With Scubapro G2 and Suunto Zoop over USB. Seems to work like a charm.

Jeremie

2018-04-20 9:56 GMT+07:00 Matt Thompson <***@gmail.com>:

>
>
> On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel <***@hohndel.org> wrote:
>
>>
>> We now have binaries for Windows, Mac, and Linux (AppImage only)
>> available in order for people to test this.
>>
>> https://github.com/Subsurface-divelog/subsurface/releases/ta
>> g/continuous-NG
>>
>>
>> I tested all three of my computers on Windows 10, macOS 10.13.4, and
> Fedora 27.
>
> My Aqualung i750TC worked correctly on all three platforms using the USB
> cable.
>
> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux. I
> think the failure on Linux is a configuration issue on my part but for
> completeness I get the following in the console:
> ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
> (atomics_cobalt_device_open)]
> INFO: dc_deveice_open error value of -6
> I get that error on both Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
> and Subsurface-4.7.8-x86_64.AppImage.
>
> My Suunto D4i failed on all three platforms. It gave various errors on
> the platforms:
> Windows 10:
> the red banner at the bottom of the main window with the message
> "Unsupported operation"
>
> Fedora: A message box with the message "Unable to open /dev/ttyUSB0" and
> a message on the console "ERROR: Failed to receive the answer. [in
> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
>
> macOS: A message box with the message "Error downloading dive data"
>
>
>
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>

[Murillo Bernardes]

Successfully downloaded dives on a Mac from:
- Oceanic OCi over USB
- Perdix AI over BLE

Murillo Bernardes

On Fri, Apr 20, 2018 at 1:05 PM, Jérémie Guichard <***@gmail.com>
wrote:

> Hey guys,
>
> Just tried this build on Windows 10: https://github.com/
> Subsurface-divelog/subsurface/releases/download/continuous-
> NG/subsurface-4.7.8-73-ga12ea13d51f5.exe
>
> With Scubapro G2 and Suunto Zoop over USB. Seems to work like a charm.
>
> Jeremie
>
> 2018-04-20 9:56 GMT+07:00 Matt Thompson <***@gmail.com>:
>
>>
>>
>> On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel <***@hohndel.org> wrote:
>>
>>>
>>> We now have binaries for Windows, Mac, and Linux (AppImage only)
>>> available in order for people to test this.
>>>
>>> https://github.com/Subsurface-divelog/subsurface/releases/ta
>>> g/continuous-NG
>>>
>>>
>>> I tested all three of my computers on Windows 10, macOS 10.13.4, and
>> Fedora 27.
>>
>> My Aqualung i750TC worked correctly on all three platforms using the USB
>> cable.
>>
>> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux. I
>> think the failure on Linux is a configuration issue on my part but for
>> completeness I get the following in the console:
>> ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
>> (atomics_cobalt_device_open)]
>> INFO: dc_deveice_open error value of -6
>> I get that error on both Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
>> and Subsurface-4.7.8-x86_64.AppImage.
>>
>> My Suunto D4i failed on all three platforms. It gave various errors on
>> the platforms:
>> Windows 10:
>> the red banner at the bottom of the main window with the message
>> "Unsupported operation"
>>
>> Fedora: A message box with the message "Unable to open /dev/ttyUSB0" and
>> a message on the console "ERROR: Failed to receive the answer. [in
>> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
>>
>> macOS: A message box with the message "Error downloading dive data"
>>
>>
>>
>> _______________________________________________
>> subsurface mailing list
>> ***@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>>
>
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>

[Jérémie Guichard]

Hi guys,

I just tried Scubapro G2 over bluetooth on Android build and it did not
work, but I must say this was already the case on Android for the normal
release.
This use case was working few month ago but cannot remember the version it
was.

I'm not sure it actually helps but I attached the log file.

Jeremie



2018-04-20 23:10 GMT+07:00 Murillo Bernardes <***@gmail.com>:

> Successfully downloaded dives on a Mac from:
> - Oceanic OCi over USB
> - Perdix AI over BLE
>
> Murillo Bernardes
>
> On Fri, Apr 20, 2018 at 1:05 PM, Jérémie Guichard <***@gmail.com>
> wrote:
>
>> Hey guys,
>>
>> Just tried this build on Windows 10: https://github.com/Subsurf
>> ace-divelog/subsurface/releases/download/continuous-NG/
>> subsurface-4.7.8-73-ga12ea13d51f5.exe
>>
>> With Scubapro G2 and Suunto Zoop over USB. Seems to work like a charm.
>>
>> Jeremie
>>
>> 2018-04-20 9:56 GMT+07:00 Matt Thompson <***@gmail.com>:
>>
>>>
>>>
>>> On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel <***@hohndel.org> wrote:
>>>
>>>>
>>>> We now have binaries for Windows, Mac, and Linux (AppImage only)
>>>> available in order for people to test this.
>>>>
>>>> https://github.com/Subsurface-divelog/subsurface/releases/ta
>>>> g/continuous-NG
>>>>
>>>>
>>>> I tested all three of my computers on Windows 10, macOS 10.13.4, and
>>> Fedora 27.
>>>
>>> My Aqualung i750TC worked correctly on all three platforms using the USB
>>> cable.
>>>
>>> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux. I
>>> think the failure on Linux is a configuration issue on my part but for
>>> completeness I get the following in the console:
>>> ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
>>> (atomics_cobalt_device_open)]
>>> INFO: dc_deveice_open error value of -6
>>> I get that error on both Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
>>> and Subsurface-4.7.8-x86_64.AppImage.
>>>
>>> My Suunto D4i failed on all three platforms. It gave various errors on
>>> the platforms:
>>> Windows 10:
>>> the red banner at the bottom of the main window with the message
>>> "Unsupported operation"
>>>
>>> Fedora: A message box with the message "Unable to open /dev/ttyUSB0"
>>> and a message on the console "ERROR: Failed to receive the answer. [in
>>> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
>>>
>>> macOS: A message box with the message "Error downloading dive data"
>>>
>>>
>>>
>>> _______________________________________________
>>> subsurface mailing list
>>> ***@subsurface-divelog.org
>>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>>
>>>
>>
>> _______________________________________________
>> subsurface mailing list
>> ***@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>>
>
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>

[Jef Driesen]

It looks like some data got transferred succesfully. But then the logging stops. Can you send the libdivecomputer logfile? That should give some more info. (I'm not sure whether android app supports saving libdc log.)

Jef

On April 22, 2018 12:52:48 PM GMT+02:00, "Jérémie Guichard" <***@gmail.com> wrote:
>Hi guys,
>
>I just tried Scubapro G2 over bluetooth on Android build and it did not
>work, but I must say this was already the case on Android for the
>normal
>release.
>This use case was working few month ago but cannot remember the version
>it
>was.
>
>I'm not sure it actually helps but I attached the log file.
>
>Jeremie
>
>
>
>2018-04-20 23:10 GMT+07:00 Murillo Bernardes <***@gmail.com>:
>
>> Successfully downloaded dives on a Mac from:
>> - Oceanic OCi over USB
>> - Perdix AI over BLE
>>
>> Murillo Bernardes
>>
>> On Fri, Apr 20, 2018 at 1:05 PM, Jérémie Guichard
><***@gmail.com>
>> wrote:
>>
>>> Hey guys,
>>>
>>> Just tried this build on Windows 10: https://github.com/Subsurf
>>> ace-divelog/subsurface/releases/download/continuous-NG/
>>> subsurface-4.7.8-73-ga12ea13d51f5.exe
>>>
>>> With Scubapro G2 and Suunto Zoop over USB. Seems to work like a
>charm.
>>>
>>> Jeremie
>>>
>>> 2018-04-20 9:56 GMT+07:00 Matt Thompson <***@gmail.com>:
>>>
>>>>
>>>>
>>>> On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel <***@hohndel.org>
>wrote:
>>>>
>>>>>
>>>>> We now have binaries for Windows, Mac, and Linux (AppImage only)
>>>>> available in order for people to test this.
>>>>>
>>>>> https://github.com/Subsurface-divelog/subsurface/releases/ta
>>>>> g/continuous-NG
>>>>>
>>>>>
>>>>> I tested all three of my computers on Windows 10, macOS 10.13.4,
>and
>>>> Fedora 27.
>>>>
>>>> My Aqualung i750TC worked correctly on all three platforms using
>the USB
>>>> cable.
>>>>
>>>> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux.
>I
>>>> think the failure on Linux is a configuration issue on my part but
>for
>>>> completeness I get the following in the console:
>>>> ERROR: Failed to open the usb device. [in
>../../src/atomics_cobalt.c:117
>>>> (atomics_cobalt_device_open)]
>>>> INFO: dc_deveice_open error value of -6
>>>> I get that error on both
>Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
>>>> and Subsurface-4.7.8-x86_64.AppImage.
>>>>
>>>> My Suunto D4i failed on all three platforms. It gave various
>errors on
>>>> the platforms:
>>>> Windows 10:
>>>> the red banner at the bottom of the main window with the message
>>>> "Unsupported operation"
>>>>
>>>> Fedora: A message box with the message "Unable to open
>/dev/ttyUSB0"
>>>> and a message on the console "ERROR: Failed to receive the answer.
>[in
>>>> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
>>>>
>>>> macOS: A message box with the message "Error downloading dive data"
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> subsurface mailing list
>>>> ***@subsurface-divelog.org
>>>>
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>>>
>>>>
>>>
>>> _______________________________________________
>>> subsurface mailing list
>>> ***@subsurface-divelog.org
>>>
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>>
>>>
>>
>> _______________________________________________
>> subsurface mailing list
>> ***@subsurface-divelog.org
>>
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>>

[Dirk Hohndel]

> On Apr 22, 2018, at 6:17 AM, Jef Driesen <***@libdivecomputer.org> wrote:
>
> It looks like some data got transferred succesfully. But then the logging stops. Can you send the libdivecomputer logfile? That should give some more info. (I'm not sure whether android app supports saving libdc log.)

It does, it's in the settings. And subsurface.log and libdivecomputer.log will be in the root of your storage device.
The latest beta builds actually show a few more interactions with the DC than earlier versions did.

/D

[Linus Torvalds]

On Sun, Apr 22, 2018 at 3:52 AM, Jérémie Guichard <***@gmail.com> wrote:
>
> I just tried Scubapro G2 over bluetooth on Android build and it did not
> work, but I must say this was already the case on Android for the normal
> release.

Hmm. I just tried my G2 over USB, and that worked fine.

But bluetooth connects and starts downloading the data fine, but then
it doesn't import:

Dive data import error dives downloaded 0

but I did get one "Failed to receive the packet" error. The BLE packet
handling is a _lot_ less reliable than serial is.

Hmm. I tried again, and it worked and downloaded all 78 dives on my G2.

So the bluetooth case works (at least on Linux desktop), it's just:

(a) really really damn slow, and you can't interrupt it in the middle
because it doesn't download one dive at a time

(b) fragile and does bad things if you get any BLE errors.

and that makes it less than wonderful (to the point of maybe being useless).

Jef, even when I already have all dives, the G2 download will
apparently just download the whole memory dump and then parse later.
That _really_ doesn't work very well. Is there no way to download one
dive at a time?

Linus

[Jef Driesen]

On 22-04-18 18:37, Linus Torvalds wrote:
> On Sun, Apr 22, 2018 at 3:52 AM, Jérémie Guichard <***@gmail.com> wrote:
>>
>> I just tried Scubapro G2 over bluetooth on Android build and it did not
>> work, but I must say this was already the case on Android for the normal
>> release.
>
> Hmm. I just tried my G2 over USB, and that worked fine.
>
> But bluetooth connects and starts downloading the data fine, but then
> it doesn't import:
>
> Dive data import error dives downloaded 0
>
> but I did get one "Failed to receive the packet" error. The BLE packet
> handling is a _lot_ less reliable than serial is.
>
> Hmm. I tried again, and it worked and downloaded all 78 dives on my G2.
>
> So the bluetooth case works (at least on Linux desktop), it's just:
>
> (a) really really damn slow, and you can't interrupt it in the middle
> because it doesn't download one dive at a time
>
> (b) fragile and does bad things if you get any BLE errors.
>
> and that makes it less than wonderful (to the point of maybe being useless).
>
> Jef, even when I already have all dives, the G2 download will
> apparently just download the whole memory dump and then parse later.
> That _really_ doesn't work very well. Is there no way to download one
> dive at a time?

No, the protocol doesn't support that. But it does support downloading only the
new dives. Unfortunately, the only way to take advantage of that is by means of
the libdivecomputer fingerprint feature.

This is actually one of those cases where trying to implement the download only
new dives feature entirely on the application side (without using the
fingerprint feature) will always be inefficient. That's because the protocol
works a bit different here. Unlike most other dive computers, it's the dive
computer that does the work. You need to send a timestamp (of the most recent
previously download dive) to the dive computer, and then the dive computer will
only send back the newer dives.

The result is that if you don't use the fingerprint feature, then you will
always request ALL dives And once you have all dives, you can ignore the ones
you already had. But at that point you have already downloaded them all.

Jef

[Dirk Hohndel]

> On Apr 22, 2018, at 12:22 PM, Jef Driesen <***@libdivecomputer.org> wrote:
>
> No, the protocol doesn't support that. But it does support downloading only the new dives. Unfortunately, the only way to take advantage of that is by means of the libdivecomputer fingerprint feature.
>
> This is actually one of those cases where trying to implement the download only new dives feature entirely on the application side (without using the fingerprint feature) will always be inefficient. That's because the protocol works a bit different here. Unlike most other dive computers, it's the dive computer that does the work. You need to send a timestamp (of the most recent previously download dive) to the dive computer, and then the dive computer will only send back the newer dives.
>
> The result is that if you don't use the fingerprint feature, then you will always request ALL dives And once you have all dives, you can ignore the ones you already had. But at that point you have already downloaded them all.

I know we initially didn't use the fingerprint (5 or so years ago) because back then something was broken with it.
Linus, is there still a design reason why we can't use it? Because that sounds like a HUGE inefficiency for dive computers like the G2 over BLE...

/D

[Linus Torvalds]

On Sun, Apr 22, 2018, 12:42 Dirk Hohndel <***@hohndel.org> wrote:

>
> I know we initially didn't use the fingerprint (5 or so years ago) because
> back then something was broken with it.
> Linus, is there still a design reason why we can't use it?


It still has the exact same problem it always had: it's random binary data
that we'd have to encode some way.

In practice, I suspect it's always just a number, but the interface is
nasty.

It would be much better as a string. Of course. Now it can be anything, so
even if it's a string we'd have to encode it somehow.

And for most dive computers it's pure garbage, and it's impossible to tell
which dive computer it actually matters for. So you have to encode this
garbage whether it's useful or not.

Linus

Linus

[Dirk Hohndel]

> On Apr 22, 2018, at 1:09 PM, Linus Torvalds <***@linux-foundation.org> wrote:
>
>
>
> On Sun, Apr 22, 2018, 12:42 Dirk Hohndel <***@hohndel.org <mailto:***@hohndel.org>> wrote:
>
> I know we initially didn't use the fingerprint (5 or so years ago) because back then something was broken with it.
> Linus, is there still a design reason why we can't use it?
>
> It still has the exact same problem it always had: it's random binary data that we'd have to encode some way.
>
> In practice, I suspect it's always just a number, but the interface is nasty.
>
> It would be much better as a string. Of course. Now it can be anything, so even if it's a string we'd have to encode it somehow.
>
> And for most dive computers it's pure garbage, and it's impossible to tell which dive computer it actually matters for. So you have to encode this garbage whether it's useful or not.

You make it sound so wonderful... libdivecomputer returns a char * and a size to us - which is different for different dive computers. Lovely.
So all we can do is store the size and base64 encode the binary data that we get.

Yeah, it's ugly, but it should make a huge difference in BLE download speed if I understand correctly what's going on.

/D

[Linus Torvalds]

On Sun, Apr 22, 2018 at 1:19 PM, Dirk Hohndel <***@hohndel.org> wrote:
>
> Yeah, it's ugly, but it should make a huge difference in BLE download speed
> if I understand correctly what's going on.

The whole thing is basically completely mis-designed and retarded. On
most dive computers it actually is *worse* than what we do right now.

It also depends on actually remembering the fingerprint, and giving it
back to the right device. Which is hard to begin with, since you don't
get the proper serial number from libdivecomputer, so it's not even
easy to know which fingerprint to use.

So now you have to remember garbage that is irrelevant in 99% of all
cases, that is ugly random data that could be any size, and that you
have to then also match up with the right dive computer based on other
garbage data that isn't even reliable.

Really?

I really don't want to touch it with a ten-foot pole.

Linus

[Linus Torvalds]

On Mon, Apr 23, 2018 at 12:56 AM, Sébastien Dugué
<***@gmail.com> wrote:
> On Sun, Apr 22, 2018 at 10:09 PM, Linus Torvalds
> <***@linux-foundation.org> wrote:
>>
>> It still has the exact same problem it always had: it's random binary data
>> that we'd have to encode some way.
>
> Well, it's not so random. It's in fact a timestamp in the DC format which
> specifies from which dive we wish to download.

I wish that was the case. It's not.

It's a timestamp on _some_ dive computers. On others, it's other random data.

On most dive computers, it's 4 bytes, on others it's 5-6, and on some
it's 16 bytes of random binary data.

On many dive computers it's entirely pointless (yes, yes, you may be
able to avoid downloading that one last dive), but they still have a
fingerprint, and there's no way to know "don't bother".

So to really get it right and download the least amount of dives you have to:

- encode this insane random binary data without knowing what it is

- also encode the insane garbage "serial number" (that isn't actually
a valid serial number at all, and hasn't even been stable across
libdivecomputer versions)

- then before downloading, match the garbage serial number and
vendor/device string to find the last dive with that dive computer, in
order to find the other garbage random binary data

honestly, it's nasty nasty nasty.

What we *could* do is to do it knowingly wrong, the way dctool does
it: don't save the fingerprint data with the real dive data at all,
just have a random "last download" cache indexed by device family and
serial number.

That's how the feature is designed to be used, and it would avoid the
nasty "pollute our logs with meaningless and badly defined crazy data
that will never be useful in the future".

"So why don't you do that, then?" I hear you say.

It's probably the best approach, and works fine if you just always
download from the same device (because the cache would be specific to
the installation, not be part of our dive data). And when it doesn't
work, arguably we wouldn't be in any worse condition that we already
are in (ie "download everything" from the devices that can't download
dives one by one), so why not?

The "why not" is because it makes re-downloading dives much nastier.
If you actually want to re-download dives (maybe because you didn't
save the dives after the last download due to some other problem?) you
now need a way to clear the cache data. And the "download all dives"
thing could do that, but then you wouldn't have the existing "don't
duplicate dives" that we *currently* have.

But it also means that when you download from the same dive computer
on a different device (ie your phone vs your laptop), you'll get get
potentiall ydifferent results. It can be very confusing.

So it's a hack, but it might be acceptable. As long as I don't have to
save that stupid fingerprint - and that broken serial number that
isn't - in the logs, I'm certainly happier with it.

Linus

[Linus Torvalds]

On Mon, Apr 23, 2018 at 10:07 AM, Linus Torvalds
<***@linux-foundation.org> wrote:
>
> What we *could* do is to do it knowingly wrong, the way dctool does
> it: don't save the fingerprint data with the real dive data at all,
> just have a random "last download" cache indexed by device family and
> serial number.
>
> That's how the feature is designed to be used, and it would avoid the
> nasty "pollute our logs with meaningless and badly defined crazy data
> that will never be useful in the future".

So here's a patch for people to play with if they want to.

This is literally how the fingerprint thing is meant to be used, and
it works, but it's a bit dangerous.

It's dangerous because the rule is "once we've downloaded the dives on
one machine, we don't want to download them again".

You can see the breakage by:

(a) applying this patch

(b) downloading some dives into a new empty xml file, or as a
different user (so that you actually download things)

(c) *NOT* saving the end result, closing subsurface

(d) opening subsurface again with the same empt xml file, and trying
to download

At that point, the fingerprint code says "I've already downloaded all
the dives on this machine, so you have nothing new to download".

Which is exactly how the feature is designed, so hey, it's doing what
it meant to do. You don't want to re-download the same dives over and
over again, do you?

And if you *do* want to re-download them, you'd better just check the
"Force download all dives" checkbox.

Note that this patch saves the fingerprint in the downloader. It would
probably be better to at *least* wait until the user has pressed "ok"
with the most recent dive checked. That still doesn't mean "saved",
but it's a lot closer.

This has been very lightly tested, and did the right thing with my Perdix AI.

Linus

[Robert Helling]

Hi,

not that really followed this and have anything significant to say about dive computer download but


> On 23. Apr 2018, at 20:57, Linus Torvalds <***@linux-foundation.org> wrote:
>
> It's dangerous because the rule is "once we've downloaded the dives on
> one machine, we don't want to download them again".
>
> You can see the breakage by:

and you know the obvious solution: store a random base64 encoded string (containing what libdc thinks is the „serial number“ and the „fingerprint“) with the dive computer field for a dive. Even if that is and additional 100 bytes it will not significantly bloat our files. And if you don’t want this information in the dive, store your hash table of latest dives in the log, as it is specific to the log and not the machine. I have great respect for your opinion on aesthetic views but here it seems to stop us from doing the right thing.

Of course it would be great if libdc provided the information for which dive computers this is worthwhile doing (where it prevents downloading the whole log).

Just my $.02

Robert

[Linus Torvalds]

On Mon, Apr 23, 2018 at 6:45 PM, Robert Helling <***@atdotde.de> wrote:
>
> and you know the obvious solution: store a random base64 encoded string

Yeah, no.

I will not do stupid things just because libdivecomputer has a moronic
interface.

Out data format is more important than this fingerprint braindamage.

Linus

[Linus Torvalds]

On Tue, Apr 24, 2018 at 5:27 AM, Sébastien Dugué
<***@gmail.com> wrote:
> On Mon, Apr 23, 2018 at 7:07 PM, Linus Torvalds <***@linux-foundation.org> wrote:
>>
>> On most dive computers, it's 4 bytes, on others it's 5-6, and on some
>> it's 16 bytes of random binary data.
>
> My bad, I assumed that feature was only present in the Uwatec DCs where it's
> a timestamp.
>
> And I cannot imagine how something else might be useful for that purpose...

Well, the fingerprint can anything, which is part of the problem. It
can be an offset into the dive computer buffer. It could be just an
index into the dive computer dive table. It could be the first few
bytes of the dive download that contains the unparsed dive data (which
probably *includes* the dive date, but can have a internal dive
computer dive number)

So in practice it really is random data, and it's not useful to
subsurface directly. We actually do use it to generate a "dive ID"
(that is used to check for duplicates), but that is a fairly simple
and well-defined thing (it's the first four bytes of a SHA1 hash -
either of the fingerprint data, or if the dive computer gives a
particular "Dive ID" string.

And I *really* don't want to save it to our dive logs, because it's
not useful long-term. It's not useful to a user, but it's not even
useful to subsurface long term - only the last dive matters. So saving
it for every dive is fundamentally wrong - it's not how it would ever
be used.

But I think I've come up with an approach that is viable, exactly
*because* we do have a dive ID anyway. We can save the fingerprint
*and* the dive ID in the cache file, and then when we *use* the
fingerprint, we just verify that we have a dive that matches the dive
ID associated with that fingerprint.

So at worst, we'll never use the fingerprint at all, because the last
time somebody did a download, they didn't save the dives (or maybe
they just did't save them into the file we're now using, or didn't
save the *last* dive or whatever).

But then we're no worse off than we are now.

And if we *do* have the dive that is associated with the fingerprint,
then we'll use it, and only download new dives up until that point.

The attached patch seems to work in my (very limited!) testing.

Testers welcome. It should apply fine to any modern subsurface tree
(ie you don't have to have the "NG" branch, but it won't hurt, and
it's what I tested and used as a base).

Linus

[Willem Ferguson]

I thought I should attach the log of my BT download from a Petrel 2.

Initial handshaking took maybe 40s, showing error message in red bar at
bottom of screen "Timeout"

But, if not interrupted, the download proceeded perfectly shortly after
the timeout message and download exited normally on the GUI.

Desktop$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
Starting download from  BT
Starting the thread 0
Bluez 5 detected.
Enabling GATT request timeout behavior 20000
qt_ble_open( 00:13:43:5B:8F:BE )
Creating default GAP/GATT services
Missing CAP_NET_ADMIN permission. Cannot determine whether a found
address is of random or public type.
addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller 00:13:43:5B:8F:BE
void QBluetoothSocketPrivate::_q_readNotify() 28 error: -1 "Resource
temporarily unavailable"
Connection on channel 1 failed. Trying on channel number 5.
INFO: dc_device_open error value of 0
Finishing the thread  dives downloaded 11

Kind regards,

willem





--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.

[Linus Torvalds]

On Tue, Apr 24, 2018 at 11:03 AM, Willem Ferguson
<***@zoology.up.ac.za> wrote:
>
> Initial handshaking took maybe 40s, showing error message in red bar at
> bottom of screen "Timeout"

Hmm. It looks like it first tried to do a BLE download, and that
failed (and this is what took a longish time).

And then because of the failure, it fell back on old-style BT rfcomm, and:

> But, if not interrupted, the download proceeded perfectly shortly after the
> timeout message and download exited normally on the GUI.

.. apparently rfcomm works for you and the fallback was successful.

Has BLE ever worked for you?

Linus

[Willem Ferguson]

On 24/04/2018 20:08, Linus Torvalds wrote:
> On Tue, Apr 24, 2018 at 11:03 AM, Willem Ferguson
> <***@zoology.up.ac.za> wrote:
>> Initial handshaking took maybe 40s, showing error message in red bar at
>> bottom of screen "Timeout"
> Hmm. It looks like it first tried to do a BLE download, and that
> failed (and this is what took a longish time).
>
> And then because of the failure, it fell back on old-style BT rfcomm, and:
>
>> But, if not interrupted, the download proceeded perfectly shortly after the
>> timeout message and download exited normally on the GUI.
> .. apparently rfcomm works for you and the fallback was successful.
>
> Has BLE ever worked for you?

NOPE

I did the same download by setting the dropdown option in the BT setup
panel to 'Force Classical'. Took about 25 sec to do handshaking, still
getting "Timeout while trying to connect". Does not appear to make
difference and successful end result is same as previously, downloading
all my dives. Interesting error message at end of log. I have never
managed to get the BLE working. My Petrel is pretty recent, so I am
reasonably sure it can do both. But the user manual and the Shearwater
website does not provide any insight into this.

Desktop$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
can't find Subsurface localization for locale "en-ZA"
Missing CAP_NET_ADMIN permission. Cannot determine whether a found
address is of random or public type.
Starting download from  BT
Starting the thread 0
Enabling GATT request timeout behavior 20000
qt_ble_open( 00:13:43:5B:8F:BE )
Creating default GAP/GATT services
addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller 00:13:43:5B:8F:BE
void QBluetoothSocketPrivate::_q_readNotify() 28 error: -1 "Resource
temporarily unavailable"
Connection on channel 1 failed. Trying on channel number 5.
INFO: dc_device_open error value of 0
[39.400513] ERROR: Failed to download the dive. [in
../../src/shearwater_petrel.c:330 (shearwater_petrel_device_foreach)]
Finishing the thread Dive data import error dives downloaded 9

Kind regards,

willem



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.

[Willem Ferguson]

On 24/04/2018 20:08, Linus Torvalds wrote:
> On Tue, Apr 24, 2018 at 11:03 AM, Willem Ferguson
> <***@zoology.up.ac.za> wrote:
>> Initial handshaking took maybe 40s, showing error message in red bar at
>> bottom of screen "Timeout"
> Hmm. It looks like it first tried to do a BLE download, and that
> failed (and this is what took a longish time).
>
> And then because of the failure, it fell back on old-style BT rfcomm, and:
>
>> But, if not interrupted, the download proceeded perfectly shortly after the
>> timeout message and download exited normally on the GUI.
> .. apparently rfcomm works for you and the fallback was successful.
>
> Has BLE ever worked for you?

NOPE

I did the same download by setting the dropdown option in the BT setup
panel to 'Force Classical'. Took about 25 sec to do handshaking, still
getting "Timeout while trying to connect". Does not appear to make
difference and successful end result is same as previously, downloading
all my dives. Interesting error message at end of log. I have never
managed to get the BLE working. My Petrel is pretty recent, so I am
reasonably sure it can do both. But the user manual and the Shearwater
website does not provide any insight into this.

Desktop$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
can't find Subsurface localization for locale "en-ZA"
Missing CAP_NET_ADMIN permission. Cannot determine whether a found
address is of random or public type.
Starting download from  BT
Starting the thread 0
Enabling GATT request timeout behavior 20000
qt_ble_open( 00:13:43:5B:8F:BE )
Creating default GAP/GATT services
addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller 00:13:43:5B:8F:BE
void QBluetoothSocketPrivate::_q_readNotify() 28 error: -1 "Resource
temporarily unavailable"
Connection on channel 1 failed. Trying on channel number 5.
INFO: dc_device_open error value of 0
[39.400513] ERROR: Failed to download the dive. [in
../../src/shearwater_petrel.c:330 (shearwater_petrel_device_foreach)]
Finishing the thread Dive data import error dives downloaded 9

Kind regards,

willem



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.

[Linus Torvalds]

On Tue, Apr 24, 2018 at 11:25 AM, Willem Ferguson
<***@zoology.up.ac.za> wrote:
>
> I did the same download by setting the dropdown option in the BT setup panel
> to 'Force Classical'.

The new code just ignores the classic/ble/auto setting right now.

I'd rather do it using the "dc_transports" model that we now use for
everything else anyway, the old model was totally different.

> Interesting error message at end of log. I have never managed to get the BLE
> working. My Petrel is pretty recent, so I am reasonably sure it can do both.

The Shearwater dive computers can be temperamental when it comes to BLE.

I've never used the rfcomm thing (my Perdix AI doesn't support it),
but the BLE works reliably for me - once it has connected once. But
getting it to connect that first time can be a crap-shoot.

So the Shearwater BLE code seems to have some history, and probably
remembers who it paired with last or something. And apparently you
have never been able to get it to get to that paired state.

Linus

[Long, Martin]

The BLE thing has basically made subsurface unusable for me for the last
month or so. Oddly, it works fine with my Perdix AI, but not with the
dual-stack Petrel 2 that's wired up to my rebreather - last time I was able
to use it was when I was able to select and force the legacy BT stack.

Does this branch expose both addresses again? If so I might have to fire up
the build environment again.

[Chirana Gheorghita Eugeniu Theodor]

Hmm very weird.
I use now latest 4.7.8 and successfully connects to Petrel 1 but will not
connect to mh older tusa zen iq-900 over usb ftdi.

On Wed, Apr 25, 2018, 10:26 Long, Martin <***@longhome.co.uk> wrote:

> The BLE thing has basically made subsurface unusable for me for the last
> month or so. Oddly, it works fine with my Perdix AI, but not with the
> dual-stack Petrel 2 that's wired up to my rebreather - last time I was able
> to use it was when I was able to select and force the legacy BT stack.
>
> Does this branch expose both addresses again? If so I might have to fire
> up the build environment again.
>
>
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>

[Long, Martin]

On 25 April 2018 at 09:07, Chirana Gheorghita Eugeniu Theodor <
***@adaptcom.ro> wrote:

> Hmm very weird.
> I use now latest 4.7.8 and successfully connects to Petrel 1 but will not
> connect to mh older tusa zen iq-900 over usb ftdi.
>

It's likely to connect to Petrel one because it is single (legacy) stack
with no BLE. However, Petrel 2, being dual stack, means subsurface only
offers BLE, which is the broken bit.

[Chirana Gheorghita Eugeniu Theodor]

Ok ... than i can confirm that for perdix does not work either. One of my
friends tested the official release

On Wed, Apr 25, 2018, 11:43 Long, Martin <***@longhome.co.uk> wrote:

>
> On 25 April 2018 at 09:07, Chirana Gheorghita Eugeniu Theodor <
> ***@adaptcom.ro> wrote:
>
>> Hmm very weird.
>> I use now latest 4.7.8 and successfully connects to Petrel 1 but will not
>> connect to mh older tusa zen iq-900 over usb ftdi.
>>
>
> It's likely to connect to Petrel one because it is single (legacy) stack
> with no BLE. However, Petrel 2, being dual stack, means subsurface only
> offers BLE, which is the broken bit.
>

[Pedro Neves]

Hi all:

I've just tested downloading from my Scubapro G2 using the latest master
built with libdivecomputer v0.7.0-devel-Subsurface-NG. It failed the
first time, but worked fine at the second attempt.

Now I'd like to test downloading from G2 using USB.

@ Linus: my sytem (Arch Linux) detects the G2 :

usb 1-10: new full-speed USB device number 6 using xhci_hcd
[ 3494.833727] usb 1-10: New USB device found, idVendor=2e6c, idProduct=3201
[ 3494.833730] usb 1-10: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 3494.833732] usb 1-10: Product: G2 dive computer
[ 3494.833733] usb 1-10: Manufacturer: Uwatec AG
[ 3494.833734] usb 1-10: SerialNumber: xxxxxxxxxxxx
[ 3494.835381] hid-generic 0003:2E6C:3201.0004: hiddev2,hidraw3: USB HID
v1.00 Device [Uwatec AG G2 dive computer] on usb-0000:00:14.0-10/input0

But fails to add an interface for it. Have you used the USB connection
to download data from your G2? Any hints?

Cheers:

Pedro

[Linus Torvalds]

On Thu, Apr 26, 2018 at 2:29 AM, Pedro Neves <***@gmail.com> wrote:
>
> @ Linus: my sytem (Arch Linux) detects the G2 :
>
> usb 1-10: new full-speed USB device number 6 using xhci_hcd
> [ 3494.833727] usb 1-10: New USB device found, idVendor=2e6c, idProduct=3201
> [ 3494.833730] usb 1-10: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 3494.833732] usb 1-10: Product: G2 dive computer
> [ 3494.833733] usb 1-10: Manufacturer: Uwatec AG
> [ 3494.833734] usb 1-10: SerialNumber: xxxxxxxxxxxx
> [ 3494.835381] hid-generic 0003:2E6C:3201.0004: hiddev2,hidraw3: USB HID
> v1.00 Device [Uwatec AG G2 dive computer] on usb-0000:00:14.0-10/input0
>
> But fails to add an interface for it.

All you need is the raw usb device, something like

/dev/bus/usb/001/010

and you need to have access rights to it.

> Have you used the USB connection to
> download data from your G2? Any hints?

Yup, it "JustWorks(tm)" for me.

But you need to have an udev rule to make sure you can access it. Something like

SUBSYSTEM=="usb",ATTR{idVendor}=="2e6c",ATTR{idProduct}=="3201",MODE="0666"

in a udev rule file. I'm not sure where Arch Linux keeps its udev
rules, but usually it's one (or both) of

/etc/udev/rules.d
/usr/lib/udev/rules.d/

and after you've created your own file (call it "91-Scubapro-G2.udev"
or something, you need to make sure udev knows about the new rules (no
need to reboot, do "udevadm control --reload").

Oh. Or just do some googling. This looks like the proper docs:

https://wiki.archlinux.org/index.php/udev

and obviously you can do better than MODE="0666" that just gives
everybody access. Some distros have a "plugdev" group that console
users get added to, but you can do anything like just making you the
owner (USER="nevesdiver" in the udev rule) etc.

Linus

[Pedro Neves]

On 26-04-2018 17:08, Linus Torvalds wrote:
> Oh. Or just do some googling. This looks like the proper docs:
>
> https://wiki.archlinux.org/index.php/udev
>
> and obviously you can do better than MODE="0666" that just gives
> everybody access. Some distros have a "plugdev" group that console
> users get added to, but you can do anything like just making you the
> owner (USER="nevesdiver" in the udev rule) etc.

Linus:

Thanks for the detailed explanations. I created the rule and all is good.
The usb download is so much faster than the bluetooth...

Cheers:

Pedro

[Jef Driesen]

On 2018-04-23 19:07, Linus Torvalds wrote:
> On Mon, Apr 23, 2018 at 12:56 AM, Sébastien Dugué
> <***@gmail.com> wrote:
>> On Sun, Apr 22, 2018 at 10:09 PM, Linus Torvalds
>> <***@linux-foundation.org> wrote:
>>>
>>> It still has the exact same problem it always had: it's random binary
>>> data
>>> that we'd have to encode some way.
>>
>> Well, it's not so random. It's in fact a timestamp in the DC format
>> which
>> specifies from which dive we wish to download.
>
> I wish that was the case. It's not.
>
> It's a timestamp on _some_ dive computers. On others, it's other random
> data.
>
> On most dive computers, it's 4 bytes, on others it's 5-6, and on some
> it's 16 bytes of random binary data.
>
> On many dive computers it's entirely pointless (yes, yes, you may be
> able to avoid downloading that one last dive), but they still have a
> fingerprint, and there's no way to know "don't bother".
>
> So to really get it right and download the least amount of dives you
> have to:
>
> - encode this insane random binary data without knowing what it is
>
> - also encode the insane garbage "serial number" (that isn't actually
> a valid serial number at all, and hasn't even been stable across
> libdivecomputer versions)
>
> - then before downloading, match the garbage serial number and
> vendor/device string to find the last dive with that dive computer, in
> order to find the other garbage random binary data
>
> honestly, it's nasty nasty nasty.
>
> What we *could* do is to do it knowingly wrong, the way dctool does
> it: don't save the fingerprint data with the real dive data at all,
> just have a random "last download" cache indexed by device family and
> serial number.
>
> That's how the feature is designed to be used, and it would avoid the
> nasty "pollute our logs with meaningless and badly defined crazy data
> that will never be useful in the future".
>
> "So why don't you do that, then?" I hear you say.
>
> It's probably the best approach, and works fine if you just always
> download from the same device (because the cache would be specific to
> the installation, not be part of our dive data). And when it doesn't
> work, arguably we wouldn't be in any worse condition that we already
> are in (ie "download everything" from the devices that can't download
> dives one by one), so why not?
>
> The "why not" is because it makes re-downloading dives much nastier.
> If you actually want to re-download dives (maybe because you didn't
> save the dives after the last download due to some other problem?) you
> now need a way to clear the cache data. And the "download all dives"
> thing could do that, but then you wouldn't have the existing "don't
> duplicate dives" that we *currently* have.
>
> But it also means that when you download from the same dive computer
> on a different device (ie your phone vs your laptop), you'll get get
> potentiall ydifferent results. It can be very confusing.
>
> So it's a hack, but it might be acceptable. As long as I don't have to
> save that stupid fingerprint - and that broken serial number that
> isn't - in the logs, I'm certainly happier with it.

The fingerprint usually contains the raw date/time data, but it depends
on the dive computer. Why should the application need to know what's
inside? It only needs to store the data somewhere until the next
download.

Using something less arbitrary for the fingerprint data, like a hash
over the dive data or even the date/time of the dive, doesn't work.
There are several reasons for that:

1. As explained before, the Uwatec/Scubapro protocol requires sending
the timestamp to the dive computer. That already rules out the use of a
hash, because we can't retrieve the timestamp back from the hash. Even
using the date/time is tricky here, because this timestamp should be
relative to the device clock, not the host clock. Since some of those
devices rely on the host clock for parsing the date/time, that means you
would have to store those values as well. Using the raw dive timestamp
as the fingerprint doesn't have those problems.

2. Many dive computer protocols support downloading some kind of index
with a summary of the available dives. That allows libdivecomputer to
check the fingerprint and decide which dives need to be downloaded
before actually downloading the dive. That's not only a bit more
efficient, but it also allows to deliver much more accurate progress
events. That improves the user experience. So this is not only about
being a little bit faster. But this is only possible if libdivecomputer
can use whatever information is available in the index that can uniquely
identify a single dive, and that's of course different for each
protocol. Hence the need to use arbitrary data.

So even if you don't really care about this last argument, then how
would you handle the first one?


The only alternative solution that I can think of is to replace the
fingerprint with the raw dive data itself. That way, the feature would
still work exactly the same as before, but with the entire dive as the
fingerprint. Internally libdivecomputer can still extract and use
whatever piece of info it needs for its implementation. The disadvantage
is that you now need to store the entire dive (which is a lot larger
than just the fingerprint), but at least it's some more meaningful data.


Note that some of your other remarks are indeed valid. But the
fingerprint feature was designed only to download the new dives. Nothing
more, nothing less. Additional logic to detect duplicates and other more
advanced stuff, belongs in the application. This kind of logic is
certainly not mutually exclusive with the fingerprint feature.
Libdivecomputer can't even do that kind of stuff because it has no
access to your previously downloaded dives. The fingerprint of the most
recent dive is all it needs.


The serial number is encoded as a number for historic reasons. I'm well
aware of that, and it's already on my todo list to take care of that.
There is need to bring that up every time.


Jef

[Jef Driesen]

On 2018-04-20 04:56, Matt Thompson wrote:
> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux. I
> think
> the failure on Linux is a configuration issue on my part but for
> completeness I get the following in the console:
> ERROR: Failed to open the usb device. [in
> ../../src/atomics_cobalt.c:117
> (atomics_cobalt_device_open)]
> INFO: dc_deveice_open error value of -6
> I get that error on both
> Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
> and Subsurface-4.7.8-x86_64.AppImage.

This looks like a permission error. Have you installed the necessary
udev rules?

Download this file:

https://raw.githubusercontent.com/libdivecomputer/libdivecomputer/master/contrib/udev/libdivecomputer.rules

and copy it to /etc/udev/rules.d/ directory.

(This assumes you are in the plugdev group.)

> My Suunto D4i failed on all three platforms. It gave various errors on
> the
> platforms:
> Windows 10:
> the red banner at the bottom of the main window with the message
> "Unsupported operation"

Difficult to tell without further info. Did you install the USB driver?

> Fedora: A message box with the message "Unable to open /dev/ttyUSB0"
> and a
> message on the console "ERROR: Failed to receive the answer. [in
> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]

Looks again like a permission error. Make sure you're in the dialout
group:

sudo usermod -a -G dialout $USER

(You'll have to logout and login again before this takes effect.)

> macOS: A message box with the message "Error downloading dive data"

No idea.

Jef

[Matt Thompson]

Thanks, Jef.

On Mon, Apr 23, 2018 at 4:59 AM, Jef Driesen <***@libdivecomputer.org>
wrote:

> On 2018-04-20 04:56, Matt Thompson wrote:
>
>> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux. I
>> think
>> the failure on Linux is a configuration issue on my part but for
>> completeness I get the following in the console:
>> ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
>> (atomics_cobalt_device_open)]
>> INFO: dc_deveice_open error value of -6
>> I get that error on both Subsurface-4.7.8-73-ga12ea13d5
>> 1f5-x86_64.AppImage
>> and Subsurface-4.7.8-x86_64.AppImage.
>>
>
> This looks like a permission error. Have you installed the necessary udev
> rules?
>
> I added the udev rule in the Subsurface FAQ but it didn't help. Tonight
I'll try the one you pointed me at below and post back.

Download this file:
>
> https://raw.githubusercontent.com/libdivecomputer/libdivecom
> puter/master/contrib/udev/libdivecomputer.rules
>
> and copy it to /etc/udev/rules.d/ directory.
>
> (This assumes you are in the plugdev group.)
>
> My Suunto D4i failed on all three platforms. It gave various errors on the
>> platforms:
>> Windows 10:
>> the red banner at the bottom of the main window with the message
>> "Unsupported operation"
>>
>
> Difficult to tell without further info. Did you install the USB driver?
>
> Fedora: A message box with the message "Unable to open /dev/ttyUSB0" and a
>> message on the console "ERROR: Failed to receive the answer. [in
>> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
>>
>
> Looks again like a permission error. Make sure you're in the dialout group:
>
> sudo usermod -a -G dialout $USER
>
> (You'll have to logout and login again before this takes effect.)
>
> macOS: A message box with the message "Error downloading dive data"
>>
>
> No idea.
>
> I do have the USB drivers for the D4i installed on macOS and Windows. On
all three platforms I was able to successfully download dives using
Subsurface 4.7.8. I take that to mean that I have the correct permissions
on the platforms so it is just down to the difference between the -NG and
4.7.8 branches. I can generate Subsurface and libdivecomputer logs if that
would help.

Thanks,
-Matt

[Dirk Hohndel]

> On Apr 23, 2018, at 7:43 AM, Matt Thompson <***@gmail.com> wrote:

> I do have the USB drivers for the D4i installed on macOS and Windows. On all three platforms I was able to successfully download dives using Subsurface 4.7.8. I take that to mean that I have the correct permissions on the platforms so it is just down to the difference between the -NG and 4.7.8 branches. I can generate Subsurface and libdivecomputer logs if that would help.

This is the logic that I care the most about.
If you have situations where 4.7.8 can successfully download, but NG cannot, then I want to see the Subsurface and libdivecomputer logs and understand why that is the case so we can fix this.
I am very eager to get NG merged into master, but not at the cost of significant regressions.

/D

[Matt Thompson]

On Mon, Apr 23, 2018 at 9:51 AM, Dirk Hohndel <***@hohndel.org> wrote:

>
> > On Apr 23, 2018, at 7:43 AM, Matt Thompson <***@gmail.com> wrote:
>
> > I do have the USB drivers for the D4i installed on macOS and Windows.
> On all three platforms I was able to successfully download dives using
> Subsurface 4.7.8. I take that to mean that I have the correct permissions
> on the platforms so it is just down to the difference between the -NG and
> 4.7.8 branches. I can generate Subsurface and libdivecomputer logs if that
> would help.
>
> This is the logic that I care the most about.
> If you have situations where 4.7.8 can successfully download, but NG
> cannot, then I want to see the Subsurface and libdivecomputer logs and
> understand why that is the case so we can fix this.
> I am very eager to get NG merged into master, but not at the cost of
> significant regressions.
>
> /D
>
> I'll generate the logs this evening and post them here.

-Matt

[Matt Thompson]

On Mon, Apr 23, 2018 at 9:59 AM, Matt Thompson <***@gmail.com> wrote:

>
> On Mon, Apr 23, 2018 at 9:51 AM, Dirk Hohndel <***@hohndel.org> wrote:
>
>>
>> > On Apr 23, 2018, at 7:43 AM, Matt Thompson <***@gmail.com> wrote:
>>
>> > I do have the USB drivers for the D4i installed on macOS and Windows.
>> On all three platforms I was able to successfully download dives using
>> Subsurface 4.7.8. I take that to mean that I have the correct permissions
>> on the platforms so it is just down to the difference between the -NG and
>> 4.7.8 branches. I can generate Subsurface and libdivecomputer logs if that
>> would help.
>>
>> This is the logic that I care the most about.
>> If you have situations where 4.7.8 can successfully download, but NG
>> cannot, then I want to see the Subsurface and libdivecomputer logs and
>> understand why that is the case so we can fix this.
>> I am very eager to get NG merged into master, but not at the cost of
>> significant regressions.
>>
>> /D
>>
>> I'll generate the logs this evening and post them here.
>
>
> Here is the libdivecomputer log from macOS. I verified once again that I
can successfully download dives from 4.7.8 but not from -NG. I'm not sure
how to generate subsurface logs. If someone can point me in the right
direction I'll generate that as well.

The console output from the same run was:
Starting download from /dev/tty.usbserial-STVBTFOQ
Starting the thread 0
INFO: dc_device_open error value of 0
[135.739204] ERROR: Failed to receive the answer. [in
../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
[138.712562] ERROR: Unexpected echo. [in ../../src/suunto_d9.c:239
(suunto_d9_device_packet)]
[141.818176] ERROR: Unexpected echo. [in ../../src/suunto_d9.c:239
(suunto_d9_device_packet)]
[141.836584] ERROR: Failed to read the memory header. [in
../../src/suunto_common2.c:255 (suunto_common2_device_foreach)]
Finishing the thread Dive data import error dives downloaded 0

-Matt

[Rick Walsh]

On 19 April 2018 at 07:01, Dirk Hohndel <***@hohndel.org> wrote:

>
> We now have binaries for Windows, Mac, and Linux (AppImage only) available
> in order for people to test this.
>
> https://github.com/Subsurface-divelog/subsurface/releases/ta
> g/continuous-NG
>
> I'm a bit late to the party, but I've tested the continuous-NG AppImage
(on Fedora 27) and Android (Galaxy S7) builds.

Linux with Shearwater Petrel 2.
Cannot pair in BLE (nothing new here) or Auto modes. The "Cannot connect
due to pending active LE connections" error message might be interesting,
but I don't know why it occurs.
Can pair in Classic BT mode, but download of dives fails in new logbook
(cannot use my real log since it already contains my last dives).

[***@localhost Downloads]$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
-v
Subsurface v4.7.8-73-ga12ea13d51f5,
built with libdivecomputer v0.7.0-devel-Subsurface-NG (
b5f53eeb1f5fac951d694c5173470f99d005bf45)
built with Qt Version 5.9.3, runtime from Qt Version 5.9.3
built with libgit2 0.26.0
"validateGL(): created OpenGLContext."
"validateGL(): obtained QOpenGLFunctions."
"validateGL(): detected OpenGL version 3.0."
can't find Qt localization for locale "en-AU" searching in
"/tmp/.mount_SubsurA3AowW/usr/translations"
can't find Subsurface localization for locale "en-AU"
Plugins Directory: QDir( "/tmp/.mount_SubsurA3AowW/usr/bin" , nameFilters
= { "*" }, QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters(
Dirs|Files|Drives|AllEntries ) )
...
Missing CAP_NET_ADMIN permission. Cannot determine whether a found address
is of random or public type.
Failed to create pairing "org.bluez.Error.InProgress"
Failed to create pairing "org.freedesktop.DBus.Error.NoReply"
Failed to create pairing "org.bluez.Error.InProgress"
Failed to create pairing "org.bluez.Error.InProgress"
Failed to create pairing "org.freedesktop.DBus.Error.NoReply"
Starting download from BT
Starting the thread 0
Enabling GATT request timeout behavior 20000
qt_ble_open( 00:13:43:0E:6B:D0 )
Creating default GAP/GATT services
Cannot connect due to pending active LE connections
HCI event triggered, type: f
RemoteDeviceManager job queue status: true
RemoteDeviceManager finished attempting to close external connections
addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: 5
HCI event triggered, type: e
HCI event triggered, type: e
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller 00:13:43:0E:6B:D0
The connection on RFCOMM channel number 1 took more than expected. Wait
another 15 seconds.
void QBluetoothSocketPrivate::_q_readNotify() 19 error: -1 "Resource
temporarily unavailable"
Failed to connect to device 00:13:43:0E:6B:D0 . Device state
QBluetoothSocket::UnconnectedState . Error: QBluetoothSocket::
UnknownSocketError
[17.322698] ERROR: No such file or directory (2) [in
../../src/serial_posix.c:295 (dc_serial_open)]
Finishing the thread Unable to open %s %s (%s) dives downloaded 0
Set the current dive site: 0

Linux with Hollis DG03 (via USB/serial cable).
Download works for 6 dives, then produces a ringbuffer error. Probably
nothing to do with the current changes. I previously (last year?) had a
similar error, that Jef fixed in libdivecomputer, but it's here again. I
rarely download dives from this dive computer (it's a backup that I
sometimes take in the water), so it doesn't get much testing anymore.

^TStarting download from /dev/ttyUSB0
Starting the thread 0
INFO: dc_device_open error value of 0
[0.351396] ERROR: Invalid ringbuffer pointer detected (0x00fea0 0x001190).
[in ../../src/oceanic_common.c:363 (oceanic_common_device_profile)]
[10.953339] ERROR: Invalid ringbuffer pointer detected (0x00fea0 0x001190).
[in ../../src/oceanic_common.c:441 (oceanic_common_device_profile)]
Finishing the thread Dive data import error dives downloaded 6


Android with Petrel 2
Download failed. extract from subsurface.log is below.

"23.711: DCDownloadThread started for Petrel 2 on LE:00:13:43:0E:6B:D0"
Starting download from BT
Starting the thread 0
Creating Android Central/Client support for BTLE
qt_ble_open( 00:13:43:0E:6B:D0 )
"LocalDeviceBroadcastReceiver::onReceive() - event:
android.bluetooth.device.action.ACL_CONNECTED"
Connection updated: error: QLowEnergyController::Error(NoError) oldState:
QLowEnergyController::ControllerState(ConnectingState) newState:
QLowEnergyController::ControllerState(ConnectedState)
connected to the controller for device 00:13:43:0E:6B:D0
.. discovering services
Service discovery initiated
Found service "{00001800-0000-1000-8000-00805f9b34fb}"
.. ignoring standard service
Found service "{0000180a-0000-1000-8000-00805f9b34fb}"
.. ignoring standard service
Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
.. created service object QLowEnergyService(0xc92907b0)
Discovery of "{fe25c237-0ece-443c-b0aa-e02033e7029d}" started
.. done discovering services
.. discovering details
Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 13
) QLowEnergyServicePrivate(0xbed70880)
"{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
.. enabling notifications
Descriptor list with 1 elements
Descriptor: "Client Characteristic Configuration" uuid:
"{00002902-0000-1000-8000-00805f9b34fb}"
now writing "0x0100" to the descriptor
"{00002902-0000-1000-8000-00805f9b34fb}"
Write descriptor with handle 13 "0100" (service:
"{fe25c237-0ece-443c-b0aa-e02033e7029d}" )
Write characteristic with handle 10 "0100ff010400228010c0" (service:
"{fe25c237-0ece-443c-b0aa-e02033e7029d}" , writeWithResponse: false ,
signed: false )
Write characteristic with handle 10 "0100ff0105002e902000c0" (service:
"{fe25c237-0ece-443c-b0aa-e02033e7029d}" , writeWithResponse: false ,
signed: false )
Deleting BLE object
"43.770: No new dives downloaded from dive computer"
Finishing the thread Dive data import error dives downloaded 0
no new dives downloaded
"43.778: DCDownloadThread finished"
"LocalDeviceBroadcastReceiver::onReceive() - event:
android.bluetooth.device.action.ACL_DISCONNECTED"
"421.803: AppState changed to inactive with no save ongoing and no unsaved
changes"
"423.626: AppState changed to suspended with no save ongoing and no unsaved
changes"

Rick

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:55 AM, Sébastien Dugué
<***@gmail.com> wrote:
>
> That's really cool! I'll try that out tonight (CET) with my Uwatec DCs just to
> check IRDA is still functional.

I'm pretty sure I broke IRDA. It should be easy to fix.

Note that IRDA support is going away in the kernel, though - we had
too many bugs and it was impossible to maintain. So you'll have to use
an older kernel.

Linus

[Linus Torvalds]

On Wed, Apr 18, 2018 at 11:48 AM, Linus Torvalds
<***@linux-foundation.org> wrote:
> On Wed, Apr 18, 2018 at 12:55 AM, Sébastien Dugué
> <***@gmail.com> wrote:
>>
>> That's really cool! I'll try that out tonight (CET) with my Uwatec DCs just to
>> check IRDA is still functional.
>
> I'm pretty sure I broke IRDA. It should be easy to fix.

This attached patch to subsurface may get IRDA working again..

Sébastien, if you can test this, and I'll commit it to my branch. I
can only test that it builds for me.

Linus

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:06 PM, Sébastien Dugué
<***@gmail.com> wrote:
>
> OK, it's good to go. The download is in progress (it's painfully
> slow), but that
> means divecomputer_device_open() did succeed!

Thanks. Committed and pushed out to the libdivecomputer-NG branch.

Linus

[Linus Torvalds]

On Wed, Apr 18, 2018 at 11:57 AM, Sébastien Dugué
<***@gmail.com> wrote:
>>
>> Note that IRDA support is going away in the kernel, though - we had
>> too many bugs and it was impossible to maintain. So you'll have to use
>> an older kernel.
>
> Arghhh! You mean the whole stack? Darn! will have to keep some old
> kernel just for loading my dives... :-(

Yeah, all of irda is going away in 4.17.

Nobody was using it, and nobody was maintaining it.

I'd love to bring it back, but it would need a maintainer.. Hint hint.

Linus

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:00 PM, Linus Torvalds
<***@linux-foundation.org> wrote:
>
> I'd love to bring it back, but it would need a maintainer.. Hint hint.

And by "it", I don't actually mean all of irda. irda is dead, dead,
dead. But maybe the actual individual driver that somebody is willing
to maintain, and a small subset of the stack.

The irda code deletion is commit d64c2a76123f ("staging: irda: remove
the irda network stack and drivers"), and it's a rather impressibe
number of garbage lines:

137 files changed, 69241 deletions(-)

so I'm afraid that a potential maintainer would have to prune it down
to the minimal that he/she actually uses and can test.

Linus

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:14 PM, Sébastien Dugué
<***@gmail.com> wrote:
>
> Right, only bring back those pieces that are of interest. I'll take a look
> at this, but I'm not really into bloated communication stacks... I'm merely
> a low-level driver coder.

If you're more comfortable just sending packets to the device, doing
it in user space would be much better.

It would also make it possible to work on OS X, because there's no
IRDA stack at all there.

So a user space stack would likely be simpler, easier to test, and
actually technically superior.

The "do IRDA in kernel space" made sense back in the bad old days when
IRDA was a real protocol used for transferring files and stuff, and
was supposed to be generic.

It never worked very well even back then, but at least it made sense
to have IRDA as a networking stack.

Today, the _only_ user I'm aware of is old dive computers. It doesn't
make sense as a networking stack any more.

Linus

[Willem Ferguson]

On 18/04/2018 21:33, Sébastien Dugué wrote:
> On Wed, Apr 18, 2018 at 9:20 PM, Linus Torvalds
> <***@linux-foundation.org> wrote:
>> If you're more comfortable just sending packets to the device, doing
>> it in user space would be much better.
> Right, I like writing drivers, but this has to be a userspace thing.
>
>> It would also make it possible to work on OS X, because there's no
>> IRDA stack at all there.
> I wasn't even aware of that, so that'd be a nice added bonus.
>
>> So a user space stack would likely be simpler, easier to test, and
>> actually technically superior.
>>
>> The "do IRDA in kernel space" made sense back in the bad old days when
>> IRDA was a real protocol used for transferring files and stuff, and
>> was supposed to be generic.
>>
>> It never worked very well even back then, but at least it made sense
>> to have IRDA as a networking stack.
>>
>> Today, the _only_ user I'm aware of is old dive computers. It doesn't
>> make sense as a networking stack any more.
> Well, they may be old but they're still selling. And I don't have the money
> for those fancy OLED thingies.
>
> Sébastien.
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Sebastien,

The Uwatec/Scubapro IrDA adapters are indeed based on the Moschip MCS
7780, as you say, still commonly and cheaply available. One area outside
diving where IrDA is till commonly used is in high-voltage environment
instrumentation where radio-based communication faces too much noise.
The problem with IrDA is probably the communications protocol that is
not maintained any more. From a hardware point of view infra-red
communication is cheap and efficient with a much lower parts count than
BT and with very, very small current drain.

Kind regards,

willem




--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.

[Willem Ferguson]

On 19/04/2018 09:29, Sébastien Dugué wrote:
> Hello Willem,
>
> On Thu, Apr 19, 2018 at 7:00 AM, Willem Ferguson
> <***@zoology.up.ac.za> wrote:
>> Sebastien,
>>
>> The Uwatec/Scubapro IrDA adapters are indeed based on the Moschip MCS 7780,
>> as you say, still commonly and cheaply available.
> Thanks for the info. I never bought the overpriced Uwatec adapter
> but only really
> cheap chinese ones. I've got a STIR4200 based one and a more obscure
> Tanic S110 one. The S100 is a quasi-clone of the STIR4200 but with the endpoints
> shufffled. I had to hack the stir4200 driver to be able to use it.
>
> Cheers,
> Sébastien.
>
I bought a CAB6490 on the internet at a quarter of the price of the
Uwatec. It appears to be the exact product that Scubapro rips us off with.

Kind regards,

willem



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:10 PM, Sébastien Dugué
<***@gmail.com> wrote:
>
> Looks like a bit daunting for me. However maybe a userspace approach
> might be doable. Dunno. Will have to think a bit more about it.

Indeed. That has been my long-term thinking about IRDA - most of the
IRDA dongles are just USB or serial devices, and the protocol
could/should be done in user space.

That's particularly true for something like a divecomputer, which
really only talks to one single device.

IRDA in _general_ is really damn complicated. And nobody actually does
the general case.

So the sane thing to do would be to basically do a special custom IRDA
thing that just talks directly to the dongle (using libusb, or just
using a serial port, depending on what the uwatec dongle actually
does?)

Linus

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:27 PM, Sébastien Dugué
<***@gmail.com> wrote:
>
> I looked into this when writing a simulator of my 2G and as far as I
> remember, there's not much of the stack involved when talking to an irda
> DC. All special cases. I may still have the traffic captures laying around

Yeah, it should be trivial. There's some small headers for addresses,
and there's a discovery protocol, but it's not complicated.

What made IRDA complex wasn't actually so much the individual
messages, but the documentation and the layering and the abstraction.

It was a classic case of somebody thinking that "hey, we should follow
the OSI model with seven layers of communication" (which was really a
very common mindset in the 80's and 90's) and the end result is not
just a ton of code, but code that is pretty hard to understand and
follow too.

So there's the IRDA physical layer, then the link access layer, then
the link management layer, and then the communication layer.

It's all completely overdesigned BS. Comms people _loved_ doing things
like that.

Linus

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:27 PM, Sébastien Dugué
<***@gmail.com> wrote:
>
> I looked into this when writing a simulator of my 2G and as far as I
> remember, there's not much of the stack involved when talking to an irda
> DC. All special cases. I may still have the traffic captures laying around

Hmm. Which IRDA chip is it that is in the Uwatec dongle?

Is it perhaps the MosChip MCS7780? You'd know, because then it would
be using USB ID 9710:7780. That seems to be the common case.

You can find datasheets for it by just googling for

MCS7780 Datasheet type:pdf

and from a quick look, the setup looks pretty simple. It has various
configuration bits, but it looks like the control register defaults to
al the normal bits, so you may not even need to touch it.

For example, it seems to default to 9600 baud, all automatic defaults
for SIR. Maybe I missed some bit, but it basically seems to default to
"ready to simply be used".

So you might be able to just set up plain USB bulk transfers to send
and receive the data. *Maybe* you need some setup, but it's not clear
that you do.

So accessing this thing with libusb looks fairly straightforward, if
you already have packet traces and know what the wrapping is (I think
the MCS7780 just wants to add a 2-byte little-endian packet length to
the data, but then whatever the IRDA address encapsulation etc is I
have no idea).

Linus

[Linus Torvalds]

On Wed, Apr 18, 2018 at 4:18 PM, Linus Torvalds
<***@linux-foundation.org> wrote:
>
> Hmm. Which IRDA chip is it that is in the Uwatec dongle?
>
> Is it perhaps the MosChip MCS7780? You'd know, because then it would
> be using USB ID 9710:7780. That seems to be the common case.

Hmm. Googling around, I see that it might also be the Sigmatel
Stir4200 (USB ID 066F:4210).

That actually has better documentation, and shows exactly the framing
for the normal MIR format (which it would be for the normal 9600
baud). I suspect the MCS7780 needs that same format, it's just not
documented as well.

The packet wrapping looks like this:

0x55 0xaa 2-byte LE length, 0xC0*n .. escaped data .. 2-byte LE CRC 0xc1

and from what I can tell, the Stir4200 also resets to sane default
values (9600 baud SIR).

But you may have to do some USB control transfers to set the data
direction. It *looks* like the MCS7780 is simpler and defaults to just
"automatic data direction" (which presumably just means "send if there
is TX data, receive otherwise").

Linus

[Jef Driesen]

On 2018-04-19 09:42, Sébastien Dugué wrote:
> On Thu, Apr 19, 2018 at 1:50 AM, Linus Torvalds
> <***@linux-foundation.org> wrote:
>> On Wed, Apr 18, 2018 at 4:18 PM, Linus Torvalds
>> <***@linux-foundation.org> wrote:
>>>
>>> Hmm. Which IRDA chip is it that is in the Uwatec dongle?
>>>
>>> Is it perhaps the MosChip MCS7780? You'd know, because then it would
>>> be using USB ID 9710:7780. That seems to be the common case.
>>
>> Hmm. Googling around, I see that it might also be the Sigmatel
>> Stir4200 (USB ID 066F:4210).
>>
>> That actually has better documentation, and shows exactly the framing
>> for the normal MIR format (which it would be for the normal 9600
>> baud). I suspect the MCS7780 needs that same format, it's just not
>> documented as well.
>>
>> The packet wrapping looks like this:
>>
>> 0x55 0xaa 2-byte LE length, 0xC0*n .. escaped data .. 2-byte LE
>> CRC 0xc1
>>
>> and from what I can tell, the Stir4200 also resets to sane default
>> values (9600 baud SIR).
>>
>> But you may have to do some USB control transfers to set the data
>> direction. It *looks* like the MCS7780 is simpler and defaults to just
>> "automatic data direction" (which presumably just means "send if there
>> is TX data, receive otherwise").
>
> Yes, but to me talking to the chip is the easy part. I'm more
> concerned
> about implementing enough of the irda protocol stack to be able to talk
> to all those embedded stacks.

I discovered this a while ago:

https://github.com/Diveboard/DC-agent/tree/master/3d-party/irda_mac

It seems to be based on some minimal IrDA stack for micro-controllers:

http://web.archive.org/web/20061124205138/www.blaulogic.com/pico_irda.shtml

This is probably a good starting point!

Jef

[Hartley Horwitz]

>
>
>
> ---------- Forwarded message ----------
> From: Linus Torvalds <***@linux-foundation.org>
> To: "Sébastien Dugué" <***@gmail.com>
> Cc: Subsurface Mailing List <***@subsurface-divelog.org>
> Bcc:
> Date: Wed, 18 Apr 2018 12:20:35 -0700
> Subject: Re: Any brave dive computer download testers out there?
> On Wed, Apr 18, 2018 at 12:14 PM, Sébastien Dugué
> <***@gmail.com> wrote:
> >
> > Right, only bring back those pieces that are of interest. I'll take a
> look
> > at this, but I'm not really into bloated communication stacks... I'm
> merely
> > a low-level driver coder.
>
> .......
>
> It never worked very well even back then, but at least it made sense
> to have IRDA as a networking stack.
>
> Today, the _only_ user I'm aware of is old dive computers. It doesn't
> make sense as a networking stack any more.
>
> Linus
>

Is this a case where many hours of developer effort will be dumped into
supporting an old obsolete group of dive computers? Maybe the current
version of Subsurface can remain available for users of the IRDA computers
and new versions will drop this feature?

I'm just not sure how many users have IRDA computers and it seems like
developer time is better spent on supporting the up-and-coming computers
which will be BT or BLE.

...Hartley

[Willem Ferguson]

From phone. You guys in the developed world have resources for all the
latest kit. I my country iRda is commonly used. In addition the CCR
community worldwide often use iRda. It has a significant role to play at
least for the next 10 years. Therefore I strongly argue for the continued
support of iRda. Subsurface is not meant only for the divers with the
latest kit. Kind regards, willem

On Wed, 18 Apr 2018, 21:54 Hartley Horwitz, <***@gmail.com> wrote:

>
>>
>> ---------- Forwarded message ----------
>> From: Linus Torvalds <***@linux-foundation.org>
>> To: "Sébastien Dugué" <***@gmail.com>
>> Cc: Subsurface Mailing List <***@subsurface-divelog.org>
>> Bcc:
>> Date: Wed, 18 Apr 2018 12:20:35 -0700
>> Subject: Re: Any brave dive computer download testers out there?
>> On Wed, Apr 18, 2018 at 12:14 PM, Sébastien Dugué
>> <***@gmail.com> wrote:
>> >
>> > Right, only bring back those pieces that are of interest. I'll take a
>> look
>> > at this, but I'm not really into bloated communication stacks... I'm
>> merely
>> > a low-level driver coder.
>>
>> .......
>>
>> It never worked very well even back then, but at least it made sense
>> to have IRDA as a networking stack.
>>
>> Today, the _only_ user I'm aware of is old dive computers. It doesn't
>> make sense as a networking stack any more.
>>
>> Linus
>>
>
> Is this a case where many hours of developer effort will be dumped into
> supporting an old obsolete group of dive computers? Maybe the current
> version of Subsurface can remain available for users of the IRDA computers
> and new versions will drop this feature?
>
> I'm just not sure how many users have IRDA computers and it seems like
> developer time is better spent on supporting the up-and-coming computers
> which will be BT or BLE.
>
> ...Hartley
>
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>

[Hartley Horwitz]

I plead ignorance. I didn't realize that CCR use IrDA.
My point was that I'd be happy to forgo some of the new wiz-bang features
and just have a stable 'old' version of Subsurface if that allows the
developers the freedom to move quicker on developing newer features. Many
of those new features are targeting Tech divers and so supporting IrDA
makes sense.

As for my own kit, I use a regulator from the 1980's and my dive computer
is from 2006, so I've never been accused of using the latest gear.

...Hartley

On Thu, Apr 19, 2018 at 3:48 AM, Sébastien Dugué <
***@gmail.com> wrote:

> On Wed, Apr 18, 2018 at 10:15 PM, Willem Ferguson
> <***@zoology.up.ac.za> wrote:
> > From phone. You guys in the developed world have resources for all the
> > latest kit. I my country iRda is commonly used. In addition the CCR
> > community worldwide often use iRda. It has a significant role to play at
> > least for the next 10 years. Therefore I strongly argue for the continued
> > support of iRda. Subsurface is not meant only for the divers with the
> latest
> > kit. Kind regards, willem
>
> I second that, a lot of divers around me are using Uwatec irda DCs.
>
> Sébastien.
>

[Willem Ferguson]

On 19/04/2018 18:03, Hartley Horwitz wrote:
> I plead ignorance.  I didn't realize that CCR use IrDA.
> My point was that I'd be happy to forgo some of the new wiz-bang
> features and just have a stable 'old' version of Subsurface if that
> allows the developers the freedom to move quicker on developing newer
> features.  Many of those new features are targeting Tech divers and so
> supporting IrDA makes sense.
>
> As for my own kit, I use a regulator from the 1980's and my dive
> computer is from 2006, so I've never been accused of using the latest
> gear.
>
> ...Hartley
No problem at all. IrDA is old-fashioned, but not obsolete. It is freely
available on the market and until last year, was the technology of
Uwatec's leading dive computer (the Sol). Technology, by its very
nature, changes all the time and requires users to adapt all the time. I
am probably pretty old-fashioned, but I am resistant to tecnology for
new technology's sake. From what I have heard and seen, I am not
convinced that BTLE provides any advantage above IrDA (both of these
rather non-standardised and idiosyncratic) in terms of ease of use and
efficiency. To see the bad side of IrDA, just go and look what Mares
have gone and done with it. The fact that Apple decided to go BTLE
should not be a market driving force - maybe Apple did not reach a good
decision, or maybe they chose it as a mechanism to lock users into the
Apple-specific implementation in order to buy more of Apple.
Kind regards,
willem


--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.

[Willem Ferguson]

On 18/04/2018 05:35, Linus Torvalds wrote:
> So libdivecomputer has a new custom IO model, which allows us to drop
> our home-made one.
>
> However, that new model is fairly different from our old model, and
> there were other updates too, so the changes are "flag-day" changes
> where we switch over both libdivecomputer and subsurface together.
>
> I have *TEST* branches for both, in case people want to help test.
> Note! I only do source code, so this really only works for people who
> can build their own subsurface binary, but if you are one of those
> hardy souls, it realy would be good to get more cases tested.
>
> I have verified and downloaded:
>
> - Shearwater Perdix AI over BLE
>
> - Suunto EON Core over USB
>
> - Suunto Vyper Air over the Suunto USB serial line
>
> so many of the transports have been tested. But I don't have any
> rfcomm devices (ie old bluetooth) and I don't have any "direct USB"
> devices (eg Atomics Aquatics Cobalt).
>
> Also, I only tested on my Linux desktop, because that's how I roll.
>
> Anyway, if you can build subsurface and libdivercomputer, and are
> interested in testing, I have test branches for both:
>
>
> It may break things. I'd be surprised if it doesn't. So keep that in
> mind. This is very much for people who are happy playing around and
> helping get some coverage for early work.
>
> Linus
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

I tested on a Petrel 2. On the desktop, the following:

I tried all three options (auto, classical,BLE) in that order. For Auto
and classical, upload worked. Only one comment, the initial handshaking
appeared to take quite a bit longer than usual. In fact, a warning
appeared in the red bar at the bottom of the Subsurface screen "Timeout
connecting to device...". Yet, eventually, the transfer did take place
and successfully. For BLE, the desktop could not connect to the Petrel.
I am reasonably sure the newer Petrel 2 like mine are dual mode but I am
not 100% sure of this. Not much info on the Shearwater web site that I
could see.

My Galileo downloaded well through IrDA.

As far as mobile version is concerned, I did not get far because Android
complains of a corrupt package. I suspect the problem lies with my
Android, not with the package.

Kind regards,

willem






--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.