OSTC over BLE experiences and questions

Alex Blasche alexander.blasche at qt.io
Wed Jul 12 06:12:15 PDT 2017



> -----Original Message-----
> From: Dirk Hohndel [mailto:dirk at hohndel.org]
> On Wed, Jul 12, 2017 at 12:02:35PM +0200, Jan Mulder wrote:
> > On 11-07-17 16:27, Dirk Hohndel wrote:
> > >
> > > > And in the meantime, I tried Android, with Qt 5.9.1 but no success yet.
> > > > Cannot open device (BLE that is, BT just works).
> > >
> > > Often that means that they are not connected / bonded. Since we
> > > don't try to do the scan / connect ourselves, we are relying on
> > > Android doing that for us. What reliably works for me is to have nRF
> > > Connect scan, connect, then bond, and THEN start Subsurface-mobile.
> > > But of course it's possible that there's yet more oddity here with the chip
> used on the OSTC...
> >
> > The OSTC3 is correctly bonded (according to Nordics nRF Connect). That
> > is, for BLE. It currently shows up on Android side only as BLE
> > capable, so no BaseRate BT, but that seems fine for this test.
> 
> I have seen this with a couple of dual stack devices. Android appears to only see
> the BLE side, not the BT side. I'm bothered by that since BLE tends to be a lot
> slower.
> 
> Alex, any insight into that?

On some platforms including Bluez you have to be a bit creative to figure out whether a device is Classic/LE/dual. However Android is pretty straight forward as there are two different API's responsible for it. At least QtBluetooth can directly map those cases. 

I would not rule out a certain low level device discovery flag not being set. An interesting question to try out is to run a classic SDP service discovery. Does that reveal anything? You can do that with QBluetoothServiceDiscoveryAgent::start(FullDiscovery).

> > I'm afraid that I will have to get a Qt install from source ... The
> > qt_ble_open() fails on a timeout (of a ridiculous 12 seconds) with
> > QLowEnergyController::ControllerState(ConnectingState) during
> > controller->connectToDevice().
> >
> > Maybe this is a question for Alex ... so some extra details.
> > Running Lineageos, Android 7.1.2, so a very new AOSP variant. Compiled
> > Subsurface-mobile for Android on Arch Linux, using Qt 5.9.1
> >
> > Some relevant logcat data is attached, but does not show anything
> > suspicious to me.
> >
> > So my question for Alex at this point: do you see anything strange in
> > the logcat fragment, and it there anything I can do to further
> > investigate the issue?
> 
> > 07-12 11:07:50.121 18522 18541 D subsurface/qt-models/messagehanINFO:
> "21.169: DCDownloadThread started for LE:00:80:25:4A:0F:C3"
> > 07-12 11:07:50.123 18522 18573 D subsurface/qt-models/messagehanINFO:
> > Starting download from  BT
> > 07-12 11:07:50.123 18522 18573 D subsurface/qt-models/messagehanINFO:
> > Starting the thread 0
> > 07-12 11:07:50.184 18522 18573 D subsurface/qt-models/messagehanINFO:
> > Creating Android Central/Client support for BTLE
> > 07-12 11:07:50.187 18522 18573 D subsurface/qt-models/messagehanINFO:
> > qt_ble_open( 00:80:25:4A:0F:C3 )
> > 07-12 11:07:50.192 18522 18573 D BluetoothGatt: connect() - device:
> > 00:80:25:4A:0F:C3, auto: false
> > 07-12 11:07:50.192 18522 18573 D BluetoothGatt: registerApp()
> > 07-12 11:07:50.193 18522 18573 D BluetoothGatt: registerApp() -
> > UUID=3c7ff85f-2377-4ce3-a8d3-758f0dd3a9bf
> > 07-12 11:07:50.196 18522 18534 D BluetoothGatt: onClientRegistered() -
> > status=0 clientIf=6
> > 07-12 11:07:50.196 18522 18573 W QtBluetoothGatt: Using Android v23
> > BluetoothDevice.connectGatt()
> > 07-12 11:07:50.196  7132  7145 D A2dpService: getA2DPService():
> > returning com.android.bluetooth.a2dp.A2dpService at 148e071
> > 07-12 11:07:50.196  7132  7145 I A2dpService: audio isMusicActive is
> > false
> > 07-12 11:07:50.197  7132  7162 D bt_btif_config:
> > btif_get_address_type: Device [00:80:25:4a:0f:c3] address type 0
> > 07-12 11:07:50.197  7132  7162 D bt_btif_config: btif_get_device_type:
> > Device [00:80:25:4a:0f:c3] type 2
> > 07-12 11:08:02.999 18522 18573 D subsurface/qt-models/messagehanINFO:
> > failed to connect to the controller  00:80:25:4A:0F:C3 with  error ""
> > and state QLowEnergyController::ControllerState(ConnectingState)
> > 07-12 11:08:03.000 18522 18573 D BluetoothGatt: cancelOpen() - device:
> > 00:80:25:4A:0F:C3
> > 07-12 11:08:03.002  7132  7169 W bt_btif : bta_gattc_conn_cback() -
> > cif=3 connected=0 conn_id=3 reason=0x0100
> > 07-12 11:08:03.002  7132  7169 W bt_btif : bta_gattc_conn_cback() -
> > cif=4 connected=0 conn_id=4 reason=0x0100
> > 07-12 11:08:03.002  7132  7169 W bt_btif : bta_gattc_conn_cback() -
> > cif=5 connected=0 conn_id=5 reason=0x0100
> > 07-12 11:08:03.002  7132  7169 W bt_btif : bta_gattc_conn_cback() -
> > cif=6 connected=0 conn_id=6 reason=0x0100
> > 07-12 11:08:03.002  7132  7169 E bt_btif : bta_gattc_mark_bg_conn
> > unable to find the bg connection mask for: 00:80:25:4a:0f:c3

There should have been another line below that tells me what the error code of the callback was. You cut the log too short.

Error 133 is probably the worst of them as it's Android's "I have no clue" explanation. You'd have to take apart the btle stack on the device. One aspect that might still help is the hci log. If you could send it to me then I could check whether I can find something in it that might explain it (for details see http://www.fte.com/webhelp/sodera/Content/Documentation/WhitePapers/BPA600/Encryption/GettingAndroidLinkKey/RetrievingHCIlog.htm)

> I have seen this behavior with my EON Steel. It claims to be connected and
> bonded, yet won't connect. If I disconnect and remove bond information in nRF
> Connect, forget mobile on the dive computer, then connect again (it asks me to
> enter a PIN again) and bond, then restart Subsurface-mobile, it works.
> 
> No idea why. BLE is weird.

This case does look similar to the case Dirk had 2 weeks ago. Forget and retry can indeed help. 

--
Alex


More information about the subsurface mailing list