• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 1275 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

[CC2640] Maximum ATT_MTU size?

CC2640R2F: Maximum TX Octets, maximum characteristic size

Gary Willette
Prodigy 110 points
Part Number: CC2640R2F


We are using the CC2460R2F with the provided "simple_np" example. We have created several services and characteristics on our AP which work fine for apps which do not attempt to negotiate MTU size. All characteristics but one are 20 bytes in size, while the last characteristic's size can be adjusted dynamically based on the exchanged MTU size, but start with size 20 bytes.

The stack indicates that the maximum supported ATT_MTU size is 247, but while fumbling through our dynamically-sized characteristic implementation, we found that only the first 20 bytes get sent (when notifications are enabled, for example), regardless of the negotiated MTU size as indicated from the SNP to our AP by way of an SNP_ATT_MTU_EVT. We tried many things with no effect, and so we started using a BLE sniffer.

During establishment of the connection, the MTU size is negotiated (between nRF Connect app on Android version 9) as follows:

Exchange MTU Request, Client Rx MTU: 517
Exchange MTU Response, Server Rx MTU: 247
LL_LENGTH_REQ, as pictured below:

LL_REQ

LL_LENGTH_RSP, as pictured below:

LL_RSP

Does this mean what I think? That the CC2460R2F only supports writing/notifying up to 20 bytes? If so, how can this be changed? From what I read, the TI BLE Stack supports DLE by default, with no configuration required.

Additionally, a simpler query:

Is it true that the appropriate size for a characteristic is ATT_MTU_SIZE-3, to leave 1 byte for the opcode and 2 bytes for the Attribute Handle?

  • 0
    TI__Guru 57865 points

    Hi Gary,

    Assigning an expert to help.

  • 0
    TI__Guru* 82811 points

    Hi Gary,

    The CC2640R2F uses 20 bytes as the default length. You can read how to change it here:

     

  • 0 in reply to Marie H
    Prodigy 110 points

    Good morning Marie,

    Thank you very much for the quick reply. I have read through the guide you suggested on using DLE and adjusting the maximum TX size. In using the simple_NP application, we had hoped to not change the source code much, for many reasons including easy migration to future stack updates. I was under the impression that connection preferences could be adjusted using the project-wide preprocessor definitions. In those definitions, the following related items are set:

    MAX_NUM_BLE_CONNS=1
    MAX_NUM_PDU=4
    MAX_PDU_SIZE=251

    Is this not enough? Is it required that I actually monitor for a connection in the simple_np project, and add the code included in the guide (shown below)? I find no other uses of the HCI_LE_SetDataLenCmd() function anywhere in the project. And being honest, I have not spent the time required (if it's even possible) to determine at what point in the code a connection is established, etc.

    uint16_t cxnHandle; //Request max supported size
uint16_t requestedPDUSize = 251;
uint16_t requestedTxTime = 2120;

GAPRole_GetParameter(GAPROLE_CONNHANDLE, &cxnHandle); //This API is documented in hci.h

HCI_LE_SetDataLenCmd(cxnHandle, requestedPDUSize, requestedTxTime);

    Gary

  • 0 in reply to Marie H
    Prodigy 110 points

    Please see my latest reply for additional questions regarding this suggestion.

  • 0 in reply to Gary Willette
    Prodigy 110 points

    I am calling HCI_LE_WriteSuggestedDefaultDataLenCmd(251, 2120); at the end of the SNP_init() function, and I now see that the device properly negotiates 251 TX octets. Thank you for your help. I am surprised to have to modify the project source code, but happy that it is working as desired now. Perhaps there was just a lack of reading and understanding of the project and the DLE standard operating procedure on my part.

    Gary