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?
Introduction:
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.
Implementation:
This is how you would implement it in your GATTDB:
const UINT8 gatt_database[]=
{
// Handle 0x01: GATT service
PRIMARY_SERVICE_UUID16 (0x0001, UUID_SERVICE_GATT),
// Indicate that entire GATTDB has been altered
// (handles: 0x0000 - 0xffff)
CHARACTERISTIC_UUID16(0x0002, 0x0003,
UUID_CHARACTERISTIC_SERVICE_CHANGED,
LEGATTDB_CHAR_PROP_INDICATE,
LEGATTDB_PERM_NONE, 4),
0x00, 0x00, 0xff, 0xff,
CHAR_DESCRIPTOR_UUID16_WRITABLE (0x0004,
UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,
LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ, 2),
0x00, 0x00,
...
}
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).
Use:
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:
For implementation of indications see:
Wiced-Smart-SDK/Apps/hello_client
Wiced-Smart-SDK/Apps/hello_server
For example firmware of a GATT change see:
Re: How to change the GATT database after init (bleapp_set_cfg) ?
For implementation of GATT discovery see:
Wiced-Smart-SDK/Apps/automation_io_client
Wiced-Smart-SDK/Apps/http_client
Show LessThe maximum LL PDU (Packet Data Unit) for BLE 4.1 is 27 Bytes. In these 27 Bytes, the actual data that is transferred as a GATT Write or Notification can be upto 20 bytes, excluding the L2CAP header, Data PDU Header and Attribute Operation Code. If the link is encrypted, the LL PDU will additionally have a 4 Byte MIC (Message Integrity Check), there by making the LL PDU as 31 Bytes.
The LL Packet comprises of LL PDU (31 Bytes) + PDU Header (2 Bytes) Header (1 Bytes) + Access Address (4 Bytes) + Cyclic Redundancy Check (3 Bytes)
= 41 Bytes
= 41 * 8 Bits
= 328 Bits
The propagation time of each bit is 1uS. So for 328 Bits it is 328 uS. After each packet is sent, an additional 80 uS is spent for acknowledgement. Also, there is T_IFS, (Interframe time between a packet and acknowledgement and also between acknowledgement and next packet)
So time taken for 1 packet to be sent is:
328uS (actual data) + 150 uS (T_IFS) + 80 uS + 150 uS (T_IFS) = 708 uS
The number of packets per connection interval = Connection interval / 708 uS.
If the connection interval is 7.5 mS, approximately, 10 packets can be sent.
The relation between the throughput and the connection interval is not so straight forward. As discussed in the previous interaction the time taken for sending 20 bytes is 708 uS.
Now let us discuss this with 3 cases of connection interval:
1) Assume that connection interval is 7.5 mS.
Number of packets sent is 7.5 mS / 708 uS = 10 packets.
Actually 708 uS * 10 = 7080 uS = 7.08 mS. So remaining 0.42 mS is idle (wasted)
2) Assume that connection interval is 8.75 mS.
Number of packets sent is 7.5 mS / 708 uS = 12 packets.
Actually 708 uS * 10 = 7080 uS = 8.496 mS. So remaining is only 0.254 mS is idle (wasted) (8.75 - 8.496 = 0.254 mS)
3) Assume that connection interval is 11.25 mS.
Number of packets sent is 11.25 mS / 708 uS = 15 packets
Actually 708 uS * 15 = 7080 uS = 10.620 mS. So remaining is 0.63mS is idle (wasted).
If you compare 1 and 2, increase in connection interval will result in less idle time. So increased throughput.
If you compare 2 and 3, increase in connection interval will result in more idle time. So less throughput.
So throughput and connection interval will not have a linear relation. However, if you increase the connection interval, power consumption will decrease. And vice versa. Because, less the connection interval, more often it has to be switched from sleep to awake and vice versa.
Show LessProduct Selection | Product Evaluation | WICED Sense | Product Development | Manufacturing / Production |