locked
Slow Response time for reading Bluetooth LE Characteristics?

    Question

  • i'm working on some winRT apps to connect with Bluetooth LE devices based on a Gatt profile.  From other operating systems, the connection seems to be pretty fast, and with little lag.

    in windows, 8.1 when i'm making calls such as beloe

    GattReadResultreadResult = awaitbodySensorLocationCharacteristics[0].ReadValueAsync();

    the call come back pretty quick.  However, the values is always cached and never changes.

    if I call

    GattReadResultreadResult =awaitbodySensorLocationCharacteristics[0].ReadValueAsync(BluetoothCacheMode.Uncached);

    it's taking about 2 to 3 seconds for the await to return, even it there is only one device paired, and the result is small (i.e. 1 to 4 bytes).  I've received the best results when using my surface to run the app.

    is there any expectation on how much overhead is associated with this function?  I'm noticing the same on our custom device, as well as with an off the shelf heartrate monitor that implements the standard profile.

    we are sampling data every 100ms, and i would like to be able to retrieve the characteristic in a similar time frame.



    Friday, November 01, 2013 11:32 PM

All replies

  • Hi I like Software,

    Welcome here!

    Please just try the sample shown on

     http://code.msdn.microsoft.com/windowsapps/Bluetooth-Generic-5a99ef95

    If the sample is slow too, please replace the Bluetooth with another one and try again, if the issue is also exist, please share with me the detail info about the test report and better with a screenshot.

    Regards!


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, November 04, 2013 2:22 AM
    Moderator
  • Hi Xiaoliang,

    this is the example I have been using.  In particular, I've tried Scernario two.

    i'm finding that this line is a bit slow

    GattReadResult readResult = await bodySensorLocationCharacteristics[0].ReadValueAsync(); 

    I've tried using a wahoo heart rate monitor. 

    The fastest I can get a response here is around 1 to 2 seconds.  I've gotten the fastest responses when using my surface pro tablet.

    I also saw a similar response time when using a custom board that we created.  in this example, I use the following code (I removed error checking, etc for simplicity)

    ............................................................................................................................................

         var devices = await DeviceInformation.FindAllAsync(GattDeviceService.GetDeviceSelectorFromShortId(0xFFB0));
             GattDeviceService service = await GattDeviceService.FromIdAsync(devices[0].Id);

            
              while(!stop){
                           // pass in characteristics uuid for the third characteristic on the service
                var forceDataCharacteristics = service.GetCharacteristics(GattCharacteristic.ConvertShortIdToUuid(0xFFB3));
         
                if (forceDataCharacteristics.Count > 0)
                {
                    GattReadResult readResult = await forceDataCharacteristics[0].ReadValueAsync(BluetoothCacheMode.Uncached);
                    if (readResult.Status == GattCommunicationStatus.Success)
                    {
                        byte[] forceData = new byte[readResult.Value.Length];

                        DataReader.FromBuffer(readResult.Value).ReadBytes(forceData);
                 }
         }
     }

    ............................................................................................................................................

    I noticed the same response time here as well.  This call returns back a 1 byte value in about 1 seconds and 32 bytes in around 2 seconds.

    What's the overhead of the framework call ReadValueAsync()?  Have you been able to get it to respond in sub millisecond times?


    Monday, November 04, 2013 3:13 AM
  • Hi I like Software,

    Welcome back!

    I note that you have said your app works fine on other operator system, Could you have a test if you have another surface? If all of them work failed, please share with me a screenshot, I will report it to the professional engineer.

    Thanks for your understanding!

    Regards!


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, November 04, 2013 6:58 AM
    Moderator
  • Hi Xiaoliang,

    we have verified the following using several devices.  Below is my summary.

    using the Sensor Tag 2540 Development Board (http://processors.wiki.ti.com/index.php/SensorTag_User_Guide)

    using their USB dungle and custom drivers, we are able to pair with the device and it transfer data at responsive rates.   if we pair with the device directly using the windows 8.1 function calls, data transfer is slower (using the same host machine). 

    We also paired with the device using an IOS app that can read characteristics and it appears to read fast as well.

    it's difficult to capture this is any sort of screenshot. 

    what can we do to help debug this? 

    Tuesday, November 05, 2013 1:24 PM
  • Hi,

    i know the thread is pretty old - still the best if found yet.

    Im experiencing the same problem... I have several sensors connected to my pc and reading all values from them takes very long. I also tracked it down to the ReadValueAsync Function wich takes ~8s for reading all of my values, while writing the same amout of data is ~1s.

    is there any news on how to fix this?

    Friday, May 22, 2015 12:02 PM
  • Microsoft eventually confirmed that there was a bug in their implementation of the read function.  They said it was something they would consider fixing in "V next" of windows.    Back in February, I received this response after working with their engineers for quite a while.

    "The Windows Engineering team took this issue to triage and unfortunately, this didn’t meet the bar for a fix in Windows 8.1. As a result, this is now being targeted for Windows vNext. The exact status will only be known when we publicly releases Windows vNext."

    So we just assumed it will be fixed later and are using other operating systems for now.

    Good luck!  if you have more questions, reach out and we can discuss.  you can reach me at walkerla (at) hip-sci (dot) com.

    Friday, May 22, 2015 12:09 PM