OSTC over BLE experiences and questions

[Alex Blasche]

> -----Original Message-----
> From: Jan Mulder [mailto:jlmulder at xs4all.nl]

> > 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.
> 
> I have added 3 attachments. Not fully sure that I captured everything you would
> like to see, but I can write to the OSTC (tested this by sending a 0xBB byte, to tell
> the OSTC3 to enter download mode). That session is in the attached txt file. The
> discovery process in there shows a successful service discovery. Further, that
> 0000fefb service is officially given a vendor specific UUID from the Bluetooth
> SIG, so I assume (and hope) that they at least checked for compliance to the
> standard. (and don't worry about the GATT error 133 at the end ... just me
> switching off the OSTC).

This is exactly what I wanted to see. Thank you. 

As you can see in the log from nRF Connect, it is confused that it cannot read the 0x2902 descriptor either. This would confirm a device problem. The descriptor should be readable.

> > 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.

Ok, here is the patch: https://codereview.qt-project.org/#/c/200076/

I was not able to test this due to lack of being able to setup a test server that has exactly this behavior. Hopefully you can verify for me that this finished the service discovery. If it is successful you should see the following logging output:

W QtBluetoothGatt: Finished current discovery for service handle <xyz>

> Don't worry about speed. I am afk the coming 3 days, and think that I
> (finally) have to make a step towards self built Qt.
> 
> > 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.

Believe me when I say this helps you as much as it helps me. Almost all problems I encountered via subsurface were due to strange device behavior. It is always nice to see how a spec translates to real world applications ;)

In case you want to build your own Qt I suggest you configure Qt as follows (my config line for the subsurface build:

-xplatform android-g++ -nomake tests -nomake examples -android-ndk ~/java/android-ndk-r10e/ -android-sdk ~/java/android-sdk-linux/ -android-toolchain-version 4.9 -skip qttranslations -skip qtwebkit -skip
qtserialport -skip qtwebkit-examples -developer-build -opensource -no-warnings-are-errors -confirm-license
-openssl-runtime -I ~/dev/subsurface/openssl-build-arm/include/

You do need r10e ndk or you will encounter build errors due to a compiler bug and clang is not yet supported. You also need the openssl headers which I took from subsurface's build.

In addition there is one more patch which you may need if you encounter Dirk's problem with MTU handling:

https://codereview.qt-project.org/#/c/199117/

Dirk added that to the Android beta binaries.

--
Alex