HandleCallback not fireing.
ehardin2 opened this issue · comments
In your WinBleTest.cpp I changed the Service and Characteristics to those for the device that I am testing.
In the main.cpp I can enumerate all of the services and all of the characteristics.
In the testSerialService I can setValue for a Tx characteristic in the service that is writeable.
However, when it gets to the part in testSerialService I never get any descriptors. I get a descriptors.size() of 2 so I go into that if (descriptors.size() > 0) block but nothing ever is reported. In fact, the HandleCallback never fires.
Do you still get the HandleCallback for your device? or did something change between VS2017 and VS2019 etc?
Edit Addition:
I started from scratch and opened and compiled in VS2017 with the v141 Toolset and SDK 10.0.18362.0. I changed the UUIDs to those for my device and ran. Again, the HandleCallback never fired.
In case this explains anything since I don't have the data for your device, my main service is FFF0 in which the FFF4 characteristic is for returns (Rx) and only has the IsNotifialbe set to true. The FFF5 is the characteristic for sending commands (Tx) and only has the IsReadable and IsWrteable set to true. If you getValue for this Tx service it will only return the last command sent via setValue.
So, because my Tx does not have an IsNotifiable, I get a txit and a rxit and get a chacteristicTx for the UUID_FFF5Tx_CHARACTERISTIC and a chacteristicRx for the UUID_FFF4Rx_CHARACTERISTIC. I send the command to turn the power on to the characteristicTx. I cannot enumerateBleDescriptors for the Tx since it is not IsNotifiable so, from that point on I use the characteristicRx since it is the receiving characteristic. Everything else remains the same as your testSerialService. I get no errors it is just that HandleCallback never fires and no descriptors are every listed.
The firing of the callback depends on the type of characteristic the test device exposes. The characteristic has to be notifiable inorder to generate a callback. As I have said this code is only POC I already know that the TX characteristic is notifiable so I don't actually check in the console app, in a production quality application all the characteristic attributes should be validated.
The TX and RX characteristic may be the wrong way around in this code. Whats important is the characteristic attributes being notifiable. Note you might actually need to enable notifications from a characteristic. Again this is device specific in my case the characteristic has notification enabled. I think its an attribute of the descriptor that determines if notification is enabled or not, it been awhile since I looked at ble stuff
Welcome to the world of Bluetooth, dispute there being a certification program and a set of tests that devices that are Bluetooth compliant must pass there are unfortunately many reasons why a device does not behave as expected. Sometimes its because the device was never certified, later firmware changes break compatibility with the certification etc. There are also issues with the Bluetooth drivers which cause compatibility issues. I have direct experience of Bluetooth issues caused buy how a chip set vendors driver interpreted the specification. These drivers + chip sets are used in millions of devices.
So you will always find examples of devices + chipsets that don't behave as expected even though they are qualified Bluetooth products.
The opening of the device handle specifies the device should be present. I am not sure if there is a way to determine if the device is still connected. It sounds like the BLE connection is being dropped, hence why the enumeration of the devices works.
Maybe the device handle can be queried to see if the device is still present, but off the top of my head I would not be 100% sure unless I looked into it again.