In the following, I will do an analysis of the Windows operating system (OS) from the point of view of communication with Bluetooth Low Energy devices – in our case with different types of SensorTags: Thunderboard React, Thunderboard Sense (both produced by Silicon Labs Company), CC2650STK and CC2541DK (both developed by Texas Instruments Company).
I what follows, I will analyze Windows 7, Windows 8.1 and the following Windows 10 versions:
The analysis will be done from the following points of view:
All the tests were done using 126.96.36.199 version of the blessTags application. The blessTags application was built having as support the Windows SDK – Bluetoothapis. Functions like BluetoothGATTGetCharacteristicValue, BluetoothGATTGetDescriptorValue, BluetoothGATTGetServices or BluetoothGATTSetCharacteristicValue were used.
This application, blessTags (BLE SensorTags) application, can be downloaded from the Windows Store Apps: https://www.microsoft.com/store/apps/9p054xsjjr1n. For more information, demo, practical applications, examples etc. please visit the following blog: http://www.blesstags.eu.
Windows 10 - Anniversary Update - Version 1607
This version of the Windows 10 operating system is the best one, from the point of view of Bluetooth Low Energy devices. It can pair without any problem with all SensorTags (regardless of the software version running on them), with which blessTags application knows how to work (CC2650STK, Thunderboard React, Thunderboard Sense and CC2541DK), and all the information from the Bluetooth’s Services Get Generic Access and Get Device Information is acquired without any problem.
Analyzing the data acquisition speed (for CC2650STK and CC2541DK devices) using notifying and reading mechanism of data transfer, we can observe the following:
If we will analyze Thunderboard React and Thunderboard Sense, we will get the equivalent results – they work without any problem in the Windows 10 Anniversary Update environment.
In fact, all the presentation movies of the blessTags application main functions and of the different specific features (like Gadgets) have been made with the support of the Windows 10 Anniversary Update.
A small demonstration and a proof of the above statements in the following movie:
Windows 10 - Creators Update - Version 1703
The Creators Update version of Windows 10 is the worst operating system (OS) from the point of view of Bluetooth Low Energy devices.
Almost nothing is working. Microsoft acknowledged that the Creators Update broke Bluetooth Low Energy (reference 1 and reference 2). The Microsoft company promised a hotfix as soon as possible. But since then they have released an updated version of Windows (Fall Creators Update) and nothing has happened – up to now within the Windows 10 Creators Update version, the Bluetooth Low Energy still does not work.
There are a large number of posts on forums in which different peoples complains regarding different types of Bluetooth devices that stop working after upgrading to Creators Update (see here, see here, see here, see here etc.).
The results, I'm going to show right away, were obtained after many tests: (1) on a desktop PC that had a CSR4.0 Bluetooth USB dongle (CSR8510 A10) and (2) on a Dell Inspiron P66F laptop with an integrated Bluetooth LE device. I know there are many solutions on the internet to fix several types of Bluetooth issues. I tried almost all, but nothing was working (update the Bluetooth driver, run Windows troubleshooter, disable and enable Bluetooth related services etc.).
So, let’s present the results:
The operating system has a strange behavior when the pairing process is initiated. In the list of discovered devices, the SensorTag appear and disappear (with a period of 1 … 1.5 s). Finally, when a mouse clicks succeed on the SensorTag, the pairing process accomplishes and the LEDs on the Thunderboard React (the blue and the green ones) have a period when they are flashing consecutively in an atypical mode.
The reading of the characteristics of the Generic Access Service (0x1800) can be done without any problem, but the reading from Device Information Service (0x180A) fails on all four existing characteristics.
Setting the sensors (embedded on SensorTag), the mode of acquiring data (on Thunderboard React you have only the following possibility: (1) to get data through the notification from 3 sensors and (2) to read data from the other four sensors) is impossible. Therefore, the impossibility of obtaining the actual data from sensors results directly from here.
The same pulsating process, observed for Thunderboard React, was found to be also existing for Thunderboard Sense – when we want to achieve the pairing process. But here, things are even worse: after pairing, the blessTag program cannot detect the SensorTag. So, no active device – no entity from where the blessTags application to acquire the data.
Also, I was able to get Generic Access data. But, at the Get Device Information service, from 9 characteristics only 6 responded and only from them it was possible to get information.
Instead, I cannot set up the device and I cannot retrieve data from sensors either through the read mechanism or through the notifications.
The behavior is identical with the behavior of CC2650STK (firmware version 1.40). At each connection attempt, you will get the following error message: "Try connecting your device again".
So, in conclusion, within this version of Windows 10 (Creators Update), it is impossible to communicate with any of the four types of SensorTags point out above. Consequently, I mention (once again) that here I have used the same software version that I also used in all test made on Windows 10 Anniversary Update.
Windows 10 – Fall Creators Update - Version 1709
This version of Windows 10 (1709 – OS Build 16299.19) is a huge step forward, compared with Windows 10 Creators Update (were on BLE almost nothing is working), but still has a long way to get to the level of Windows 10 Anniversary Update (1607) operating system.
But let's see why I made this statement:
In the same mode like in Windows 10 Creators Update, the SensorTag appear and disappear when we want to add a new Bluetooth device. The same behavior can be highlighted in the action center on Bluetooth’s quick action button were “Not connected" and "Thunderboard React" are displayed repeatedly (please see in the following movie this process starting from the time index 5.14 s). Immediately we can conclude that Thunderboard React is guilty, mainly due to a flawed implementation of the advertising mechanism by Silicon Labs engineers. But, searching on the internet, we will notice that other users reported the same problem to other types of BLE devices, after installing the Fall Creators Update – e.g. view this movie on YouTube.
After pairing the SensorTag, the blessTags application is not able to find the Thunderboard React device. So, at this point nothing is working: Generic Access and the Device Information services or data acquisition from the sensors embedded on Thunderboard React SensorTag.
The mode to behave is similar to the one of the Thunderboard React. This Bluetooth device is displayed and disappears repeatedly. When the pairing process succeeded, it is possible to take data from Generic Access Service. But from this point, nothing is working anymore.
I will treat these two devices here simultaneously because their behavior related to the Windows 10 (1709) operating system is similar.
The pairing operation and the reading, from the Generic Access and the Device Information services, are working perfectly without any kind of problems.
The problems only occur when we want to read information from the sensors. The data transfer mechanism through notifications does not work at all.
The only way to get data from the sensors, embedded in the SensorTag, is by means of the direct reading mechanism from the device. This approach has two issues: (1) lower data transfer speed (as we have shown above) and (2) if all the sensors accept one of the two data transfer methods (through reading and notification), the buttons on the SensorTag can be interrogated only through the notification mechanism. Thanks to this "feature" of the Windows 10 (1709) OS, the blessTags application implements, starting with version 188.8.131.52, the reading method for data acquisition also.
A problem appears with the CC2650STK SensorTag having the firmware version 1.20. If the process of pairing and data reading from Generic Access service works very well, the reading process from Device Information services is not possible. Moreover, the sensors reading (from this SensorTag with this firmware version) does not work through either one of the two possible mechanisms (reading or notification).
As a conclusion, up now on Windows 10 Fall Creators Update (1709, build 16229.19) only the SensorTags produced by TI (CC2650STK and CC2541DK) are working. More, they are working only in reading mode. But attention! Only CC2650STK firmware version 1.40 will work in this mode. Unfortunately, when you buy a CC2650STK you have a very high chance of taking a device with firmware revision 1.20. So, to be able to communicate with a such a type of SensorTag an upgrade it is necessary at least to the firmware version 1.40.
Below I present a movie that proves all these statements made above for Windows 10 Fall Creators Update.
Since the first release of Windows 10 Fall Creators Update (build 16229.19), on October 17th, 2017, there have been no improvements or errors corrections related with Bluetooth LE up to KB4054517 (released on December 12th, 2017). In KB4054517 (OS Build 16299.125) there is a key change on Bluetooth LE (see here): “Addresses issue with personalized Bluetooth devices that don't support bonding”. Since this message is very cryptic, I've decided to resume all my analysis donned so far and to see if there are any improvements compared to the first release of Windows 10 Fall Creators Update (build 16229.19). … and a little surprise, right now I am able to get: (1) data from Thunderboard Sense (from the sensors embedded on the SensorTag but only through the reading mechanism) and (2) all the information from Generic Access and Device Information services. There are no other improvements.
As a first Microsoft OS with BLE support, the implementation is satisfactory, but it is far to be an excellent one. The only devices that work with this operating system are CC2650STK and CC2541DK.
Setting the acquisition time to 150 [ms], for the CC2650STK, we can get the data (from all embedded sensors), complying the 150 [ms] sampling rate, through the notification mechanism without any problems. Unfortunately, using the CCC2650STK reading mechanism, we can get data (from all the sensors) with a period of 2 seconds.
The situation is getting worse when we are talking about CC2541DK. Through the notification mechanism, the data is obtained with a period of 0.4 ... 0.6 seconds. While using the reading mechanism we can retrieve the data with a fluctuating period of 2.8 ... 3 seconds. The conditions are the same: acquisition period 150 [ms] from all the sensors embedded on the CC2541DK SensorTag.
The Microsoft company has added support for the Bluetooth Low Energy (BLE) stack starting with the Windows 8 operating system. They have provided an API which enables applications to access BLE devices.
But the Microsoft has not ported the BLE API's to Windows 7. The Windows 7’s built-in stack supports only Bluetooth version 2.1/3.0, there is no support for BLE (4.0, 4.1 or 4.2). So, from the point a view of a developer it is impossible to communicate, in Windows 7, with a BLE device using Windows 7’s stack.
The TI company have a program called the BLE Device Monitor that is able: (1) to run on Windows 7 and (2) to communicate with a SensorTag. But you must use for these a special USB dongle (e.g. CC2540 Bluetooth Low Energy USB). If the source code for the USB dongle is free, the source code for the BLE Device Monitor is not available – it is only for the internal use of the TI company.
The Windows 10 Anniversary Update (Version 1607) is the best Windows version ever made by Microsoft from the point a view of Bluetooth Low Energy (BLE) devices – SensorTags in our case. Obviously, this is also due to the considerable number of improvements that took place at the Bluetooth LE level in the following OS builds (see for more info: https://support.microsoft.com/en-us/help/4000825): 14393.51, 14393.105, 14393.189, 14393.222, 14393.321, 14393.351, 14393.726 and 14393.1083.
The blessTags (BLE SensorTags) application can be downloaded from the Windows Store Apps: https://www.microsoft.com/store/apps/9p054xsjjr1n. For more information, demo, practical applications, examples etc. please visit the following blog: http://www.blesstags.eu.
Synthesizing all of the above results we will get the table below.