Recent Posts

Pages: 1 [2] 3 4 ... 10
11
Bluetooth Framework / Re: Access denied
« Last post by Mike Petrichenko on July 28, 2022, 07:54:22 PM »
Hello,

This may appear when device lost link key (for classic devices) or when device requires authentication (for BLE devices).
12
Bluetooth Framework / Access denied
« Last post by MrPaulCarpenter on July 28, 2022, 05:12:04 PM »
Just recently my Windows program which I have been using for 3 years is sending back
 Error=0x00050029 Access denied
from the event handler fot wclClientConnectionConnectEvent

This is happening frequently.  I do not recall seeing it before.  I do not know how to resolve it.



Using wclBluetoothFramework version:7.15.0.0 wclCommunication version:7.7.1.0 wclCommon version:7.7.4.0
13
Bluetooth Framework / Re: Windows 10 perhipheral disconnect long timeout
« Last post by Mike Petrichenko on June 01, 2022, 10:12:13 AM »
Hi,

If you use version with source code please send an e-mail to us at support@btframework.com and we will provide a latest beta version that possible fixes the issue.
Unfortunately if you use version without source code you have to wait for release. We are planing the release of new version in about a couple of weeks.
14
Bluetooth Framework / Re: Windows 10 perhipheral disconnect long timeout
« Last post by mksiezopolski on June 01, 2022, 10:10:09 AM »
Hi,
Any progress on this issue or maybe some estimated time when we might expect an update?

15
Its OS timing. We will add flag to indicate that remote device disconnects so Bluetooth Framework will not try to unsubscribe.
16
Bluetooth Framework / Re: Windows 10 perhipheral disconnect long timeout
« Last post by mksiezopolski on May 25, 2022, 10:28:17 AM »
OK. Thanks.
Just out of curiosity, does the Unsubscribe timeout occur in the library or is it an OS thing (trying to write to a disconnected device produces such a timeout)? Is the timeout related to the connection parameters of the peripheral device or is it hardcoded somewhere?

17
Got it. It may take time when disconnecting because when you call Disconnect() or when emote device disconnects its implementation unsubscribes from all subscribed characteristics. This operation includes 2 steps:

1. Call to Unsubscribe()
2. Write client configuration descriptor.

So in case your app calls Disconnect() it does not take too much time because device is available. However if device is not available writing client configuration descriptor takes time.

We will try to find better solution for this case. I will let you know once we find it (should not take too long).
18
Bluetooth Framework / Re: Windows 10 perhipheral disconnect long timeout
« Last post by mksiezopolski on May 25, 2022, 09:49:27 AM »
Also a collegue of mine sent you a video (to support) which maybe helps a bit to see what happens  ;). I just wanted to describe the problem more thoroughly here.
19
Bluetooth Framework / Re: Windows 10 perhipheral disconnect long timeout
« Last post by mksiezopolski on May 25, 2022, 09:43:38 AM »
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:
Code: [Select]
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:
Code: [Select]
  __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:
Code: [Select]
  __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).
20
Hi,

To be able to reproduce and fix the issue it would be great to know which notifications you turned off/on.
Pages: 1 [2] 3 4 ... 10