Bluetooth LE - wclThread?

[mentosan]

Hello

I am currently evaluating the Bluetooth library and it looks very promising.
I am using it for coding a BLE Client which uses the beacon watcher to wait for a specific custom UUID, then I attempt to connect to that address and read our custom service/characteristics/data.
What I am not sure about is how should I _continuously read data_ after finding my characteristic.
I am looping now inside a Task and I am not 100% sure this is the right approach (sometimes the client.Disconnect or manager.Close hang indefinitely and I am afraid of a deadlock).

What I have now:

* discovering the UUID via beacon watcher
* in ClientConnected event, I enumerate the services, then I find the characteristic (everything happens in the main thread) and the I spawn a task where I read characteristic value until no value comes back (which means our peripheral stopped streaming data).

Is calling the ReadCharacteristicValue on a different thread a potential issue?
Should I refactor my code and perform all operations inside a wclThread (hoping that if the client/manager hang I could kill the thread and recreate it)?

Thanks a lot in advance for any suggestion!

Best regards,
Radu

[Mike Petrichenko]

Hello,

Call to ReadCharacteristicValue in separate thread is OK and absolutely safe in common cases. However it is always better to have all the connection and communication code in single thread because of hard synchronization otherwise.

Let say you call ReadCharacteristicValue and it started executing. Then CPU switchs to other task and disconnect appears. All resources have been released and when CPU switches back to Read execution there is potential A/V.

I recommend to use wclThread for such cases and put wclGattClient object in this thread together with all connect/disconnect/services reading methods. That is safer and faster.

One more tip: it is not good idea to read characteristics values that way you are trying to do it. BLE developed to be more power safe and provides other methods to get continuous data from a device. The best way for your task is characteristic change notifications. Of course if your device does not provide this then yes, the only way is to read data in loop. But add some delays between each read call.

[mentosan]

Hello and thank you for the fast reply!

As I am also coding the mobile app (which provides the GATT server) I think that I will be able to use change notifications.
This will indeed be more power efficient and matches the actual data stream we have (data gets rarely updated) !

Thanks a lot!

[mentosan]

Evaluation of your Bluetooth library is over: I've managed to get both polling and notifications working. The notifications way will stay and get into production.

Your libraries are excellent (we use the WiFi lib too); we'll buy the complete library during next week.

Thank you!

[Mike Petrichenko]

Greate that you got it working. We are about to publish new version with GATT server support (we have already done services and characteristic publishing, read and write characteristics values). Only notifications left.

[mentosan]

Our GATT server runs inside a mobile app (Xamarin), but I am sure that a .NET implementation will help tons of other use cases.
For Windows, we only need the client, which is perfectly provided by your library.