Multiple Notifications in an App...?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hello,

  I would like to add an additional Notification in the hello_sensor app.  The app already has the following Characteristic Notification defined...

// Handle 0x29: characteristic Hello Notification, handle 0x2a characteristic value
// we support both notification and indication.  Peer need to allow notifications
// or indications by writing in the Characteristic Client Configuration Descriptor
// (see handle 2b below).  Note that UUID of the vendor specific characteristic is
// 16 bytes, unlike standard Bluetooth UUIDs which are 2 bytes.  _UUID128 version
// of the macro should be used.
CHARACTERISTIC_UUID128 (0x0029, HANDLE_HELLO_SENSOR_VALUE_NOTIFY, UUID_HELLO_CHARACTERISTIC_NOTIFY,
                      LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_NOTIFY | LEGATTDB_CHAR_PROP_INDICATE,
                      LEGATTDB_PERM_READABLE, 7),
   'H','e','l','l','o',' ','0',

    // Handle 0x2b: Characteristic Client Configuration Descriptor.

// This is standard GATT characteristic descriptor.  2 byte value 0 means that
// message to the client is disabled.  Peer can write value 1 or 2 to enable
// notifications or indications respectively.  Not _WRITABLE in the macro.  This
// means that attribute can be written by the peer.
CHAR_DESCRIPTOR_UUID16_WRITABLE (HANDLE_HELLO_SENSOR_CLIENT_CONFIGURATION_DESCRIPTOR,
                                UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,
                                LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ, 2),
   0x00,0x00,

Now lets say I want to add another Characteristic Notification as such Do I also need to add an additional Characteristic Client Configuration Descriptor for this 2nd Notification/Indication?  If so how does the BTLE Stack recognize that the 2nd Client Configuration Descriptor is for the 2nd Characteristic Notification?  Is it simply that it follows the Handle ID # in increasing value?

To avoid messing up any of the rest of the handles I would insert this after handle after Handle 0x2D as such

   // Handle 0x2E: characteristic Hello Notification, handle 0x2F characteristic value

CHARACTERISTIC_UUID128 (0x002E, HANDLE_COMMAND_ACK_NOTIFY, UUID_HELLO_CHARACTERISTIC_NOTIFY,
                       LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_NOTIFY | LEGATTDB_CHAR_PROP_INDICATE,
                      

LEGATTDB_PERM_READABLE, 2), 0x00, 0x00

Now do I need to add another Client Configuration descriptor to Enable the Notifications/Indications?

// Handle 0x30: Characteristic Client Configuration Descriptor.

   CHAR_DESCRIPTOR_UUID16_WRITABLE (HANDLE_SENSOR_CLIENT_CONFIGURATION_DESCRIPTOR,

                                     UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,

                                     LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ, 2),

        0x00,0x00,

Is there anything additional that needs to be done to have this additional notification be usable?

Regards,

Frank

0 Likes
1 Solution

All descriptors are 16 bit and the values are created by Bluetooth SIG.  Client Configuration descriptor is one of those with a value 0x2902.  128 bit UUIDs are vendor specific.  Meaning that you can make a 16 byte random number and use it as UUID for your vendor specific characteristic.  The difference is that only you will know what is the contents of the characteristic.  While everybody who read the GATT spec knows how to treat and to use Client Configuration descriptor. 

If you are on the both sides you can do whatever you want.  You do not even use GATT to send data.  But if you have an OS on one of the side, it might not pass your data.

Properties are property bits that client will read when it performs GATT discovery.  After discovery is done client will know if it can write into your characteristic, or if it can be indicated.  When your client actually writes, or your device sends indication, properties are not send along.  Only value goes over the air.

View solution in original post

0 Likes
5 Replies
VictorZ_46
Employee
Employee
5 comments on blog 25 sign-ins 250 likes received

Each characteristic can have only 1 client configuration descriptor.  The descriptor serves for the client to tell device if notifications/indications are allowed or not.  There is not much idea to have 2 descriptors for the same and it is not allowed in the spec.

If for some reason you want to have 2 types of notifications, you will need to add another characteristic and have client configuration descriptor for it as well.  Please make sure that new characteristic has unique UUID.  And yes all handles should be in ascending order.

Having said that, you are doing vendor specific service, so you will have your own application running on the client (for example iPhone).  You should be able to do everything with 1 type of notifications.  For example you can use first byte of the value to indicate if it is hello or goodbye.

0 Likes
Anonymous
Not applicable

Hi Victor,

  Thanks for the response.  Yes I see that I would need to create a Unique 128bit UUID for the additional Notification being declared.  For the CLIENT_CONFIGURATION I realize the 16bit UUID's are vendor specific so this would mean that the CLIENT_CONFIGURATION being used in the hello_sensor app is Vendor Specific and registered with Bluetooth Sig being that it is what is shown below...?  Can someone get by with using the 16bit Descriptor if they control both sides? 

// Handle 0x2b: Characteristic Client Configuration Descriptor.

    // This is standard GATT characteristic descriptor.  2 byte value 0 means that

    // message to the client is disabled.  Peer can write value 1 or 2 to enable

    // notifications or indications respectively.  Not _WRITABLE in the macro.  This

    // means that attribute can be written by the peer.

    CHAR_DESCRIPTOR_UUID16_WRITABLE (HANDLE_HELLO_SENSOR_CLIENT_CONFIGURATION_DESCRIPTOR,

                                     UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,

                                     LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ, 2),

        0x00,0x00,

Another question on Characteristic Properties...for the following properties what is the ACK or Response that one would see on the Master/Central side for the following Characteristic Properties?

LEGATTDB_CHAR_PROP_WRITE ->  Permits the write of the characteristic value with Response.  What is the response seen on the Host Side?

LEGATTDB_CHAR_PROP_INDICATE -> Permits the indication of the characteristic value with acknowledgement.  What is the ACK that would be seen?

Regards,

Frank

0 Likes

All descriptors are 16 bit and the values are created by Bluetooth SIG.  Client Configuration descriptor is one of those with a value 0x2902.  128 bit UUIDs are vendor specific.  Meaning that you can make a 16 byte random number and use it as UUID for your vendor specific characteristic.  The difference is that only you will know what is the contents of the characteristic.  While everybody who read the GATT spec knows how to treat and to use Client Configuration descriptor. 

If you are on the both sides you can do whatever you want.  You do not even use GATT to send data.  But if you have an OS on one of the side, it might not pass your data.

Properties are property bits that client will read when it performs GATT discovery.  After discovery is done client will know if it can write into your characteristic, or if it can be indicated.  When your client actually writes, or your device sends indication, properties are not send along.  Only value goes over the air.

0 Likes
Anonymous
Not applicable

Hi Victor, Frank,

I cannot find the right answer for question:

LEGATTDB_CHAR_PROP_WRITE ->  Permits the write of the characteristic value with Response.  What is the response seen on the Host Side?

I also want to know what be seen on host side, can you provide me an answer?

Regards,

Manh

0 Likes

Manh,

It will depend on what host and what API you are using to send GATT Write Request.  It is possible that your Write API call just returns success or failure.  Over the air you should see GATT Write Response or GATT Error Response if write_handler in the application returns anything but 0. 

Thanks,

Victor

0 Likes