blessTags configuration panel

        Starting with the blessTags version 11.2.6.0 a new panel, used to configure the blessTags application, was introduced – see the below figure. This configuration panel is active only in the full version of the blessTags application.

This panel brings the following new features:

1. Unlimited number of instances for the blessTags application

        The first option allows to run an instance or many instances (the number of instances it is not limited) of the blessTags application. In this mode, an instance of the blessTags application can manage one type of SensorTag (e.g. CC2650STK) and another instance of the blessTags application can manage another SensorTags (e.g. ThunderBoard Sense).  The blessTags Lite application allows only one instance of the application to run at one time moment.

2. The system tray icon

        Right now, the application has the possibility to be represented by a button on the taskbar or by a small icon on the system tray.

       Left clicking on this icon will minimize – maximize the blessTags application. By right clicking on this icon three different controls are accessible to the user in order to: close the blessTags application, configure the active SensorTag (the last SensorTag selected by the user) and disconnect the SensorTag (all the sensors embedded on the SensorTag will be configured in sleep mode and the Bluetooth LE communication will be terminated).

       A short demonstration movie with these two configuration options is presented below.

3. Display text information in real time

       One of the most time-consuming operations is data displaying on the user interface. When the acquisition frequency is very high (like in the situation of Nordic Semiconductor Thingy:52 SensorTag), the blessTags application will be unable to take in time the entire steam of data events due to the time spent in data displaying operations.

       To solve this problem, the data from sensors will be displayed every 250 ms (four times in a second). Checking the box “Display text information in real time,” the data will be posted at the acquisition frequency set by the user.

       This option is used only for the Nordic Semiconductor Thingy:52 SensorTag. In the Lite version of the application for the Thingy:52 SensorTag the display period is 250 ms regardless of the frequency chosen by the user to get the data.

       This option affects only the display operations. The data acquisition frequency is the one selected by the application’s user, and this option does not influence it.

4. Set the priority for the application

       This option is implemented from the blessTags version 12.0.0.0, only in the full version of the application. From the configuration menu, a priority level for the application can be selected. Five different priorities are allowed (from fastest to slowest):   Realtime - highest priority, High, Above normal, Normal (the program priority by default) and Below normal.

       In Windows, each thread is scheduled to run based on its scheduling priority. By default, in the Windows operating system (OS), all the threads have the same priority – Normal priority. The schedule of the OS assigns time slices to all the threads, in a round-robin fashion, starting with the threads with the highest priority. If none of these threads are ready to run, the system assigns time slices in the same mode (round-robin fashion) to all threads with the next highest priority. Every time when a higher-priority thread becomes available to run, the system ceases to execute the lower-priority thread and assigns a full-time slice to the higher-priority thread.

       This option can be used mainly to improve the speed of the data acquisition, especially when we use a faster SensorTags like Nordic Thingy:52 (with a movement data acquisition up to 200 Hz) or a modified software version for the CC2650STK.

5. Removing the software restrictions

       In order to work correctly, the blessTags application imposes several restrictions. For example, the identification of different types of SensorTags can be done using the mandatory BLE service Generic Access, based on the 0x2A00 characteristic. This embedded characteristic, the Device Name (0x2A00 characteristic), have a special string that defines in a unique way different SensorTags. Using this last option, the user can use custom names from each SensorTags.

      Additionally, other restrictions are also eliminated. For example, in order to be able to use a modified software version of the CC2650STK SensorTag (that acquires the acceleration at a higher speed – less than 150 [ms] for each sample), this option must be selected.

Please visit blessTags online:

BlessTags on Windows Store: http://www.microsoft.com/en-us/p/blesstags/9p054xsjjr1n

BlessTags Lite (the free version): http://www.microsoft.com/store/apps/9mt2kgztfjf5

On Facebook: http://www.facebook.com/blessTags

On Twitter: https://twitter.com/blesstags
Instagram: www.instagram.com/blesstags/
Or subscribe to Bluetooth low energy SensorTag by Email

blessTags 12.0.0.0 release

      In a few days, prepare you for a new release for the blessTags application - the version 12.0.0.0. The new release will bring support to the Nordic Semiconductor Thingy:52 SensorTag.

      It is a wonderful news, but it also means that only a few days remain left to check the following functionalities (that are activated in the Lite version – the free version of the blessTags): events, warnings, activities, developer mode, application configuration and the save function.

Please visit blessTags online:

• BlessTags on Windows Store: http://www.microsoft.com/en-us/p/blesstags/9p054xsjjr1n
• BlessTags Lite (the free version): http://www.microsoft.com/store/apps/9mt2kgztfjf5
• On Facebook: http://www.facebook.com/blessTags
• The associated blog: http://www.blesstags.eu
• On Twitter: https://twitter.com/blesstags
• Instagram: https://www.instagram.com/blesstags/
  

blessTags application Privacy Policy

Network Usage:

       The blessTags application uses the internet to send an email when an event will take place – the desired sensor value (instantaneous, mean or the variance) is lower or higher than a threshold value or is inside or outside of a specific range of values. But, this email will be sent only to the people indicated by the user of the blessTags application! No one else will know, use or store the email address or the email body message.

Data Collected:

      The blessTags program does not collect any kind of personal data from users.  It does not ask for your name or email address and does not knowingly send them back to the developer. No your IP address (or your gateway’s IP address) will be collected or transmitted to the developer.

      blessTags shares this information with the following parties:

• No data will be shared using this application and the application doesn't have abilities to collect personal user information.

More info about:

     You are always welcome to write to me about the application. If you would like to have further information, use the following email:

• mdobrea at gmail.com

     This policy is subject to change without notice. Please check this page for the latest privacy policy. If you disagree with this policy, please discontinue use of the application.

How many hours do you spend on the development of the blessTags application?

       This is a very hard question. I have never been counting how much time I spent in developing the blessTags application. With the release of each new version, the number of code lines that the new version of the application has it is counted and presented to the users - please see the blessTags version history section. This indicator, the number of code lines of the blessTags application, it is a very good reference for the efforts made in developing the application. But that's not all. Testing the newly developed features, testing their integration with the rest of the application also takes a lot of time.

       In order to highlight these efforts (made in the testing phase of the application), but also those deployed in the development of the blessTags application, I think an image is much more exciting. 

       In the below figure, I present all the coins batteries (CR2032) depleted in the last 6-8 months in the development phase and testing phase of the blessTags application with different types of the SensorTags.

Q&A (question and answer) section

      In this section of this blog, I will answer the various questions from users of the blessTags application. So, if you have questions on which do you have not found answers in the pages of this blog, please email me at mdobrea at gmail.com - I will answer at each of them. If a question is repeated constantly by many users or the response to a specific question concerns more users of the blessTags application, I will post the answer to it on this page.

1. What is it the blessTags application main advantage comparing with other similar application?
2. How many hours do you spend on the development of the blessTagsapplication?

Services, Characteristics, Descriptors and Declarations in Bluetooth BLE

      When we interact with a SensorTag device, we interact with a specific element named Attribute. Services, Characteristics, Descriptors, and Declaration are different types of Attribute.

      The behavior of a BLE device (a SensorTag) is given by the different Services that encapsulate different parts of this behavior. Mainly, a service is a container for different data items – these data items can be read (e.g. a sensor value from a SensorTag) or write (e.g. we must write a value in order to configure a sensor – for example, to set the dynamic range for the accelerometer sensor). For example, the behavior of the ThunderBoard Sense SensorTag is encapsulated in the following services: 

• Generic Access Service (UUID = 0x1800);
• Generic Attribute Service (UUID = 0x1801);
• Device Information Service (UUID = 0x180A);
• Battery Service (UUID = 0x180F);
• Environment Sensing Service (UUID = 0x181A);
• Power Management Service (UUID = EC61A454-ED00-A5E8-B8F9-DE9EC026EC51);
• Indoor Air Quality Service (UUID = EFD658AE-C400-EF33-76E7-91B00019103B);
• User Interface Service (UUID = FCB89C40-C600-59F3-7DC3-5ECE444A401B);
• Automation IO Service (UUID = 0x1815) and
• Acceleration Orientation Service (UUID = A4E649F4-4BE5-11E5-885D-FEFF819CDC9F).

     As a conclusion, a service represents a specific hardware feature of a SensorTag (or to other type of Bluetooth device) – e.g. in ThunderBoard Sense SensorTag the sensors values related with the air quality (these sensors can detect the existence of ethanol and hazardous gases such as carbon monoxide and a wide range of volatile organic compounds) are grouped in Indoor Air Quality Service. The complete table with all information regarding the services for ThunderBoard Sense SensorTag can be found here. The blessTags software gives the possibility to interrogate different types of unknown BLE devices – in order to be able to obtain the complete GATT attribute table for an unknown BLE device several steps must be done, such example can be found here.

     In a Bluetooth device, a service contains, at least, one or more characteristics. A characteristic owns none or more descriptors. The descriptors are completely optional, but a service must contain at least one characteristic. Each service, characteristic and descriptor must be identified by a unique identifier (UUID). UUIDs can be 16- or 128-bit values. For example, the Generic Access Service (presented above) have a UUID on 16 bits value (0x1800) while the service Acceleration Orientation Service (presented above) have a UUID on 128 bits value (A4E649F4-4BE5-11E5-885D-FEFF819CDC9F).

     A characteristic of a service is related to an internal state of a BLE device – e.g. a value that quantifies the volatile organic compounds from the air, obtained from the CCS811 digital gas sensor embedded inside the ThunderBoard Sense SensorTag. Also, Characteristics contain various properties. A property describes what another device (a client) can do with a characteristic over Bluetooth.  The operations such as READ, WRITE, NOTIFY or INDICATE are permitted or not, functions of specific value defined by a property associated with a characteristic. For a deep description of properties please visit the post “Reading vs. notifying”. 

Example 1: So, let’s take an example. The Service Automation IO Service (with the short UUID = 0x1815 and with the long UUID = 00001815-0000-1000-8000-00805F9B34FB) have two Characteristics. The first one with UUID_0 = 0x2a56 and the second one with UUID_1 = 0x2a56. The first Characteristics owns three Descriptors, with UUIDs: 0x2902, 0x2904 and 0x2909. The second Characteristics owns only two descriptors with the UUIDs: 0x2902 and 0x2909. See the figure from below (the figure was obtained with the developer function of the blessTags application).

     The characteristics UUID can be predefined ones - like the ones presented above with the UUID = 0x2a56. These predefine UUIDs have specific functions associated by the Bluetooth BLE standard.  The Characteristic’s UUIDs defined by Bluetooth BLE standard always follow the formats: (a) 0x2A[xx] – where the [xx] are two hex values and (b) 0x2B[yy] – where the [yy] are hex values.

     The Descriptors are special types of attributes that describe a characteristic value (they contain different type of metadata, based on this information they augment a characteristic) with which they are associated. A very important descriptor is the Client Characteristic Configuration Descriptor (abbreviated to CCCD) – based on this descriptor the notification messages can be switched on or off.  Up to now, descriptors have associated only short UUIDs (16 bits value). The descriptor’s UUIDs identifiers always follow the format: 0x290[y] – where the [y] value is a hex number.

     A special type of attribute is the declarations. The declarations are used to separate distinct group of attributes: in services and inside a service in characteristics. A Service Declaration attribute has always the standard UUID the 0x2800 value. The Characteristic Declaration have the standard UUID the 0x2803 value. Please see this in the figure presented above. The declaration’s UUIDs identifiers always follow the format: 0x280[z] – where the [z] value is a hex number as follow {0, 1, 2, 3}.

Example 2: In ThunderBoard Sense, the service Indoor Air Quality Service has three characteristics – the service attribute table is presented in the above picture. A service starts with a Service Declaration attribute (UUID = 0x2800) and each characteristic is separated by the other characteristics with a Characteristic Declaration (UUID = 0x2803). All the characteristics UUIDs, of this service, are not defined in Bluetooth BLE standard – have UUIDs different from 0x2A[xx] and 0x2AB[yy] format. In this case, the UUIDs values are defined by the producer of the ThunderBoard Sense SensorTag – the Silicon Labs company. The third characteristic has associated only one descriptor – the CCCD. To access the data from the first two characteristics, a READ operation must be initiated – the [R] property in the figure.

      Starting with the version 11.0.0.0 of the blessTags application all the characteristics (more than 200 characteristics) defined by the Bluetooth BLE standard are identified and presented to the user.

Example 3: To understand better the advantage of knowing the characteristics defined by the Bluetooth BLE standard, below are presented: (a) the attribute table for the Device Information Service (UUID = 0x180A) knowing the characteristics defined by the Bluetooth BLE standard – the first figure presented below and (b) the same table unknowing the characteristics defined by the Bluetooth BLE standard – the second image presented below.

The blessTags application can be downloaded from the Windows Store Apps: https://www.microsoft.com/store/apps/9p054xsjjr1n.

   

The blessTags Lite application (the free version of blessTags) can be downloaded from the Windows Store Apps: https://www.microsoft.com/store/apps/9mt2kgztfjf5.

Thank you very much for reading this article and your interest in Bluetooth LE technology!