Is 80 kbps throughput really possible with 20736S?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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.

Thanks

0 Likes
1 Solution
Anonymous
Not applicable

J.T,

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.

Kevin

View solution in original post

7 Replies
Anonymous
Not applicable

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.

Thanks

JT

0 Likes
Anonymous
Not applicable

J.T.,

I’ll give it shot next week.

Thanks

Kevin

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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,

JT

0 Likes
Anonymous
Not applicable

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

Procedure:

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

}

Results

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

Conclusion:

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.

Questions

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?

Thanks,

Kevin

0 Likes
Anonymous
Not applicable

J.T,

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.

Kevin