As I discussed in a previous blog article, the Raspberry PI3 Bluetooth driver for Windows 10-IoT-Core becomes errant and misses updates when the update rate is high. This is a known issue with the RPI. This problem does not exist other Windows 10 systems including the Dragonboard running IOT-Core. This article again discusses the problem and presents a workaround that does work. Includes how to disable/enable a driver using devcon.

The Issue

In previous articles, I have discussed a couple of GitHub projects for UWP apps monitoring of a TI SensorTag that provides environmental sensors that can continuously send update data to the app over a Bluetooth Low Energy (BLE) stream to the device hosting the app. There are two versions currently available with a general purpose BLE explorer app on its way.

Given that the apps are UWP they can be deployed to Windows 10 desktop, phone and IoT-Core.


· TI CC2650 SensorTag on GitHub

· CC2650SensorTag-CS-Creators on GitHub

· Bluetooth Low Energy on Windows 10 Creators Edition and a RPi3 issue.

· The original Microsoft BT GATT sample app


The older version of the app is a port of the Microsoft UWP sample code app for an older TI SensorTag to the TI CC2650 SensorTag. It also implemented a separation between the UI and the Bluetooth functionality with the BLE in a separate library for reuse in other apps. This app continuously displays the sensor update values and logs the updates to a file, logging the number of updates per 15 seconds. This app requires the SensorTag to be paired with the device running the app. The most recent update on GitHub requires Visual Studio 2017 and Creators Edition.

The second app requires the Windows 10 Creators edition version of the OS to be running on the device hosting that app. This is because it uses Advertisement by the tag as the basis of connectivity rather than pairing. Advertisement was only implemented on Creators. This app’s UI is a bit more rudimentary than the first app but is focused upon logging update rates with various options as well as directly reading sensors rather than using updates, as an alternative option.

The logging requirements came about because we discovered that although the app will run seamlessly on the desktop, phone and Qualcomm 410c (running IoT-Core) , they are both errant on the Raspberry PI3. See:


The above is the updates per 15 seconds which should average just under 80. At times, little or no updates occur. The app appears to stop for a while. This does not happen on the desktop, phone nor on the Dragonboard (Q410c).


I received this acknowledgement when I logged this issue:

You are correct, there is an issue with the RPi3.  More specifically, the Broadcom Bluetooth driver on the RPi3 will only work reliably with low bandwidth devices. There is no timeline at this moment on whether this will be addressed in the future, as we do not have support from Broadcom for a new or improved Bluetooth driver. The workaround is to use an external BT dongle and disabling the internal radio.



The Workaround

As suggested, the workaround is to disable the radio and then plug in a suitable USB dongle.

The Dongle

I had a USB BLE dongle that I was using on my desktop so I tried that in the workaround and it worked. The dongle I used (and worked) is from Jaycar in Australia:
USB2.0 Bluetooth® V4.0 Class 2 Dongle
The dongle seemed to be reasonably generic, just a Cambridge Silicon Radio Ltd chip. The IoT-Core BLE hardware compatibility list is at :


Note that I left the dongle’s insertion until after disabling the radio. Also, the process did not require a system reboot.

I actually did insert the dongle when the inbuilt radio wasn’t disabled but it came up with error 10.
From Device Portal-Devices, explore down the ACPI tree to “Generic Bluetooth Adapter” under “Generic USB Hub”:


ID : USB\VID_0A12&PID_0001\5&3753427A&0&4
Description : Generic Bluetooth Adapter
Class : Bluetooth
Manufacturer : GenericAdapter
StatusCode : 25191424
ProblemCode : 10


When running properly (with the inbuilt radio disabled) the properties are:

ID : USB\VID_0A12&PID_0001\5&3753427A&0&2
Description : Generic Bluetooth Adapter
Class : Bluetooth
Manufacturer : GenericAdapter
StatusCode : 25190410


When running on my desktop, the following information was gleaned about the dongle form Device Manager:

Generic Buetooth Radio

Device type: Bluetooth
Manufacturer: Cambridge Silicon Radio Ltd.
Location Port_#0006 Hub_#0006


Device Instance Path USB\VID_0A12&PID_0001\6&1343F042&0&6
Problem Code 0

Uses Microsoft drivers


Disabling the Radio

It was suggested to disable the radio through registry command.

reg add hklm\system\controlset001\services\BtwSerialH5Bus /v Start /t REG_DWORD /d 4

Run as administrator through Powershell (take link from Device Portal)

I used devcon instead and was able to only disable the BLE radio, not WiFi

Run a Powershell prompt to the RPI3 and login as Administrator

Now for some preliminaries. Try the following:

  • devcon find =mouse
  • devcon hwids =mouse
  • devcon find =MEDIA
  • devcon hwids =MEDIA

For the last I got:

Name: Raspberry Pi 2 audio
Hardware IDs:
  • devcon -r disable ROOT\rpiwav
ROOT\RPIWAV\0000 : Disabled
1 device(s) disabled.
  • devcon -r enable ROOT\rpiwav
ROOT\RPIWAV\0000 : Enabled
1 device(s) are enabled.

I tested driver disable on Audio (Media) as I’m not currently using it and can reinstall OS if all went aray.


Now to try it on Bluetooth radio

  • devcon find =Bluetooth

Amongst other related enumaerations I got:

BCMBTBUS\BLUETOOTH\3&2113EC42&0&4097 : Bluetooth Radio
  • devcon hwids =Bluetooth

Amongst other related enumerations I got:

Name: Bluetooth Radio
Hardware IDs:
Compatible IDs:

Now here it is, drum roll …:

  • devcon disable BCMBTBUS\BLUETOOTH
BCMBTBUS\BLUETOOTH\3&2113EC42&0&4097 : Disabled
1 device(s) disabled.

Device Portal then showed the inbuilt Bluetooth radio status as:

Description : Bluetooth Radio
Class : Bluetooth
Manufacturer : Microsoft
StatusCode : 25175040
ProblemCode : 22


At this point I plugged in the USB BLE dongle, its status came up in Device Portal as OK, no ProblemCode, and both apps ran without a glitch. The second app ran for over 12 hours without an issue before logging was manually stopped. The second app then ran for over 16 hours after which updates stopped, probably the tag’s battery got a bit low… (Update) Yes the tag’s button cell was flat.




  • · devcon enable BCMBTBUS\BLUETOOTH

To would re-enable .

Note devcon -r will reboot the system if that is required in the operation



Possibly the dongle should work OK without the need for turning off the inbuilt Bluetooth if the apps are run on a RPI2 as it doesn’t have inbuilt Bluetooth.  ..Yes the RPI2 worked OK with the BLE dongle and these apps without system modification.