GATT Client - How Can I Improve Transmission Rate?

[briandunham]

I am trying to use the CwclGattClient::SetConnectionParams(const wclBluetoothLeConnectionParametersType Params) function to achieve higher throughput, and I get the returned error: 0X0005105F (WCL_E_BLUETOOTH_LE_FEATURE_NOT_SUPPORTED). I'm wondering if this is just a limitation of Windows 10? Or is this really just my BLE driver not supporting this capability? Does this just set the connection interval to be lower?

Are there other options for improving the transmission rate? My program currently does consecutive CwclGattClient::WriteCharacteristicValue(...) calls when sending large amounts of data and the time it takes to return from the WriteCharacteristicValue call seems to be very slow.

[briandunham]

I should also mention that I am currently subscribing for notifications from the GATT client, which is mandatory for our design.

[Mike Petrichenko]

Hello,

Connection parameters can be changed only on Windows 11 with MS drivers.

About writing characterisitc vakue: There are 2 ways to write long vakues for nowL

1. Split data to smallamounts.
2. Run Write operationin separate thread.

[briandunham]

I am already currently splitting the data into smaller chunks and have a dedicated write thread. Would changing my application to be the GATT server improve the write speed?

[briandunham]

And could my application be running both the GATT server and the GATT client simultaneously?

[Mike Petrichenko]

I am already currently splitting the data into smaller chunks and have a dedicated write thread. Would changing my application to be the GATT server improve the write speed?

Unfortunatelly no,

[Mike Petrichenko]

And could my application be running both the GATT server and the GATT client simultaneously?

Usually yes, but depends on your hardware

[briandunham]

So I put timers around the CwclGattClient::WriteCharacteristicValue(...) call and it takes about 78ms to 150ms to run that single line of code. And I am only sending 16 bytes per write notify. This seems incredibly slow as I'm only able to get transmission speeds of about 150 bytes per second. Is there really no other way to make this faster?

Here is a code snippet of how I'm measuring the time:

      DWORD startTime = GetTickCount();

      int Res = m_pGattClient->WriteCharacteristicValue(s_rxDataCharacteristic, (unsigned char*)msg, msg->msgLength, plNone);
      if (Res != WCL_E_SUCCESS)
         TRACE("Error: 0x%x\n", Res);
      else
      {
         result = TRUE;
         DWORD endTime = GetTickCount();

         TRACE("Time: %dms\n", endTime - startTime);
      }

[Mike Petrichenko]

Unfortunatellyu no. BLE (and GATT) was designed for power saving, not for bulk data transferring. For big data you should use classic Bluetooth. Not GATT. Of course modern BT 5 allows to transfer audio and video but it does not use GATT for that.

[Mike Petrichenko]

By the way, latest version allows to get max PDU size (and has event to notify when max PDU size changed). So you can split your data to the max PDU size (-3 bytes) to send it more affective.

[briandunham]

I should mention here that I was able to drastically improve my throughput by setting the connection interval on the server side (not Windows 10). And when the connection is established, the client and server negotiate the connection params which causes Windows 10 to adjust the connection interval properly.

[Mike Petrichenko]

I should mention here that I was able to drastically improve my throughput by setting the connection interval on the server side (not Windows 10). And when the connection is established, the client and server negotiate the connection params which causes Windows 10 to adjust the connection interval properly.

That is absolutely correct way and I 100% agree with this solution. If you can adjust any params on your HW side (not on Windows one) it is always right way. Because MS does not allow to control too much things in BLE communication.