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.
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:
As suggested, the workaround is to disable the radio and then plug in a suitable USB 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 DongleThe 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&4Description : Generic Bluetooth AdapterClass : BluetoothManufacturer : GenericAdapterStatusCode : 25191424ProblemCode : 10
When running properly (with the inbuilt radio disabled) the properties are:
When running on my desktop, the following information was gleaned about the dongle form Device Manager:
Generic Buetooth Radio
Device type: BluetoothManufacturer: Cambridge Silicon Radio Ltd.Location Port_#0006 Hub_#0006
Device Instance Path USB\VID_0A12&PID_0001\6&1343F042&0&6Problem Code 0
Uses Microsoft driversbthport.sysBTHUSB.SYS
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:
For the last I got:
Name: Raspberry Pi 2 audio
ROOT\RPIWAV\0000 : Disabled
1 device(s) disabled.
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
Amongst other related enumaerations I got:
BCMBTBUS\BLUETOOTH\3&2113EC42&0&4097 : Bluetooth Radio
Amongst other related enumerations I got:
Name: Bluetooth Radio
Now here it is, drum roll …:
BCMBTBUS\BLUETOOTH\3&2113EC42&0&4097 : Disabled
1 device(s) disabled.
Device Portal then showed the inbuilt Bluetooth radio status as:
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.
Thank you for the workaround. I just tried it on my Raspberry Pi 3 running Win 10 IoT. It solved the problem I earlier observed with the BLE stack causing BLEWatcher to stop working. I use a CSR 4.0 Bluetooth dongle with the original driver provided by Win 10 IoT. But, unfortunately, even with this workaround, after providing correct BLE communication for a short time, the application starts reporting on every BLE device advertisement "Device Not Reachable". I verified that with Win 10.IoT build 10.0.17115.1 the BLE stack behavior has been improved and provides good quality communication with BLE devices for a couple of hours, but then the BLE Watcher still stops working and causes the application to slow down and hang-up. Please advise me for a possible solution of the BLE communication problems in Win 1oT 10 on Raspberry Pi 3. Thanks. As a reference, in Device Portal, Device Manager-> Microsoft Radio Device Enumeration Bus->Bluetooth, the CSR dongle is not shown, but instead a Microsoft device: Properties: ID : SWD\RADIO\BLUETOOTH_001A7DDA7113 Description : Generic software device FriendlyName : Bluetooth Class : SoftwareDevice Manufacturer : Microsoft StatusCode : 1098915850
Thank you for the workaround. I just tried it on my Raspberry Pi 3 running Win 10 IoT. It solved the problem I earlier observed with the BLE stack causing BLEWatcher to stop working. I use a CSR 4.0 Bluetooth dongle with the original driver provided by Win 10 IoT. But, unfortunately, even with this workaround, after providing correct BLE communication for a short time, the application starts reporting on every BLE device advertisement "Device Not Reachable". I verified that with Win 10.IoT build 10.0.17115.1 the BLE stack behavior has been improved and provides good quality communication with BLE devices for a couple of hours, but then the BLE Watcher still stops working and causes the application to slow down and hang-up. Please advise me for a possible solution of the BLE communication problems in Win 1oT 10 on Raspberry Pi 3. Thanks.
When the BLE dongle is inserted it shows up on the default startup app main page as two entries: USB Composite Device CSR8510A10
The above "comment" is the Device tree on Device Portal-Devices for the Bluetooth Driver/s with the USB dongle inserted.
>HTREE\ROOT\0 >ACPI ARM-based PC >Microsoft ACPI-Compiant System >Microsoft DWCHSOTG USB Host Controller >DwcHsOtg USB Root Hub >Generic USB Hub >Generic Bluetooth Adapter Properties: ID : USB\VID_0A12&PID_0001\5&3753427A&0&4 Description : Generic Bluetooth Adapter Class : Bluetooth Manufacturer : GenericAdapter StatusCode : 25190410 >Microsoft Bluetooth Enumerator >Bluetooth Device (RFCOMM Protocol TDI) >Bluetooth Device (Personal Area Network) >BthL2cap Driver >Microsoft Bluetooth LE Enumerator