How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices

[brianreinhold]

I started with the C++/winRT example BluetoothLE Scenario1_Discovery.cpp and closed issue #513 and #932. What makes using the API so difficult is probably that it is so generic and one must learn what the meaning and definitions of numerous Microsoft unique fields are like Properties which has esoteric names like System.Devices.Aep.DeviceAddress with a very limited description of what the consequences of these strings are when used in the DeviceWatcher. In addition there is this L"(System.Devices.Aep.ProtocolId:=\"{bb7bb05e-5972-42b5-94fc-76eaa7084d49}\")" string (the above from the example) which is completely undocumented. The example is very terse in its explanation of the parameters and their effects (the hard part) which makes using these API very confusing (especially when coming from a much more straight forward type of API as provided in embedded systems or Android.

What I wanted to do was simulate the simple LE advertisement watcher which does exactly what I expect it to do; its just that I cannot connect to a discovered device using that method (even though the discovered adv IS connectable. So now the DeviceWatcher First I try the createWatcher(string) only. The mysterious ProtocolID above. Result? Immediate signal of the enumeration completed callback and no ability to discover an advertising BTLE device. Okay, next I add that list of properties. Same result. Immediate enumeration stop, and no discovery of any devices. Now add the association kind. No immediate enumeration stop. I do discover devices BUT there is a catch. If the device was discovered previously (and is not active) it is STILL reported even though the Properties contains the System.Devices.Aep.IsPresent is included. It will get removed. And then one can re-discover it. But it will not get removed, even though the device stops advertising. Then I can only discover that once; a restart of the device is not shown. A stop and restart does not re-discover the device.

The Advertisement watcher is SOOOO much cleaner I would love to throw the DeviceWatcher in the trash and use the advertisement watcher ... if I could only connect. Or maybe microsoft could clearly document how the DeviceWatcher is used for BTLE devices and what all the parameters do (and what are the default behaviors when various fields are NOT included...

[oldnewthing]

Sorry for the frustrating experience you're having. I've engaged the Bluetooth team to see what they can do to make the samples clearer. Just to make sure I understand (since I'm not a Bluetooth person) - what you want is a way to identify Bluetooth LE devices and connect to them, and the existing sample (Scenario1: Discovery) doesn't do that.

By the way, the endpoint protocol IDs are documented here but that page is evidently not very discoverable. What pages do you recommend as good candidates for links to the page that documents the various endpoint IDs?

[brianreinhold]

Dear Raymond Chen,

I actually want to develop a complete central for health devices. But discovery is the first part.

The confusing aspect about the DeviceWatcher is that it works with EVERYTHING. When I created the watcher with no arguments I discovered BT, BTLE, PnP, DLNA, Wi-Fi, USB all kinds of things. So one is going to need to do quite a bit of work to filter that down.

What is not clear is what all the options do, what is assumed when I have just one or two of the three parameters, etc. Of course I am only interested in Bluetooth. SO I look at the example and I see the following:

aqsAllBluetoothLEDevices = L"(System.Devices.Aep.ProtocolId:=\"{bb7bb05e-5972-42b5-94fc-76eaa7084d49}

This parameter was the most mystifying to me. Where did it come from? Is it something MS pulled out of thin air or is it some standardized value? Its not clear that one can even set values or when one can set values.

This is a tricky part and there needs to be a good explanation of what kind of controls one has over the search for Bluetooth devices.

What I would like to do is limit my search to only those BTLE devices that advertise certain service UUIDs. This is a common thing for centrals to do. (Note that many centrals works with multiple devices in a generic manner). I do not know if this is even possible.

The advertisement watcher is much more straight forward as all it does is work with BTLE adv. However, its filtering is limited but I can do that in software (and have). The downside is if I use the advertiser, when I try to connect, the co_await BluetoothLEDevice::FromBluetoothAddressAsync(eventArgs.BluetoothAddress(), BluetoothAddressType::Random); returns null, so one can not go any further,

Here is what a BTLE Central SHOULD be able to do

1. Search for devices (scan for advertisements)
2. Select amongst those advertisements those that are of interest. In our case, it is devices supporting the standard BTLE health profiles.
3. .If the discovered device is one that is new, have someone (usually a user) decide if they want to connect
4. If so, initiate a connection
5. When the connection event is received, start service discovery
6. When service discovery is done, read/write/enable characteristics
7. Be prepared to handle indications/notifications

IF at any time the device sends a security request OR an insufficient authentication error, begin pairing - this is part of the BTLE spec.

confirmation or passkey dialogs may be required.

repeat the action that caused the authentication error (such as attempting to write to the characteristic configuration descriptor)

Note this approach allows support of BOTH pairable and unpairable devices without the user knowing ahead of time whether the device is pairable or not.

1. Now when searching for devices if the above device is discovered, reconnect without user intervention
2. If the device was paired and bonded, begin encryption - no need to do service discovery and re-enable descriptors.
3. Ready to roll
4. If the device was unpairable, one has to repeat the steps above.

We have implemented such a central on a set of embedded platforms, Android, and on Linux. We have a growing number of requests to do the same on Windows.

Hope this helps.

I hope I can get this to work!

Brian

---

From: Raymond Chen notifications@github.com Sent: Monday, April 22, 2019 2:04 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Author Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

Sorry for the frustrating experience you're having. I've engaged the Bluetooth team to see what they can do to make the samples clearer. Just to make sure I understand (since I'm not a Bluetooth person) - what you want is a way to identify Bluetooth LE devices and connect to them, and the existing sample (Scenario1: Discovery) doesn't do that.

By the way, the endpoint protocol IDs are documented herehttps://docs.microsoft.com/en-us/windows/uwp/devices-sensors/aep-service-class-ids but that page is evidently not very discoverable. What pages do you recommend as good candidates for links to the page that documents the various endpoint IDs?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-485496386, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO6ZYUEM5YUIKQRJSPYDPRX43JANCNFSM4HHLTETQ.

[oldnewthing]

I'm not very knowledgeable about Bluetooth, so I can't really make much sense of what you wrote. The Bluetooth team points out that there is another repo that demonstrates many Bluetooth-specific scenarios, and it's linked from this sample: Bluetooth LE Explorer. They mentioned specifically

• Getting the device address from a BluetoothLEDevice obtained from a DeviceWatcher.
• You aren't expected to build your own custom query strings. You can use the BluetoothLEDevice.GetDeviceSelector() / GetDeviceSelectorFromXxx() methods to obtain prewritten query strings for common scenarios.

[brianreinhold]

Raymond,

You have it kind of backwards. The device address is easy to get. What is trickier is to get the BluetoothLEDevice object when using the Advertisement watcher. The method to perform the task fails (returns NULL).

The Watcher gives DevceIdentifier objects or update variants. I have not tried getting the BluetoothLEDevice object from that yet; I have been unable to filter the watcher responses down to something I want (which I can do with the advertiser). I have no idea what the is contained in the DeviceIdenfier UUID fields as the possibilities are endless. An LE advertisement follows a standard and I know exactly what can be in it and can handle that myself.

This is where more complete documentation on how to create the watcher for Bluetooth LE devices (and classic BLuetooth devices ) ... which are very different ... is necessary.

The other major pitfall I see with the Bluetooth LE API is that no matter how one tries to obtain the BluetoothLEDevice object, the method simultaneously starts a connection. However, I cannot register for a events like a connection until I get the BluetoothLEDevice! I have never in my life seen a transport API where it was not possible to setup all callbacks and event handlers BEFORE one even thinks about initiating a connection.

I do not even know if it is possible in this API to obtain a connection event (the ConnectionStatusChange callback) ... at least for the connection event.

Brian

---

From: Raymond Chen notifications@github.com Sent: Monday, April 22, 2019 7:38 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Author Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

I'm not very knowledgeable about Bluetooth, so I can't really make much sense of what you wrote. The Bluetooth team points out that there is another repo that demonstrates many Bluetooth-specific scenarios, and it's linked from this sample: Bluetooth LE Explorerhttps://github.com/Microsoft/BluetoothLEExplorer. They mentioned specifically

• Getting the device address from a BluetoothLEDevice obtained from a DeviceWatcherhttps://github.com/Microsoft/BluetoothLEExplorer/search?q=fromidasync&unscoped_q=fromidasync.
• You aren't expected to build your own custom query strings. You can use the BluetoothLEDevice.GetDeviceSelector() / GetDeviceSelectorFromXxx() methods to obtain prewritten query strings for common scenarios.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-485589018, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO62ANWOEP4UYNSOR4KLPRZD6BANCNFSM4HHLTETQ.

[oldnewthing]

Okay, I'm going to let the Bluetooth team respond instead of trying to play telephone. I asked them to reply to this thread.

[brianreinhold]

Raymond,

Thanks for that. Its a complex subject!! Note that I am also using C++/winRT which is still quite new (especially for me). There may be different behaviors there than in C# or C++/CX

Brian

---

From: Raymond Chen notifications@github.com Sent: Monday, April 22, 2019 8:14 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Author Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

Okay, I'm going to let the Bluetooth team respond instead of trying to play telephone. I asked them to reply to this thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-485595715, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO64Q2S27RDGB3IZPLPTPRZIHBANCNFSM4HHLTETQ.

[brianreinhold]

Raymond,

I have more for the Bluetooth team.

Given that there is some bug that does not allow one to connect to a BTLE device discovered by the AdvertistementWatcher., I have tried the DeviceWatcher. It has a couple of serious shortcomings which are so serious I would call them bugs.

A BTLE health device central application want to support all devices that support the BTLE health device profiles. These profiles have standardized service UUIDs and are the same regardless of the manufacturer.

Thus one wants to be able to programmatically filter discovery responses to those that indicate support for these profiles. That information is present in the BTLE advertisements/scan responses.

That filtering can be done in one of two ways

1. The API allows one to define a set of filter parameters in the watcher such that the watcher returns only those devices that have these service UUIDs.
2. The watcher return device information that allows the programmer to filter those of interest.

In the case of the AdvertismentWatcher, number one is only half-possible; you can only filter on one profile. So that is not usable

BUT the discovery results contain the advertisement or scan response and the programmer can use these to filter.

The downside is one cannot get a BluetoothLEDevice object from the data collected by the advertisement watcher (one should ... this is a bug)

In the case of the DeviceWatcher number one is only half possible with the same restriction as the AdvertisementWatcher. So the only choice is to accept all BTLE devices

BUT number two is not possible as the DeviceWatcher's DeviceInformation responses does NOT contain any Property values so one has no idea what the device is. It does know its name and BT address but that tells you nothing about the device.

These shortcomings make it impossible to support a generic central application for health devices such as one can do on Android, Linux, and iOS.

Brian

---

From: Raymond Chen notifications@github.com Sent: Monday, April 22, 2019 8:14 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Author Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

Okay, I'm going to let the Bluetooth team respond instead of trying to play telephone. I asked them to reply to this thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-485595715, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO64Q2S27RDGB3IZPLPTPRZIHBANCNFSM4HHLTETQ.

[jevansaks]

I just linked a bunch of issues reported on the documentation site to this issue. Once this discussion concludes we can decide what to do with those issues.

[brianreinhold]

To all!! The single most important issue is closed issue #613. The issues with the DeviceWatcher I can figure out with trial and error. I CANNOT DO ANYTHING with issue #613. That is a total blocker!

[FrankGorgenyi]

Hi @brianreinhold,

I work on the Bluetooth team for the Windows Core OS. We own the APIs under Windows.Devices.Bluetooth. and I helped with the design for Windows.Devices.Enumeration. long ago so I am sure we can help.

We are dealing with some other escalations right now and we're a small team. I'll get to you later tonight or tomorrow.

In the mean time can you please take a trace that includes you calling BluetoothLEDevice.FromBluetoothAddressAsync on the address returned from the AdvertisementWatcher?

Bluetooth Tracing

Thanks, Fg

[brianreinhold]

Frank,

Maybe you know right off hand if what we seek to do is possible in Windows Bluetooth. We want to create a remote patient monitoring application that works as automatically with all standardized Bluetooth Health Device profiles such that the user (often elderly) need only take measurements with their devices and they upload automatically. We have such applications on Android. A company has tried to use their Win 10 Chromebook Android bridge but that had too many issues in the Bluetooth so they are hoping a WIndows based solution might work.

Such a central will need to discover advertisements and identify what type of health device it is from the service UUIDs. I can do this with the AdvertismentWatcher in software.

On a first time discovery, if the device is a standard health device, a popup occurs and the user is asked if he/she wants to connect to it. If yes, connection begins.

Service discovery is done, and then reading, writing, and enabling of characteristics is done and indication/notifications are handled. If at any time the device sends a security request or insufficient authentication error, pairing is done. The user does not have to know whether the device is pairable or not. The user might have to respond to a passkey entry or confirmation.

On a rediscovery (often next measurement), connection happens automatically, if paired, encryption and then data transfer can begin. If not paired, connection happens automatically but service discovery and enabling will need to be redone.

Is this possible with the Windows BLE API?

I know the AdvertisementWatcher is the way to go as it gets device information with the need to connect. I have, however, been unable to connect to the device when using the AdvertisementWatcher. Using the DeviceWatcher, I have been unable to filter the discovery results based upon services. I can based on friendly names but that is not standardized and would require tedious configuration

Thanks,

Brian

---

From: Frank Gorgenyi notifications@github.com Sent: Thursday, April 25, 2019 1:11 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Author Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

Hi Jevan,

I work on the Bluetooth team for the Windows Core OS. We own the APIs under Windows.Devices.Bluetooth. and I helped with the design for Windows.Devices.Enumeration. long ago so I am sure we can help.

We are dealing with some other escalations right now and we're a small team. I'll get to you later tonight or tomorrow.

Thanks, Fg

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-486758888, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO66MIP2UUDC73FTMPPLPSHQ5DANCNFSM4HHLTETQ.

[FrankGorgenyi]

Hey Brian,

Yes I am happy to talk about the design first and then diagnose issues.

There should be no issues discovering the advertisements you need with the AdvertisementWatcher. There are limitations on concurrent connections:

1. How many devices are you expecting to connect to concurrently?
2. How you will decide when to connect to a particular device?

The scenario:

3. If you're pairing with the central, does the whole area share a single central or does each person have there own device?
4. Is having a user present at the device to pair desirable or just the working solution?

Diagnosing Issues:

5. Did you have success in collecting a trace of BluetoothLEDevice.FromBluetoothAddressAsync on the address returned from the AdvertisementWatcher and can you share them?
6. Are you aware of using BTVS (Bluetooth Virtual Sniffer) it allows you to view HCI traces live with Forfront or Wireshark. It's in the WDK, unfortunately it's a large download we are looking for a better delivery solution.

Thanks, Fg

[brianreinhold]

Frank,

See below (in dark indigo) ... AND THANKS!

Brian

---

From: Frank Gorgenyi notifications@github.com Sent: Thursday, April 25, 2019 5:55 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Mention Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

Hey Brian,

Yes I am happy to talk about the design first and then diagnose issues.

There should be no issues discovering the advertisements you need with the AdvertisementWatcher. There are limitations on concurrent connections:

1. How many devices are you expecting to connect to concurrently?
2. Brian: Up to as many as the system allows. Some devices are slow to disconnect and we have had use cases where patients take a second or third measurement (with different devices) and then there are several simultaneous connections. We have not had a problem with this on RL78 based embedded platforms, Android, or Linux.
3. How you will decide when to connect to a particular device?
4. Brian: The user will decide one the first-time use. After that, the connection happens automatically when the user takes a measurement.

The scenario:

1. If you're pairing with the central, does the whole area share a single central or does each person have there own device?
2. Brian: Pairing happens on the fly and only when needed.Some devices do not pair. All that do pair will tell the central when it must pair. There are multiple use cases. A single central could service multiple patients each with multiple devices (nursing home perhaps) or a patient could have their own central and multiple devices. Devices can be changed as needed and come from different manufacturers. The central is expected to work with ALL devices that follow the standard.
3. Is having a user present at the device to pair desirable or just the working solution?
4. Brian: This is a common scenario, but there are also scenarios where someone pre-pairs a device. The central should handle both. Setup should require minimal interaction with the user. The user should not have to engage with the central to start discovery to initially connect to a device. Thus the popup when the device is discovered. Only supported health devices are ever presented to the user. Then all the user does is say yes/no. In a BTLE advertisement/scanResponse from a standard health device, device type and friendly name are available given the user enough information to make a decision. Pairing will happen only if needed. The most complex action the user will have to take is entering a passkey for an MITM device. Once the device is known by the central, there is no interaction between the user and central. Reconnects are automatic.

Diagnosing Issues:

1. Did you have success in collecting a trace of BluetoothLEDevice.FromBluetoothAddressAsync on the address returned from the AdvertisementWatcher and can you share them?
2. Brian: I did. I used a Frontline BPA 600 sniffer. A connection event was never sent by the central (I configure for active scans so I get both advertisements and scanResponses). I did not save the trace but I could make another one.
3. Are you aware of using BTVS (Bluetooth Virtual Sniffer) it allows you to view HCI traces live with Forfront or Wireshark. It's in the WDK, unfortunately it's a large download we are looking for a better delivery solution.
4. Brian: I was not aware of this tool. That is something to consider. Since the sniff revealed no connection event, it would be interesting to see why it never went out. I could send you my project. It is still very small at this stage. The Bluetooth part is in a dll (small as it is).

Thanks, Fg

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-486851595, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO62R42O5SG5TUTW7GTTPSISDNANCNFSM4HHLTETQ.

[brianreinhold]

Frank,

Just for interest's sake I will tell you how it is done on the Android:

Discovery is done continuously in the background. It alternates between N seconds doing a classic discovery followed by M seconds doing a BTLE scan

When a supported device is discovered for the first time, a popup appears with info about the device

THe user usually selects yes

If so, a connection is started. Android requires an object that you implement that handles all possible callbacks

When a connection event is received, service discovery begins

Then the DIS is read

Then the Current time. It may be set if possible and needed

Then descriptors of interest are enabled

Pairing happens at any time the peer requests it (it may not)

This becomes a known device

Next time a known device is discovered, connection is automatic. There is no user interaction.

Brian

---

From: Frank Gorgenyi notifications@github.com Sent: Thursday, April 25, 2019 5:55 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Mention Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

Hey Brian,

Yes I am happy to talk about the design first and then diagnose issues.

There should be no issues discovering the advertisements you need with the AdvertisementWatcher. There are limitations on concurrent connections:

1. How many devices are you expecting to connect to concurrently?
2. How you will decide when to connect to a particular device?

The scenario:

1. If you're pairing with the central, does the whole area share a single central or does each person have there own device?
2. Is having a user present at the device to pair desirable or just the working solution?

Diagnosing Issues:

1. Did you have success in collecting a trace of BluetoothLEDevice.FromBluetoothAddressAsync on the address returned from the AdvertisementWatcher and can you share them?
2. Are you aware of using BTVS (Bluetooth Virtual Sniffer) it allows you to view HCI traces live with Forfront or Wireshark. It's in the WDK, unfortunately it's a large download we are looking for a better delivery solution.

Thanks, Fg

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-486851595, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO62R42O5SG5TUTW7GTTPSISDNANCNFSM4HHLTETQ.

[FrankGorgenyi]

Hi Brian,

Thanks for the details of your prefered flow above. What you described in the Andriod scenario is possible on Windows as well, except:

1. We handle the connection and apps have little direct control we use a ref count model accross all apps and Windows.
2. On Desktop editions apps can't handle all incoming pairings; on IoT editions apps may. The decision is based on policies for end-user security.

Let me describe how you'd do it on Windows:

1. Use the Advertisement Watcher to watch for the device in question or DeviceWatcher.
2. When your app finds a device it's interested in, use BluetoothLEDevice.FromBluetoothAddressAsync or BluetoothLEDevice.FromIdAsync depending on which was used for discovery.
3. When your app gets a non-null BluetoothLEDevice use GetGattServicesAsync or GetGattServices to get the service objects. Null responses mean we couldn't connect, unfortunately for non-paired devices that implement address rotation this is expect to occur if your on a rotation boundary. It can also occur if we simply couldn't connect for radio issues.
4. At GattService object has a Session property; set it to true if you'd like us to maintain the connection and auto-reconnect while your app is using it.
5. Perform your app's operations as you would on Android.

What is different? Your users will need to handle the incoming pairing toasts when the remote device requests authenticiation if it's not paired.

What your app could do differently? If you did know ahead of time about needing to pair you could call PairAsync and handle the ceremony at least then you could hand the flow in your app deterministically.

Send your traces of problems collected with the BPA and our host logs collected at the same time and we'll seee what your encountering.

Thanks, Fg

[brianreinhold]

Frank,

It does not look like it is too different from the Android. In fact, it appears the same. When pairing is needed (security request or insufficient authentication) Android starts the pairing. I do not have to; the system always beats me to it. If a confirmation/passkey is needed, Android pops up necessary dialogs even if I do start the pairing from the app. I do not have to. So in that regard the flow IS the same.

Android also has an auto connect option which I do not use. I found it less reliable than re-discovering myself and reconnecting myself.

Resolvable random addressing shall not change during a connection; and it is only meaningful for peers that pair. So far, there are no market health devices that use resolvable random addressing. Android and iOS do, however. So I am setting my Windows client to do the same.

I am using the AdvertisementWatcher as it gives me the advertisements and thus the info I need about the device and for filtering.

So at this point there only seems to be one difficulty, and its a big one

BluetoothLEDevice.FromBluetoothAddressAsync() ALWAYS returns NULL.

Brian

---

From: Frank Gorgenyi notifications@github.com Sent: Monday, April 29, 2019 9:49 AM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Mention Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

Hi Brian,

Thanks for the details of your prefered flow above. What you described in the Andriod scenario is possible on Windows as well, except:

1. We handle the connection and apps have little direct control we use a ref count model accross all apps and Windows.
2. On Desktop editions apps can't handle all incoming pairings; on IoT editions apps may. The decision is based on policies for end-user security.

Let me describe how you'd do it on Windows:

1. Use the Advertisement Watcher to watch for the device in question or DeviceWatcher.
2. When your app finds a device it's interested in, use BluetoothLEDevice.FromBluetoothAddressAsync or BluetoothLEDevice.FromIdAsync depending on which was used for discovery.
3. When your app gets a non-null BluetoothLEDevice use GetGattServicesAsync or GetGattServices to get the service objects. Null responses mean we couldn't connect, unfortunately for non-paired devices that implement address rotation this is expect to occur if your on a rotation boundary. It can also occur if we simply couldn't connect for radio issues.
4. At GattService object has a Session property; set it to true if you'd like us to maintain the connection and auto-reconnect while your app is using it.
5. Perform your app's operations as you would on Android.

What is different? Your users will need to handle the incoming pairing toasts when the remote device requests authenticiation if it's not paired.

What your app could do differently? If you did know ahead of time about needing to pair you could call PairAsync and handle the ceremony at least then you could hand the flow in your app deterministically.

Send your traces of problems collected with the BPA and our host logs collected at the same time and we'll seee what your encountering.

Thanks, Fg

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-487586755, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO62DUFRXJXASOSDHYHLPS34INANCNFSM4HHLTETQ.

[FrankGorgenyi]

Provide the requested traces and we'll see why. :)

[brianreinhold]

Frank,

Attached is BPA trace of a Philips Thermometer. I also attached my project. Below is the log from the app:

'BtleScannerTest.exe' (Win32): Loaded 'E:\projects\WinBluetooth\BtleScannerTest\Debug\BtleScannerTest\AppX\BtleScannerTest.exe'. Symbols loaded. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ntdll.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\kernel32.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\KernelBase.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\combase.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ucrtbase.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\rpcrt4.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sspicli.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\cryptbase.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\bcryptprimitives.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sechost.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\oleaut32.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcp_win.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'E:\projects\WinBluetooth\BtleScannerTest\Debug\BtleScannerTest\AppX\WindowsBluetoothAdapter.dll'. Symbols loaded. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00.Debug_14.0.27508.1_x86__8wekyb3d8bbwe\vcruntime140d_app.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'E:\projects\WinBluetooth\BtleScannerTest\Debug\BtleScannerTest\AppX\ucrtbased.dll'. 'BtleScannerTest.exe' (Win32): Unloaded 'E:\projects\WinBluetooth\BtleScannerTest\Debug\BtleScannerTest\AppX\ucrtbased.dll' 'BtleScannerTest.exe' (Win32): Loaded 'C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00.Debug_14.0.27508.1_x86__8wekyb3d8bbwe\msvcp140d_app.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'E:\projects\WinBluetooth\BtleScannerTest\Debug\BtleScannerTest\AppX\ucrtbased.dll'. The thread 0x34e8 has exited with code 0 (0x0). 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\kernel.appcore.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcrt.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\twinapi.appcore.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\rmclient.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\WinTypes.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\SHCore.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\user32.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\win32u.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\gdi32.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\gdi32full.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\imm32.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.UI.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\TextInputFramework.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\InputHost.dll'. 'BtleScannerTest.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\InputHost.dll' 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\CoreMessaging.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\CoreUIComponents.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\advapi32.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ntmarta.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\InputHost.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\d2d1.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\propsys.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\d3d11.dll'. 'BtleScannerTest.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\d2d1.dll' 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\dxgi.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\d2d1.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\OneCoreUAPCommonProxyStub.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\uxtheme.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\dwmapi.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\crypt32.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msasn1.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\cryptsp.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msctf.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\MrmCoreR.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.Shell.ServiceHostBuilder.dll'. 'BtleScannerTest.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\Windows.Shell.ServiceHostBuilder.dll' 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.Shell.ServiceHostBuilder.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\execmodelproxy.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\UiaManager.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.UI.Core.TextInput.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\dcomp.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.Devices.Bluetooth.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\biwinrt.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.Networking.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ws2_32.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.Networking.HostName.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.Networking.HostName.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.Networking.Connectivity.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\FirewallAPI.dll'. 'BtleScannerTest.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\Windows.Networking.HostName.dll' 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\dnsapi.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\nsi.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\IPHLPAPI.DLL'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\fwbase.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.Internal.Bluetooth.dll'. 'BtleScannerTest.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\Windows.Internal.Bluetooth.dll' 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\Windows.Internal.Bluetooth.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\embeddedmodesvcapi.dll'. 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\bcrypt.dll'. Scanner started 'BtleScannerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\deviceaccess.dll'. New advertisment/scanResponse with UUID 00001809-0000-1000-8000-00805F9B34FB and BT address 0x1C877400EC20 New ad/scanResponse pair with name Philips ear thermometer and UUID 00001809-0000-1000-8000-00805F9B34FB Connect to device called onecoreuap\drivers\wdm\bluetooth\user\winrt\common\bluetoothutilities.cpp(509)\Windows.Devices.Bluetooth.dll!0FF9FDD6: (caller: 0FFAB977) ReturnHr(1) tid(214c) 80070490 Element not found. onecoreuap\drivers\wdm\bluetooth\user\winrt\device\bluetoothledevice.cpp(428)\Windows.Devices.Bluetooth.dll!0FFAB9B7: (caller: 0FFAAF01) ReturnHr(2) tid(214c) 80070490 Element not found. BluetoothLEDevice returned BluetoothLEDevice returned is NULL. Can't register

Brian

---

From: Frank Gorgenyi notifications@github.com Sent: Monday, April 29, 2019 10:58 AM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Mention Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

Provide the requested traces and we'll see why. :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-487613844, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO65465OH27B4RPWTWVDPS4EK3ANCNFSM4HHLTETQ.

[FrankGorgenyi]

Hey Brian,

Did you perhaps reply to the notification email? The attachements are not posted online and I found no URL to fetch them to investigate.

Frank, Attached is BPA trace of a Philips Thermometer. I also attached my project.

Thanks, Fg

[brianreinhold]

Frank,

I am confused. A notification email? I will resend them here

Brian

---

From: Frank Gorgenyi notifications@github.com Sent: Thursday, May 2, 2019 5:28 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Mention Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

Hey Brian,

Did you perhaps reply to the notification email? The attachements are posted online and I found no URL to fetch them to investigate.

Frank, Attached is BPA trace of a Philips Thermometer. I also attached my project.

Thanks, Fg

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-488838577, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO64A4EIPTRJZ6Q3FBYTPTNMJRANCNFSM4HHLTETQ.

[brianreinhold]

Frank,

I see that the email is a notification. I do not know what else to send it to. Can you give me a real email address that foes to a human?

Brian

---

From: Frank Gorgenyi notifications@github.com Sent: Thursday, May 2, 2019 5:28 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Mention Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

Hey Brian,

Did you perhaps reply to the notification email? The attachements are posted online and I found no URL to fetch them to investigate.

Frank, Attached is BPA trace of a Philips Thermometer. I also attached my project.

Thanks, Fg

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-488838577, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO64A4EIPTRJZ6Q3FBYTPTNMJRANCNFSM4HHLTETQ.

[oldnewthing]

@brianreinhold I think you replied to the email rather than replying on the web site. If you reply on the web site, you can add attachments by drag/dropping them into the message.

[brianreinhold]

Oh, I see here. In the issue! Bummer, this web site wont accept these files. These are BPA sniffer files. You need a BPA file reader (free) to view them. Available here

http://www.fte.com/support/download.aspx?mode=update&iid=1w

But first, you need to get the files.

[brianreinhold]

Raymond,

The web site will not accept my files. BPA sniffer files. Free reader available here

http://www.fte.com/support/download.aspx?mode=update&iid=1w

Frontline Downloads - Frontline BPA 600: Dual Mode Bluetooth Protocol Analyzer - Frontline Test Equipmenthttp://www.fte.com/support/download.aspx?mode=update&iid=1w www.fte.com Frontline Test Equipment, Inc. - The Leader in Portable, Affordable, PC-Based Datacom Test Equipment and Custom Decodes

But you need to get the files first ...

Brian

---

From: Raymond Chen notifications@github.com Sent: Thursday, May 2, 2019 5:43 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Mention Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

@brianreinholdhttps://github.com/brianreinhold I think you replied to the email rather than replying on the web site. If you reply on the web site, you can add attachments by drag/dropping them into the message.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-488842867, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO65HUPWY4RQRTDMHUNDPTNN6PANCNFSM4HHLTETQ.

[FrankGorgenyi]

@brianreinhold you simply save the files you like into a zip archive, or you can use OneDrive or any similar sharing site.

[brianreinhold]

That worked! ediit ... It SAID it worked but it clearly didn't.

I will say this, the files I attempted to attach will be very boring. All they will show are advertisements and scan response, Nothing else to see.

---

From: Frank Gorgenyi notifications@github.com Sent: Thursday, May 2, 2019 6:35 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Mention Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

@brianreinholdhttps://github.com/brianreinhold you simply save the files you like into a zip archive, or you can use OneDrive or any similar sharing site.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-488856228, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO663ZFFLCGDTIKEIL73PTNUC3ANCNFSM4HHLTETQ.

[FrankGorgenyi]

@brianreinhold I don't see a link your reply or an attachment on the forum.

[brianreinhold]

Frank,

All I did was attach a zip file to the bug. I do not know what 'link to your reply' really means. I am now at an HL7 meeting and do not have access to those files. I will be back next thursday. I think I will need an email address to se =nd thise files too. Nothing else seems to work

I did this @brianreinholdhttps://github.com/brianreinhold you simply save the files you like into a zip archive, or you can use OneDrive or any similar sharing site

and it seemed to work. I did not get a reject in any case.

Brian

---

From: Frank Gorgenyi notifications@github.com Sent: Friday, May 3, 2019 1:01 PM To: Microsoft/Windows-universal-samples Cc: Brian Reinhold; Mention Subject: Re: [Microsoft/Windows-universal-samples] How does the DeviceWatcher actually work with respect to discovering bluetooth LE devices (#1089)

@brianreinholdhttps://github.com/brianreinhold I don't see a link your reply or an attachment on the forum.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/Windows-universal-samples/issues/1089#issuecomment-489167185, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMDO63H3XSSTGOJAJYK4VTPTRVXHANCNFSM4HHLTETQ.

[brianreinhold]

Well, now that I am here its clear it didnt work. The line below is not true. It says 'attache files by ... "

Nope! Didnt happen! Said it did, but it clearly did not.

[brianreinhold]

ThermometerNoConnect.zip I try again and I see again the 'link' above. I do not know if it will be there when I exit and come back.

[FrankGorgenyi]

Hey @brianreinhold,

Thanks for the log files I am glad you have uploads working.

Unfortunately I can only confirm the device is advertising as this is only part of the information requested. We need both the Windows traces and the air trace captured at the same time.

In the mean time can you please take a trace that includes you calling BluetoothLEDevice.FromBluetoothAddressAsync on the address returned from the AdvertisementWatcher?

Bluetooth Tracing

From the data provided it's clear there is a connectable advertisement that has the UUID for Health Thermometer.

LE ADV:
    Channel Selection #2: Not Supported
    PDU Type: ADV_IND
    Advertiser Address Type: public
    Payload Length: 16
    Advertiser Address: 0x1c877400ec20
    AD Data
        AD Element
            Length: 2
            AD Type: Flags
            AD Data
                BR/EDR Not Supported: Yes
                LE General Discoverable Mode: Yes
        AD Element
            Length: 3
            AD Type: Incomplete list of 16-bit UUIDs
            AD Data
                UUID: Health Thermometer

Unfortunately there is nothing showing CONNECT_IND, and there are no Windows traces to see if we sent the command to the radio, nor if the APIs forwarded it to the stack that manages the radio.

We need the requested information to help you.

Thanks, Fg

[brianreinhold]

Yes I know there was no connection event (at least not on the air). I had no idea what a Windows trace was (I assumed it was my log statements and anything else printed in the VS debug window while running. But I see there is a special Bluetooth Tracing. I will give it a whirl.

[brianreinhold]

setupapi.dev.log The other two files did not exist

I did the power shell thing (had to CD my butt off!), Pasted in the wget from the readme, ran my program. started my device, the usual happened. Went after the logs. Only one of the three existed.

I tried the 'radio' option as well. That did not make a trace. I don't think I know what I am doing.

[brianreinhold]

Frank, What if I just attach the project? Its just a test application to try and get basic connectivity using UWP and C++/winRT and dll

You can change/add a UUID to a device that you have. Does that make sense?

[brianreinhold]

BtleScannerTest.zip Attached is the project. It is very basic. Sets up an advertisement watcher and looks for advertisements with certain service UUIDs. When it finds one, it tries to connect. That is where the failure happens. You can change the UUID searched for a UUID exposed by whatever device you have. The Bluetooth project is a dll (WindowsBluetoothAdapter).

I think this will make debugging much easier. You might even make it into an example for C++/winRT Bluetooth using the Advertisement watcher ... a much more reasonable approach for BTLE devices than the DeviceWatcher because the advertisements give you the maximum amount of information one can get from a BTLE device before connecting.

[PPRiphagen]

Hello, Did you happen to find a solution to this problem? I have the same problem using c++ FromBluetoothAddressAsync

[brianreinhold]

@PPRiphagen I did not and have not found a solution. My personal opinion is that it does not work and that is why there has been no further response. The project I sent them is really no more than a unit test;; you can't get much simpler.

[PPRiphagen]

Thanks for the response, neither did I. Now looking at the Qt implementation of this, functionality, but is seems to be subject to the same problems, at least on Windows 10

[brianreinhold]

@PPRiphagen If you ever find a solution, I would be happy to know it. Our windows implementation has come to a grinding halt because of this. Looks like we will need to rely on Linux and Android.

[FrankGorgenyi]

Hi @PPRiphagen,

Our team focuses on issues with logs first. So can you please take a trace that includes you calling BluetoothLEDevice.FromBluetoothAddressAsync on the address returned from the AdvertisementWatcher?

Bluetooth Tracing

Thanks

[brianreinhold]

@PPRiphagen Maybe you will have better luck with this Bluetooth Tracing. I could not get it to work. The readme docs does not really explain setup very well (in fact it doesn't explain setup at all). In the end my files contained nothing; my own project print logs were much more informative. That's when I just packaged up my project so they could do the Bluetooth Tracing on it,.

The number of things I could have been doing wrong are so numerous I don't know where to start. I have no idea what those command lines are doing or what these *.wprp files are and how to 'install' them or whatever. If you have better luck, let me know what you did.

[PPRiphagen]

@brianreinhold btlescanner.zip I attached my class which is now able to scan for bluetooth devices. I still get the Element not found warnings, but I am able to get bluetooth names and Mac addresses while scanning. It also does not seem to crash, only sometimes when using breakpoints in debug mode. Hope the zip file contains some methods that are useful to you.

The code is still in early stage, no cleanup done, but I can at least scan for btle devices now.

[brianreinhold]

@PPRiphagen I can scan for devices, that has always worked. BUT I cannot connect to them. Are you able to connect to a discovered device (using the advertisement watcher as the scanning object)?

[PPRiphagen]

@brianreinhold I do get passed the FromBluetoothAddressAsync function, in it's callback where I can get more information. Or do you mean even passed that? For our application I just need to scan for non-paired devices, I do no need to connect to them

[brianreinhold]

@PPRiphagen Oh, well I need to connect to them. The AdvertisementWatcher is far superior to the DeviceWatcher with respect to scanning and getting device information, but using either I cannot connect. My application needs to connect to transfer measurements (like Blood pressure, glucose concentration, etc.).

[FrankGorgenyi]

@brianreinhold our team looks at issues with logs first, we'll not likely get to using your project file and attempt it our-self.

The tracing requires no installation. The wprp is simply a configuration file for the wpr.exe file that is already installed. The configuration file lists our trace provider ids. The output file is the *.etl (BthTracing.etl), it will be in the same folder that your ran the command from. The commands only work in an elevated (admin) PowerShell session.

[brianreinhold]

OKay I was going to give it another try. Its been a while. Brushed off the dust, opened the project in Visual Studio 2019 Community, ran the debuuger after a clean and rebuild, but it crashed with these statements Scanner started onecoreuap\drivers\wdm\bluetooth\user\winrt\advertisement\bluetoothleadvertisementwatcher.cpp(1487)\Windows.Devices.Bluetooth.dll!03B03426: (caller: 03B04CC2) Exception(1) tid(1360) 80070490 Element not found. Exception thrown at 0x75DBFD82 in BtleScannerTest.exe: Microsoft C++ exception: wil::ResultException at memory location 0x00E4E508. Exception thrown at 0x75DBFD82 in BtleScannerTest.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.

Went and updated VS and got the same result. I'm in a state of confusion ... its the same project I attached to this thread. I have yet to find anything on the issue googling...

[gabrielfreire]

BluetoothLEDevice.FromIdAsync(deviceId) returns NULL for me too, i've tried with Windows 10 bluetooth ON, then OFF, calling from inside the UI thread, outside the UI thread, i can't figure it out, it always returns NULL.

My WPF project has the Bluetooth Capability, everything was setup correctly, but the API just doesn't work, even worse, it only lists my BLE device if i pair to Windows first, if i "Remove Device" and turn the bluetooth OFF, or even leave it ON, the API never lists my BLE device, it doesn't make any sense.

If i pair the device to Windows, i get it listed but i can't get it paired with my application and can't get BluetoothLEDevice either, i get only NULL all the time.

I've gone through all the forums and stackoverflows possible looking for answers, nobody seems to know nothing and the API never gets fixed, i see people who has this same issue since 2016 and never got an answer.

Regards,

[FrankGorgenyi]

@gabrielfreire can you try providing logs on a recent build?

Bluetooth Tracing

[gabrielfreire]

BthTracing.etl https://drive.google.com/file/d/1OJddaP-fJIvMnWqLQXskbOxYNAc_ZM2V/view?usp=sharing

BluetoothStack.wprp

https://drive.google.com/file/d/1Jy_lHa09aTqQVONs6578seRhNJPO3hgG/view?usp=sharing

Steps

1. turn bluetooth OFF and ON
2. open WPF app
3. Try to unpair my device that was paired by Windows
4. Try to list it again (nothing was listed)
5. turn bluetooth OFF and ON again
6. restart WPF app
7. start listening
8. device is on but never gets listed