27
Hey,
Not sure what you mean by "which notifications" but I will try to answer.
We turn on notifications for various characteristics - standard BLE battery service (0x180f) and battery characteristic (0x2a19) and 8 custom characteristics in our device (in 4 custom services). It does not matter whether we turn on notifications in our custom services or only the standard BLE battery service (custom services not used in this case) - the problem always occurs. All the characteristics are either Read/Notify or Read/Write/Notify - no indications are used.
Here is a snippet for the code turning on notifications:
BleError BleCharacteristic::setNotificationEnabled(bool suscribe) {
if (!characteristic.IsNotifiable && !characteristic.IsIndicatable) {
return BleError::CharacteristicNotNotifiable;
}
if (!cccdPresent) {
return BleError::CharacteristicNoCccd;
}
qDebug() << "Start write descriptor for char" << getUuid() << suscribe;
if (suscribe) {
int result = gattClient.SubscribeForNotifications(characteristic, goReadFromDevice, plNone);
if (result != WCL_E_SUCCESS) {
auto errorString = BleUtils::convertWclErrorCodeToString(result);
qWarning() << "Error writing CCCD for char" << getUuid() << errorString;
return {BleError::CharacteristicSubscribeError, errorString};
}
} else {
int result = gattClient.UnsubscribeFromNotifications(characteristic, goReadFromDevice, plNone);
if (result != WCL_E_SUCCESS) {
auto errorString = BleUtils::convertWclErrorCodeToString(result);
qWarning() << "Error writing CCCD for char" << getUuid() << errorString;
return {BleError::CharacteristicUnsubscribeError, errorString};
}
}
return BleError::NoError;
}
We hook up the notifications using:
__hook(&CwclGattClient::OnCharacteristicChanged, gattClient, &BleDevice::handleCharacteristicChanged);
Everything works perfectly during normal operation of the device: we can connect/disconnect, interact with the device, pair/unpair etc. The only major problem is the one that I described, that if the device turns off suddenly (or performs a reset which leads to a spurious disconnect) then the library waits a long time before calling the event:
__hook(&CwclGattClient::OnDisconnect, gattClient, &BleDevice::handleDisconnected);
If we turn off the notifications then this problem does not occur and as I have mentioned the more characteristics we have subscriptions turned on, the longer this delay lasts...
Let me just mention that this problem does not occur in Android (using Android BLE library) in our custom Android application nor in the nRF connect Android application - the disconnect is caught within a few seconds (according to connection timeout parameter of the BLE device).
Recent Posts
. I just wanted to describe the problem more thoroughly here.