• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 2343 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.

CC2652R: Streaming Data using Notifications and/or Indications

Stuart Baker
Genius 10830 points

Part Number: CC2652R

I'm working with a customer who wants to stream data from a GATT server (peripheral) to a GATT client (central). It happens to be a DMM project with 15.4, but that is not very relevant to this discussion (at this time), other than the fact that some connection events will be missed, due to 15.4 communication having priority. The BLE connection parameters are intentionally chosen to deal with this fact.

We are presently using SDK 3.10, but will be eventually moving to SDK 4.20 or later.

I've setup a demo that streams data using indications. With indications "enabled":

  1. Server set the data stream characteristic.
  2. Indication is sent to client on next connection event.
  3. ATT_HANDLE_VALUE_IND is delivered to client.
    1. ATT_HandleValueCfm() is triggered.
  4. Clientl sends acknowledgement on next connection event.
  5. ATT_HANDLE_VALUE_CFM is delivered to server.
    1. Repeat from step 1.

By following this sequence, I can see in my example that an indication is sent on every other connection event, and an acknowledgment is sent on the connection events between those that carry the indications. This is the behavior I expect. The potential issue that I see is that only every other connection event sends any substantial data. Therefore, we are looking at ways to increase the amount of data that can be sent.

I've read through the following guide that provides some tips on increasing throughput: https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/. I have some questions.

First off, my understanding is that both indications and notifications are acknowledged at the link layer (please confirm), and only indications actually deliver acknowledgments to the application layer. As long as the connection remains active, and there are successful connection events occurring, the server can make a reasonable assumption that notifications are making their way to the client.

  1. If multiple notifications (no application layer acknowledgement) are triggered by the server application does the order of reception on the client (ATT_HANDLE_VALUE_NOTI) get preserved in the presence of link layer retries?
  2. Can the return value of GATTServApp_ProcessCharCfg() be used on the server to determine if the server application needs to "back-off" so that previously queued notifications can be sent?
    1. Is there a way to notify the server application when a previously queued notification has actually been sent? The idea would be to limit the number of notifications that are "in flight" at any given time and preserve some BLE stack buffer bandwidth for other activities.
  3. Can more than one indication (different characteristics) be sent per connection event. I understand this to be possible with notifications on both the same and different characteristics because of the lack of application level acknowledgment (please confirm).

Thanks,

Stuart

  • 0
    TI__Guru** 101570 points

    Hi Stuart,

    - I confirm, the Link Layer uses a system of acknowledgement using the parameters transmitSeqNum and nextExpectedSeqNum, each one bit in size. Please look at BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 6, Part B, §4.5.9 for additional details.

    - The Link Layer transmits the payloads in the order provided. The Link Layer continue to retransmit each PDU until it is acknowledged. (BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 6, Part B,§4.5.13.3)
    So you have the notifications will be delivered in the order they are sent.

    - There is no way to dequeue data already queued in the BLE stack. In other words, if you enqueue a notification, you will have to wait for the BLE stack to send it out to get the memory back (and be able to enqueue other stuff). Of course there are way to modulate the size of the BLE stack buffers (look for "MAX_NUM_PDU" in the documentation).

    - It is definitely possible to send more than one indication per connection event.

    I hope this will help,

    Regards,

  • 0 in reply to Clément
    TI__Genius 10830 points

    Clement,

    This is very helpful and answers a number of questions. I have one remaining question that when answered will help us to optimize the application for the option of using notifications.

    Is there a way to notify the server application when a previously queued notification has actually been sent successfully (buffer freed)? The idea would be to limit the number of notifications that are "in flight" at any given time and preserve some BLE stack buffers for other activities.

    We understand how to configure the number of stack buffers, but we want to ensure that we limit the number of buffers used at any given time for streaming data notifications. Alternatively, is there an API that can be called from the application to determine how many buffers are currently available? This would allow the application to back off when the number of free buffers drops below a certain threshold.

    Thanks,

    Stuart

  • 0 in reply to Stuart Baker
    TI__Guru** 101570 points

    Hi Stuart,

    I do not have all the elements to answer your question. I have requested R&D's help. Please bear with me.

    Regard,

  • 0 in reply to Clément
    TI__Guru** 101570 points

    Hi Stuart,

    The Bluetooth LE stack uses dynamic allocation for the buffers sent out. These allocations are made using ICall. You could leverage the function ICall_getHeapStats to read the amount of heap available before enqueuing a new notification. That way you can decide to reserve a part of the heap to the second traffic.

    Let us know if it helps,

    Regards,