none
Windows.Devices.Bluetooth.GenericAttributeProfile.GattSession.MaintainConnection - how to handle reconnection RRS feed

  • Question

  • Asking a new question after highjacking another thread.


    I'm trying to understand how to handle ble dropouts/disconnections and reconnections.

    Frank mentions setting GattSession.MaintainConnection to let library handle reconnecting the device after a dropout/disconnect.

    I tested this a bit and when the device reconnects, the old service is no longer available (I believe it was disposed). I'm not understanding what the flow would be for this. 

    It seems that GattSession.MaintainConnection should be true and we have the GattSession.SessionStatusChanged event hooked up. If the ble device disconnects and then reconnects, we can detect that via SessionStatusChanged, but how do we get the service back? The GattSession seems to still be valid, but not the service?

    Original response from Frank:

    Hi Jeremy,

    Greater than 30 seconds is an extended period of time for active scans. However the class you reference does both active and passive scans based on the ScanningMode property. If you're connected why did you choose an active scan? This is typically to get the scan response data or device name, which if you're connected it seems you'd not need.

    Also, you don't need to perform scanning to have an in-use device recover the connection. We'll do it under the covers more efficently if you use MaintainConnection property.

    If your using scaning for another reason, in the best case you have a very specific filter on payload or RSSI as we have vendor specific extensions to perform filtered scanning in an efficient means.   When scanning is performed a percentaged of the entire radio (Wi-Fi and Bluetooth) is used to do the scanning, this unfortunately effects the Wi-Fi performance, Bluetooth performance and power. 

    This can be extreme when performing a full active scan, which we recommend doing this for the shortest period of time possible.

    In the worst case there is the issue that we are improving in RS5 which can cause the original posters failure, it only occurs in extended duration cases in where many advertisements match, regardless were improving it. You can validated the change in 19H1 where the improvement is already released.

    Hope this helps,

    Frank

    Friday, May 17, 2019 2:43 AM

Answers

  • The least intensive option is to have code similar to the following:

    1. Using the instance of GattSession try BluetoothLEDevice.FromIdAsync(gattSession.DeviceId)
    2. From the instance of bluetoothLEDevice.GetGattServicesForUuidAsync(uuid)

    Also the following should work too:

    1. Keep an instance of BluetoothLEDevice alive.
    2. Subscribe to BluetoothLEDevice::GattServicesChanged.

    The remarks on the event explain what happens for paired vs unpaired devices.

    Thursday, May 23, 2019 5:23 PM

All replies

  • The least intensive option is to have code similar to the following:

    1. Using the instance of GattSession try BluetoothLEDevice.FromIdAsync(gattSession.DeviceId)
    2. From the instance of bluetoothLEDevice.GetGattServicesForUuidAsync(uuid)

    Also the following should work too:

    1. Keep an instance of BluetoothLEDevice alive.
    2. Subscribe to BluetoothLEDevice::GattServicesChanged.

    The remarks on the event explain what happens for paired vs unpaired devices.

    Thursday, May 23, 2019 5:23 PM
  • Frank,

    Our Bluetooth remote devices (whether Classic or BLE) function as Central devices and write to a Windows Server.

    The current BLE peripheral mode implementation on Windows has been a slow evolution.  Is it now at a point we can have a Central BLE ioT device write to a Windows GattServer --- and establish an initial connection one day, do 50-70 writes a day, 7 days a week --- going off the air each time once the write has completed, waking up an hour or so later and immediately be recognized by the GattServer using your "MaintainConnection" property?

    We do that with Classic because it offers a static MAC address to remember and write to.  We would like to do that, or close to it, in BLE.  Our total start-to-finish time to wake up, detect and recognize the GattServer out of the many dozens or hundreds of advertising packets filling the air, connect, write a 150-byte block of data, and go back to sleep --- must all be completed in a very short timeframe measured in 0.5 to a max of 2 seconds.  

    Tuesday, August 27, 2019 6:14 PM
  • Happy Dawg,

    Either side can cause a disconnection so I can't speak to the use case, nor can I answer generally about behavior that may vary by radio. I can say if the GattServer is active and the property MaintainConnection is true we don't take a specific action, while the system and application are active to disconnect.  This means, 'going off the air' doesn't happen. As well if a host is disconnected, the time to reconnect is non-zero so 'immediate' is not a requirement that can be met.

    I recommend developers that have precise technical requirements and are using Bluetooth LE start with reading Robin's book Bluetooth Low Energy: The Developer's Handbook. This fundamental knowledge about the protocol's behavior will make our API surface more clear and enable you to ask specific questions about the API's behavior where there isn't clarity. It also explains how scheduling, time and connections work.

    I hope that helps.

    Thanks,

    Fg

    Tuesday, August 27, 2019 7:06 PM
  • I will order the book, Frank, thank you.

    I've been writing BLE code for a couple years --- and had no difficulties with Texas instruments' full implementation of the standard.  It all works exactly as specified, with the exception of the occasional bug.

    The problems I've encountered have been with Microsoft's offerings.  I think you have far more difficult challenges and security concerns, which have caused the team to be able to implement only a small part of the standard. The "immediate" aspect is taken from Classic Bluetooth, where a remote device operating as a Central can wake up, establish a connection with a listening server at a known address on the workstation, and begin uploading data in two to four seconds.  In human terms, this is "immediate".  With BLE, our devices do this in about a quarter of a second between themselves.  With the Microsoft stack, normal scans take a very long time, as in tens of seconds. By then our user has walked away. Then one is expected to interrogate each until one identifies which one is the "right" one, since Microsoft decided to prevent anyone using a static address for the GattServer sitting there, waiting. To speed things up, we proposed to use a custom beacon running on the workstation that would provide a unique payload and the address of the workstation radio --- then use that address to write to the known service handle of the GattServer expecting to receive the data. Unfortunately this is apparently not possible when working from a Windows laptop to a Windows workstation.  The laptop detecting the beacon thinks the radio / workstation / whatever it thinks it is pointing at is a classic device, not a BLE device.  Go figure.

    On this last, I would be happy to provide the low level function calls that appear to contain an unhandled exception, and are unable to create a device object for the BLE device.



    • Edited by Happy Dawg Tuesday, August 27, 2019 11:04 PM
    Tuesday, August 27, 2019 10:47 PM
  • Hey Happy Dawg,

    Our challenges are balancing the workload of the normal PC role and expected privacy with other Bluetooth features.  The scanning duty cycle does impact responsiveness, especially for dedicated workloads. To your point, yes our LE Scanning Duty Cycle is manage by the host and not configurable by the applications. We often get questions about it. As of the current Windows 10 release the values are about 2% if there are only HID devices paired, 10% if proximity features (Swift Pair, et al.) are active, 15% if there is an AdvertisementWatcher and 100% if the Settings Page is actively searching to pair devices.

    You can use performance monitor or PowerShell get the current value.

     ((Get-Counter -ListSet "Bluetooth Radio").Paths |? { $_ -like "*Scan Duty*"} | get-counter).Readings 

    I don't think I understand your comments on Windows devices confusing BR and LE, we have Bluetooth LE Explorer in the store that shows using both roles just fine on a PC. If you're having issues provided a trace. The source code is open source to review and copy.

    Thanks,

    Fg

    Wednesday, August 28, 2019 1:19 AM
  • Morning, Frank

    Goal One: I would like to add a few unique bytes to the GattServer advertising packet.  I found a way to accomplish this.  I start the GattServer, and then start publishing a custom beacon.  The GattServer advertising packet now contains the added information taken from the custom beacon, and the custom beacon does not advertise.    This was a surprising accident --- I don't recall ever reading anywhere that this is the desired behavior, but it certainly does exactly what I wanted to do.

    Question: Can you confirm this is the intended behavior of the Microsoft stack, and can I rely on this to continue in future releases?

    Goal Two: How do we change the MTU on the Windows workstation GattServer in advance so that we can perform one single write to the GattServer without going through the back-and-forth MTU size renegotiation process?



    • Edited by Happy Dawg Wednesday, August 28, 2019 5:27 PM
    Wednesday, August 28, 2019 2:59 PM
  • Happy Dawg,

    The Bluetooth stack on Windows does attempt to coalesce advertising payload to the fewest advertisements. You can rely on that behavior, you cannot rely that it will always be in the packet with your server which is what I think what you want.  To do that you need to use the StartAdvertising overload that takes GattServiceProviderAdvertistingParameters to set the service data.

    However, take caution in what you advertise, if you advertise a fixed unique id you'll impact the end user's privacy. I enjoyed this paper (Tracking Anonymized Bluetooth Devices) and think it would help you understand the privacy implications. 

    Thanks,

    Fg

    Wednesday, August 28, 2019 5:40 PM
  • Frank,

    Could you comment on my second question:

    Goal Two: How do we change the MTU on the Windows workstation GattServer in advance so that we can perform one single write to the GattServer without going through the back-and-forth MTU size renegotiation process?

    Thanks

    Friday, August 30, 2019 2:01 PM