• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 55 subscribers
  • Views 5261 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.

Maximum characteristic value length vector.

Frederico
Intellectual 405 points
Other Parts Discussed in Thread: CC2540

Hi,

In my application, I will need a 500 bytes buffer from A/D converter and send them when the connection is established. I am currently building a application based on SimplePeripheral demo. I have changed the simpleGATTprofile.c code to test if it would be possible to create a characteristic value vector with 500 bytes length with the code below. 

case SIMPLEPROFILE_CHAR1_UUID:

case SIMPLEPROFILE_CHAR2_UUID:

*pLen = 500;

pValue[0] = 1;

pValue[1] = 2;

pValue[2] = 3;

pValue[3] = 4;

pValue[4] = 5;

break;

Although, it hasn't worked.

I have noted that when *pLen is larger than 19 I always get the message in BTool that says: "ATTR_NOT_FOUND" when I tried to read the data with UUID = 0xFFF1 .

What is the maximum vector length that the protocol supports considering the characteristics value? 

Is there some way to change it? If yes, how? 

If I am not able to create a characteristics value vector length larger than 19, do you have any idea on how to buffer the A/D data and send them efficiently?

Looking forward to your reply

Sincerely 

Frederico

  • 0
    Expert 1880 points

    I had the same problem, no answer yet (on the forum it was sustained by TI that it's 20 but it's not).

    The funnier thing is if you try to write the variable with the EXT_ATT_PREPARE_WRITE_REQ and EXT_ATT_EXECUTE_WRITE_REQ HCI commands the maximum length writable there is 18, bigger values will trigger error (the error is triggered sooner than our user code from the profile). So this value for some functions is 19, for some are 18 (tough the offset is in 2 bytes everywhere so i don't see the point of this 1 byte change on prepare/execute write).

    So I wait for a clear answer as well ...

    regards,

    B.

     

     

  • 0 in reply to Barna Csenteri
    Expert 1880 points

    About longer data - you can create longer buffers but you have to read/write them in chunks using the EXT_ATT_READ_BLOB_REQ and either the prepare.execute write request, either the GATT write LONG data command. You should check the HCI command guide which comes with the SDK for details about those - the read blob can be tried with BTool if I remember well at the extended commands.

    But this still not answers the question about the limitation if 19 and sometimes 18 byte chunks.

  • 0 in reply to Barna Csenteri
    Intellectual 405 points

    Hi Brown,

     

    Thanks for tip, It was very usefull and I will try to transmite the data on this way! 

     

    Frederico

  • 0 in reply to Frederico
    Prodigy 100 points

    Hello,

    We have need to occasionally transfer a decent sized file to a PC or another BLE device.  We are looking at the blob read and write which, from our understanding of the BLE spec, should support 512 byte chunks.  But there seems to be some confusion about the capabilities of the CC2540 in this regard, at least according to info on the TI wireless community site.

    Can TI provide some clarity on this topic?

    Simon

  • 0 in reply to Simon D
    Intellectual 805 points

    Hello -

    I have posted to my profile "Files" area a set of .hex files built for the TI development kit hardware. These files implement a conforming, proprietary BLE Profile which achieves streaming generic data from Uart-to-UART over the BLE link. They also just auto-generate (in a well-known pattern for error checking on the receiver side) a 24024-byte data stream for conducting a data throughput "speed test". You are welcome to download it and check it out.

    The Proprietary Profile Application Library on which this Demo App is built would abstract your problem to just sending and receiving the chunk or stream of data that you need to, and it will take care of all of the details of how it get over the BLE link. This would leave you to focus on what your Application has to do to generate and/or consume that data, as well as to implement the pairing, power management, and security that your Application will require.

    Cheers,

  • 0 in reply to Barna Csenteri
    Intellectual 345 points

    Hi! Can you please elaborate on how to implement Prepare and Execute or GATT_WriteLongCharValue()? Thank you.

  • 0 in reply to Akshat Kharaya
    Mastermind 8695 points

    The GATT_WriteLongCharDesc can be used to write data longer than 18 or 19 bytes. Check the "adv.Commands" tab of the BTool to find this GATT command. The data will be broken down into smaller packets. The peripheral/server will receive the packets as normal, only with an offset. I add the offset to the destination pointer in the osal_memcpy function. 

    But I'm running into trouble when it comes to reading this data. I use the command GATT_ReadLongCharValue, but how do I program my peripheral/server to handle sending multiple responses?