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.

RTOS/CC2640R2F: sdk 1.40 : notification/indication max-size remains 20 bytes, while read size can be increased to 251

Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2541

Tool/software: TI-RTOS

Using simplelink_cc2640r2_sdk_1_40_00_45, and creating a read/indicate CHAR on a service, the indication size is limited to 20, while the read size is limited to 251.

Is it according to the BLE standard, or is this a known limitation of the SDK ver 1.40?

Is this fixed in simplelink_cc2640r2_sdk_1_50_00_71 or simplelink_cc2640r2_sdk_1_50_00_58?

See the implementation of gattServApp_SendNotiInd, and the lines in bold

 /*********************************************************************
 * @fn      gattServApp_SendNotiInd
 *
 * @brief   Send an ATT Notification/Indication.
 *
 * @param   connHandle - connection handle to use.
 * @param   cccValue - client characteristic configuration value.
 * @param   authenticated - whether an authenticated link is required.
 * @param   pAttr - pointer to attribute record.
 * @param   taskId - task to be notified of confirmation.
 * @param   pfnReadAttrCB - read callback function pointer.
 *
 * @return  Success or Failure
 */
static bStatus_t gattServApp_SendNotiInd( uint16 connHandle, uint8 cccValue,
                                          uint8 authenticated, gattAttribute_t *pAttr,
                                          uint8 taskId, pfnGATTReadAttrCB_t pfnReadAttrCB )
{
  attHandleValueNoti_t noti;
  uint16 len;
  bStatus_t status;

  // If the attribute value is longer than (ATT_MTU - 3) octets, then
  // only the first (ATT_MTU - 3) octets of this attributes value can
  // be sent in a notification.
  noti.pValue = (uint8 *)GATT_bm_alloc( connHandle, ATT_HANDLE_VALUE_NOTI,
                                        GATT_MAX_MTU, &len );
  if ( noti.pValue != NULL )
  {
    status = (*pfnReadAttrCB)( connHandle, pAttr, noti.pValue, &noti.len,
                               0, len, GATT_LOCAL_READ );
    if ( status == SUCCESS )
    {
      noti.handle = pAttr->handle;

      if ( cccValue & GATT_CLIENT_CFG_NOTIFY )
      {
        status = GATT_Notification( connHandle, &noti, authenticated );
      }
      else // GATT_CLIENT_CFG_INDICATE
      {
        status = GATT_Indication( connHandle, (attHandleValueInd_t *)&noti,
                                  authenticated, taskId );
      }
    }

    if ( status != SUCCESS )
    {
      GATT_bm_free( (gattMsg_t *)&noti, ATT_HANDLE_VALUE_NOTI );
    }
  }
  else
  {
    status = bleNoResources;
  }

  return ( status );
}

  • Hello Koby,

    This is in accordance with the BLE Spec. In fact the comment that is bolded is directly taken from Bluetooth Core Spec Version 4.2 [Vol 3, Part F], Section 3.4.7.2. There is no change in this function in 1.50.00.58.

    In summary the size of the indication that you are able to send is ATT_MTU-3. The MTU needs to be negotiated for each connection. What is the MTU size of your active connection? Do you have an accompanying sniffer capture?
    1. What about 1.50.00.71? does it change there?
    2. I understood that simplelink_cc2640r2_sdk_1_40_00_45 supports BLE 5.0, not only BLE 4.2.
      What are the specifications of BLE 5.0 regarding the indication/notification MTU size, and does simplelink_cc2640r2_sdk_1_40_00_45 comply with them?
    3. I set MAX_PDU_SIZE, in the application and stack projects, to 255.
      I have tested the BLE read operation, and it can send >100 bytes in one-go.
    4. Is there a real need for a sniffer tool? that will take me days to acquire and test with, instead of TI telling me how to enable BLE 5.0 features and allow high-throughput using indications/notifications, which should be possible, according to this https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/

  • 1. No. You are correct that 1.50.00.71 supports BLE 5.0, but as per Bluetooth Core Specification Version 5.0 [Vol 3, Part F], Section 3.4.7.1 the specification regarding indications and notifications has not changed

    2. See #1

    3. Setting the MAX_PDU_SIZE in the projects is the first step, you also have to perform an MTU exchange over the air and be sure that your peer device also supports large MTU. You will receive an event in your application notifying you of the negotiated MTU.

    4. Absolutely yes. It is significantly harder to develop a wireless application without a sniffer. If you are interested in throughput, I would recommend taking a look at the throughput example here github.com/.../ble_examples
  • Thanks Sean for the assistance,

    1. OK. indications are limited to 20 bytes per indication packet, on all SDKs.
    2. I would love a table explaining which BLE versions and features are supported by each TI BLE SDK.
    3. again, read operation works fine for large packets. indications are the ones that fail.
    4. A 'getter' API for active-connection MTU size would be less time-consuming for me than using a sniffer. Is there one?

    Another question - let me know if you'd rather I open another ticket:

    Trying to send those 20-byte-long indications, with a delay <100 ms between indications, mostly fails. only if the delay between consecutive indications is 100 ms or longer, will they succeed on every send.
    I had a similar problem on the CC2541, which was solved - I remember something about a 'multiple packet per connection-interval' macro, that needed to be activated, but I can't remember exactly what it was - can you help?

    regards,

    Koby
  • Hi Koby,

    I just wrote a nice summary of MTU exchanges and how to maximize them here: e2e.ti.com/.../2430638

    #1. Sorry, but this is not true, indications are limited to ATT_MTU-3, with our SDKs the max ATT_MTU is 251. Meaning you can send over 200B in an indication. We have an example that will do this with notifications. See the throughput demo on Github github.com/.../ble_examples

    #2. I agree this would be useful, I would refer to the release notes from each SDK.

    #4. linkDB_GetInfo () will populate a structure linkDBInfo_t which contains MTU size. See linkdb.h

    Indications must be acknowledged by your peer device at its application layer, if you try to perform other GATT procedures while an indication is pending, you will get an error. In order to reduce this overhead, I would use notifications.
  • Thanks, I will try the suggestions in the following weeks. For now, I will settle for READ instead of INDICATE.