Bluetooth performance issues RRS feed

  • Question

  • Hi,

    I am writing an application that communicates the PC with a device using a bluetooth RFCOMM connection managed with the winsock2 API.

    Basically, the device sends data to the computer up to 24kb/s and the computer is reading it.

    After intensive tests in different computers, operative systems and bluetooth antennas, we have detected a problem with the performance in the reception of the data, specially in the very first seconds of the transmission.  Some of the messages are delayed or even lost but, after 20-30 seconds, everything seems to work properly and with no major problems.

    I am aware that some data can be lost using bluetooth, but it looks like there is something "special" happening at the beginning of the transmission that is making it more prone to fail. Is there any "flow control" inside the bluetooth stack that might be causing this behavior?

    We have also detected that this behavior is changing over time. We have verified that the load of the computer does affect the result but sometimes, with the same load, the results are different. Is it possible that the new updates are affecting the bluetooth stack?

    Monday, October 15, 2018 9:46 AM

All replies

  • Hi Pablo,

    It's impossible to tell from your descriptions what the issue is there are two paths forward:

    1) You can analyze this yourself using btvs.exe from the WDK if you have access to Frontline Protocol Analysis System (FTE). The last minute of the video 'Bluetooth: Bluetooth GATT Server - Part 3 of 3' shows using it.

    2) You can collect Bluetooth logs following the instructions linked and provide a link in your reply.



    Thursday, October 18, 2018 4:22 AM
  • Hi Frank,

    Thank you for the quick response.

    I have followed the second path you suggested and collected some logs:

    - This log contains the trace of an execution with the odd behavior we detected.!dkZQEaYT!b4chn3isHu0KU3gqBS7qKvJuCjIOHZz9W1WBw6JybtA

    - This log contains a trace with the expected behevior.!B5YWHaxA!v7DT7Ml10I1MbQ8u6bGmxQqE1hsDgsx-LNrhv5CJIqI

    I hope this helps to clarify the issue.



    Tuesday, October 23, 2018 9:23 AM
  • Hi,

    We are experiencing issues as well with Bluetooth, SPP profile, using both the Winsock2 API and direct communication through the virtual COM Port, since the last 1803 build Bluetooth updates. Similarly to Pablo, the same apps have been working fine on all machines, until the mentioned update. 

    Our devices stream data over Bluetooth to Microsoft Windows PC Hosts. The Bluetooth link gets stuck after a few seconds. No issues were reported for our program versions running at low data rates.

    Questions: Is this a known issue by Microsoft? Is there any plan to fix in next releases? Is there a workaround other than trying to use a different profile? Any help would be very much appreciated.



    • Edited by LatyrFall Friday, October 26, 2018 8:04 PM
    Thursday, October 25, 2018 2:39 PM
  • Hi, 

    Here are more precisions on the issue we are currently experiencing:

    - When we notice data exchange issue while streaming from the device to the Host Machine running Windows 10 build 1803, it is the upload link (device -> PC) which doesn't work for some reason, causing the read operation on the vCOM to Timeout... The PC Host is still able to successfully send data to the device.

    - Enabling File Sharing as described which is disabled by default on Windows 10 did partially solve the issue, since the uploading link doesn't get stuck anymore. Device is able to properly stream data expectedly.

    - So far so good... until the user tries to connect a Bluetooth Audio device, then the uploading link gets stuck again.

    Hope this would be helpful.


    Friday, October 26, 2018 8:02 PM
  • Hi,

    Adding more info to the issue.  We have found that if we start the data interchange with a low load (say 320 bytes/s) for the first 30 seconds, then we can increase the bandwidth  as much as we need (2.4 kbytes/s) with no problems.


    Monday, October 29, 2018 8:03 AM