Thanks, but this is an old project before BLE 4.2 which mean without new advanced speed features.
I agree with your view.
And I'm afraid to say that I don't agree Cypress company let developer to test the throughput by themselves.
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.
I totally agree with you , in this respect TI and Nordic indeed doing better
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:
BLE 4.1 Link layer PDU:
BLE 4.2 Link layer PDU:
Theory data rate for BLE4.1:
1. LL_Payload = 27 bytes, no MIC.
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 bytes.
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.