Re: Choosing Tx Buffers in BLE stack


Chettimada, Vinayak Kariappa
 

Hi Dhananjay,

Related PR and its explanation in the commit message: https://github.com/zephyrproject-rtos/zephyr/pull/10332

This does not solve your Windows crash, but will in general reduce data transmission latencies in the cases where in host is trying to continuously transmit packets as fast as it can.

Regards,
Vinayak

-----Original Message-----
From: <devel@lists.zephyrproject.org> on behalf of "dhguja@gmail.com" <dhguja@gmail.com>
Date: Monday, 1 October 2018 at 4:20 PM
To: "Dunaj, Pawel" <Pawel.Dunaj@nordicsemi.no>
Cc: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] Choosing Tx Buffers in BLE stack

Hello Pawel,
Thank you very much for the reply.


Yes i used the zephyr sample as reference(HoG mouse device) but modified for keyboard. The report map i use is directly from Nordic SDK HID keyboard sample.
I am also sending standard USB HID report for every character (u8_t
modifier, u8_t media, u8_t keys[6]
=> totally 8 bytes). I think every BLE packet sends one character
since I did not change the MTU size (~20 bytes for application)


This report map and report along with BLE Tx buffer changes works fine in Android and iOS device without any problems. Even in Windows if i use the default buffer

settings where 1 character is sent every connection interval, things works fine. Only when there are more packets sent continuously without a delay windows HID driver
crashes in the middle. I also tried to enable some low level logs in zephyr BLE for debugging but apparently logging adds some delay which hides the problem from appearing.


Also your comment is true
"Zephyr will block when there is no buffer available to add the notification data too"

Zephyr did block the notify API when the windows driver crashed and could not receive further characters.




I checked the behavior of other existing HID barcode scanner devices where i see that there is at least a delay (almost connection interval time) every 9-10 characters sent.
I was just curious if we can config this as setting in Zephyr. These commercial devices also send the data to windows with similar timing per packet (~ 600 microsec)
as my Zephyr based device . The only difference is the delay of connection interval for every ~10 packets.



Is there something i can further do from zephyr configs?


Regards,
Dhananjay G J


On Mon, Oct 1, 2018 at 3:37 PM <pawel.dunaj@nordicsemi.no> wrote:


Hi,

Whatever Zephyr is doing I don't think Win should crash. I expect this is a bug in the OS or the driver. You can try MS support, maybe they can help. It should simply reject the data (that will probably not help you much as you may miss an information about
key release).

At first I expected you are not sending normal HID data but instead put some custom data in the HID report, but you state that you work on a keyboard. Are you using zephyr hid sample? How is your report defined? How much data are you sending with each notification?

Zephyr will block when there is no buffer available to add the notification data too. If data is not picked fast enough by the host (i.e. connection is slow) pipeline of data waiting to be served will build up. It is up to your application to ensure the valid
data flow. For that you can check optional callback added to Zephyr recently.

As for limiting the number of data sent with each connection interval, you are doing that by correctly setting up the report map and sending data according to it. Are you doing that? (Maybe system receives too much data compared to what was stated in the map
and crash?)

To limit the data sent with each interval you can try changing MTU, however I don't think this is the problem.

Thanks,
Pawel

Join devel@lists.zephyrproject.org to automatically receive all group messages.