Cleaned up and rebased "libdivecomputer-NG" branch

Dirk Hohndel dirk at hohndel.org
Wed Apr 25 16:21:02 PDT 2018


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


More information about the subsurface mailing list