Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
The beginning of every GATT database (GATTDB) within the SDK begins the comment: // Service change characteristic is optional and is not presentW...
The beginning of every GATT database (GATTDB) within the SDK begins the comment:
// Service change characteristic is optional and is not present
What is the service change characteristic? Why would I want it? And how would I implement it?
When a GATT client and server connect for the very first time, the client knows nothing about the server. In order to achieve a useful relationship, the client performs a GATT discovery on the server. There are a few variations in how the client can choose to go about this--search by handle, by type, etc.--we won't delve into the specifics of discovery.
With low power in mind, these GATT discoveries are costly. Given that the client has the resources, it is far more efficient to jot down the details of the server's GATTDB and store that locally--this is called an Attribute Cache. In order to save power, upon future reconnections, the client will not perform a GATT discovery, but rather reach into its local memory to save power on both the client and server devices.
However, a problem arises when we change the GATTDB between connections. The client will think the servers GATTDB is of the old form and begin operating on that basis. Now, this will only happen in the field under the premise that your firmware alters the GATTDB between connections.
How do we fix this? One way is to utilize the Service Changed Characteristic. This characteristic is essentially a way for the server to indicate to the client that a change has been made to its GATTDB. The client should then update its Attribute Cache with the newest values.
This is how you would implement it in your GATTDB:
This characteristic is implemented under the GATT Service that is mandatory to all GATTDB's. The Service Change Characteristic has a spec defined UUID. It needs only the ability to indicate and should have no required permissions. Lastly, it needs a value length of 4 bytes. These 4 bytes are used to designate the range of handles which have been changed. The first 2 bytes are the start handle, the last 2 bytes are the stop handle. As can be seen in the code above, we have specified this range to be all handles 0x0000 - 0xffff--tlling the client to completely rediscover the GATTDB.
Since we need to use indications, this characteristic now needs a Client Configuration Descriptor--as all server initiated communications need. This descriptor is, essentially, two client-writable bytes that allow the client to give the server permission to transmit asynchronous communications--one byte is for notifications and the other is for indications. The service changed characteristic requires the use of indications (a notification with an application level ACK).
The actual use of the Service Changed Characteristic requires the implementation of indications, GATT discovery by the client, and a change in the GATTDB by the server. These will not be covered here, but there exist individual resources for each:
If you are having problems with your installer, check that the download size of the installer is roughly 260MB, installer problems are typically caused by incomplete downloads.
The picture below shows a very common error message. Our SDK utilizes a 32-bit version of an Eclipse based IDE which requires a 32-bit version of JRE to be installed. If you already have the 64-bit JRE installed, you will also need to install the 32-bit version as well. The JRE is designed to allow both 32 and 64 bit variants to be installed on the system.
The WICED Sense kit uses a Silicon Labs USB to Serial Device. The TAG3 board uses an FTDI USB to Serial Device. Both should be installed as part of the SDK 2.2.1 installation process. If not, the FTDI drivers for the TAG3 reinstall them using the file /WICED-Smart-SDK/Drivers/dpinst.exe (make sure you access from the command line). The Silicon Labs USB Drivers can be foundWICED Sense Table of Contents
Everything we have for the WICED Sense, such as schematics, drivers, and Android application source code, can be accessed through theWICED Sense Table of Contents. A great post for the WICED Sense is theWICED SENSE Kit BLOGwhich is like a WICED Sense quick start guide.
Some Android devices appear to have issues pairing to the WICED Sense Tag from inside the app, linked is a work-around that should allow you to connect to your Android device:WICED Sense Android Pairing Work-Around