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.

Many notification of small characteristic vs One notification of large characteristic

Other Parts Discussed in Thread: CC2541, CC2650, CC2640

Hi everybody,

sometime ago I've performed some test to establish the maximum throughput between a cc2541 and an Android smartphone. In those tests I sent some dummy data (a counter) in a 20 Byte characteristic that was updated 3 times each connection event (I used the connection event notification). Now I'm working with cc2650, (but I think that it causes no difference) and looking at this wiki it seems that using longer characteristic the overhead is reduced and an higher throughput is possible. Is that true?

  • Hi Davide,

    Yes, with higher MTU size, you will see higher throughput without the overhead of the L2CAP headers. Though it is supported in the CC2640, you will have to make sure the peer device also supports this higher MTU size.

    Best wishes

  • Thanks.

    I'm trying to understand how long are the headers but there is a lot of information on this and it is not easy to filter which is clear and relevant.

    Based on what I've found on web and looking at what the sniffer show me: L2CAP header is 4 bytes long, 1 byte is for ATT op code and 2 bytes are reserved for attribute handle (7 bytes in total). Then, to send a long (more than 20 bytes of application data) characteristic notification the first packet will contain the 7 bytes header but the following packets won't contain any L2CAP header. Is that correct or the following ones will contain some header?

    If someone can point me to a clear source of information on this I appreciate.

  • Hi,

    This is illustrated in the BLE SW Dev Guide (SWRU393), Sec 5.5.2 Maximum Transmission Unit (MTU). You can, of course, also refer to the BT4.0 core specification.

    Best wishes