PSoC™ 4

Anonymous
Not applicable

# BLE 4.2 max payload throughput

What is the maximum theoretical payload throughput for a BLE 4.2 connection (1 central and 1 peripheral device)?

There can be a maximum of four packets sent per connection interval, and each packet can have up to 251 bytes of payload. According to the BLE specification, the allowable range for connection parameters is from 7.5ms to 4000ms.

267kbps (33466 byte/s) = 251 byte / 7.5 ms (1 payload packet per connection interval)
1070kbps (133866 byte/s) = 4*(251 byte) / 7.5 ms (4 payload packets per connection interval)

Is my assumption correct?

1 Solution
Employee
Employee

# Re: BLE 4.2 max payload throughput

Dear all(Buerger, PieApple, Helon_Chen,mbvrm)

Let's me clarify this topic since I have done some study for BLE data rate, should be a little long(thanks for your patient).

Some basic concept:

Connection model(T_IFS=150us):

Theory data rate for BLE4.1:

1. LL_Payload = 27 bytes, no MIC.

Ts=(1+4+2+27+3)*8us=296us,

2. S->M use notification to put data with max frequency.

3. M->S with ACK, ACK_Payload = 0;

Tm=(1+4+2+3)*8us = 80us.

4. Total time for S->M->S, T=296us+150us+80us+150us = 676us.

5. Set the connection interval to 7.5ms, MTU=512.

6. Chip's prepare time for next connection event should >676us.

7. So in one connection interval, we can transfer 7.5ms/0.676ms = ~11.09.  Minus the prepare time, we can transfer max 10 times in one connection interval.

8. In application we notify 512-3=509 bytes data. In first LL_PDU we need 4 bytes for L2CAP header and 3 bytes for ATT header. So we need to transfer 509+7=516 bytes in LL_PDU.   516/27=19.1, so we need 20 packages to transfer 509 user data.

9.  20 packages need 2 connection interval per #7.

10. Data rate = (1000ms/15ms)*509 bytes*8bits/byte =  271.46kbps.

Theory For BLE4.2

1. LL_PDU = 251, MTU = 498. connection interval = 37.5ms.

2. Total time for S->M->S, T=2088us+150us+80us+150us = 2468us.

3. 37.5ms/2.468ms = 15.1. Max 14 times in one connection interval.

4. user data in one notify package: 498-3 = 495. We need to transfer LL_PDU data:495+7=502 bytes for 495 user data.

5. 14 package contain 7*495=3465 bytes user data.

6. Data rate = (1000ms/37.5ms) *3465 bytes*8 bits/byte = 739.2 kbps.

Please change the parameters per my post and verify the data rate based on Post#2(day24).

Note: This is for PSoC BLE to PSoB BLE.  For Phone to BLE, the data rate is lower.

Please feel free to update for further discuss.

9 Replies
Anonymous
Not applicable

# Re: BLE 4.2 max payload throughput

Hi mbvrm,

Project #024: BLE Throughput - Pushing the Limits may be of use to you.

http://www.cypress.com/blog/100-projects-100-days/project-024-ble-throughput-pushing-limits

Anonymous
Not applicable

# Re: BLE 4.2 max payload throughput

Thanks, but this is an old project before BLE 4.2 which mean without new advanced speed features.

Anonymous
Not applicable

# Re: BLE 4.2 max payload throughput

Hi mbvrm,

And I'm afraid to say that I don't agree Cypress company let developer to test the throughput by themselves.

Why ?

Throughput is also a hot topic on TI BLE solution and Nordic BLE solution.
In engineering view of TI and Nordic,  the engineering design everything on that. So they will know what's the  constraint on different level in the BLE protocol. And then they can figure out the  thoughput value.

The  throughput  will depend on  not only BLE host firmware and BLE controller chip, but also depend on how you implement on application level,  what another chip you communicate with and what parameter you set.

In the designer view, we still need to know what BLE chip should we choice.
In the forum of TI and Nordic, you can find out the  information clearly and they will  tell you how to speed up the throughput and how to do. So the designer just need  to evaluate the  throughput value and decide what chip they need to use.

But in the forum of Cypress, we cannot get the clearly information. The information is still in a black-box.
When the information is stay in the black-box, It's will become a problem when evaluation.

If Cypress can give us  more BLE throughput information, it's mean the  Cypress solution can put in more and more important project.
But If  Cypress BLE solution  cannot give the throughput information , The cypress BLE solution must lost some marketing share in the BLE domain.

In my opinion, I would like to expect Cypress company to give us the throughput information clearly.
Because I also would  like  to more and more developer using Cypress  BLE solution.

Anonymous
Not applicable

# Re: BLE 4.2 max payload throughput

Hi,PieApple

I totally agree with you , in this respect TI and Nordic indeed doing better

Employee
Employee

# Re: BLE 4.2 max payload throughput

Dear all(Buerger, PieApple, Helon_Chen,mbvrm)

Let's me clarify this topic since I have done some study for BLE data rate, should be a little long(thanks for your patient).

Some basic concept:

Connection model(T_IFS=150us):

Theory data rate for BLE4.1:

1. LL_Payload = 27 bytes, no MIC.

Ts=(1+4+2+27+3)*8us=296us,

2. S->M use notification to put data with max frequency.

3. M->S with ACK, ACK_Payload = 0;

Tm=(1+4+2+3)*8us = 80us.

4. Total time for S->M->S, T=296us+150us+80us+150us = 676us.

5. Set the connection interval to 7.5ms, MTU=512.

6. Chip's prepare time for next connection event should >676us.

7. So in one connection interval, we can transfer 7.5ms/0.676ms = ~11.09.  Minus the prepare time, we can transfer max 10 times in one connection interval.

8. In application we notify 512-3=509 bytes data. In first LL_PDU we need 4 bytes for L2CAP header and 3 bytes for ATT header. So we need to transfer 509+7=516 bytes in LL_PDU.   516/27=19.1, so we need 20 packages to transfer 509 user data.

9.  20 packages need 2 connection interval per #7.

10. Data rate = (1000ms/15ms)*509 bytes*8bits/byte =  271.46kbps.

Theory For BLE4.2

1. LL_PDU = 251, MTU = 498. connection interval = 37.5ms.

2. Total time for S->M->S, T=2088us+150us+80us+150us = 2468us.

3. 37.5ms/2.468ms = 15.1. Max 14 times in one connection interval.

4. user data in one notify package: 498-3 = 495. We need to transfer LL_PDU data:495+7=502 bytes for 495 user data.

5. 14 package contain 7*495=3465 bytes user data.

6. Data rate = (1000ms/37.5ms) *3465 bytes*8 bits/byte = 739.2 kbps.

Please change the parameters per my post and verify the data rate based on Post#2(day24).

Note: This is for PSoC BLE to PSoB BLE.  For Phone to BLE, the data rate is lower.

Please feel free to update for further discuss.

Anonymous
Not applicable

# Re: BLE 4.2 max payload throughput

Hello,
Can you tell me how i know the throughput when the payload is 32 bytes? Im a bit confuse, i wanna send it over notification.

Thank You

Anonymous
Not applicable

# Re: BLE 4.2 max payload throughput

set MTU = 32

The usable data per packet is 29 (32-3)

14 packages per connection interval contain 7*29 = 203 bytes of user data

Data Rate = 1000ms/37.5ms *203 bytes*8 bits/byte = 43.3067 kbps

(The example calculations are using notifications as read/write halve the data rate for confirmation/reliability)

Anonymous
Not applicable

# Re: BLE 4.2 max payload throughput

Why do you assume it will send 14 packeges? With a small data and the same time, would not be possible send more packects?
And why you multiple by 7?
Thank You

Anonymous
Not applicable

# Re: BLE 4.2 max payload throughput

Based on yans​ post with a theory-guide of the calculations.

 Theory For BLE4.21. LL_PDU = 251, MTU = 498. connection interval = 37.5ms.2. Total time for S->M->S, T=2088us+150us+80us+150us = 2468us.3. 37.5ms/2.468ms = 15.1. Max 14 times in one connection interval.4. user data in one notify package: 498-3 = 495. We need to transfer LL_PDU data:495+7=502 bytes for 495 user data.  5. 14 package contain 7*495=3465 bytes user data.6. Data rate = (1000ms/37.5ms) *3465 bytes*8 bits/byte = 739.2 kbps.

The 14 packets is from the time it takes to send a single packet divided by the connection interval for the packets per connection interval.

The 7 is related to the encoding of extended length data packets I believe (merely copying it from step 5). Very probably, to do an extended MTU packet large than the default size of packet requires sending two packets (one with the data, and the second with the start for the data packet)