Cleaned up and rebased "libdivecomputer-NG" branch

[Linus Torvalds]

Ok, I finally got around to cleaning up my subsurface changes, and
there is now a newly rebased libdivecomputer-NG branch at

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

that I think is in good enough shape to be pulled.

That branch has the same requirement on the "Subsurface-NG" branch in
libdivecomputer, but has additionally:

- many cleanups, including entirely removing the "ble_serial" code
(which in the old branch stayed around as dead code)

The ble_serial code wrapped the BLE code in a serial emulation
layer, but now that libdivecomputer natively knows about BLE, there's
no point any more.

- simplified history.

I couldn't really split things up into lots of small changes (since
it's a flag-day for the new libdivecomputer interface anyway), and
instead the conversion history is just two commits: (a) convert our
custom IO implementation to the new libdivecomputer world order and
(b) hook it all in and use the new world order.

- I added the fingerprint patch.

Ok, so this has nothing to do with the new world order, and maybe
Dirk wants to handle this some other way, but it was part of my
testing and seems solid, and is technically about libdivecomputer (and
affects nothing else).

NOTE! I have *not* updated libdivecomputer itself. I looked at it, and
it all looks fine. I think Dirk should just use his "NG-test" branch
as-is (ie my NG update and merging in the libdivecomputer upstream
bugfix). But just rebasing it on top of the libdivecomputer OSTC3
bugfix would be fine too. But unlike the subsurface branch, there's
not really any big *reason* to rebase.

Dirk - up to you. And obviously, I don't know when you want to cut
over to the new libdivecomputer world order.

Linus

[Dirk Hohndel]

> On Apr 24, 2018, at 12:53 PM, Linus Torvalds <***@linux-foundation.org> wrote:
>
> Ok, I finally got around to cleaning up my subsurface changes, and
> there is now a newly rebased libdivecomputer-NG branch at
>
> git://github.com/torvalds/subsurface-for-dirk.git libdivecomputer-NG

Excellent - I’ve been waiting for that. I’m running out of time today, but
I’ll work on this tomorrow.

> that I think is in good enough shape to be pulled.
>
> That branch has the same requirement on the "Subsurface-NG" branch in
> libdivecomputer, but has additionally:
>
> - many cleanups, including entirely removing the "ble_serial" code
> (which in the old branch stayed around as dead code)
>
> The ble_serial code wrapped the BLE code in a serial emulation
> layer, but now that libdivecomputer natively knows about BLE, there's
> no point any more.
>
> - simplified history.
>
> I couldn't really split things up into lots of small changes (since
> it's a flag-day for the new libdivecomputer interface anyway), and
> instead the conversion history is just two commits: (a) convert our
> custom IO implementation to the new libdivecomputer world order and
> (b) hook it all in and use the new world order.
>
> - I added the fingerprint patch.
>
> Ok, so this has nothing to do with the new world order, and maybe
> Dirk wants to handle this some other way, but it was part of my
> testing and seems solid, and is technically about libdivecomputer (and
> affects nothing else).

I think that last iteration made sense. I haven’t thought it through for
all the different OSs to make sure it works, but given that you used
a standard path, it should.

> NOTE! I have *not* updated libdivecomputer itself. I looked at it, and
> it all looks fine. I think Dirk should just use his "NG-test" branch
> as-is (ie my NG update and merging in the libdivecomputer upstream
> bugfix). But just rebasing it on top of the libdivecomputer OSTC3
> bugfix would be fine too. But unlike the subsurface branch, there's
> not really any big *reason* to rebase.
>
> Dirk - up to you. And obviously, I don't know when you want to cut
> over to the new libdivecomputer world order.

I’m happy to do it now - but for libdivecomputer I’m always a bit
gun shy, so I’d prefer that you did the rebasing and just pointed
me to a tree that you want me to start with (as this is a new branch).

Thanks

/D

[Linus Torvalds]

On Tue, Apr 24, 2018 at 5:11 PM, Dirk Hohndel <***@hohndel.org> wrote:
>>
>> Dirk - up to you. And obviously, I don't know when you want to cut
>> over to the new libdivecomputer world order.
>
> I’m happy to do it now - but for libdivecomputer I’m always a bit
> gun shy, so I’d prefer that you did the rebasing and just pointed
> me to a tree that you want me to start with (as this is a new branch).

Ok, I've rebased the Subsurface-NG branch in my git repo on top of
Jef's current branch, so now that branch has the OSTC3 fix:

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

NOTE! I have *not* updated the 'libdivecomputer' subproject in the
subsurface repository to point to that version of libdivecomputer. I
still build them as separate projects, and particularly when I was
rebasing, I didn't want to tie them together. I was thinking you'd do
that.

Linus

[Dirk Hohndel]

> On Apr 24, 2018, at 5:43 PM, Linus Torvalds <***@linux-foundation.org> wrote:
>
> On Tue, Apr 24, 2018 at 5:11 PM, Dirk Hohndel <***@hohndel.org> wrote:
>>>
>>> Dirk - up to you. And obviously, I don't know when you want to cut
>>> over to the new libdivecomputer world order.
>>
>> I’m happy to do it now - but for libdivecomputer I’m always a bit
>> gun shy, so I’d prefer that you did the rebasing and just pointed
>> me to a tree that you want me to start with (as this is a new branch).
>
> Ok, I've rebased the Subsurface-NG branch in my git repo on top of
> Jef's current branch, so now that branch has the OSTC3 fix:
>
> git://github.com/torvalds/libdc-for-dirk.git Subsurface-NG

Thanks - so we’ll stick with Subsurface-NG as branch name? :-)

> NOTE! I have *not* updated the 'libdivecomputer' subproject in the
> subsurface repository to point to that version of libdivecomputer. I
> still build them as separate projects, and particularly when I was
> rebasing, I didn't want to tie them together. I was thinking you'd do
> that.

Yes, that’s easy. I’ll do that.

Thanks

/D

[Linus Torvalds]

On Tue, Apr 24, 2018 at 5:43 PM, Linus Torvalds
<***@linux-foundation.org> wrote:
> NOTE! I have *not* updated the 'libdivecomputer' subproject in the
> subsurface repository to point to that version of libdivecomputer. I
> still build them as separate projects, and particularly when I was
> rebasing, I didn't want to tie them together. I was thinking you'd do
> that.

Oh, and I realized that I should also mention that I didn't apply your
fixes. I (obviously) had no test coverage for them, but they all
looked fine.

So you'll need to cherry pick or rebase your transport patches and the
Android stuff. My rebased branch was the same old contents, just
cleaned up.

I assume that was all obvious, but I though maybe better just make it explicit.

Linus

[Dirk Hohndel]

> On Apr 24, 2018, at 5:58 PM, Linus Torvalds <***@linux-foundation.org> wrote:
>
> On Tue, Apr 24, 2018 at 5:43 PM, Linus Torvalds
> <***@linux-foundation.org> wrote:
>> NOTE! I have *not* updated the 'libdivecomputer' subproject in the
>> subsurface repository to point to that version of libdivecomputer. I
>> still build them as separate projects, and particularly when I was
>> rebasing, I didn't want to tie them together. I was thinking you'd do
>> that.
>
> Oh, and I realized that I should also mention that I didn't apply your
> fixes. I (obviously) had no test coverage for them, but they all
> looked fine.
>
> So you'll need to cherry pick or rebase your transport patches and the
> Android stuff. My rebased branch was the same old contents, just
> cleaned up.
>
> I assume that was all obvious, but I though maybe better just make it explicit.

I should have seen this, but I didn’t. I simply wrapped it all up and pushed
it to Travis for some testing. I’ll add my changes and re-start that process.

Thanks for the warning :-)

/D

[Dirk Hohndel]

> On Apr 24, 2018, at 5:59 PM, Dirk Hohndel <***@hohndel.org> wrote:
>>
>> Oh, and I realized that I should also mention that I didn't apply your
>> fixes. I (obviously) had no test coverage for them, but they all
>> looked fine.
>>
>> So you'll need to cherry pick or rebase your transport patches and the
>> Android stuff. My rebased branch was the same old contents, just
>> cleaned up.

Actually, the removal of the old BLE code made the Android patch unnecessary.
But I’ll add the discovery of supported dive computers while I’m at it.

/D

[Dirk Hohndel]

> On Apr 24, 2018, at 6:04 PM, Dirk Hohndel <***@hohndel.org> wrote:
>
>
>> On Apr 24, 2018, at 5:59 PM, Dirk Hohndel <***@hohndel.org> wrote:
>>>
>>> Oh, and I realized that I should also mention that I didn't apply your
>>> fixes. I (obviously) had no test coverage for them, but they all
>>> looked fine.
>>>
>>> So you'll need to cherry pick or rebase your transport patches and the
>>> Android stuff. My rebased branch was the same old contents, just
>>> cleaned up.
>
> Actually, the removal of the old BLE code made the Android patch unnecessary.

And what I meant to say was “almost makes it unnecessary”. Arg.
I LOVE TRAVIS.

/D

[Dirk Hohndel]

The libdivecomputer and Subsurface changes have now been pushed to master.
I've also updated the documentation to refer to this as the Subsurface-NG branch.

We should now focus on figuring out the problems with the Shearwater downloads.
For some people these fail on rfcomm, for some they fail on BLE but succeed on
rfcomm, and it seems that some can't download from their Shearwater devices at
all...

/D

[Linus Torvalds]

On Wed, Apr 25, 2018 at 8:43 AM, Dirk Hohndel <***@hohndel.org> wrote:
>
> We should now focus on figuring out the problems with the Shearwater downloads.
> For some people these fail on rfcomm, for some they fail on BLE but succeed on
> rfcomm, and it seems that some can't download from their Shearwater devices at
> all...

So attached is a trial patch. It makes sense to me, but I don't have
any rfcomm devices to try with.

What it does is:

- create a notion of "supported protocols"

- use the "bluetooth_mode" to switch that between "BT and BLE" and
"everything _but_ BT and BLE"

- take the "LE:" prefix into account when in bluetooth mode, and
limit things to _only_ BLE in that case

- limit the final set of protocols to the bitwise logical and of the
"dive computer supports this protocol" and "we support this protocol".

- and finally, try rfcomm _before_ trying BLE

What the *effect* of this should be:

- we don't try the crazy "fall back on other protocols" if
bluetooth_mode was set

- we actually start taking that "LE:" prefix into account again.

- people who prefer rfcomm won't have us trying BLE first

but it's entirely untested. Well - it builds for me, and my Perdix AI
still downloads, but I obviously can't test the case that really
matters.

Linus

[Dirk Hohndel]

On Wed, Apr 25, 2018 at 09:47:27AM -0700, Linus Torvalds wrote:
>
> So attached is a trial patch. It makes sense to me, but I don't have
> any rfcomm devices to try with.

Which tree should this apply against? Maybe I'm just extra dumb today, but
it applies neither to current master nor to your tree from yesterday.
What am I missing (besides a brain, I mean)?

/D

[Dirk Hohndel]

On Wed, Apr 25, 2018 at 11:57:13AM -0700, Dirk Hohndel wrote:
> On Wed, Apr 25, 2018 at 09:47:27AM -0700, Linus Torvalds wrote:
> >
> > So attached is a trial patch. It makes sense to me, but I don't have
> > any rfcomm devices to try with.
>
> Which tree should this apply against? Maybe I'm just extra dumb today, but
> it applies neither to current master nor to your tree from yesterday.
> What am I missing (besides a brain, I mean)?

As I guessed, it was the brain. Ignore, please.

/D

[Linus Torvalds]

On Wed, Apr 25, 2018 at 11:57 AM, Dirk Hohndel <***@hohndel.org> wrote:
>
> Which tree should this apply against? Maybe I'm just extra dumb today, but
> it applies neither to current master nor to your tree from yesterday.
> What am I missing (besides a brain, I mean)?

Odd. It was _supposed_ to apply to current master.

Linus

[Linus Torvalds]

On Wed, Apr 25, 2018 at 12:57 PM, Linus Torvalds
<***@linux-foundation.org> wrote:
>
> Odd. It was _supposed_ to apply to current master.

Ok, apparently you worked it out.

Anyway, the commit message could be something simple along the lines of

Do a better job of picking which transport to use

If the user specified bluetooth, we really should pick bluetooth, not
probe and possibly fall back to something else.

We should also honor the users choice of BLE vs classic BT.

Signed-off-by: Linus Torvalds <***@linux-foundation.org>

or similar. But it _would_ be good to test that this actually makes
Petrel 2 work with rfcomm. Because it's certainly possible that there
is something else wrong with rfcomm.

Maybe we have screwed up the rfcomm channel number logic or something?
Because we have a very special case with that whole "channel number
5". That's all old code and I had nothing to do with it (because I've
never had anything that worked with this anyway).

Linus

[Dirk Hohndel]

On Wed, Apr 25, 2018 at 01:04:36PM -0700, Linus Torvalds wrote:
> On Wed, Apr 25, 2018 at 12:57 PM, Linus Torvalds
> <***@linux-foundation.org> wrote:
> >
> > Odd. It was _supposed_ to apply to current master.
>
> Ok, apparently you worked it out.

Yes

> Anyway, the commit message could be something simple along the lines of
>
> Do a better job of picking which transport to use
>
> If the user specified bluetooth, we really should pick bluetooth, not
> probe and possibly fall back to something else.
>
> We should also honor the users choice of BLE vs classic BT.
>
> Signed-off-by: Linus Torvalds <***@linux-foundation.org>

I'll add that.


> or similar. But it _would_ be good to test that this actually makes
> Petrel 2 work with rfcomm. Because it's certainly possible that there
> is something else wrong with rfcomm.

Right now I'm testing.

(1) BT-only Petrel and Android: works
- but if you cancel on the Petrel (which makes it shut down its BT
stack) then Subsurface-mobile gets confused. It keeps sitting in the
download screen, Cancel doesn't work, and I can't get it to show me
the dives that it has downloaded so far.
(2) dual stack Petrel 2 and Android:
- RF Connect claims this is an LE only device
- whatever I try, it refuses to pair / connect / bond
I know that this Petrel 2 has connected to this Android phone before,
so this is yet another of these "what the heck is going on" situations.
Next I'll remove the battery and reboot the phone, but I'm running out
of ideas how to make this work.

I ran out of time testing on Mac.

> Maybe we have screwed up the rfcomm channel number logic or something?
> Because we have a very special case with that whole "channel number
> 5". That's all old code and I had nothing to do with it (because I've
> never had anything that worked with this anyway).

If I had any faith that the Petrel 2 wasn't completely hosed, I'd bring it
over to you...

/D

[Dirk Hohndel]

> On Apr 25, 2018, at 1:34 PM, Dirk Hohndel <***@hohndel.org> wrote:
>> or similar. But it _would_ be good to test that this actually makes
>> Petrel 2 work with rfcomm. Because it's certainly possible that there
>> is something else wrong with rfcomm.
>
> Right now I'm testing.
>
> (1) BT-only Petrel and Android: works
> - but if you cancel on the Petrel (which makes it shut down its BT
> stack) then Subsurface-mobile gets confused. It keeps sitting in the
> download screen, Cancel doesn't work, and I can't get it to show me
> the dives that it has downloaded so far.
> (2) dual stack Petrel 2 and Android:
> - RF Connect claims this is an LE only device
> - whatever I try, it refuses to pair / connect / bond
> I know that this Petrel 2 has connected to this Android phone before,
> so this is yet another of these "what the heck is going on" situations.
> Next I'll remove the battery and reboot the phone, but I'm running out
> of ideas how to make this work.

And after rebooting everything I finally got it connected.
Subsurface sees it both as LE and classic device. I tried downloading
via both protocols and in both cases got "Dive computer transport
not supported". So we must be doing something wrong there.
I'll add more debugging output to see what I can figure out.

/D

[Dirk Hohndel]

On Wed, Apr 25, 2018 at 01:50:46PM -0700, Dirk Hohndel wrote:
>
> > On Apr 25, 2018, at 1:34 PM, Dirk Hohndel <***@hohndel.org> wrote:
> >> or similar. But it _would_ be good to test that this actually makes
> >> Petrel 2 work with rfcomm. Because it's certainly possible that there
> >> is something else wrong with rfcomm.
> >
> > Right now I'm testing.
> >
> > (1) BT-only Petrel and Android: works
> > - but if you cancel on the Petrel (which makes it shut down its BT
> > stack) then Subsurface-mobile gets confused. It keeps sitting in the
> > download screen, Cancel doesn't work, and I can't get it to show me
> > the dives that it has downloaded so far.
> > (2) dual stack Petrel 2 and Android:
> > - RF Connect claims this is an LE only device
> > - whatever I try, it refuses to pair / connect / bond
> > I know that this Petrel 2 has connected to this Android phone before,
> > so this is yet another of these "what the heck is going on" situations.
> > Next I'll remove the battery and reboot the phone, but I'm running out
> > of ideas how to make this work.
>
> And after rebooting everything I finally got it connected.
> Subsurface sees it both as LE and classic device. I tried downloading
> via both protocols and in both cases got "Dive computer transport
> not supported". So we must be doing something wrong there.
> I'll add more debugging output to see what I can figure out.

With a bunch more debugging code added (and a rewritten function to report
the supported transports), here are the logs from the attempts with BLE
and with BT to connect to my Petrel 2 / dual stack:


"10.440: DCDownloadThread started for Petrel 2 on LE:00:13:43:0D:2B:30"
Starting download from BT
Starting the thread 0
"10.441: dc_descriptor_get_transports"
"10.441: SERIAL BT BLE "
"10.442: get_supported_transports returns"
"10.442: BLE "
Creating Android Central/Client support for BTLE
qt_ble_open( 00:13:43:0D:2B:30 )
Connection updated: error: QLowEnergyController::Error(NoError) oldState: QLowEnergyController::ControllerState(ConnectingState) newState: QLowEnergyController::ControllerState(ConnectedState)
"LocalDeviceBroadcastReceiver::onReceive() - event: android.bluetooth.device.action.ACL_CONNECTED"
connected to the controller for device 00:13:43:0D:2B:30
.. discovering services
Service discovery initiated
.. done discovering services
failed to find suitable service on 00:13:43:0D:2B:30
Deleting BLE object
"34.311: Failed to find suitable service on '00:13:43:0D:2B:30'"
Finishing the thread Unable to open %s %s (%s) dives downloaded 0
Finishing the thread Unable to open %s %s (%s) dives downloaded 0
"34.313: Unsupported operation"
no new dives downloaded
"34.315: DCDownloadThread finished"
"LocalDeviceBroadcastReceiver::onReceive() - event: android.bluetooth.device.action.ACL_DISCONNECTED"

[...]


"8.657: DCDownloadThread started for Petrel 2 on 00:13:43:06:75:62"
Starting download from BT
Starting the thread 0
"8.659: dc_descriptor_get_transports"
"8.659: SERIAL BT BLE "
"8.659: get_supported_transports returns"
"8.659: BT BLE "
connecting to Uuid "{00001101-0000-1000-8000-00805f9b34fb}"
connectToService() "00:13:43:06:75:62" "{00001101-0000-1000-8000-00805f9b34fb}"
Connnecting via insecure rfcomm
Connecting socket
The connection step took more than expected. Wait another 20 seconds
Falling back to reverse uuid workaround.
Workaround failed
Failed to connect to device 00:13:43:06:75:62 . Device state QBluetoothSocket::UnconnectedState . Error: QBluetoothSocket::ServiceNotFoundError
Creating Android Central/Client support for BTLE
qt_ble_open( 00:13:43:06:75:62 )
timeout while trying to connect to the controller 00:13:43:06:75:62
"26.247: Timeout while trying to connect to 00:13:43:06:75:62"
Finishing the thread Unable to open %s %s (%s) dives downloaded 0
"26.252: Unsupported operation"
no new dives downloaded
"26.289: DCDownloadThread finished"

Any idea what to poke at next?

/D

[Linus Torvalds]

On Wed, Apr 25, 2018 at 4:08 PM, Dirk Hohndel <***@hohndel.org> wrote:
>>
>> And after rebooting everything I finally got it connected.
>> Subsurface sees it both as LE and classic device. I tried downloading
>> via both protocols and in both cases got "Dive computer transport
>> not supported". So we must be doing something wrong there.
>> I'll add more debugging output to see what I can figure out.
>
> With a bunch more debugging code added (and a rewritten function to report
> the supported transports), here are the logs from the attempts with BLE
> and with BT to connect to my Petrel 2 / dual stack:
>
>
> "10.440: DCDownloadThread started for Petrel 2 on LE:00:13:43:0D:2B:30"
> Starting download from BT
> Starting the thread 0
> "10.441: dc_descriptor_get_transports"
> "10.441: SERIAL BT BLE "

Ok, so far so good, with the odd "libdivecomputer thinks rfcomm means
it talks serial".

> "10.442: get_supported_transports returns"
> "10.442: BLE "

Ok, apparently you scanned this and the address contained the "LE:"
thing that limited us to LE only?

> Creating Android Central/Client support for BTLE
> qt_ble_open( 00:13:43:0D:2B:30 )
> Connection updated: error: QLowEnergyController::Error(NoError) oldState: QLowEnergyController::ControllerState(ConnectingState) newState: QLowEnergyController::ControllerState(ConnectedState)
> "LocalDeviceBroadcastReceiver::onReceive() - event: android.bluetooth.device.action.ACL_CONNECTED"
> connected to the controller for device 00:13:43:0D:2B:30
> .. discovering services
> Service discovery initiated
> .. done discovering services
> failed to find suitable service on 00:13:43:0D:2B:30

Ok, so it's using the BLE code, it just isn't able to get a service list. Odd.


> [...]
>
>
> "8.657: DCDownloadThread started for Petrel 2 on 00:13:43:06:75:62"
> Starting download from BT
> Starting the thread 0
> "8.659: dc_descriptor_get_transports"
> "8.659: SERIAL BT BLE "
> "8.659: get_supported_transports returns"
> "8.659: BT BLE "

Ok, so this time you used "auto", and now it is ok with both BT and BLE.

> connecting to Uuid "{00001101-0000-1000-8000-00805f9b34fb}"
> connectToService() "00:13:43:06:75:62" "{00001101-0000-1000-8000-00805f9b34fb}"
> Connnecting via insecure rfcomm\

So it tries rfcomm first.

> Connecting socket
> The connection step took more than expected. Wait another 20 seconds

..except it never connected.

> Falling back to reverse uuid workaround.
> Workaround failed

This failed too.

> Failed to connect to device 00:13:43:06:75:62 . Device state QBluetoothSocket::UnconnectedState . Error: QBluetoothSocket::ServiceNotFoundError

So now we failed the rfcomm, but since it supports LE too, we go and try that:

> Creating Android Central/Client support for BTLE
> qt_ble_open( 00:13:43:06:75:62 )
> timeout while trying to connect to the controller 00:13:43:06:75:62

But it didn't even get as far as connecting, much less getting a service list.

> Any idea what to poke at next?

It's like the Petrel isn't really willing to talk to your device.

Maybe the same old "Shearwater dive computers have some random memory
of what they talked to last, and refuse to talk to anybody else". With
some unknown rule for what that memory is..

I have no idea.

Linus

[Dirk Hohndel]

On Wed, Apr 25, 2018 at 04:17:18PM -0700, Linus Torvalds wrote:
> > With a bunch more debugging code added (and a rewritten function to report
> > the supported transports), here are the logs from the attempts with BLE
> > and with BT to connect to my Petrel 2 / dual stack:
> >
> > "10.440: DCDownloadThread started for Petrel 2 on LE:00:13:43:0D:2B:30"
> > Starting download from BT
> > Starting the thread 0
> > "10.441: dc_descriptor_get_transports"
> > "10.441: SERIAL BT BLE "
>
> Ok, so far so good, with the odd "libdivecomputer thinks rfcomm means
> it talks serial".

Yep.

> > "10.442: get_supported_transports returns"
> > "10.442: BLE "
>
> Ok, apparently you scanned this and the address contained the "LE:"
> thing that limited us to LE only?

That's your code - it says if the address starts with LE:, restrict to
BLE.

> > Creating Android Central/Client support for BTLE
> > qt_ble_open( 00:13:43:0D:2B:30 )
> > Connection updated: error: QLowEnergyController::Error(NoError) oldState: QLowEnergyController::ControllerState(ConnectingState) newState: QLowEnergyController::ControllerState(ConnectedState)
> > "LocalDeviceBroadcastReceiver::onReceive() - event: android.bluetooth.device.action.ACL_CONNECTED"
> > connected to the controller for device 00:13:43:0D:2B:30
> > .. discovering services
> > Service discovery initiated
> > .. done discovering services
> > failed to find suitable service on 00:13:43:0D:2B:30
>
> Ok, so it's using the BLE code, it just isn't able to get a service list. Odd.

Indeed - what's the next step to debug this? My guess is that we should
somehow dump what we get back?

> >
> > "8.657: DCDownloadThread started for Petrel 2 on 00:13:43:06:75:62"
> > Starting download from BT
> > Starting the thread 0
> > "8.659: dc_descriptor_get_transports"
> > "8.659: SERIAL BT BLE "
> > "8.659: get_supported_transports returns"
> > "8.659: BT BLE "
>
> Ok, so this time you used "auto", and now it is ok with both BT and BLE.

Yes, this time I picked the non-LE: address from the dropdown.

> > connecting to Uuid "{00001101-0000-1000-8000-00805f9b34fb}"
> > connectToService() "00:13:43:06:75:62" "{00001101-0000-1000-8000-00805f9b34fb}"
> > Connnecting via insecure rfcomm\
>
> So it tries rfcomm first.
>
> > Connecting socket
> > The connection step took more than expected. Wait another 20 seconds
>
> ..except it never connected.
>
> > Falling back to reverse uuid workaround.
> > Workaround failed
>
> This failed too.
>
> > Failed to connect to device 00:13:43:06:75:62 . Device state QBluetoothSocket::UnconnectedState . Error: QBluetoothSocket::ServiceNotFoundError
>
> So now we failed the rfcomm, but since it supports LE too, we go and try that:
>
> > Creating Android Central/Client support for BTLE
> > qt_ble_open( 00:13:43:06:75:62 )
> > timeout while trying to connect to the controller 00:13:43:06:75:62
>
> But it didn't even get as far as connecting, much less getting a service list.
>
> > Any idea what to poke at next?
>
> It's like the Petrel isn't really willing to talk to your device.
>
> Maybe the same old "Shearwater dive computers have some random memory
> of what they talked to last, and refuse to talk to anybody else". With
> some unknown rule for what that memory is..

Yeah, but Shearwater says it doesn't. There must be something magic that
we aren't sending to the dive computer. Or something.

> I have no idea.

Drat.

/D

[Linus Torvalds]

On Wed, Apr 25, 2018 at 4:21 PM, Dirk Hohndel <***@hohndel.org> wrote:
>>
>> Ok, so it's using the BLE code, it just isn't able to get a service list. Odd.
>
> Indeed - what's the next step to debug this? My guess is that we should
> somehow dump what we get back?

We do. Normally you'd see that whole song and dance:

connected to the controller for device F0:73:0A:BA:CD:F9
.. discovering services
Sending read_by_group_type request, startHandle: 1 endHandle: ffff 2800
Received size: 3 data: "035000"
Server MTU: 80 resulting mtu: 80
Received size: 14 data: "11060100090000180a000a000118"
Found uuid: "{00001800-0000-1000-8000-00805f9b34fb}" start handle: 1
end handle: 9
Found service "{00001800-0000-1000-8000-00805f9b34fb}"

from our normal BLE debug messages.

>> Maybe the same old "Shearwater dive computers have some random memory
>> of what they talked to last, and refuse to talk to anybody else". With
>> some unknown rule for what that memory is..
>
> Yeah, but Shearwater says it doesn't. There must be something magic that
> we aren't sending to the dive computer. Or something.

It may just have some very limited bluetooth stack, and be very picky,
and there's something randomly going wrong.

Linus

[Dirk Hohndel]

On Wed, Apr 25, 2018 at 04:24:25PM -0700, Linus Torvalds wrote:
> On Wed, Apr 25, 2018 at 4:21 PM, Dirk Hohndel <***@hohndel.org> wrote:
> >>
> >> Ok, so it's using the BLE code, it just isn't able to get a service list. Odd.
> >
> > Indeed - what's the next step to debug this? My guess is that we should
> > somehow dump what we get back?
>
> We do. Normally you'd see that whole song and dance:
>
> connected to the controller for device F0:73:0A:BA:CD:F9
> .. discovering services
> Sending read_by_group_type request, startHandle: 1 endHandle: ffff 2800
> Received size: 3 data: "035000"
> Server MTU: 80 resulting mtu: 80
> Received size: 14 data: "11060100090000180a000a000118"
> Found uuid: "{00001800-0000-1000-8000-00805f9b34fb}" start handle: 1
> end handle: 9
> Found service "{00001800-0000-1000-8000-00805f9b34fb}"

That's what I thought - so we haven't turned that off by mistake or
anything...

> >> Maybe the same old "Shearwater dive computers have some random memory
> >> of what they talked to last, and refuse to talk to anybody else". With
> >> some unknown rule for what that memory is..
> >
> > Yeah, but Shearwater says it doesn't. There must be something magic that
> > we aren't sending to the dive computer. Or something.
>
> It may just have some very limited bluetooth stack, and be very picky,
> and there's something randomly going wrong.

I'm reading the Shearwater Cloud Beta information... under "I am having
trouble connecting my Android device to my dive computer" they write:

There are a few ways you can try to establish connectivity with your Android device:

Restart the app
Ensure “Location Services” are enabled
Restarting the Bluetooth connection every 30 seconds
Restart the Android device


The second one is an oddity in Android BLE permissions. That isn't our
problem as other BLE devices work.
The third one is interesting... not sure what to do with that.

So clearly there is some Shearwater issue hidden here. I'll keep playing
with it. So frustrating.

/D

[Dirk Hohndel]

So Shearwater is not going to win any awards for their Bluetooth implementation,
that seems pretty sure.
Through literally several dozen tries and reboots and random sequences, I got my
old BT-only Mac to connect with the Petrel 2 in order to do a Firmware update to
the latest (53).
I then finally got Android to connect at all. This is in no cloud mode, empty log file:

"4.696: DCDownloadThread started for Petrel 2 on LE:00:13:43:0D:2B:30"
Starting download from BT
Starting the thread 0
"4.698: dc_descriptor_get_transports"
"4.698: SERIAL BT BLE "
"4.698: get_supported_transports returns"
"4.698: BLE "
Creating Android Central/Client support for BTLE
qt_ble_open( 00:13:43:0D:2B:30 )
Connection updated: error: QLowEnergyController::Error(NoError) oldState: QLowEnergyController::ControllerState(ConnectingState) newState: QLowEnergyController::ControllerState(ConnectedState)
connected to the controller for device 00:13:43:0D:2B:30
.. 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(0xc52d6de0)
Discovery of "{fe25c237-0ece-443c-b0aa-e02033e7029d}" started
Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) QLowEnergyServicePrivate(0xc5271c00)
.. done discovering services
.. discovering details
.. enabling notifications
Deleting BLE object
"4.929: No new dives downloaded from dive computer"
Finishing the thread Dive data import error dives downloaded 0
no new dives downloaded
"4.932: DCDownloadThread finished”

So we are successfully connecting, are discovering the services and then we give
up right away. Not sure if this adds any more useful information, but I thought I’d
pass it along.

/D

[Linus Torvalds]

On Fri, Apr 27, 2018 at 11:25 AM Dirk Hohndel <***@hohndel.org> wrote:

> Through literally several dozen tries and reboots and random sequences, I
got my
> old BT-only Mac to connect with the Petrel 2 in order to do a Firmware
update to
> the latest (53).
> I then finally got Android to connect at all.

Ok, so the firmware update at least made some change. That's a good sign,
in that it does imply that at least _some_ of the problems were due to a
bug that the Shearwater people knew about and fixed.

> This is in no cloud mode, empty log file:

> "4.696: DCDownloadThread started for Petrel 2 on LE:00:13:43:0D:2B:30"
> Starting download from BT
> Starting the thread 0
> "4.698: dc_descriptor_get_transports"
> "4.698: SERIAL BT BLE "
> "4.698: get_supported_transports returns"
> "4.698: BLE "
> Creating Android Central/Client support for BTLE
> qt_ble_open( 00:13:43:0D:2B:30 )
> Connection updated: error: QLowEnergyController::Error(NoError) oldState:
QLowEnergyController::ControllerState(ConnectingState) newState:
QLowEnergyController::ControllerState(ConnectedState)
> connected to the controller for device 00:13:43:0D:2B:30
> .. 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(0xc52d6de0)
> Discovery of "{fe25c237-0ece-443c-b0aa-e02033e7029d}" started
> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end:
9 ) QLowEnergyServicePrivate(0xc5271c00)
> .. done discovering services
> .. discovering details
> .. enabling notifications

Ok, this all looks successful.

> Deleting BLE object
> "4.929: No new dives downloaded from dive computer"

Hmm. I'm not seeing any errors here either, but I'm surprised to not see
any actual *communication* debugging.

I wonder if that got turned off in your version of Qt? Because all the
messages above are our _own_ qdebug output.

The actual *data* transfer debugging is from qt itself, and we turn it on
and off with

QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
true"));
QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
false"));

and I wonder if maybe Qt itself stopped doing those debug messages?

For example, on my desktop, I see not just the "Found service" messages
that we output, I also see a lot of other debug data from Qt itself:

..
Sending read_by_group_type request, startHandle: b endHandle: ffff 2800
Received size: 22 data: "11140b00ffff9d02e73320e0aab03c44ce0e37c225fe"
Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}" start handle: b end
handle: ffff
Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
..

and your log doesn't have any of that. So then the fact that you *also*
don't have the actual IO debugging actually makes sense.

> Finishing the thread Dive data import error dives downloaded 0
> no new dives downloaded
> "4.932: DCDownloadThread finished”

Because this would all be successful for the "no dives on the dive
computer" case other than the complete lack of debug messages..

> So we are successfully connecting, are discovering the services and then
we give
> up right away. Not sure if this adds any more useful information, but I
thought I’d
> pass it along.

I think "we give up right away" may actually be "we exchanged just a couple
of packets and found that there were no dives".

Did the firmware update perhaps reset the dive computer entirely and remove
all dives on the dive computer?

Linus

[Dirk Hohndel]

> On Apr 27, 2018, at 11:46 AM, Linus Torvalds <***@linux-foundation.org> wrote:
>> I then finally got Android to connect at all.
>
> Ok, so the firmware update at least made some change. That's a good sign,
> in that it does imply that at least _some_ of the problems were due to a
> bug that the Shearwater people knew about and fixed.

Yes - but there’s still something seriously broken when talking to Android
devices - both using Subsurface and Sheawater’s own app.
>> Deleting BLE object
>> "4.929: No new dives downloaded from dive computer"
>
> Hmm. I'm not seeing any errors here either, but I'm surprised to not see
> any actual *communication* debugging.
>
> I wonder if that got turned off in your version of Qt? Because all the
> messages above are our _own_ qdebug output.
>
> The actual *data* transfer debugging is from qt itself, and we turn it on
> and off with
>
> QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
> true"));
> QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
> false"));
>
> and I wonder if maybe Qt itself stopped doing those debug messages?
>
> For example, on my desktop, I see not just the "Found service" messages
> that we output, I also see a lot of other debug data from Qt itself:
>
> ..
> Sending read_by_group_type request, startHandle: b endHandle: ffff 2800
> Received size: 22 data: "11140b00ffff9d02e73320e0aab03c44ce0e37c225fe"
> Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}" start handle: b end
> handle: ffff
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
> ..
>
> and your log doesn't have any of that. So then the fact that you *also*
> don't have the actual IO debugging actually makes sense.

I switched to a newer Qt version - it would be strange for them to disable
something as critical as this, but definitely worth investigating further.

>> Finishing the thread Dive data import error dives downloaded 0
>> no new dives downloaded
>> "4.932: DCDownloadThread finished”
>
> Because this would all be successful for the "no dives on the dive
> computer" case other than the complete lack of debug messages..
>
>> So we are successfully connecting, are discovering the services and then
> we give
>> up right away. Not sure if this adds any more useful information, but I
> thought I’d
>> pass it along.
>
> I think "we give up right away" may actually be "we exchanged just a couple
> of packets and found that there were no dives".
>
> Did the firmware update perhaps reset the dive computer entirely and remove
> all dives on the dive computer?

Nope. I just completed an iOS build with the latest code and that connected
without a problem and downloaded the 20 dives on this dive computer via
BLE. This is with the current master.

/D

[Lubomir I. Ivanov]

On 27 April 2018 at 22:46, Dirk Hohndel <***@hohndel.org> wrote:
>
>> On Apr 27, 2018, at 11:46 AM, Linus Torvalds <***@linux-foundation.org> wrote:
>>
>> Hmm. I'm not seeing any errors here either, but I'm surprised to not see
>> any actual *communication* debugging.
>>
>> I wonder if that got turned off in your version of Qt? Because all the
>> messages above are our _own_ qdebug output.
>>
>> The actual *data* transfer debugging is from qt itself, and we turn it on
>> and off with
>>
>> QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
>> true"));
>> QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
>> false"));
>>
>> and I wonder if maybe Qt itself stopped doing those debug messages?
>>
>> For example, on my desktop, I see not just the "Found service" messages
>> that we output, I also see a lot of other debug data from Qt itself:
>>
>> ..
>> Sending read_by_group_type request, startHandle: b endHandle: ffff 2800
>> Received size: 22 data: "11140b00ffff9d02e73320e0aab03c44ce0e37c225fe"
>> Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}" start handle: b end
>> handle: ffff
>> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
>> ..
>>
>> and your log doesn't have any of that. So then the fact that you *also*
>> don't have the actual IO debugging actually makes sense.
>
> I switched to a newer Qt version - it would be strange for them to disable
> something as critical as this, but definitely worth investigating further.
>

i don't see any changes here that disable debugging output:
https://github.com/qt/qtconnectivity/blob/5.10/src/bluetooth/qlowenergycontroller_android.cpp
(same goes for 5.10.1 and the 5.11 branches)
.
the log entry "Service discovery initiated" can be seen and it's
visibility is controlled by the same logging rules as those for
reading and writing of characteristics and descriptors.

> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) QLowEnergyServicePrivate(0xc5271c00)

^ so a non-standard service is found here.

> .. done discovering services
> .. discovering details
> .. enabling notifications

https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L377

at this point given this isn't a HW DC (Shearwater instead?) it should
list the descriptors for this service's last characteristic if the
service has characteristics.
i think the list of characteristics is empty.

i guess this can be confirmed by this slot which should trigger when
we start the service details discovery:
https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L47

does the same service UUID have characteristics on iOS?
if yes, i think this might be a bug in qt-ble-android.

btw, what Qt version is this for Android?

lubomir
--

[Dirk Hohndel]

> On Apr 27, 2018, at 1:48 PM, Lubomir I. Ivanov <***@gmail.com> wrote:
>>
>> I switched to a newer Qt version - it would be strange for them to disable
>> something as critical as this, but definitely worth investigating further.

It seems that I DIDN’T switch to a newer Qt after all. Strange. Something is mixed
up in my build script it seems.

> i don't see any changes here that disable debugging output:
> https://github.com/qt/qtconnectivity/blob/5.10/src/bluetooth/qlowenergycontroller_android.cpp
> (same goes for 5.10.1 and the 5.11 branches)
> .
> the log entry "Service discovery initiated" can be seen and it's
> visibility is controlled by the same logging rules as those for
> reading and writing of characteristics and descriptors.
>
>> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) QLowEnergyServicePrivate(0xc5271c00)
>
> ^ so a non-standard service is found here.
>
>> .. done discovering services
>> .. discovering details
>> .. enabling notifications
>
> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L377
>
> at this point given this isn't a HW DC (Shearwater instead?) it should
> list the descriptors for this service's last characteristic if the
> service has characteristics.
> i think the list of characteristics is empty.

It doesn’t seem impossible, given all the issues with their BT/BLE stack


> i guess this can be confirmed by this slot which should trigger when
> we start the service details discovery:
> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L47
>
> does the same service UUID have characteristics on iOS?
> if yes, i think this might be a bug in qt-ble-android.
>
> btw, what Qt version is this for Android?

We are still on 5.9.3.
I need to figure out why 5.10.1 didn’t build as intended

/D

[Lubomir I. Ivanov]

On 28 April 2018 at 00:03, Dirk Hohndel <***@hohndel.org> wrote:
>
>> On Apr 27, 2018, at 1:48 PM, Lubomir I. Ivanov <***@gmail.com> wrote:
>>>
>>> I switched to a newer Qt version - it would be strange for them to disable
>>> something as critical as this, but definitely worth investigating further.
>
> It seems that I DIDN’T switch to a newer Qt after all. Strange. Something is mixed
> up in my build script it seems.
>
>> i don't see any changes here that disable debugging output:
>> https://github.com/qt/qtconnectivity/blob/5.10/src/bluetooth/qlowenergycontroller_android.cpp
>> (same goes for 5.10.1 and the 5.11 branches)
>> .
>> the log entry "Service discovery initiated" can be seen and it's
>> visibility is controlled by the same logging rules as those for
>> reading and writing of characteristics and descriptors.
>>
>>> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) QLowEnergyServicePrivate(0xc5271c00)
>>
>> ^ so a non-standard service is found here.
>>
>>> .. done discovering services
>>> .. discovering details
>>> .. enabling notifications
>>
>> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L377
>>
>> at this point given this isn't a HW DC (Shearwater instead?) it should
>> list the descriptors for this service's last characteristic if the
>> service has characteristics.
>> i think the list of characteristics is empty.
>
> It doesn’t seem impossible, given all the issues with their BT/BLE stack
>
>

> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) QLowEnergyServicePrivate(0xc5271c00)

just realized that 9 / 9 mean the start and end handle for this service.
so i guess that also confirms that the service has no characteristics
if they are equal.

the origin of the handles comes from the java backend.
the file hasn't seen activity since July 2017.

it might be hard to figure out what's going on unless some debug code
is added in this java file near the callers of this function:
https://github.com/qt/qtconnectivity/blob/5.10.1/src/android/bluetooth/src/org/qtproject/qt5/android/bluetooth/QtBluetoothLE.java#L867

the comment on top of the function says:
"//TODO function not yet used"

yet, i see that's it's being used to make this JNI call
"leServiceDetailDiscoveryFinished()" which reaches the C++ methods
that trigger the debug messages such as the one above:
"Service XXXX discovered (..."

>> i guess this can be confirmed by this slot which should trigger when
>> we start the service details discovery:
>> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L47
>>
>> does the same service UUID have characteristics on iOS?
>> if yes, i think this might be a bug in qt-ble-android.
>>
>> btw, what Qt version is this for Android?
>
> We are still on 5.9.3.
> I need to figure out why 5.10.1 didn’t build as intended
>

i think that the issue comes from the java backend which hasn't seen
new contributions, so this could still be present in the latest Qt
too.
i would try with another device to narrow down if this is an issue
with the Android OS version with the Android device BLE hardware.

lubomir
--

[Dirk Hohndel]

> On Apr 27, 2018, at 2:49 PM, Lubomir I. Ivanov <***@gmail.com> wrote:
>
>> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) QLowEnergyServicePrivate(0xc5271c00)
>
> just realized that 9 / 9 mean the start and end handle for this service.
> so i guess that also confirms that the service has no characteristics
> if they are equal.

That makes sense

> the origin of the handles comes from the java backend.
> the file hasn't seen activity since July 2017.
>
> it might be hard to figure out what's going on unless some debug code
> is added in this java file near the callers of this function:
> https://github.com/qt/qtconnectivity/blob/5.10.1/src/android/bluetooth/src/org/qtproject/qt5/android/bluetooth/QtBluetoothLE.java#L867
>
> the comment on top of the function says:
> "//TODO function not yet used"
>
> yet, i see that's it's being used to make this JNI call
> "leServiceDetailDiscoveryFinished()" which reaches the C++ methods
> that trigger the debug messages such as the one above:
> "Service XXXX discovered (…"

Interesting - definitely there are oddities in that Java code. I just noticed
that my dual stack Petrel 2 isn’t recognized as dual stack at all - only as
BT device.

>>> i guess this can be confirmed by this slot which should trigger when
>>> we start the service details discovery:
>>> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L47
>>>
>>> does the same service UUID have characteristics on iOS?
>>> if yes, i think this might be a bug in qt-ble-android.
>>>
>>> btw, what Qt version is this for Android?
>>
>> We are still on 5.9.3.
>> I need to figure out why 5.10.1 didn’t build as intended
>>
>
> i think that the issue comes from the java backend which hasn't seen
> new contributions, so this could still be present in the latest Qt
> too.
> i would try with another device to narrow down if this is an issue
> with the Android OS version with the Android device BLE hardware.

I’ll have to see what other Android devices I have that support BLE and
have a different Android OS version - since I tend to update fairly actively
to deal with the security issues in Android, I’m not sure how much luck I’m
going to have there…

/D

[Dirk Hohndel]

> On Apr 27, 2018, at 2:53 PM, Dirk Hohndel <***@hohndel.org> wrote:
>
>
>> On Apr 27, 2018, at 2:49 PM, Lubomir I. Ivanov <***@gmail.com> wrote:
>>
>>> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) QLowEnergyServicePrivate(0xc5271c00)
>>
>> just realized that 9 / 9 mean the start and end handle for this service.
>> so i guess that also confirms that the service has no characteristics
>> if they are equal.
>
> That makes sense

More testing shows even less reasonable results.

Android only ever sees the Petrel 2 as type 2 (BLE only) device (even though it should
be a type 3 (dual stack) device).
Trying to force a BLE bonding from nRF Connect makes the BT stack crash.
Trying to download over BLE from Subsurface-mobile on Android fails as described.
But… ignoring the “BLE only” designation and instead downloading via rfcomm succeeds.

Hrmpf.

I guess I’ll have to add a special case for Petrel devices that if they fail on BLE they should
try BT after all, anyway? Not my preferred solution, but I’m not sure what else to try.

/D

[Lubomir I. Ivanov]

On 28 April 2018 at 02:01, Dirk Hohndel <***@hohndel.org> wrote:
>
>> On Apr 27, 2018, at 2:53 PM, Dirk Hohndel <***@hohndel.org> wrote:
>>
>>
>>> On Apr 27, 2018, at 2:49 PM, Lubomir I. Ivanov <***@gmail.com> wrote:
>>>
>>>> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) QLowEnergyServicePrivate(0xc5271c00)
>>>
>>> just realized that 9 / 9 mean the start and end handle for this service.
>>> so i guess that also confirms that the service has no characteristics
>>> if they are equal.
>>
>> That makes sense
>
> More testing shows even less reasonable results.
>
> Android only ever sees the Petrel 2 as type 2 (BLE only) device (even though it should
> be a type 3 (dual stack) device).
> Trying to force a BLE bonding from nRF Connect makes the BT stack crash.
> Trying to download over BLE from Subsurface-mobile on Android fails as described.
> But… ignoring the “BLE only” designation and instead downloading via rfcomm succeeds.
>
> Hrmpf.
>
> I guess I’ll have to add a special case for Petrel devices that if they fail on BLE they should
> try BT after all, anyway? Not my preferred solution, but I’m not sure what else to try.
>

here is a similar problem after googling:

https://stackoverflow.com/questions/48659598/ble-device-works-on-ios-but-not-on-android

"BLE device works on ios but not on Android"
" I can connect to the device, but one of the Service (UUID:7570)
becomes empty, and I can't read or write to any characteristic."
"If a service is empty when it shouldn't be, it's probably incorrectly
set up at the GATT server"

if nRF Connect is crashing this might not be a Qt bug.

this app claims that it can enumerate the services and characteristics
on a device:
https://play.google.com/store/apps/details?id=com.macdom.ble.blescanner&hl=en_US

if such apps don't work then it's not a Qt bug.
if it works on another Android phone then it's OS / HW specific.
if it's an Android wide issue i think the fallback to classic BT is a
good option for this device / vendor, for now.

lubomir
--

[Davide DB]

As final user I can do no other than express my utmost appreciation for
you guys trying to untangle this mess fo BT Petrel stack, OS version and
Libdivecomputer.
Without going deeper into Subsurface download it's clear to me that the
problem starts with the Android BT pairing already.

With my Petrel 2 dual stack controller

LG Xpower 220 & Android 6.0.1:
- I see the device but as I try to pair, Petrel shows a "BT INIT FAIL" and
quits.
- The phone believes that pairing was ok and shows me something like
00:13:43:5B:8F:BE address.
- Subsurface see this address but of course it doesn't work.

Nexus 5x & Android 8.1.0
- I see the device and I can pair successfully.
- Subsurface sees two addresses. Something like:
00:13:43:5B:8F:BE
LE:00:13:43:5B:8F:BE
- LE download doesn't start at all saying there are no new dives on device
(but the Petrel shows no sign of packet exchange)
- normal BT download works but after few dives Petrel shows a "Error
sending packet" error. My workaround is stopping the download after 2 or 3
dives so I can save them.

Nexus 7 (1st gen.) & Android 4.4
- I see the device and I can pair successfully.
- Subsurface sees one address. Something like 00:13:43:5B:8F:BE address
- normal BT download works but after few dives Petrel shows a "Error
sending packet" error. My workaround is stopping the download after 2 or 3
dives so I can save them.

About Libdivecomputer

I'm convinced that the underlying Libdivecomputer Shearwater protocol impl.
has some problem already.
In the past I downloaded raw Petrel controller data with dctool on a number
of different devices and OS and I was never able to complete a download.
At some point I always get an "Error sending packet" on Petrel. On the
contrary the Shearwater desktop/mobile download is always 100% reliable.

[Chirana Gheorghita Eugeniu Theodor]

Maibe shearwater support should be informed?? For me using their win
application always fails. My other friend who has latest perdix did not
even once succeded in connecting to computer.

On Mon, Apr 30, 2018, 13:21 Davide DB <***@gmail.com> wrote:

> As final user I can do no other than express my utmost appreciation for
> you guys trying to untangle this mess fo BT Petrel stack, OS version and
> Libdivecomputer.
> Without going deeper into Subsurface download it's clear to me that the
> problem starts with the Android BT pairing already.
>
> With my Petrel 2 dual stack controller
>
> LG Xpower 220 & Android 6.0.1:
> - I see the device but as I try to pair, Petrel shows a "BT INIT FAIL" and
> quits.
> - The phone believes that pairing was ok and shows me something like
> 00:13:43:5B:8F:BE address.
> - Subsurface see this address but of course it doesn't work.
>
> Nexus 5x & Android 8.1.0
> - I see the device and I can pair successfully.
> - Subsurface sees two addresses. Something like:
> 00:13:43:5B:8F:BE
> LE:00:13:43:5B:8F:BE
> - LE download doesn't start at all saying there are no new dives on device
> (but the Petrel shows no sign of packet exchange)
> - normal BT download works but after few dives Petrel shows a "Error
> sending packet" error. My workaround is stopping the download after 2 or 3
> dives so I can save them.
>
> Nexus 7 (1st gen.) & Android 4.4
> - I see the device and I can pair successfully.
> - Subsurface sees one address. Something like 00:13:43:5B:8F:BE address
> - normal BT download works but after few dives Petrel shows a "Error
> sending packet" error. My workaround is stopping the download after 2 or 3
> dives so I can save them.
>
> About Libdivecomputer
>
> I'm convinced that the underlying Libdivecomputer Shearwater protocol impl.
> has some problem already.
> In the past I downloaded raw Petrel controller data with dctool on a number
> of different devices and OS and I was never able to complete a download.
> At some point I always get an "Error sending packet" on Petrel. On the
> contrary the Shearwater desktop/mobile download is always 100% reliable.
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>

[Willem Ferguson]

On 30/04/2018 12:20, Davide DB wrote:
> On the
> contrary the Shearwater desktop/mobile download is always 100% reliable.
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

If it works reliably on the desktop, then it is unlikely to be a
libdivecomputer problem.

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.

[Davide DB]

On Mon, 30 Apr 2018 at 13:45, Willem Ferguson <
***@zoology.up.ac.za> wrote:

> On 30/04/2018 12:20, Davide DB wrote:
> > On the
> > contrary the Shearwater desktop/mobile download is always 100% reliable.
> > _______________________________________________
> > subsurface mailing list
> > ***@subsurface-divelog.org
> > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

> If it works reliably on the desktop, then it is unlikely to be a
> libdivecomputer problem.

For me it works flawlessly either on desktop and mobile.
On the contrary I was never able to completely download a Petrel with
dctool on desktop.

Bye