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

CC2540 throughput difference on BLE-Stack 1.2.1 & 1.4.0

cai chengzuo
Prodigy 230 points

Other Parts Discussed in Thread: PACKET-SNIFFER, CC2540, BLE-STACK

Dear TI guys


I made CC2450 throughput test according to WiKi http://processors.wiki.ti.com/index.php/CC2540_Data_Throughput, at most beginning I was using BLE-Stack 1.4.0, the tested throughput result was very low, only 500Byte/s. Then, I got 4.8KByte/s after I changed to BLE-Stack 1.2.1. During this two tests, I used a commerical CC2540 evaluation board, and it was pairing with BTool through a TI-CC2540-USB-dongle during test, and Packet-Sniffer was used to record this communication, the Packet-Sniffer was running on another TI-CC2540-USB-dongle. I double confirmed this test and test result for more than 10 times.

My question is:
 Can TI guys help confirm this test result? Is that true throughtput on 1.4.0 is much slower than 1.2.1?

I'm going to use CC2540 for data transimtion, the required speed is around 2kB/s, so now 4.8KB/s is OK for me, but I have to use UART, and I noticed that 1.4.0 is providing a more robust support on UART, so I hope the 1.4.0 could also provide 4.8KB/s throughtput.


Thanks for your help in advance, and happy new year:)

  • 0
    TI__Guru** 105180 points
    Hi Cai,

    I'm not aware of any significant throughput difference between BLE-Stack v1.2.1 & v1.4.0. Also, the Data Throughput example on the BLE Wiki is more illustrative than practical. Did you enable Overlap Processing on v1.4.0: http://processors.wiki.ti.com/index.php/OverlappedProcessing ?

    Since you were able to capture sniffer traces, can you elaborate on the differences between the two traces? Do you see multiple packets being sent per connection event?

    Best wishes.
  • 0 in reply to JXS
    Prodigy 230 points
    Hi Jxs

    Thanks for your quick reply.
    I didn't enable overlap processing when testing on both BLE-Stacks. In my application, the CC2540 is acting as peripheral, and it's going to connect with Andriod or iOS device. According to the wiki, it seems that the OverlappedProcessing might not able to use on non-CC2540 devices. So I can't enable Overlap Processing.
    According to the captured packets, I can see multiple packets being sent per connection event on both stacks. But the interval between two connection events on 1.4.0 is very bit, it took around 98mS. But it only took around 8ms on 1.2.1. I think this interval is controlled by SBP_BURST_EVT_PERIOD, but confirmed that on both stacks, the value of SBP_BURST_EVT_PERIOD is 7.
    Would you please help point out how to deal with this issue? I can share my test code and sniffer traces, but I don't know how to post it on this page. Please let me know if you need those files, I can send to you by e-mail. Thanks for your help again!
  • 0 in reply to cai chengzuo
    Prodigy 230 points
    Hi Ti Guys
    Would you please help confirm this issue?
  • 0 in reply to cai chengzuo
    Genius 4470 points

    Hi,

    Please let me know following parameters you are using:

    1. Connection interval

    2. Slave latency

    3. Enable update request

    Thanks,

    Dhaval

  • 0 in reply to cai chengzuo
    TI__Guru** 105180 points

    Hi,

    In addition, please attach the sniffer traces if those are available. You can use the "Insert/Edit Media" button to attach a file.

    Best wishes

  • 0 in reply to JXS
    Prodigy 230 points
    Hi Jxs and Dhaval
    Thanks for your reply, now seems I have solved this issue.
    When start notification with 1.2.1 stack, it will initial a SIG_Connection_Param_Update_Req to update the connetion interval, latency... To synchronize those parameter with master (btool). It seems that the stack sent this request automatically, as I didn't see such code in my test program.
    But when using 1.4.0 stack, their was no such packet when starting notification. After I changed those parameter manually on btool, then I can get almost same throughput with 1.2.1 stack, it's around 5KB/s.
    Thanks both for your help.
  • 0 in reply to cai chengzuo
    Genius 4470 points

    Hi,

    Happy to hear that you are able to resolve the problem! But I think if you enable the update request then you don't need to do anything with Central device. You can configure that as follows:

    uint8 enableUpdate = TRUE;

    GAPRole_SetParameter( GAPROLE_PARAM_UPDATE_ENABLE, sizeof( uint8 ), &enableUpdate );

    So whichever central device connects with the peripheral device, it's parameters get updated as the peripheral device parameters.

    Hope this helps!

    Thanks,

    Dhaval