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).
In what follows, I will analyze Windows 7, Windows 8 and the following Windows 10 versions:
- Anniversary Update (released on August 2, 2016; end of support: tentatively March 2018),
- Creators Update (released on April 5, 2017; end of support: tentatively September 2018) and
- Fall Creators Update (released on October 17th, 2017; end of support: tentatively March 2019).
The analysis will be done from the following points of view:
- The ability of the operating system (OS) to pair with the SensorTag;
- The ability to get Generic Access data (this is a mandatory service);
- The ability to get Device Information (this service exposes manufacturer and/or vendor information related to a specific SensorTag);
- The ability to get the SensorTag's data using for this the reading approach and
- The ability to get the SensorTag's data using for this the notification approach.
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.
This version of the Windows 10 operating system is the best one, from the point of view of Bluetooth Low Energy devices. It is able to 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 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:
- through the notification mechanism, we can get data from all sensors (eight) from 150 [ms] to 150 [ms] without any problems;
- instead, when we set the acquisition time to 150 [ms] and we use the reading mechanism - in the happiest situation, we get 713 [ms] and in the worst case, we get 840 ms.
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:
The Creators Update version of Windows 10 is the worst operating system from the point of view of Bluetooth Low Energy devices. Almost nothing is working. Microsoft acknowledged that the Creators Update breaks Bluetooth Low Energy (reference1 and reference2). 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 to fix several types of Bluetooth issues. I tried 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:
- On the firmware version 1.40 pairing the SensorTag device with Windows is impossible (I repeated the process several times, at least 8-10 times, I turned on and off the Bluetooth and I tried again – the results were the same: it was impossible to add this device).
- In the firmware version 1.20, the PC discovered the SensorTag and I was able to pair the SensorTag with the PC.
Also, I was able to get Generic Access data. But, at the Device Information service, from 9 characteristics only 6 responded and only from them it was possible to get data.
Instead, I cannot set up the device and I cannot retrieve data from sensors either through the read mechanism or through the notifications.
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 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 blessTagprogram cannot detect the SensorTag. So, no active device - no entity from where the blessTags application to acquire the data.
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.
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:
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) (2) if all the sensors accept 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 18.104.22.168, 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) does not work through either one of the two possible mechanisms (reading or notification).
In the same mode as 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 the following movie 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 this problem to other 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 with the one of Thunderboard React, this Bluetooth device is displayed and disappear repeatedly. When the pairing process succeeded, it is possible to take data from Generic Access Service. But from this point, nothing is working anymore.
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.