> -----Original Message----- > From: Jan Mulder [mailto:[email protected]]
> > 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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
