Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Throughput issue with Infineon-CYW20704 #622

Open
xihua13104 opened this issue Jul 30, 2024 · 7 comments
Open

Throughput issue with Infineon-CYW20704 #622

xihua13104 opened this issue Jul 30, 2024 · 7 comments

Comments

@xihua13104
Copy link

xihua13104 commented Jul 30, 2024

Describe the bug
Hi, I am running BTstack v1.6 with the CYW20704 on an STM32F407 with ENABLE_LE_DATA_LENGTH_EXTENSION on. I'm using the gatt_streamer_server demo to test throughput by connecting from my smartphone (Android-13). However, I am only got a maximum TX data rate of about 16 kB/s with different parameters(GATT MTU size,connection interval,packet size per transmit.....). From the HCI packet log of our device, I noticed that the CYW20704 is only sending one packet (244 bytes) per connection interval (15ms). Is there any way to configure the CYW20704 to send multiple packets per connection interval?

To Reproduce
Steps to reproduce the behavior:

  1. Enable ENABLE_LE_DATA_LENGTH_EXTENSION in btstack_config.h
  2. Run example 'gatt_streamer_server'
  3. Connect from remove device 'xiaomi note11' with nrf-connect
  4. Start action 'enable notification on one of the characteristic'

Expected behavior
CYW20704 send multiple packets per connection interval, and achieve 30+kB/s TX data rate.
for example, if CYW20704 send 2 packets(244 bytes) per connection interval(15ms), we will got a tx data rate:
(1000 * packet number * packet size) / conn interval = (1000 * 2 * 244) / 15 = 32.5kB/s

HCI Packet Logs
HCI packet log.zip

Environment: (please complete the following information):

  • Current BTstack : V1.6
  • Bluetooth Controller : CYW20704
  • Remote device: xiaomi-note11 android-13

Additional context
no.

@mringwal
Copy link
Member

In LE, each side can close a connection event. It would be good to figure out which side closes the connection event in your case. Do you other devices to test with? E.g. a second setup with the CYW20704 or an ESP32? You can run le_streamer_client on the other device.

Alternatively, an air trace can also show which side stops. Our Raccoon sniffer does not support DLE yet, but others, e.g. Nordic's version support it: https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-ble-sniffer/nrfutil-ble-sniffer_0.12.0.html

@mringwal
Copy link
Member

There are no direct HCI parameter to control how many packets per connection interval is sent.
You may also play with the Min/Max CE parameters, but it seems to be vendor specific how these are used. E.g. the old CSR8510 will send/receive as many ACL packets in each connection interval.

@xihua13104
Copy link
Author

Hi mringwal,
Thanks for your quick response. I have captured the air log by nRF BLE sniffer. From the air log, I can see that the master only generates one connection event with the slave in each connection interval, even if there is a lot of free time in this connection interval. Can you help me find out what happened to the master?
sniff-android.zip

@mringwal
Copy link
Member

mringwal commented Aug 2, 2024

Thanks for the logs. The master (your phone) sends an empty pdu which allows the slave (your device) to send one PDU. In this PDU, the "more data" flag is not set, which is unexpected. The Controller (CYW20704) should have multiple buffers that are kept full all the time, which then would let it indicate that it has "more data" to send.

What baud rate do you use between STM32F407 and CYW20704?
If you check the HCI log, you can find the number of LE ACL buffers (4-10) and then check if BTstack fills them at the start, providing a new packet when one has been confirmed as sent in the HCI Number Completed Packets events.
(you've provided .cfa file above, which is for Teledyne radio sniffer as far as I know).

@xihua13104
Copy link
Author

I use 2M baud rate.
And i see there are 15 LE ACL buffer with 251 bytes each. When we start streaming data to Phone, after a short time, the 15 LE ACL buffers are quickly filled up. Then waiting for CYW20704 to report the HCI Number Completed Packets events to give us new buffers to use. Each time CYW20704 only gives us 2 new buffers. The LE ACL buffer is always full, so there is no reason for the CYW20704 to close the connection event.

I got a new HCI Packet Log by create_packet_log.py, please take a look.
COM5_2024858414.zip

@mringwal
Copy link
Member

In the log, it looks like the HCI Dump might slow down your HCI communication - on start, the 15 buffers should fill up in no time.

You can add #define HCI_DUMP_STDOUT_MAX_SIZE_ACL 200 in btstack_config.h to only print a short summary instead of the full message and/or increase the debug console baud rate or use SEGGER RTT (which is really fast).

@xihua13104
Copy link
Author

xihua13104 commented Dec 13, 2024

Hi,
I have made some progress. I got 2 CYW20704 with one running the gatt_streamer_server demo, and another one running the le_streamer_client demo. From the air log, I observed that the Master sent an LL_CONNECTION_PARAM_REQ, but it was rejected by the Slave with the error code Different Transaction Collision (0x2a). This indicates a conflict in some interactions at the Link Layer. So I moved the call to gap_request_connection_parameter_update() from receiving the GAP_SUBEVENT_LE_CONNECTION_COMPLETE event to the ATT_EVENT_CONNECTED event. After this modification, the negotiation for a 7.5ms connection interval succeeded, and I achieved a transmission rate of over 32 KB/s.

image
image
sniff-cyw20704.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants