CC2650 real-world throughput?

Do you mean 190 kbps of data or 190 kbps total? Chip makers like to include CRC bits in "total" throughput statistics...

Actual data throughput.

Hi Fredrik,
Thank you.

Eric

Hi Fredrik,
One step further.. Do you have any data WRT the approximate maximum expected BLE throughput when the CC2650 is paired/connected and transferring data to an iPhone (say 5s or 6s).. same question for a typical Android phone (say Samsung S6)? I am wondering if the phones reduce the (~190kbps) max throughput. Thanks, Merril

Hi Merril,

Yes, iOS does constrain the throughput on BLE. I haven't confirmed with iOS9, but on iOS8, the maximum throughput was limited to 6 connection event packets @ the nominal 30ms connection interval that iOS typically establishes the connection. I don't have any characterization on Samsung throughput, although Android devices usually accept faster connection intervals than iOS.

You can also take note of the BLE High Throughput wiki article: processors.wiki.ti.com/.../CC26XX_BLE_Throughput which demonstrates the maximum BLE throughput using two CC2640 devices. These devices are operating in standard BLE mode.

Best wishes

Based on this doc :

developer.apple.com/.../BluetoothDesignGuidelines.pdf

It seems that if we configure our device as a HID the  min packet interval time can drop to 11.5ms, but for all other devices the minimum will be 20ms.

Please confirm if that is your understanding as well.

There are 2 other questions:

1. apparently the BLE spec says that number of packets is 6 (although I could not find it in spec), and iOS only supports 4 (which I also could not find in any spec).

2. several sources also state that BLE can send 20 bytes per packet .. again, I couldn't find this in the spec.

With the data above I end up with
packet interval time = 20ms
number of packets per interval = 4
number of bytes per packet = 20

=> 4000 bytes per second

 

Hello,

Regarding the Apple BT Design Guide, you are correct in that you can request 11.5ms for a HID device, although it may only allow HID. Note that I've seen the iOS device assign a 15ms CI when 11.5ms is requested. I'm not sure where you obtained the number of packets iOS supports. YMMV.

For your other questions,

1) The BT Core Spec does not define a numerical limit for the number of LE packets in a connection. The connection event is over when one of the following occurs, a) there is not enough time to send another packet before the start of the next event (150uS before), b) two CRC or missed packets occur, or c) the Master elects not to continue the connection event after the first packet. Refer to "4.5.1 Connection Events" in the BT4.0 Core Spec, Vol 6, Part B (Link Layer Specification).

2) The PDU size is 27 bytes for BLE in BT4.0 & BT4.1. Depending on the higher level protocol being used, the number of payload bytes may be less. For a default ATT_MTU of 23, the max GATT Notification payload is 20 bytes.

Best wishes

hi all
I am using 2 cc2640 evm v2.1 sdk, till now i am able to achive only 1260 bytes/second. actually required is 16000bytes/sec. i went through above post i found it is possible to achive 190kbps(~23000bytes/second) in order to achieve this what all are the configurations changes i need to make, Thanks in advance.

madhusudan sangam69 said:

hi all
I am using 2 cc2640evm v2.1 sdk, till now i am able to achive only 1260 bytes/second. actually required is 16000bytes/sec. i went through above post i found it is possible to achive 190kbps(~23000bytes/second) in order to achieve this what all are the configurations changes i need to make, Thanks in advance.

I'm looking at the wiki on cc26xx throughput but to me there are some points that are not clear.

1) why MAX_PDU_SIZE to 255 and using long characteristic (248byte) minimize the overhead? It is because the characteristic handle is sent only once every notification sent? EDIT: this has been moved HERE

2) at the end it is stated that: "...29 packets of 248 GATT payload bytes are sent in one connection event (200 ms). This comes out to 295.8 kbps.". But, if the characteristic is 248byte long, and the application manage to send 29 notification for this characteristic every 200ms for me the throughput is: 248Byte * 29Noti * 8bit/Byte * 1/200ms = 287.68kbps which is quite below the 295.8 kbps. Why? What am I missing?

 

Davide.

Hello Eric & Davide,

Please refer to "5.5.2 Maximum Transmission Unit (MTU)" in the BLE SW Dev Guide (SWRU393) for an explanation of the ATT_MTU and why using a larger MTU size is more efficient.

Although CC2640 is capable of higher throughput as shown in the wiki example, remember that BLE is not meant for high-throughput applications. Most BLE implementations are sub 100kbps and favor low power over throughput. For example, you won't see > 55kbps with an iOS device due to iOS imposed limitations on throughput.

If your (non smartphone) throughput requirements start to exceed 150kbps, you may want to consider classic Bluetooth, such as the CC2564 BT/BLE dual-mode controller with the Health Device Profile (HDP). You may also want to consider adding loss-less compression to data before transmission over the air interface.

Best wishes

Great, I missed the new version of swru393!

Thanks, 

Davide.