This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to notify/indicate



Hello,

I have some questions to the use of the functions GATT_Indication() / GATT_Notification(): How are they supposed to be used? In the SimpleBLEPeripheral, they are only called, from a write operation to the CCCD of the characteristic. How are they to be used from a _not_ BLE context. Lets say I have a key and want to notify the key-pressed-state. From that context I do not have any connection, nor do I know if there is a device connected.

First parameter: connHandle - connection to use:

Do I have to get all connections on my own, iterate over all connections, check the corresponding CCCDs and than call GATT_Indication() / GATT_Notification() if the client is subscribed? How do to iterate over the connections?

Second parameter: pInd - pointer to indication to be sent:

The struct contains a pointer to uint8_t denoting the changed data. How am I'm supposed to tell the api the length of the data? Or is the pointer indeed a pointer to a struct containing data and length (or length and data)?

Sorry, but I can't find that information from the documentation (SW Developers Guide), nor from the function prototype documentation.

BTW: The BLE Software Developers Guide, is stating that a part of the second parameter to GATT_Indication() / GATT_Notification() have to be dynamically allocated. May we could have that part of the documentation in the header too?

Kind regards,

Torsten

  • I think I can answer my question on my own: The function to be used is GATTServApp_ProcessCharCfg(). Looks like the documentation (Process Client Characteristic Configuration change.) is just wrong. The function iterates over all possible connections, checks if the client is configured to receive notification / indication and finally calls GATT_Indication() / GATT_Notification() (indirectly).
  • Hi Torsten,

    You can see an example of using GATT_Notification on our throughput wiki specifically in the Notification Queuing function.
    processors.wiki.ti.com/.../CC26XX_BLE_Throughput

    Can you please explain how the documentation may be incorrect so that we may update it?
  • Hi Sean,

    your example seems to not care about the connection handle that have to be provided as first argument to GATT_Indication() / GATT_Notification(). This looks a little bit like cheating to me ;-) (just kidding).

    The documentation of GATTServApp_ProcessCharCfg() says:

      >> Process Client Characteristic Configuration change. << 

    So, the function is processing something, and that something are changes. Changes to what? Changes to the "Client Characteristic Configuration". So, it sounds like the function would do, what is necessary to process an ATT Write to the Characteristics Client Characteristic Configuration, which is an attribute within the characteristic that stores the information whether or not a client has subscribed notifications or indications (UUID 0x2902).

    What about:

    @brief This function informs all connected clients about changes to the given attribute by sending them Handle Value Notifications or Handle Value Indications.
    
        If a client did not subscribed to notifications or indications by writing the respective values to the Client Characteristic Configuration of the given characteristic (did not subscribed), the function will not send notifications or indications to that client. The value send to the clients is retrieved by calling pfnReadAttrCB. pValue is used to identify the changed characteristic value with the service given by the service attribute table attrTbl and numAttrs. If the changed characteristic supports indications, taskId denotes the task, where incoming Handle Value Confirmations are posted to.
    
        @param   charCfgTbl - characteristic configuration table for the changed characteristic.
        @param   pValue - pointer to attribute value, used to lookup the changed value in the attribute table.
        @param   authenticated - whether an authenticated link is required.
        @param   attrTbl - Pointer to first element of the attribute table of the service that contains the changed characteristic.
        @param   numAttrs - number of attributes in attribute table.
        @param   taskId - task to be notified of Handle Value Confirmations.
        @param   pfnReadAttrCB - function to evaluate the new, changed value of the characteristic.
    
        @sa BT Core Vol 3; Part F 3.4.7
        @sa BT Code Vol 3; Part G 3.3.3.3

    In addition, I would like to see a second function that does not lookup the attribute table entry by taking 3 parameters, but that takes the attribute table entry as parameter, because the table entry is usually known by the caller:

        bStatus_t GATTServApp_ProcessCharacteristChanges(
            gattCharCfg_t  const    *clientCharacteristicConfigurations, 
            bool                    authenticated, 
            gattAttribute_t const   *changedAttribute,
            uint8                   indicationConfirmationReceiver,
            pfnGATTReadAttrCB_t     newValue );
    

    At least I would stop to lookup (most likely by a linear search) the characteristic value attribute for every connection as the search should yield always the same result ;-)

    kind regards

    Torsten

  • Torsten,

    The example code I attached is more concerned with studying throughput so it assumes there is only one connection. You are correct though that a connection handle should be passed. You can get this information by reading the GAPROLE_CONNHANDLE parameter.

    Thanks for the feedback, we will always consider it for our next release. In the mean time, the reason why we provide these files in source code format is so that you can modify them to your needs, feel free to make any changes that make sense to you.