7 Replies Latest reply on Dec 10, 2015 11:50 PM by kejo_2153576

    Is 80 kbps throughput really possible with 20736S?

      I have implemented bulk transfer communication between an Android device and the 20736. The implementation is based on the speed test example code where there's a while() loop and blecm_getAvailableTxBuffers() is called. Data is sent via notifications. Just like the speed test example, the notifications are sent from the fine timer callback.

      Connection parameters are:

      Min connection interval = 7.5 mS

      Max connection interval = 7.5 mS

      Slave latency = 0 mS


      The following snippet was taken from the BT HCI log retrieved from the Android device showing data transmitted via notifications from the 20736 to Android

      WireShark Capture of Notification Traffic 12-7-2015.JPG

      Time stamps are in the second column and show the following.

      • Typically only 1 packet is sent per connection interval
      • Sometimes connection intervals are skipped (there's ~14 mS gaps between some data)

      Note that when data is sent from Android to the 20736, I see up to 4 packets within one connection interval. See snippet below

      WireShark Capture of Notification Traffic Android to 20736_12-7-2015.JPG

      Hence, the speed limitation does not seem to be on the Android side.

      What can I do to get more than one packet to be sent from the 20736 to Android during one connection interval?

      Why are some connection intervals not even sending 1 packet?

      Shouldn't it be possible to send 4 packets in one interval?


      I can't event get 20 bytes per 7.5 mS. Please help me figure this out.



        • 1. Re: Is 80 kbps throughput really possible with 20736S?

          Hello Kevin,


          We have noticed this error as well.


          We have a new release SDK 2.2.2 that will provide a fix.


          The SDK should be available early to mid next week.




          • 2. Re: Is 80 kbps throughput really possible with 20736S?



            I’ll give it shot next week.



            • 4. Re: Is 80 kbps throughput really possible with 20736S?

              I updated to 2.2.2 version of SDK and the problem is still not fixed. I do occasionally see 2 packets get sent during one connection interval. But most of the time there's only one packet of data per connection interval and there are frequent intervals where no packets are sent. I see the same ~14 mS gaps in the data that I saw with 2.2.1.


              It almost seems like the notifications are being treated like indications inside the stack.

              • 5. Re: Is 80 kbps throughput really possible with 20736S?

                Hello Kevin,


                Sorry for the difficulty that you are having.


                1.  You are correct, you should get 4 packets per connection.

                2.  However the number of packets that the Android device is getting depends on whether the master is receiving it or not.

                3   Windows speed test works because our use of the dongle means that we are always ready to receive.

                4.  For instance, iOS will never allow less than 30ms.

                5.  You need to send us an Over-The-Air Trace of the packets between the Android and your peripheral - Using a Frontline sniffer, for instance.

                6.  Your device may be sending a packet with the MB bit set and if that is the case the Host/Master has to open its Rx Window and receive again.

                7.  If the peripheral has to repeat the packet several times, then it will look like the Master is NOT receiving.

                8.  You should observe a transmit from the 20736 and you will also see another transmit that won't get acknowledged.

                9.  So on the next connection interval, it will get repeated and the Master will drop that packet an it will be repeated.

                10. So essentially it appears that you are only sending out one packet per interval.


                Hope this helps,


                • 6. Re: Is 80 kbps throughput really possible with 20736S?

                  Hi JT,


                  I don't have a sniffer, but I'll see if I can get one.


                  In the meantime, I did the following experiment.


                  Purpose: To find out at what rate are packets added to the TX queue when calling bleprofile_sendNotification() from the fine timer callback


                  Use spare GPIO pin so that timing can be observed on an oscilloscope


                  1. Configure a spare GPIO pin as an output and set it HIGH initially.

                  2. Connect a wire onto the GPIO pin and attach the scope probe to it

                  3. Use code like the following to send the notification


                  while( 0 < blecm_getAvailableTxBuffers() && 0 < packetCount ) {

                      gpio_setPinOutput(...)  // SET GPIO pin LOW

                      bleprofile_sendNotification(...)    // Send the data

                      gpio_setPinOutput(...)  // SET GPIO pin HIGH




                  The oscilloscope shows that the GPIO line is low for 9.4 mS every time bleprofile_sendNotification() is called from the fine timer callback.



                  The TX queue is only being filled at a rate of 1 packet per 9.4 mS. This seems to be what is limiting throughput. The speed test approach does not allow packets to be queued fast enough to get max throughput.



                  1. Is bleprofile_sendNotification() a blocking call, i.e. it does not return until the packet is sent?

                  2. Is there some way to queue up the packets so that the stack can send them as expected, 4 packets per connection?

                  3. Is this some kind of threading issue? If bleprofile_sendNotification was simply queuing packets, why does it take 9.4 mS to execute?





                  • 7. Re: Is 80 kbps throughput really possible with 20736S?


                    There is no problem in the stack. The reason that my code couldn't load data into the TX queue any faster than 9.4 mS was that I had several ble_trace calls in my while loop. I thought that tracing was disabled, but it was on.


                    I disabled tracing and now I get the 4 packets per 7.5 mS connection interval As expected.


                    Thanks for your help.


                    2 of 2 people found this helpful