• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 52 subscribers
  • Views 851 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.

CC2640R2F: The speed of characteristic writing from central to peripheral

Wei Lu
Expert 1900 points
Part Number: CC2640R2F

Hi all,

So far all the throughput tests are based on notification or indication send from peripheral to central,

for example, the example of throughput demo of TI SimpleLink CC2640R2 SDK 1.40.00.45 is the one we used to test before.

But now, we'd like to test the throughput for opposite direction, write characteristic from central to peripheral,

however, it stuck in around 2 kilo-byte per second even PHY 2M was set before.

Can share the knowledge of difference between writing characteristic and notification? And what's the max speed of characteristic writing?

*Project: ble5_spp_ble_server_cc2640r2lp

*Connection interval was set to 15 ms

*PDU size was set to 189

*Android 8.0 phone was used in this case

Thanks a lot.

Wei Lu

  • 0
    TI__Mastermind 33460 points
    Hi Wei,

    A characteristic write is an acknowledged procedure meaning that the central device will have to write the characteristic and the peer device will need to acknowledge it before any other GATT traffic can occur. In the worse case, this transaction can be split across two connection events, which will greatly degrade throughput.

    As an alternative to GATT writes, you can look into WriteNoResp or having the central send notifications. Both of these procedures are not acknowledged and thus will be faster.

    developer.android.com/.../BluetoothGatt

    A quick look at the Android docs appears that only GATT writes are supported, but I am not an Android dev or expert. Perhaps you can ask them if either of these procedures are supported
  • 0 in reply to Sean2
    Expert 1900 points
    Hi Sean,

    Thanks for the reply,
    according to your words, having the central to send notifications is one of the way to test throughput,
    but how to do it?? Central role doesn't own the notification characteristic.

    And you didn't answer the question I asked before,"what's the max speed of characteristic writing?"

    Thanks a lot

    Wei Lu
  • 0 in reply to Wei Lu
    TI__Mastermind 33460 points

    Hi Wei,

    "Central role doesn't own the notification characteristic."
    Correct, central can be a GATT server and client, not sure if this is possible in Android, but if it is that is one way.

    "what's the max speed of characteristic writing?"
    This is a heavily implementation dependent answer as I explained above. It depends on the following:
    - What connection intervals are supported by your phone?
    - What MTU is supported by your phone?
    - What is the max number of packets per connection event that you are allowed to send one the phone.
    - Does the phone support 4.2 LE Data Length Extension? What is the max PDU size?

    Once you know these parameters you can calculate throughput for a GATT Characteristic write (with response)
    as following: MAX_APP_DATA_PER_CONN_EVT /(2 * CI)

    The 2* CI is explained by the fact that every GATT write must be acknowledged, see the ASCII art sequence diagram below. Each | here is a connection event.


    | |
    | -------------Master Sends Data------------>|
    | * potential link layer fragmentation * |
    |<------------Slave acknowledges Data---- |
    | |


    MAX_APP_DATA_PER_CONN_EVT = (ATT_MTU_SIZE - GATT_OVERHEAD) * NUM_PKTS_PER_EVT)

    In the case of a GATT characteristic write (with response) the packet overhead is as follows:

    GATT_OVERHEAD = 3B , as per BLE Specification Version 4.2 Vol 3, Part F, Section 3.4.5.1
    NUM_PKTS_PER_EVT = 1 because GATT request/responses are synchronous as per BLE Specification Version 4.2 Vol 3, Part F, Section 3.3.2

    It is in theory possible for the slave to acknowledge a GATT write request and have the master send another write request in the same connection event, but I have not observed this in practice. If it is possible to have multiple request/resonses in a single connection event, then NUM_PKTS_PER_EVT may be greater than 1, and you do not have to multiply the CI by two. Again, I have not seen this in practice. You can/should characterize this on your Android device with a sniffer.

    NUM_PKTS_PER_EVT and the request/response being split across two connection events is the most likely cause for your degraded throughput. Both of these can be alleviated by finding a way to either send write no response or notifications on the central device. Again, I am not sure if this is possible on Android.

  • 0 in reply to Sean2
    TI__Mastermind 33460 points
    Hello,

    Looking at the Android developer reference developer.android.com/.../BluetoothGattCharacteristic.html

    It appears write no response is enabled. I would make sure you use this to improve your throughput.
    However the equation MAX_APP_DATA_PER_CONN_EVT = (ATT_MTU_SIZE - GATT_OVERHEAD) * NUM_PKTS_PER_EVT)

    If the request/acknowledge procedure is not split across two connection events (as should be the case with write no response)
    then theoretical throughput can be calculated as: MAX_APP_DATA_PER_CONN_EVT/CI

    Where CI is connection interval.