OSTC over BLE experiences and questions

Alex Blasche alexander.blasche at qt.io
Wed Jul 12 23:30:05 PDT 2017


>this email off-list, as I do not want to scrutinize the logcat on any
>unwanted disclosures.
...
>However, the good things is that the logcat now contains more relevant
>data, and the failure is now in "controller->discoverServices();" that
>does not find the wanted service ... which is code that is (obviously)
>perfectly working on Linux with Bluez stack. So, any ideas on this one?

The hci log does not contain the gatt communication which is what I was after. Damn. I thought this traffic type was automatically included.... Linus' last traces from Android had GATT communication in them too. Linus, did you do sth special to enable the gatt log in your hci snoop on Android when doing the EON Steel monitoring? 

OK, looking through your log I can see a few strange things. Here is the relevant sections of the log:

07-12 15:32:54.840  4741  4837 W QtBluetoothGatt: Performing queued job, handle: 18 Read (false) ValueKnown: false Skipping: false Descriptor
...
07-12 15:32:57.843  4741  4741 W QtBluetoothGatt: ****** Timeout for request on handle 18
07-12 15:32:57.843  4741  4741 W QtBluetoothGatt: ****** Looks like the characteristic or descriptor does NOT act in accordance to Bluetooth 4.x spec.
07-12 15:32:57.843  4741  4741 W QtBluetoothGatt: ****** Please check server implementation. Continuing under reservation.
07-12 15:32:57.843  4741  4741 W QtBluetoothGatt: Performing queued job, handle: 19 Read (false) ValueKnown: false Skipping: true Characteristic
07-12 15:32:57.843  4741  4741 D QtBluetoothGatt: Non-readable characteristic 00000004-0000-1000-8000-008025000000 for service 0000fefb-0000-1000-8000-00805f9b34fb
...
07-12 15:32:57.849  4741  4741 W QtBluetoothGatt: Performing queued job, handle: 21 Read (false) ValueKnown: false Skipping: true Descriptor
07-12 15:32:57.850  4741  4741 D QtBluetoothGatt: Non-readable descriptor 00002902-0000-1000-8000-00805f9b34fb for service/char0000fefb-0000-1000-8000-00805f9b34fb/00000004-0000-1000-8000-008025000000


There is an unusual amount of chars and descriptors in your service (0000fefb) which are not readable or every attempt by Android to read them fails. This is strange because for example a descriptor like the last read for 00002902 (handle 21)  should succeed. If I read the standard right there is no concept of non-readable descriptors. 

Handle 18 above is unusual as well. Trying to read the handle never returns. That's why there is this timeout kicking in. Otherwise the state machine discovering the service details would have been stuck. 

Can you read those descriptors using "nRF Connect". In fact, I would appreciate it if you could send me a snapshot of what the tools tells you about service 0xfefb (including your attempts to read the values). In some way I would argue the timeouts and non-readable chars make the service non-compliant. At the very least it screws up Qt Bluetooth's discovery process.

Since your communication doesn't continue I assume that subsurface is waiting for the state transition of QLowEnergyService from DiscoveringServices to ServiceDiscovered. Can you confirm that? 

The immediate problem that I believe I can see is that the state machine has a missing end transition on my side. The last descriptor read of the service discovery is a failure and therefore the usual Android callbacks which finish the discovery do not kick in. I have to add an exit conditions which unfortunately means that you'll need a custom patch for QtBluetoothLE.java. I am stuck in workshop today and tomorrow. I'll try to squeeze it somewhere in between.

Having said all that I still don't know how much further you get. Depending which chars and descriptors you need to read to retrieve information it may or may not matter.

--
Alex



More information about the subsurface mailing list