5 Replies Latest reply on Sep 28, 2017 3:07 AM by yans

    BLE 4.2 max payload throughput

    m.buerger

      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.

         

      throughput(kbps) = payload(byte) / interval(ms)
      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. Re: BLE 4.2 max payload throughput
          George.Riggall_1541811

          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

          • 2. Re: BLE 4.2 max payload throughput
            m.buerger

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

            • 3. Re: BLE 4.2 max payload throughput
              pie.apple

              Hi mbvrm,  

                 

              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.

              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. 

               

              • 4. Re: BLE 4.2 max payload throughput
                Helon_chen_1478911

                Hi,PieApple
                 

                   

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

                • 5. Re: BLE 4.2 max payload throughput
                  yans

                  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:

                  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 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.