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

CC2650: Throughput problem, GATT_Notification takes too much time

Xin ZHAO
Prodigy 40 points
Part Number: CC2650


Hello,

My project is based on CC2650 Throughput example. Using the example I can easily get a throughput of about 30KB/s without any problem. 

As I understand, once MTU size updated, the program enters an infinite while loop and sends packages of 244B data continuously. Only keypress are processed inside the while loop. 

I then start to add a sensor, generating interrupts via GPIO pin at about 80Hz frequency. I want that each time the interrupt is triggered, a BLE package of 244B is sent to the Central.

I tried: 

1. using event: I added an event inside SimpleBLEPeripheral main task (just like SBP_PERIODIC_EVT)

2. using appMsgQueue, I added it inside SimpleBLEPeripheral. HWI interrupts are treated in SimpleBLEPeripheral_processAppMsg (just like SBP_CHAR_CHANGE_EVT).

3. creating a new task with priority of 2. The HWI interrupt posts semaphores to this task. The task waits for the semaphore, then sends a package of 244B to the Central. 

No matter which method I use, I only get about 2KB/s. 

I checked sensor interrupt frequency, everything is OK.

I then checked GATT_Notification return value. It actually returns 0x04 (MSG_BUFFER_NOT_AVAIL) 10 times before finally succeeding to send one 244B package to the Central. As a result, data transmission speed slows down dramatically. 

I changed to connection interval to 7.5 ms, no luck. 

It seems that GATT_Notification needs time to prepare and send BLE data, and sensor interrupts of 80Hz are just way too fast. But how to explain the results obtained with the Throughput example (using an infinite while loop)?

Once I use an infinite while loop and send 244B data no stop, I get the top speed (about 30KB/s), once I start to implement HWI / semaphore / events to synchronize things between them, everything slows down. 

Could someone tell me what I am doing wrong?

Thank you

Kind regards 

Xin

  • 0
    Prodigy 40 points

    Oh sorry, I want to correct one thing: when putting GATT_Notification inside a deadly infinite while loop (just like SimpleBLEPeripheral_blastData in the Throughput example), I actually got more 0x04 (MSG_BUFFER_NOT_AVAIL) before succeeding to send one package. But still I achieved the top speed. 

  • 0 in reply to Xin ZHAO
    TI__Mastermind 25810 points

    Hey Xin,

    Thanks for posting on e2e. I think it is expected to see some decrease in throughput as you add more tasks at the application layer which will in theory pre-empt the throughput task. The MSG_BUFFER_NOT_AVAIL is also expected since we are queueing packets to the stack very quickly, and this could be part of the reason for the decreased throughput.

    That all being said, I've assigned this post to a colleague who can help you investigate this further. Which SDK version are you using? Are you also running this on a CC2650 LaunchPad?

  • 0 in reply to Ammar N
    Prodigy 40 points

    Hello Ammar,

    Thank you very much for the kind reply. Yes it would be great if someone could help me. 

    The main thing is how I can replace that infinite while loop in the Throughput example by an HWI (about 80Hz). Therefore BLE transmission is triggered by an external interrupt.  

    I use CC2650 LaunchPad as Central and a custom board as Peripheral. The SDK version that I use is 2.02.01.18.

    Regards 

    Xin

  • 0 in reply to Xin ZHAO
    TI__Mastermind 42320 points

    Hi Xin,

    The MSG_BUFFER_NOT_AVAIL return code means that there is no HCI buffer available at the time the GATT_Notification function is called. This information can be found in the Software Developer's User's Guide found in the BLE Stack SDK.

    In this case, you can retry at a later time. With regards to the connection interval, the value should be set to a higher value than 7.5ms in order to obtain the maximum throughput. At 7.5ms, the amount of downtime vs time spent transmitting is very high (2-3ms downtime per connection event) which will reduce the overall throughput as you have seen. The Connection Interval section of the Throughput Example documentation discusses this tradeoff: 

    If you are sending your own custom data, then you will likely need to modify the blastData function to ensure the notifications are packaged and queued up properly with regards to the data you are sending. The Notification Queuing section of the example documentation. I would also recommend referencing the 5.3.5 Allocating Memory for GATT Procedures section of the Software Developer's Guide discusses the process for allocation memory as well.

    Do you have a second launchpad with which you can run the peripheral project on? This will help us isolate this behavior on the SW side.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 40 points

    Hi Jan,

    Thank you so much for the detailed reply. This helped me a lot. 

    Indeed I started with the default configuration as per the Throughput example (connection interval = 100ms). As things did not work well, I doubted if there is a limit on the maximum number of notification packets in single connection interval. That is the reason why I reduced connection interval. 

    As you proposed, I retry things several times if GATT_Notification returns 0x04, and I got better throughput. But still some packets are lost. 

    In the Throughput example, we actually do not care about if GATT_Notification returns SUCCESS or not, as in the infinite while loop GATT_Notification is called non-stop. In my case however, if GATT_Notification fails, my sensor interrupt is missed, and my current packet is lost. 

    Sorry to insist, could you please explain to me: 

    1. is there a limit on the maximum number of notification packets in single connection interval? If yes which value?

    2. how to avoid GATT_Notification returns 0x04  (MSG_BUFFER_NOT_AVAIL)? 

    Thank you for the kind support

    Regards 

    Xin

  • +1 in reply to Xin ZHAO
    TI__Mastermind 42320 points

    Hi Xin,

    I am glad that my reply was helpful!

    Xin ZHAO said:

    1. is there a limit on the maximum number of notification packets in single connection interval? If yes which value?

    There is no limitation on the number of packet transactions per connection event other than MAX_NUM_PDU. To send more packets per connection event, you would need to increase the value of MAX_NUM_PDU to greater than the minimum number of packets per connection event desired. In your case, I would recommend increasing to higher values to see how your observed throughput is impacted.

    Xin ZHAO said:
    2. how to avoid GATT_Notification returns 0x04  (MSG_BUFFER_NOT_AVAIL)? 

    Increasing the number of PDUs may help here.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 40 points

    Hello Jan,

    Thank you so much for the kind help.

    Kind regards,

    Xin