Re: Choosing Tx Buffers in BLE stack

Hi All,
      With regards to my previous problems I have some basic questions to understand this problem. 
By increasing the Tx Buffers i increased the number packets transmitted per connection interval. 
Even though this increased my data transfer speed i faced compatibility issue with windows HID driver 
crashing in the middle of transmission. I read that Android and iOS systems sometimes have a limit on 
the number of packets transmitted per connection interval time. May be for windows too there may be 
some limit  on this factor. when i checked the HCI logs i see that almost all the HID characters are sent 
with in one connection interval for my device. 

Is it possible to configure this factor in zephyr either directly or indirectly?
Should application layer handle these delays?

Dhananjay G J

On Fri, Sep 21, 2018 at 3:42 PM dhananjay gj <dhguja@...> wrote:
    Thanks for the reply. Sorry if there is some confusion regarding the crash on windows. 

I will explain more elaborately below what i am trying to achieve & what i debugged till now.

I am working on BLE based barcode scanner which will send the data via HID over GATT profile. I am using nRF52840 
device and Zephyr 1.13 with default connection interval parameters. With the default Tx buffer numbers provided in zephyr
the characters are sent to peer devices very slowly. We can literally see that characters are printed one by one. When i checked
the HCI timestamps using btmon i see that 1 character is sent every connection interval time(around 45 ms ). 

To remove the bottleneck on Tx buffers i increased Maximum number of pending TX buffers (3) , Number of Tx buffers(3).
I see that characters are sent instantly now (within one connection interval or even less than 10ms). The improvement in speed
is seen only when i change both of these parameters from the default values.

Now with this new config changes related to Tx buffers my application works fast as expected in Android, iOS, Linux systems. 
But on windows 10 system after two or three scans 'Windows' HID driver crashes probably due to buffer overflow from sending the 
data so fast. I checked the windows log and i see that "A command sent to the adapter has timed out. The adapter did not respond".
The behavior seen is that characters are not accepted anymore and the last character that is sent to windows is printed continuously 
until the connection is closed. On the zephyr side, the bt_gatt_notify API is blocked until this time and then returns with error. 
I also checked the connection interval used with Windows 10 system as 40 ms.

I also changed different buffer numbers to know the behavior but this just changes the time when this crash in windows occurs again. 
I also checked with some commercial devices that have similar application of using HID profile to send data and it also uses buffering
to speed up. One thing i noticed in commercial device is for every 10 characters sent there is some delay equal to max connection 
interval time. But in case of my application using zephyr there is just 1 delay with connection interval for even up to 40 characters that are 

In order to control the speed of buffering i tried changing different buffer numbers but with no luck or information on how to proceed
further. If i know how to calculate or more information on these i can try to control the speed of my application by using buffer numbers or 
delays like i saw in other commercial devices. It would be helpful even if i had to look for something else in BLE specification or Zephyr.

Thanks very much for the help.

Dhananjay G J

On Fri, Sep 21, 2018 at 1:20 PM Von Dentz, Luiz <luiz.von.dentz@...> wrote:

I guess that is because with more buffer one can queue more data and
is less affected by the speed in which the controller acknowledge
their transmissions, obviously this increase the footprint but it is
the usual trade of size for speed. Btw, if the improvement is
substantial maybe we should have 3 by default, though we need to
figure if the crash on windows is due to some misbehaviour on our side
when are operating with more buffers.

On Fri, Sep 21, 2018 at 1:58 PM, Cufi, Carles <Carles.Cufi@...> wrote:
> Hi there,
> Copying a few people to this thread.
> Carles
> ________________________________
> From: devel@... <devel@...> on
> behalf of dhguja@... <dhguja@...>
> Sent: Thursday, September 20, 2018 11:56 AM
> To: devel@...
> Subject: [Zephyr-devel] Choosing Tx Buffers in BLE stack
> Hello,
>       I am working on a BLE HID keyboard application using zephyr 1.13.
> I was playing around with Tx buffers (specifically Maximum number of pending
> TX buffers, Number of Tx buffers).
> With default buffer settings the characters were transmitted very slowly due
> to small number of buffers. But as soon as
> i increased it to 3 pending buffers and 3 Tx buffers i saw significant
> improvement in the speed of characters transmitted.
> My question is how to choose the buffer values for this?.
> The reason is currently i face a compatibility problem with my HID
> application, where it works fine in Linux, Android, iOS devices
> with increased number of buffers, but crashes on windows system. When i
> debugged the HCI log (from btmon) i saw that with
> increased buffers, characters are sent very quickly on the order of 500 us
> for each character. This causes the data (of 20 characters)
> to be transmitted within one or two connection intervals. Maybe this causes
> some overflow in windows systems. I would like to know
> what are the implications of choosing a number of Tx buffers and pending
> buffers.
> It will be helpful if anyone can tell how to choose the number of Tx
> buffers? or even point to some direction in the BLE specification?
> Thank you,
> Dhananjay G J

Join to automatically receive all group messages.