ARM / ARM64 Catastrophic Failure when connecting to BLE Device Arduino Nano Sense 33(u-blox NINA B306 Bluetooth 5)

[Naphier]

HoloLens 2 OS version: 100.19041.1103 (up to date as of 10am June 2, 2020)
Windows 10 PC OS version 1909
Microsoft.NETCore.UniversalWindowsPlatform v6.2.10
UWP SDK version 1903 (10.0; Build 18362) (target and min)

We're trying to get our HoloLens 2 devices to communicate with Bluetooth LE devices (specifically the u-blox NINA B306 -- which is a standard Bluetooth 5 series -- embedded on an Arduino Nano Sense 33).
NINA info:
https://www.u-blox.com/sites/default/files/NINA-B3_DataSheet_%28UBX-17052099%29.pdf
Nano BE Sense 33 Info:
https://store.arduino.cc/usa/nano-33-ble-sense

Using: https://github.com/microsoft/Windows-universal-samples/tree/master/Samples/BluetoothLE
Under a Windows 10 PC (v 1909) the UWP x86/x64 build works 100% fine.
Devices are enumerated, can be connected to and queried for GATT services and characteristics, can listen to value changes. No real problems. We extracted the code from the example to our own app and all works well. Device name, id, isConnected isConnectable, isPaired, and isEnabled properties all report as expected.

Under HoloLens 2 neither the UWP ARM or ARM64 build will work properly. Devices are discovered and my nano device shows up. It seems to fail when either connecting or when trying to get the service list with a CATASTROPHIC FAILURE HR Result.
This failure occurs within this repository's BluetoothLE sample, my app, and the "Bluetooth LE Explorer (by MS)" app on the windows store.
Interestingly on the HoloLens the device names are often not listed. The ID of the devices seems different than Windows desktop sees, and the properties are not the same such as isConnectable (almost always false but sometimes flips very frequently) and isConnected seem to be wrong.

For example (differing IDs):
On HoloLens the name / ID of the Nano is
BLEServduino / BluetoothLE#BluetoothLE84:57:33:69:a6:92-e5:2f:88:f8:d5:ce
On windows PC it is
BLEServduino / BluetoothLE#BluetoothLEfc:77:74:37:b2:97-e5:2f:88:f8:d5:ce
The device's address (according to the ArduinoBLE library running on the device) is:
33:69:a6:92:00:01

Failure occurs at
await device.GetGattServicesAsync(BluetoothCacheMode.Uncached);
I've also tried
await device.GetGattServicesForUuidAsync(MyService_GUID, BluetoothCacheMode.Uncached);

I've tried a few other methods too like using AdvertisementWatcher. Works on Win10 x86/64 but not on ARM/ARM64.

I'm stuck and unfortunately we thought that, like most mobile BLE APIs, this would just work out of the box without a hassle. Now I've spent days trying to work with this and it seems no one knows.

[N0RAIR]

Have you enabled the Bluetooth Capability? Check if in the manifest file there is this entry
<DeviceCapability Name="bluetooth" />
And just make sure, that the Bluetooth is turned on, on the HoloLens.

We are using like
var gattservices = await device.GetGattServicesAsync();
and it works without issues.

[Naphier]

Yes capability has been declared and Bluetooth is turned on (devices are discovered)

    <Capabilities>
        <Capability Name="internetClient" />
        <!--BT_Code: Always declare the bluetooth capability when using Bluetooth-->
        <DeviceCapability Name="bluetooth" />
    </Capabilities>

Are you running on HoloLens 2 ARM or ARM 64? What BT device (maybe that's our issue, but we've tried a couple)?
Thanks

[joshcaspersz]

I’m getting the same issue after upgrading to 100.19041.1103 on Hololens 2 with connecting to an Arduino over Bluetooth.
It was working fine in the last update, downgrading to an older update with Advanced Recovery Companion fixes the issue but is not ideal.

[Naphier]

That at least gives me hope though. Will give that a try next week. Thank you!

…

On Sun, Jun 7, 2020, 08:39 Josh Caspersz ***@***.***> wrote: I’m getting the same issue after upgrading to 100.19041.1103 on Hololens 2 with connecting to an Arduino over Bluetooth. It was working fine in the last update, downgrading to an older update with Advanced Recovery Companion fixes the issue but is not ideal. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1209 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNJYPAJQVFM7NOLEU2OKJDRVODBVANCNFSM4NRB4ZPQ> .

[Naphier]

Downgrading to 10.0.18362.1061 doesn't seem to have helped (ms told us to try downgrading to this version). @joshcaspersz what version did you downgrade to and what Arduino device are you using? Thanks!

[Naphier]

Disregard previous message. Downgrade worked. My engineer mistakenly paired the BLE device vs the OS BT device manager (not sure why that's even possible with a BLE device - as it doesn't pair anyway -- different issue).
Long story short, this is definitely an OS issues on HL2. I'll update this issue when an OS release fixes it.

[joshcaspersz]

I can also confirm that 10.0.18362.1061 is working.
Interestingly I get a similar issue with connecting to the Arduino MKR WiFi 1010 using the BLE sample on my Windows 10 desktop running build 19041.329 (Version 2004). It was working when previously running a 18362 build (1903).
So it seems the issue may not just be the Hololens 2, but the 19041 build.

[Naphier]

MS is aware of the issue, but is asking for devs to report feedback to elevate the issue.

Here's what they asked:

There's an active incident being tracked for this issue. Can you submit a Feedback Hub report on your HoloLens - https://docs.microsoft.com/en-us/hololens/hololens-feedback?
Make sure to include relevant data by recording your problem. Make sure to include a unique description so you can provide that to me so we can find it.

I ask that anyone affected by this should report ASAP so that we can get MS to pay attention as this is pretty critical to a lot of us.

[joshcaspersz]

It seems this is an issue with the AndroidBLE library.
Making the following change to the library arduino-libraries/ArduinoBLE#95 seems to fix the issue.

[oldnewthing]

Closing since not an issue with the sample.

[Naphier]

Yup verified. All fixed with some great help from the MS team in finding a flaw in the ArdunioBLE lib. Still abit curious as to why this wasn't a problem in earlier OS versions, but at least there's a way to work with it now. Cheers!