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

    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