Cleaned up and rebased "libdivecomputer-NG" branch

[Linus Torvalds]

On Wed, Apr 25, 2018 at 4:08 PM, Dirk Hohndel <dirk at 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