gh-raspberrypi/pico-sdk
Watch
1
0
Fork
You've already forked pico-sdk
 0
Code Issues 262 Pull requests 63 Releases Activity

BLE Host is only able to receive one packet per interval #1342

New issue
Open
opened 2023-04-12 02:51:43 -05:00 by sanjay900 · 99 comments
sanjay900 commented 2023-04-12 02:51:43 -05:00 (Migrated from github.com)

I currently have two pico ws, one configured as a HOG Host, and one configured as a HOG Device, using code very similar to the hog keyboard hog host examples.

If i connect the device over bluetooth from a PC, i can get to poll rate around 850hz or so, which suggests that multiple packets are being sent per connection interval. However, if i instead connect to the HOG host running on a pico w, i end up with a poll rate of around 32hz, which lines up with the default 30ms connection interval.

If I then add the following line to the HOG host, I can lower the connection interval to the minimum 7.5ms, and I do end up seeing a poll rate of around 130hz or so, which also lines up with the 7.5ms connection interval.
gap_set_connection_parameters(0x0060, 0x0030, 0x06, 0x06, 0, 0x0048, 2, 0x0030);

I also ran BTStack locally on my PC using the libusb port, and found that that did get to around 850hz as well, so it does appear to just be an issue with the pico w port specifically.

My eventual goal is to use this to allow a user to create a usb adapter for a bluetooth controller i am working on that can then be plugged into a console, hence the need for a very low latency.

I currently have two pico ws, one configured as a HOG Host, and one configured as a HOG Device, using code very similar to the hog keyboard hog host examples. If i connect the device over bluetooth from a PC, i can get to poll rate around 850hz or so, which suggests that multiple packets are being sent per connection interval. However, if i instead connect to the HOG host running on a pico w, i end up with a poll rate of around 32hz, which lines up with the default 30ms connection interval. If I then add the following line to the HOG host, I can lower the connection interval to the minimum 7.5ms, and I do end up seeing a poll rate of around 130hz or so, which also lines up with the 7.5ms connection interval. `gap_set_connection_parameters(0x0060, 0x0030, 0x06, 0x06, 0, 0x0048, 2, 0x0030);` I also ran BTStack locally on my PC using the libusb port, and found that that did get to around 850hz as well, so it does appear to just be an issue with the pico w port specifically. My eventual goal is to use this to allow a user to create a usb adapter for a bluetooth controller i am working on that can then be plugged into a console, hence the need for a very low latency.
peterharperuk commented 2023-04-12 04:04:10 -05:00 (Migrated from github.com)

You'll have to provide more context about the code you're running. What method are you using polling, background or are you using an rtos? Do you have any code that demonstrates a problem. Note that we're not actually bluetooth experts here so your report is assuming lots of prior knowledge. I don't know what "interval" you're referring to for example. Unless you can clarify what you're reporting in a way I can investigate a problem you're unlikely to get any help.

You'll have to provide more context about the code you're running. What method are you using polling, background or are you using an rtos? Do you have any code that demonstrates a problem. Note that we're not actually bluetooth experts here so your report is assuming lots of prior knowledge. I don't know what "interval" you're referring to for example. Unless you can clarify what you're reporting in a way I can investigate a problem you're unlikely to get any help.
sanjay900 commented 2023-04-12 04:19:31 -05:00 (Migrated from github.com)

Fair call, ill throw together a simplified repo that has an example for both sides of the pico. Ill admit I also don't really have much knowledge on the matter either, this was just what i gleamed after some experimentation with some of the btstack options, and some research.

From what i understand, BLE has a concept of a connection interval, which both sides of the connection agree on, and then the host will send out a packet each time the interval is hit. This can be configured but there is a lower limit of 7.5ms. It sounds like however you can sent multiple packets within this interval, which is how devices can update faster than 7.5ms.

I have essentially taken the hog_keyboard_demo and just have it sending data as often as possible, and with a PC (either using the linux bluetooth stack or btstack via libusb) it seems to be able to update at ~1ms or so, which suggests that this side of the equation is able to send out multiple packets per interval. I even left this side at the default connection interval of 30ms, so it is sending multiple packets per interval.

I then took the hog_host_demo and added a line to print out how often it receives data. It appears that GATTSERVICE_SUBEVENT_HID_REPORT is only ever fired once per connection interval here, so by default i only seem to get one report every 30ms. I can adjust the connection interval with gap_set_connection_parameters and if i lower it to the minimum 7.5ms value, then i also noted that I would get reports every 7.5ms.

I am using the background method, on both the device and the host.

Fair call, ill throw together a simplified repo that has an example for both sides of the pico. Ill admit I also don't really have much knowledge on the matter either, this was just what i gleamed after some experimentation with some of the btstack options, and some research. From what i understand, BLE has a concept of a connection interval, which both sides of the connection agree on, and then the host will send out a packet each time the interval is hit. This can be configured but there is a lower limit of 7.5ms. It sounds like however you can sent multiple packets within this interval, which is how devices can update faster than 7.5ms. I have essentially taken the [hog_keyboard_demo](https://github.com/bluekitchen/btstack/blob/master/example/hog_keyboard_demo.c) and just have it sending data as often as possible, and with a PC (either using the linux bluetooth stack or btstack via libusb) it seems to be able to update at ~1ms or so, which suggests that this side of the equation is able to send out multiple packets per interval. I even left this side at the default connection interval of 30ms, so it is sending multiple packets per interval. I then took the [hog_host_demo](https://github.com/bluekitchen/btstack/blob/master/example/hog_host_demo.c) and added a line to print out how often it receives data. It appears that `GATTSERVICE_SUBEVENT_HID_REPORT` is only ever fired once per connection interval here, so by default i only seem to get one report every 30ms. I can adjust the connection interval with `gap_set_connection_parameters` and if i lower it to the minimum 7.5ms value, then i also noted that I would get reports every 7.5ms. I am using the background method, on both the device and the host.
peterharperuk commented 2023-04-12 04:41:34 -05:00 (Migrated from github.com)

Ok, thanks for adding some context. Examples (or modifications to existing examples) would be useful. In the background mode, we get an interrupt via a gpio to tell us there might be work to do (cyw43_gpio_irq_handler). This ends up in a call to cyw43_poll_func. We ask the chip if there's any work to do (cyw43_ll_bt_has_work) and call cyw43_bluetooth_hci_process which signals that a btstack data source has work to do. BTstack calls hci_transport_cyw43_process which keeps reading hci commands. So if the chip thinks there's nothing to do or there are no hci commands to read we won't try and "receive" anything. I would avoid debugging via logging as it's likely to affect timings. Probably best to use a logic analyser to work out what's going on.

Ok, thanks for adding some context. Examples (or modifications to existing examples) would be useful. In the background mode, we get an interrupt via a gpio to tell us there might be work to do (cyw43_gpio_irq_handler). This ends up in a call to cyw43_poll_func. We ask the chip if there's any work to do (cyw43_ll_bt_has_work) and call cyw43_bluetooth_hci_process which signals that a btstack data source has work to do. BTstack calls hci_transport_cyw43_process which keeps reading hci commands. So if the chip thinks there's nothing to do or there are no hci commands to read we won't try and "receive" anything. I would avoid debugging via logging as it's likely to affect timings. Probably best to use a logic analyser to work out what's going on.
mringwal commented 2023-04-12 04:48:48 -05:00 (Migrated from github.com)

@peterharperuk if there are more than one ACL packet stored in the cyw43 ring buffer, will all of them get processed in a row until it's empty? or does this require another interrrupt via the GPIO line?

@peterharperuk if there are more than one ACL packet stored in the cyw43 ring buffer, will all of them get processed in a row until it's empty? or does this require another interrrupt via the GPIO line?
peterharperuk commented 2023-04-12 04:56:50 -05:00 (Migrated from github.com)

@mringwal I think it should yes. hci_transport_cyw43_process keeps reading hci commands until there's no data (or an error). It's possible this loop is faulty somehow. It should perhaps keep going while cyw43_ll_bt_has_work is true. It might be worth debugging this area (without using printf).

@mringwal I think it should yes. hci_transport_cyw43_process keeps reading hci commands until there's no data (or an error). It's possible this loop is faulty somehow. It should perhaps keep going while cyw43_ll_bt_has_work is true. It might be worth debugging this area (without using printf).
sanjay900 commented 2023-04-12 05:00:04 -05:00 (Migrated from github.com)

https://gist.github.com/sanjay900/fe87afaad7474707459718d0945da759
Here is my gamepad implementation, i am currently testing by just sending a random value to an axis on each tick, which I can then use tools like evhz on linux to test with. For the pico receiver, the standard hog_host_demo is enough to demonstrate the problem, simply just printing the milliseconds since the last GATTSERVICE_SUBEVENT_HID_REPORT is enough to show the issue (I was actually testing this with a program that would redirect the inputs directly to USB hid and testing with evhz, so I was not dealing with printf delays on that front)

You can listen to the LE_CONNECTION_COMPLETE event to get an idea of what the current interval is. I added this to the hog example locally just to work out what the current interval even was.

switch (hci_event_le_meta_get_subevent_code(packet)) {
    case HCI_SUBEVENT_LE_CONNECTION_COMPLETE: {
        // print connection parameters (without using float operations)
        uint16_t conn_interval = hci_subevent_le_connection_complete_get_conn_interval(packet);
        printf("LE Connection Complete:\n");
        printf("- Connection Interval: %u.%02u ms\n", conn_interval * 125 / 100, 25 * (conn_interval & 3));
        printf("- Connection Latency: %u\n", hci_subevent_le_connection_complete_get_conn_latency(packet));
        break;
    }
    case HCI_SUBEVENT_LE_CONNECTION_UPDATE_COMPLETE: {
        // print connection parameters (without using float operations)
        uint16_t conn_interval = hci_subevent_le_connection_update_complete_get_conn_interval(packet);
        printf("LE Connection Update:\n");
        printf("- Connection Interval: %u.%02u ms\n", conn_interval * 125 / 100, 25 * (conn_interval & 3));
        printf("- Connection Latency: %u\n", hci_subevent_le_connection_update_complete_get_conn_latency(packet));
        break;
    }
    default:
        break;
}

If you do just want to see the actual project i am testing with, it is at https://github.com/sanjay900/Ardwiino

https://gist.github.com/sanjay900/fe87afaad7474707459718d0945da759 Here is my gamepad implementation, i am currently testing by just sending a random value to an axis on each tick, which I can then use tools like `evhz` on linux to test with. For the pico receiver, the standard [hog_host_demo](https://github.com/bluekitchen/btstack/blob/master/example/hog_host_demo.c) is enough to demonstrate the problem, simply just printing the milliseconds since the last GATTSERVICE_SUBEVENT_HID_REPORT is enough to show the issue (I was actually testing this with a program that would redirect the inputs directly to USB hid and testing with evhz, so I was not dealing with printf delays on that front) You can listen to the LE_CONNECTION_COMPLETE event to get an idea of what the current interval is. I added this to the hog example locally just to work out what the current interval even was. ```c switch (hci_event_le_meta_get_subevent_code(packet)) { case HCI_SUBEVENT_LE_CONNECTION_COMPLETE: { // print connection parameters (without using float operations) uint16_t conn_interval = hci_subevent_le_connection_complete_get_conn_interval(packet); printf("LE Connection Complete:\n"); printf("- Connection Interval: %u.%02u ms\n", conn_interval * 125 / 100, 25 * (conn_interval & 3)); printf("- Connection Latency: %u\n", hci_subevent_le_connection_complete_get_conn_latency(packet)); break; } case HCI_SUBEVENT_LE_CONNECTION_UPDATE_COMPLETE: { // print connection parameters (without using float operations) uint16_t conn_interval = hci_subevent_le_connection_update_complete_get_conn_interval(packet); printf("LE Connection Update:\n"); printf("- Connection Interval: %u.%02u ms\n", conn_interval * 125 / 100, 25 * (conn_interval & 3)); printf("- Connection Latency: %u\n", hci_subevent_le_connection_update_complete_get_conn_latency(packet)); break; } default: break; } ``` If you do just want to see the actual project i am testing with, it is at https://github.com/sanjay900/Ardwiino
mringwal commented 2023-04-12 05:03:14 -05:00 (Migrated from github.com)

@sanjay900 Could you run gatt_streamer_server on one pico and le_streamer_client on the other. le_streamer_client should be configured to use TEST_MODE_ENABLE_NOTIFICATIONS - so it's only receiving. As the demo prints the throughput, we can check how many packets are sent per interval.

I still don't see how only a single packet could get received in a connection interval. The sender in peripheral role will send as long as the central allows it to send and the central will keep the connection event open until it's buffers overflow. event with controller to host flow control, we should get a least a few packets per conn interval.

@sanjay900 Could you run gatt_streamer_server on one pico and le_streamer_client on the other. le_streamer_client should be configured to use TEST_MODE_ENABLE_NOTIFICATIONS - so it's only receiving. As the demo prints the throughput, we can check how many packets are sent per interval. I still don't see how only a single packet could get received in a connection interval. The sender in peripheral role will send as long as the central allows it to send and the central will keep the connection event open until it's buffers overflow. event with controller to host flow control, we should get a least a few packets per conn interval.
sanjay900 commented 2023-04-12 05:07:45 -05:00 (Migrated from github.com)

Let me just build both of those and i will give it a try

Let me just build both of those and i will give it a try
sanjay900 commented 2023-04-12 05:32:49 -05:00 (Migrated from github.com)

Hmm, doesn't seem to be working right, here are the logs from the le_streamer_client

BTstack up and running on 43:43:A2:12:1F:AC.
Start scanning!
Stop scan. Connect to device with addr 43:43:A2:12:1F:AC.
Connection Interval: 30.00 ms
Connection Latency: 4
Search for LE Streamer service.
SERVICE_QUERY_RESULT, ATT Error 0x7f.
Disconnected 43:43:A2:12:1F:AC
Start scanning!
Stop scan. Connect to device with addr 43:43:A2:12:1F:AC.
Connection Interval: 30.00 ms
Connection Latency: 4
Search for LE Streamer service.

And from the gatt_streamer_server:

BTstack up and running on 43:43:A2:12:1F:AC.
To start the streaming, please run the le_streamer_client example on other device, or use some GATT Explorer, e.g. LightBlue, BLExplr.
A: ATT connected, handle 0x0040, test data len 20
- LE Connection 0x0040: connected - connection interval 30.00 ms, latency 4
- LE Connection 0x0040: request 15 ms connection interval
A: ATT MTU = 1688 => use test data of len 200
- LE Connection 0x0040: connection update - connection interval 15.00 ms, latency 0
A: ATT disconnected, handle 0x0040
- LE Connection 0x0040: disconnect, reason 22
A: ATT connected, handle 0x0040, test data len 20
- LE Connection 0x0040: connected - connection interval 30.00 ms, latency 4
- LE Connection 0x0040: request 15 ms connection interval
A: ATT MTU = 1688 => use test data of len 200
- LE Connection 0x0040: connection update - connection interval 15.00 ms, latency 0
Hmm, doesn't seem to be working right, here are the logs from the le_streamer_client ``` BTstack up and running on 43:43:A2:12:1F:AC. Start scanning! Stop scan. Connect to device with addr 43:43:A2:12:1F:AC. Connection Interval: 30.00 ms Connection Latency: 4 Search for LE Streamer service. SERVICE_QUERY_RESULT, ATT Error 0x7f. Disconnected 43:43:A2:12:1F:AC Start scanning! Stop scan. Connect to device with addr 43:43:A2:12:1F:AC. Connection Interval: 30.00 ms Connection Latency: 4 Search for LE Streamer service. ``` And from the gatt_streamer_server: ``` BTstack up and running on 43:43:A2:12:1F:AC. To start the streaming, please run the le_streamer_client example on other device, or use some GATT Explorer, e.g. LightBlue, BLExplr. A: ATT connected, handle 0x0040, test data len 20 - LE Connection 0x0040: connected - connection interval 30.00 ms, latency 4 - LE Connection 0x0040: request 15 ms connection interval A: ATT MTU = 1688 => use test data of len 200 - LE Connection 0x0040: connection update - connection interval 15.00 ms, latency 0 A: ATT disconnected, handle 0x0040 - LE Connection 0x0040: disconnect, reason 22 A: ATT connected, handle 0x0040, test data len 20 - LE Connection 0x0040: connected - connection interval 30.00 ms, latency 4 - LE Connection 0x0040: request 15 ms connection interval A: ATT MTU = 1688 => use test data of len 200 - LE Connection 0x0040: connection update - connection interval 15.00 ms, latency 0 ```
mringwal commented 2023-04-12 05:37:58 -05:00 (Migrated from github.com)

@peterharperuk did anybody complain about all pico w using the same BD ADDR? In @sanjay900's logs, both have 43:43:A2:12:1F:AC - the first 6 hex digits indicate the used controller, a 4343A2.

I don't remember exactly, but BTstack avoids connections to devices with the same BD ADDR, as that allows for some sneaky security hacks.

@sanjay900 Thanks for trying. I can check myself tomorrow or Friday.

@peterharperuk did anybody complain about all pico w using the same BD ADDR? In @sanjay900's logs, both have 43:43:A2:12:1F:AC - the first 6 hex digits indicate the used controller, a 4343A2. I don't remember exactly, but BTstack avoids connections to devices with the same BD ADDR, as that allows for some sneaky security hacks. @sanjay900 Thanks for trying. I can check myself tomorrow or Friday.
sanjay900 commented 2023-04-12 05:38:55 -05:00 (Migrated from github.com)

It does however seem like something is broken with updating the connection parameters, as commenting out gap_request_connection_parameter_update(con_handle, 12, 12, 0, 0x0048); is enough to make it run. I actually found this myself too when i was looking for ways to increase my connection interval, but just assumed i was doing something wrong when it hung.

@peterharperuk
Do you want this raised as a separate issue, or just kept here? I have no idea where that problem lies as it is just something i have found by testing.

@mringwal here is the output with that line commented out

BTstack up and running on 43:43:A2:12:1F:AC.
To start the streaming, please run the le_streamer_client example on other device, or use some GATT Explorer, e.g. LightBlue, BLExplr.
A: ATT connected, handle 0x0040, test data len 20
- LE Connection 0x0040: connected - connection interval 30.00 ms, latency 4
- LE Connection 0x0040: request 15 ms connection interval
A: ATT MTU = 1688 => use test data of len 200
A: Notifications enabled 1
A: 21000 bytes sent-> 6.930 kB/s
A: 19600 bytes sent-> 6.533 kB/s
A: 19600 bytes sent-> 6.533 kB/s
A: 19600 bytes sent-> 6.468 kB/s
A: 20000 bytes sent-> 6.666 kB/s
A: 20000 bytes sent-> 6.538 kB/s
A: 20000 bytes sent-> 6.600 kB/s
A: 20000 bytes sent-> 6.600 kB/s
A: 19600 bytes sent-> 6.468 kB/s
A: 20000 bytes sent-> 6.666 kB/s
A: 19600 bytes sent-> 6.533 kB/s
A: 19600 bytes sent-> 6.533 kB/s
A: 20000 bytes sent-> 6.600 kB/s
A: 20000 bytes sent-> 6.602 kB/s
A: 19200 bytes sent-> 6.400 kB/s
A: 19600 bytes sent-> 6.468 kB/s
A: 19600 bytes sent-> 6.533 kB/s
A: 19200 bytes sent-> 6.400 kB/s
A: 20000 bytes sent-> 6.666 kB/s
A: 19600 bytes sent-> 6.533 kB/s
A: 19800 bytes sent-> 6.600 kB/s
It does however seem like something is broken with updating the connection parameters, as commenting out `gap_request_connection_parameter_update(con_handle, 12, 12, 0, 0x0048);` is enough to make it run. I actually found this myself too when i was looking for ways to increase my connection interval, but just assumed i was doing something wrong when it hung. @peterharperuk Do you want this raised as a separate issue, or just kept here? I have no idea where that problem lies as it is just something i have found by testing. @mringwal here is the output with that line commented out ``` BTstack up and running on 43:43:A2:12:1F:AC. To start the streaming, please run the le_streamer_client example on other device, or use some GATT Explorer, e.g. LightBlue, BLExplr. A: ATT connected, handle 0x0040, test data len 20 - LE Connection 0x0040: connected - connection interval 30.00 ms, latency 4 - LE Connection 0x0040: request 15 ms connection interval A: ATT MTU = 1688 => use test data of len 200 A: Notifications enabled 1 A: 21000 bytes sent-> 6.930 kB/s A: 19600 bytes sent-> 6.533 kB/s A: 19600 bytes sent-> 6.533 kB/s A: 19600 bytes sent-> 6.468 kB/s A: 20000 bytes sent-> 6.666 kB/s A: 20000 bytes sent-> 6.538 kB/s A: 20000 bytes sent-> 6.600 kB/s A: 20000 bytes sent-> 6.600 kB/s A: 19600 bytes sent-> 6.468 kB/s A: 20000 bytes sent-> 6.666 kB/s A: 19600 bytes sent-> 6.533 kB/s A: 19600 bytes sent-> 6.533 kB/s A: 20000 bytes sent-> 6.600 kB/s A: 20000 bytes sent-> 6.602 kB/s A: 19200 bytes sent-> 6.400 kB/s A: 19600 bytes sent-> 6.468 kB/s A: 19600 bytes sent-> 6.533 kB/s A: 19200 bytes sent-> 6.400 kB/s A: 20000 bytes sent-> 6.666 kB/s A: 19600 bytes sent-> 6.533 kB/s A: 19800 bytes sent-> 6.600 kB/s ```
sanjay900 commented 2023-04-12 05:40:12 -05:00 (Migrated from github.com)

@peterharperuk did anybody complain about all pico w using the same BD ADDR? In @sanjay900's logs, both have 43:43:A2:12:1F:AC - the first 6 hex digits indicate the used controller, a 4343A2.

I don't remember exactly, but BTstack avoids connections to devices with the same BD ADDR, as that allows for some sneaky security hacks.

@sanjay900 Thanks for trying. I can check myself tomorrow or Friday.

@mringwal
I know there are fixes for that in the develop branch, and I also had that thought myself but i ran my hid code with the develop branch and didn't really find it affected anything.

To run these examples I just pulled the pico-examples repo down for running these tests, which grabbed the currently released SDK which doesn't have the fix for BT addresses.

> @peterharperuk did anybody complain about all pico w using the same BD ADDR? In @sanjay900's logs, both have 43:43:A2:12:1F:AC - the first 6 hex digits indicate the used controller, a 4343A2. > > I don't remember exactly, but BTstack avoids connections to devices with the same BD ADDR, as that allows for some sneaky security hacks. > > @sanjay900 Thanks for trying. I can check myself tomorrow or Friday. @mringwal I know there are fixes for that in the develop branch, and I also had that thought myself but i ran my hid code with the develop branch and didn't really find it affected anything. To run these examples I just pulled the pico-examples repo down for running these tests, which grabbed the currently released SDK which doesn't have the fix for BT addresses.
peterharperuk commented 2023-04-12 06:10:27 -05:00 (Migrated from github.com)

Yes 43:43:A2:12:1F:AC is the default btstack address (hardcoded in the infineon firmware to always be the same). I have a fix on develop that makes sure the btstack address is +1 the wifi mac address.

However I still haven't got to the bottom of why this issue is happening. I was unsure if it was because the OTP had not been set in the factory or if we had devices with duplicate addresses. @sanjay900 I would appreciate it if I could see the lines that say something like this for both the devices you have...

Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb9
cyw43 loaded ok, mac 28:cd:c1:07:86:f7
BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed
BTstack up and running on 28:CD:C1:07:86:F8.
Yes 43:43:A2:12:1F:AC is the default btstack address (hardcoded in the infineon firmware to always be the same). I have a fix on develop that makes sure the btstack address is +1 the wifi mac address. However I still haven't got to the bottom of why this issue is happening. I was unsure if it was because the OTP had not been set in the factory or if we had devices with duplicate addresses. @sanjay900 I would appreciate it if I could see the lines that say something like this for both the devices you have... ``` Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb9 cyw43 loaded ok, mac 28:cd:c1:07:86:f7 BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed BTstack up and running on 28:CD:C1:07:86:F8. ```
sanjay900 commented 2023-04-12 06:13:31 -05:00 (Migrated from github.com)

Yes 43:43:A2:12:1F:AC is the default btstack address (hardcoded in the infineon firmware to always be the same). I have a fix on develop that makes sure the btstack address is +1 the wifi mac address.

However I still haven't got to the bottom of why this issue is happening. I was unsure if it was because the OTP had not been set in the factory or if we had devices with duplicate addresses. @sanjay900 I would appreciate it if I could see the lines that say something like this for both the devices you have...

Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb9
cyw43 loaded ok, mac 28:cd:c1:07:86:f7
BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed
BTstack up and running on 28:CD:C1:07:86:F8.

what defines do i need to set to make those lines show up?

> Yes 43:43:A2:12:1F:AC is the default btstack address (hardcoded in the infineon firmware to always be the same). I have a fix on develop that makes sure the btstack address is +1 the wifi mac address. > > However I still haven't got to the bottom of why this issue is happening. I was unsure if it was because the OTP had not been set in the factory or if we had devices with duplicate addresses. @sanjay900 I would appreciate it if I could see the lines that say something like this for both the devices you have... > > ``` > Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb9 > cyw43 loaded ok, mac 28:cd:c1:07:86:f7 > BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed > BTstack up and running on 28:CD:C1:07:86:F8. > ``` what defines do i need to set to make those lines show up?
sanjay900 commented 2023-04-12 06:20:42 -05:00 (Migrated from github.com)

@peterharperuk I can get the outputs for one of them now, and ill hook up a UART to the other one tomorrow. If it helps i can test the other ones i have as well?

Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb0879
cyw43 loaded ok, mac 28:cd:c1:07:b7:95
BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed
BTstack up and running on 43:43:A2:12:1F:AC.
To start the streaming, please run the le_streamer_client example on other device, or use some GATT Explorer, e.g. LightBlue, BLExplr.
@peterharperuk I can get the outputs for one of them now, and ill hook up a UART to the other one tomorrow. If it helps i can test the other ones i have as well? ``` Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb0879 cyw43 loaded ok, mac 28:cd:c1:07:b7:95 BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed BTstack up and running on 43:43:A2:12:1F:AC. To start the streaming, please run the le_streamer_client example on other device, or use some GATT Explorer, e.g. LightBlue, BLExplr. ```
peterharperuk commented 2023-04-12 06:38:40 -05:00 (Migrated from github.com)

@sanjay900 thanks. It seems that OTP is set in your device, but for some reason the bt device address is not set. This is isn't the case with the devices I have suggesting something has changed in the factory.

@sanjay900 thanks. It seems that OTP is set in your device, but for some reason the bt device address is not set. This is isn't the case with the devices I have suggesting something has changed in the factory.
mringwal commented 2023-04-12 06:56:59 -05:00 (Migrated from github.com)

@sanjay900 good idea to skip the conn param update. With 30 ms and about 6.5 kB/s, we end up with 200 bytes per connection interval, which would indicate a single packet with 200 bytes (if DLE is supported and I think it is).

@sanjay900 good idea to skip the conn param update. With 30 ms and about 6.5 kB/s, we end up with 200 bytes per connection interval, which would indicate a single packet with 200 bytes (if DLE is supported and I think it is).
sanjay900 commented 2023-04-12 15:17:36 -05:00 (Migrated from github.com)

@mringwal Out of curiosity, any idea why the conn param update breaks things?

@mringwal Out of curiosity, any idea why the conn param update breaks things?
sanjay900 commented 2023-04-12 16:49:31 -05:00 (Migrated from github.com)

I figured id try running the le_streamer_client on my pc using the libusb port, with a pico w running the gatt_streamer_server, and got this result:

Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb0879
cyw43 loaded ok, mac 28:cd:c1:07:b7:95
BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed
BTstack up and running on 43:43:A2:12:1F:AC.
To start the streaming, please run the le_streamer_client example on other device, or use some GATT Explorer, e.g. LightBlue, BLExplr.
A: ATT connected, handle 0x0040, test data len 20
- LE Connection 0x0040: connected - connection interval 30.00 ms, latency 4
- LE Connection 0x0040: request 15 ms connection interval
A: ATT MTU = 1688 => use test data of len 200
A: Notifications enabled 1
A: 97200 bytes sent-> 32.324 kB/s
A: 95000 bytes sent-> 31.666 kB/s
A: 87400 bytes sent-> 29.055 kB/s
A: 86800 bytes sent-> 28.770 kB/s
A: 94000 bytes sent-> 31.281 kB/s
A: 90000 bytes sent-> 30.000 kB/s

Here are the results if i run the gatt_streamer_server on my pc with the libusb port and the le_streamer_client on my pico w:

Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb0879
cyw43 loaded ok, mac 28:cd:c1:07:b7:95
BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed
BTstack up and running on 43:43:A2:12:1F:AC.
Start scanning!
Stop scan. Connect to device with addr 00:15:83:ED:65:E8.
Connection Interval: 30.00 ms
Connection Latency: 4
Search for LE Streamer service.
SERVICE_QUERY_RESULT, ATT Error 0x1f.
Disconnected 00:15:83:ED:65:E8
Start scanning!
Stop scan. Connect to device with addr 00:15:83:ED:65:E8.
Connection Interval: 30.00 ms
Connection Latency: 4
Search for LE Streamer service.
Search for LE Streamer RX characteristic.
Search for LE Streamer TX characteristic.
A: ATT MTU = 1691 => use test data of len 200
Start streaming - enable notify on test characteristic.
Notifications enabled, ATT status 0x00
A: 16800 bytes -> 5.586 kB/s
A: 18400 bytes -> 6.131 kB/s
A: 18600 bytes -> 6.200 kB/s
A: 18600 bytes -> 6.154 kB/s
A: 19400 bytes -> 6.449 kB/s
A: 19000 bytes -> 6.333 kB/s
A: 19000 bytes -> 6.333 kB/s
A: 19200 bytes -> 6.400 kB/s
A: 19400 bytes -> 6.402 kB/s
A: 19400 bytes -> 6.466 kB/s
A: 18600 bytes -> 6.200 kB/s
A: 19000 bytes -> 6.285 kB/s
A: 20000 bytes -> 6.648 kB/s
A: 18800 bytes -> 6.266 kB/s
A: 19200 bytes -> 6.351 kB/s
A: 18400 bytes -> 6.119 kB/s
A: 19200 bytes -> 6.400 kB/s
A: 19600 bytes -> 6.533 kB/s

Interestingly, even when running the gatt_streamer_server on my pc with the libusb port, I still needed to comment out the conn param line for the connection to work

I figured id try running the `le_streamer_client` on my pc using the libusb port, with a pico w running the `gatt_streamer_server`, and got this result: ``` Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb0879 cyw43 loaded ok, mac 28:cd:c1:07:b7:95 BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed BTstack up and running on 43:43:A2:12:1F:AC. To start the streaming, please run the le_streamer_client example on other device, or use some GATT Explorer, e.g. LightBlue, BLExplr. A: ATT connected, handle 0x0040, test data len 20 - LE Connection 0x0040: connected - connection interval 30.00 ms, latency 4 - LE Connection 0x0040: request 15 ms connection interval A: ATT MTU = 1688 => use test data of len 200 A: Notifications enabled 1 A: 97200 bytes sent-> 32.324 kB/s A: 95000 bytes sent-> 31.666 kB/s A: 87400 bytes sent-> 29.055 kB/s A: 86800 bytes sent-> 28.770 kB/s A: 94000 bytes sent-> 31.281 kB/s A: 90000 bytes sent-> 30.000 kB/s ``` Here are the results if i run the `gatt_streamer_server` on my pc with the libusb port and the `le_streamer_client` on my pico w: ``` Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb0879 cyw43 loaded ok, mac 28:cd:c1:07:b7:95 BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed BTstack up and running on 43:43:A2:12:1F:AC. Start scanning! Stop scan. Connect to device with addr 00:15:83:ED:65:E8. Connection Interval: 30.00 ms Connection Latency: 4 Search for LE Streamer service. SERVICE_QUERY_RESULT, ATT Error 0x1f. Disconnected 00:15:83:ED:65:E8 Start scanning! Stop scan. Connect to device with addr 00:15:83:ED:65:E8. Connection Interval: 30.00 ms Connection Latency: 4 Search for LE Streamer service. Search for LE Streamer RX characteristic. Search for LE Streamer TX characteristic. A: ATT MTU = 1691 => use test data of len 200 Start streaming - enable notify on test characteristic. Notifications enabled, ATT status 0x00 A: 16800 bytes -> 5.586 kB/s A: 18400 bytes -> 6.131 kB/s A: 18600 bytes -> 6.200 kB/s A: 18600 bytes -> 6.154 kB/s A: 19400 bytes -> 6.449 kB/s A: 19000 bytes -> 6.333 kB/s A: 19000 bytes -> 6.333 kB/s A: 19200 bytes -> 6.400 kB/s A: 19400 bytes -> 6.402 kB/s A: 19400 bytes -> 6.466 kB/s A: 18600 bytes -> 6.200 kB/s A: 19000 bytes -> 6.285 kB/s A: 20000 bytes -> 6.648 kB/s A: 18800 bytes -> 6.266 kB/s A: 19200 bytes -> 6.351 kB/s A: 18400 bytes -> 6.119 kB/s A: 19200 bytes -> 6.400 kB/s A: 19600 bytes -> 6.533 kB/s ``` Interestingly, even when running the `gatt_streamer_server` on my pc with the libusb port, I still needed to comment out the conn param line for the connection to work
sanjay900 commented 2023-04-12 17:05:11 -05:00 (Migrated from github.com)

@peterharperuk not sure if you still need this but heres that line from the other pico:
I was wrong i did only buy just these two.

Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb0879
cyw43 loaded ok, mac 28:cd:c1:07:b8:11
BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed
BTstack up and running on 43:43:A2:12:1F:AC.
To start the streaming, please run the le_streamer_client example on other device, or use some GATT Explorer, e.g. LightBlue, BLExplr.
@peterharperuk not sure if you still need this but heres that line from the other pico: I was wrong i did only buy just these two. ``` Version: 7.95.61 (abcd531 CY) CRC: 4528a809 Date: Wed 2023-01-11 10:29:38 PST Ucode Ver: 1043.2169 FWID 01-7afb0879 cyw43 loaded ok, mac 28:cd:c1:07:b8:11 BT FW download, version = CYW4343A2_001.003.016.0031.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed BTstack up and running on 43:43:A2:12:1F:AC. To start the streaming, please run the le_streamer_client example on other device, or use some GATT Explorer, e.g. LightBlue, BLExplr. ```
sanjay900 commented 2023-04-13 03:39:37 -05:00 (Migrated from github.com)

If there is anything else i can provide let me know

If there is anything else i can provide let me know
mringwal commented 2023-04-13 05:33:44 -05:00 (Migrated from github.com)

@mringwal Out of curiosity, any idea why the conn param update breaks things?

Well, the controllers seem to fail in synchronizing the change. You can try to use slave latency = 4 with the connection interval = 15 ms, too.

> @mringwal Out of curiosity, any idea why the conn param update breaks things? Well, the controllers seem to fail in synchronizing the change. You can try to use slave latency = 4 with the connection interval = 15 ms, too.
mringwal commented 2023-04-15 05:07:55 -05:00 (Migrated from github.com)

Minor update: I've repeated the test with le_streamer_client on Pico W and gatt_streamer_server on my Mac with an USB CSR8510 dongle and as able to get a air trace using our Raccoon nRF5x sniffer.

I get the same (low) throughput. Interestingly, as the CSR8510 does not support DLE, the 200 bytes test packets are split into several smaller packets over the air. Still, only one of these packets are send per connection interval. The packets indicate that the peripheral (CSR8510) always has data to send, but the central (pico_w) does not/cannot receive it. While not impossible, I cannot imagine that the CYW43 can only receive this 200 bytes per connection interval. Quick test replacing the pico_w/cyw43439 with a CYW20704 on my Mac, I get 25 kB/s as well.

My hypothesis here is that they get stuck in the CYW43 on the Pico W. Will review the code a bit more to see if we can more details on this.

Minor update: I've repeated the test with le_streamer_client on Pico W and gatt_streamer_server on my Mac with an USB CSR8510 dongle and as able to get a air trace using our Raccoon nRF5x sniffer. I get the same (low) throughput. Interestingly, as the CSR8510 does not support DLE, the 200 bytes test packets are split into several smaller packets over the air. Still, only one of these packets are send per connection interval. The packets indicate that the peripheral (CSR8510) always has data to send, but the central (pico_w) does not/cannot receive it. While not impossible, I cannot imagine that the CYW43 can only receive this 200 bytes per connection interval. Quick test replacing the pico_w/cyw43439 with a CYW20704 on my Mac, I get 25 kB/s as well. My hypothesis here is that they get stuck in the CYW43 on the Pico W. Will review the code a bit more to see if we can more details on this.
sanjay900 commented 2023-04-15 05:20:46 -05:00 (Migrated from github.com)

Thanks for looking into it :)

Thanks for looking into it :)
mringwal commented 2023-04-17 04:33:14 -05:00 (Migrated from github.com)

To get deeper, I've reviewed the code (no issues there) and toggled a GPIO while in a) hci_transport_cyw43_process, b) cyw43_bluetooth_hci_read, and c) the processing in BTstack. Please see attached traces.

When testing against a CYW20704, I did get 66 kB/s when sending 200 byte packets. With lower packet sizes, the throughput goes down. One fact is that the CYW20704 has 8 buffers for LE ACL packets. If we receive them faster than we can read the with the RP2040, this could be a bottleneck.

@peterharperuk : in the traces for smaller packet sizes, hci_transport_cyw43_process is entered, but cyw43_bluetooth_hci_read seems to report no data to read. I don't know what to make of that.

@sanjay900 : what's your project requirements? Is it pico<->pico only? You can 'play' with the connection interval and the packet size (e.g. sending multiple reports in one packet if you don't need to comply to a standard). You could also try to use Bluetooth Classic HID to see if that works better for your case.

I still don't know what's really going on. One idea would be to ask Infineon if they can increase the number of LE ACL buffers (right not 8 x 251 ~ 2 kB are used and the Controller should have way more memory). e.g. 16 buffers? :0) this might help. I've also tried shorted connection intervals and in one session just got broken links while in another, it worked as expected with the same hardware on my table.

traces.zip

To get deeper, I've reviewed the code (no issues there) and toggled a GPIO while in a) hci_transport_cyw43_process, b) cyw43_bluetooth_hci_read, and c) the processing in BTstack. Please see attached traces. When testing against a CYW20704, I did get 66 kB/s when sending 200 byte packets. With lower packet sizes, the throughput goes down. One fact is that the CYW20704 has 8 buffers for LE ACL packets. If we receive them faster than we can read the with the RP2040, this could be a bottleneck. @peterharperuk : in the traces for smaller packet sizes, hci_transport_cyw43_process is entered, but cyw43_bluetooth_hci_read seems to report no data to read. I don't know what to make of that. @sanjay900 : what's your project requirements? Is it pico<->pico only? You can 'play' with the connection interval and the packet size (e.g. sending multiple reports in one packet if you don't need to comply to a standard). You could also try to use Bluetooth Classic HID to see if that works better for your case. I still don't know what's really going on. One idea would be to ask Infineon if they can increase the number of LE ACL buffers (right not 8 x 251 ~ 2 kB are used and the Controller should have way more memory). e.g. 16 buffers? :0) this might help. I've also tried shorted connection intervals and in one session just got broken links while in another, it worked as expected with the same hardware on my table. [traces.zip](https://github.com/raspberrypi/pico-sdk/files/11248539/traces.zip)
sanjay900 commented 2023-04-17 04:45:40 -05:00 (Migrated from github.com)

@mringwal If i can i would like to stick with something HID based, as my goal is for my game controller to still work with a PC normally, and then for the pico <-> pico bit to be only necessary if a user would like to use their controller on a game console.

I originally tried bluetooth classic but it seems that had a lower latency even with just a PC when i tried that originally, but i didn't actually change any settings from the defaults in the classic examples.

@mringwal If i can i would like to stick with something HID based, as my goal is for my game controller to still work with a PC normally, and then for the pico <-> pico bit to be only necessary if a user would like to use their controller on a game console. I originally tried bluetooth classic but it seems that had a lower latency even with just a PC when i tried that originally, but i didn't actually change any settings from the defaults in the classic examples.
mringwal commented 2023-04-17 04:47:13 -05:00 (Migrated from github.com)

@sanjay900 In that case, I would suggest to try the Classic HID examples :)

@sanjay900 In that case, I would suggest to try the Classic HID examples :)
sanjay900 commented 2023-04-17 04:49:25 -05:00 (Migrated from github.com)

Ill give that a go again tomorrow and see if i can work out a way to get them working at a decent speed.

Ill give that a go again tomorrow and see if i can work out a way to get them working at a decent speed.
sanjay900 commented 2023-04-18 05:24:28 -05:00 (Migrated from github.com)

it seems going to classic HID cuts the poll rate to around 374hz with a pc, though thats just using the default hid example, are there things i can tweak there to get a lower latency out of it?

it seems going to classic HID cuts the poll rate to around 374hz with a pc, though thats just using the default hid example, are there things i can tweak there to get a lower latency out of it?
mringwal commented 2023-04-18 05:27:21 -05:00 (Migrated from github.com)

Well, that's one report every 3 ms. isn't that good enough? :)
you can compare to same code with libusb.

Well, that's one report every 3 ms. isn't that good enough? :) you can compare to same code with libusb.
sanjay900 commented 2023-04-18 05:29:06 -05:00 (Migrated from github.com)

See it would be if BLE wasn't giving me 850hz haha
These controllers are being used for rhythm games so the lower the better really

See it would be if BLE wasn't giving me 850hz haha These controllers are being used for rhythm games so the lower the better really
sanjay900 commented 2023-04-29 03:23:30 -05:00 (Migrated from github.com)

Is it possible to ask infineon if they have any idea whats going on / if they can increase the number of LE ACL buffers?

Is it possible to ask infineon if they have any idea whats going on / if they can increase the number of LE ACL buffers?
mringwal commented 2023-04-29 04:15:17 -05:00 (Migrated from github.com)

Hi

What about this: the problem only happens when receiving on the Pico W. If you receive HOG from your PC it's fine, right?
In this case, you could provide a separate mode for Pico W <-> Pico W communication. Instead of sending a single report in single packet, you could add a second 'Burst HOG Service' where multiple reports are send in a single packet (up to 250 bytes..). By that, you should be able to send even more reports per second than previously.

best
Matthias

On 29 Apr 2023, at 10:23, Sanjay Govind @.***> wrote:

Is it possible to ask infineon if they have any idea whats going on / if they can increase the number of LE ACL buffers?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

Hi What about this: the problem only happens when receiving on the Pico W. If you receive HOG from your PC it's fine, right? In this case, you could provide a separate mode for Pico W <-> Pico W communication. Instead of sending a single report in single packet, you could add a second 'Burst HOG Service' where multiple reports are send in a single packet (up to 250 bytes..). By that, you should be able to send even more reports per second than previously. best Matthias > On 29 Apr 2023, at 10:23, Sanjay Govind ***@***.***> wrote: > > > Is it possible to ask infineon if they have any idea whats going on / if they can increase the number of LE ACL buffers? > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you were mentioned.Message ID: ***@***.***>
sanjay900 commented 2023-04-29 04:30:02 -05:00 (Migrated from github.com)

ill see if i can figure out how to do that and give it a go, are there any examples of doing anything remotely similar to this?

ill see if i can figure out how to do that and give it a go, are there any examples of doing anything remotely similar to this?
mringwal commented 2023-04-29 04:32:41 -05:00 (Migrated from github.com)

nothing that contains the logic, but the gatt_streamer_server and le_streamer_client show how to send data as fast as possible. You only need the notifications on the server side.

For your use case, you can follow le streamer and try to check if the streamer service is available. If yes, you use that. If not, you use the existing hog client as before.

On 29 Apr 2023, at 11:30, Sanjay Govind @.***> wrote:

ill see if i can figure out how to do that and give it a go, are there any examples of doing anything remotely similar to this?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

nothing that contains the logic, but the gatt_streamer_server and le_streamer_client show how to send data as fast as possible. You only need the notifications on the server side. For your use case, you can follow le streamer and try to check if the streamer service is available. If yes, you use that. If not, you use the existing hog client as before. > On 29 Apr 2023, at 11:30, Sanjay Govind ***@***.***> wrote: > > > ill see if i can figure out how to do that and give it a go, are there any examples of doing anything remotely similar to this? > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you were mentioned.Message ID: ***@***.***>
peterharperuk commented 2023-05-02 05:37:35 -05:00 (Migrated from github.com)

Is it possible to ask infineon if they have any idea whats going on / if they can increase the number of LE ACL buffers?

If someone can summarise the problem and question we need to ask, I can send something to Infineon.

> Is it possible to ask infineon if they have any idea whats going on / if they can increase the number of LE ACL buffers? If someone can summarise the problem and question we need to ask, I can send something to Infineon.
mringwal commented 2023-05-03 03:37:31 -05:00 (Migrated from github.com)

Ok, let me try.

When trying to send many small packets (e.g. HID reports over GATT), the CYW43439 receives less than expected - the connection interval isn't fully used even when using the minimal connection interval of 7.5 ms. An air trace shows that CYW43439 in Central role ends the connection event.

Our hypothesis here is that we cannot get the packets out of the Controller via the shared bus fast enough which causes all incoming ACL buffers to get full. When sending larger data, we can achieve optimal throughput. From HCI log, it looks like there are current 8 ACL LE buffers of 251 bytes. Is there any RAM left to increase the numbers of buffers, e.g. to double the numbers of buffers to validate this hypothesis?

Ok, let me try. When trying to send many small packets (e.g. HID reports over GATT), the CYW43439 receives less than expected - the connection interval isn't fully used even when using the minimal connection interval of 7.5 ms. An air trace shows that CYW43439 in Central role ends the connection event. Our hypothesis here is that we cannot get the packets out of the Controller via the shared bus fast enough which causes all incoming ACL buffers to get full. When sending larger data, we can achieve optimal throughput. From HCI log, it looks like there are current 8 ACL LE buffers of 251 bytes. Is there any RAM left to increase the numbers of buffers, e.g. to double the numbers of buffers to validate this hypothesis?
sanjay900 commented 2023-05-05 21:37:58 -05:00 (Migrated from github.com)

@mringwal thanks for that
@peterharperuk thank you, have you had a chance to send any comms to infineon yet?

@mringwal thanks for that @peterharperuk thank you, have you had a chance to send any comms to infineon yet?
peterharperuk commented 2023-05-09 07:40:19 -05:00 (Migrated from github.com)

No - I'll do it now.

No - I'll do it now.
sanjay900 commented 2023-05-09 21:39:29 -05:00 (Migrated from github.com)

Thank you

Thank you
peterharperuk commented 2023-05-10 04:31:12 -05:00 (Migrated from github.com)

Would you guys be able to test this updated firmware? https://github.com/peterharperuk/cyw43-driver/tree/Updated_BLE_ACL_Config

Please just use this for testing. It seems faster to me but I'm not sure how to test for your use case. You will have to go into pico-sdk/lib/cyw43-driver and checkout the Updated_BLE_ACL_Config branch from my repo. In debug on boot it should say the following...

BT FW download, version = CYW4343A2_001.003.016.0058.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed + Updated BLE ACL Config

They say it "has host_claim_host_to_device_count, host_to_device_count and device_to_host_count updated value to 16 (from default value 8)."

Would you guys be able to test this updated firmware? https://github.com/peterharperuk/cyw43-driver/tree/Updated_BLE_ACL_Config Please just use this for testing. It seems faster to me but I'm not sure how to test for your use case. You will have to go into pico-sdk/lib/cyw43-driver and checkout the Updated_BLE_ACL_Config branch from my repo. In debug on boot it should say the following... BT FW download, version = CYW4343A2_001.003.016.0058.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed + **Updated BLE ACL Config** They say it "has host_claim_host_to_device_count, host_to_device_count and device_to_host_count updated value to 16 (from default value 8)."
sanjay900 commented 2023-05-10 07:18:31 -05:00 (Migrated from github.com)

I used this version of the firmware but unfortunately it does not appear to have fixed the problem.

I used this version of the firmware but unfortunately it does not appear to have fixed the problem.
mringwal commented 2023-05-10 07:31:25 -05:00 (Migrated from github.com)

@sanjay900 Could you provide some measurements? If you're using the HOG device/host: how man HID reports are sent/received per connection interval? how many bytes are in one report?
Would you have a packet log with the test firmware?

@sanjay900 Could you provide some measurements? If you're using the HOG device/host: how man HID reports are sent/received per connection interval? how many bytes are in one report? Would you have a packet log with the test firmware?
mringwal commented 2023-05-10 10:24:40 -05:00 (Migrated from github.com)

@mringwal Out of curiosity, any idea why the conn param update breaks things?

Well, I might have now. BTstack was using a max ce length of 0xffff and while nobody really knows what this value is used for, it looks like 0xffff causes a disconnect, while all other values are ok.

Could you update to the current BTstack develop branch (which uses max ce length = 0) and verify that the conn param update works now?

> @mringwal Out of curiosity, any idea why the conn param update breaks things? Well, I might have now. BTstack was using a max ce length of 0xffff and while nobody really knows what this value is used for, it looks like 0xffff causes a disconnect, while all other values are ok. Could you update to the current BTstack develop branch (which uses max ce length = 0) and verify that the conn param update works now?
sanjay900 commented 2023-05-10 15:43:58 -05:00 (Migrated from github.com)

@sanjay900 Could you provide some measurements? If you're using the HOG device/host: how man HID reports are sent/received per connection interval? how many bytes are in one report? Would you have a packet log with the test firmware?

With HOG device/host, it is still just one packet per interval. I don't really have a easy way to get a packet log, but there are 27 bytes per report.

> @sanjay900 Could you provide some measurements? If you're using the HOG device/host: how man HID reports are sent/received per connection interval? how many bytes are in one report? Would you have a packet log with the test firmware? With HOG device/host, it is still just one packet per interval. I don't really have a easy way to get a packet log, but there are 27 bytes per report.
mringwal commented 2023-05-10 15:46:55 -05:00 (Migrated from github.com)

With HOG device/host, it is still just one packet per interval. I don't really have a easy way to get a packet log, but there are 27 bytes per report.

Thanks, that's a start. Which connection interval is this? And how many packets do you get per conn interval on the PC with the same connection interval?

> With HOG device/host, it is still just one packet per interval. I don't really have a easy way to get a packet log, but there are 27 bytes per report. Thanks, that's a start. Which connection interval is this? And how many packets do you get per conn interval on the PC with the same connection interval?
sanjay900 commented 2023-05-11 05:27:39 -05:00 (Migrated from github.com)

@mringwal Can confirm, using the latest develop branch did fix the conn param update. With that, i set my transmitter to request a 7.5ms interval with a latency of 0.

For testing, i have just been emulating a gamepad, and assigning a random value to the joystick, and this then ends up sending out a new report as often as possible. With the hog/host, i have then been emulating a usb gamepad and feeding all bluetooth inputs directly to it.

For HOG device/host, i end up with a average poll rate of 129hz or so, which ends up being close to around 1 packet per 7.5ms interval

For HOG device/pc, i end up with an average poll rate of around 750hz, which ends up being just over 5 and a half packets per interval

@mringwal Can confirm, using the latest develop branch did fix the conn param update. With that, i set my transmitter to request a 7.5ms interval with a latency of 0. For testing, i have just been emulating a gamepad, and assigning a random value to the joystick, and this then ends up sending out a new report as often as possible. With the hog/host, i have then been emulating a usb gamepad and feeding all bluetooth inputs directly to it. For HOG device/host, i end up with a average poll rate of 129hz or so, which ends up being close to around 1 packet per 7.5ms interval For HOG device/pc, i end up with an average poll rate of around 750hz, which ends up being just over 5 and a half packets per interval
mringwal commented 2023-05-11 05:48:15 -05:00 (Migrated from github.com)

Did you check if 7.5 ms connection interval was used in both cases?

Did you check if 7.5 ms connection interval was used in both cases?
sanjay900 commented 2023-05-11 06:05:52 -05:00 (Migrated from github.com)

Yeah, i have the firmware printing out the connection params

BT FW download, version = CYW4343A2_001.003.016.0058.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed + Updated BLE ACL Config
LE Connection Complete:
- Connection Interval: 30.00 ms
- Connection Latency: 4
Just works requested
Pairing complete, success
Search for HID service.
HID service client connected, found 1 services
Ready - receiving data
LE Connection Update:
- Connection Interval: 7.50 ms
- Connection Latency: 0

And if the connection interval is different with the HOG host, than the poll rate also suffers with the exact relationship youd expect for a single packet per interval

Yeah, i have the firmware printing out the connection params ``` BT FW download, version = CYW4343A2_001.003.016.0058.0000_Generic_SDIO_37MHz_wlbga_BU_dl_signed + Updated BLE ACL Config LE Connection Complete: - Connection Interval: 30.00 ms - Connection Latency: 4 Just works requested Pairing complete, success Search for HID service. HID service client connected, found 1 services Ready - receiving data LE Connection Update: - Connection Interval: 7.50 ms - Connection Latency: 0 ``` And if the connection interval is different with the HOG host, than the poll rate also suffers with the exact relationship youd expect for a single packet per interval
sanjay900 commented 2023-05-19 07:13:09 -05:00 (Migrated from github.com)

@mringwal were there possibly any settings in btstack_config.h that i should play around with with the new firmware?

@mringwal were there possibly any settings in `btstack_config.h` that i should play around with with the new firmware?
mringwal commented 2023-05-22 02:20:06 -05:00 (Migrated from github.com)

@sanjay900 No, there aren't. I'd need to get an air trace to confirm that it's still the central side that slows down, then the question is why. I was busy with other stuff though.

@sanjay900 No, there aren't. I'd need to get an air trace to confirm that it's still the central side that slows down, then the question is why. I was busy with other stuff though.
kilograham commented 2023-05-26 13:01:48 -05:00 (Migrated from github.com)

@peterharperuk should this be in 1.5.1 milestone?

@peterharperuk should this be in 1.5.1 milestone?
sanjay900 commented 2023-06-10 22:00:37 -05:00 (Migrated from github.com)

@mringwal have you had a chance to grab an air trace? Sorry that i can't help there i don't have the tools for that myself

@mringwal have you had a chance to grab an air trace? Sorry that i can't help there i don't have the tools for that myself
peterharperuk commented 2023-06-13 04:01:16 -05:00 (Migrated from github.com)

@kilograham No - it shouldn't be on 1.5.1

@kilograham No - it shouldn't be on 1.5.1
mringwal commented 2023-06-13 04:19:17 -05:00 (Migrated from github.com)

@sanjay900 Sorry, nope, was busy otherwise.

How urgent is this for your project? Could you use a custom solution, e.g. sending multiple reports in a single notification to get full throughput if the connection is between two Pico Ws for the time being.

It's unclear what exactly is causing this (stack, interface to controller, controller itself, radio link). The air trace might narrow this a bit down.

@sanjay900 Sorry, nope, was busy otherwise. How urgent is this for your project? Could you use a custom solution, e.g. sending multiple reports in a single notification to get full throughput if the connection is between two Pico Ws for the time being. It's unclear what exactly is causing this (stack, interface to controller, controller itself, radio link). The air trace might narrow this a bit down.
sanjay900 commented 2023-06-13 04:20:35 -05:00 (Migrated from github.com)

Yeah for the moment I'll do something custom, was just curious if you'd had
any time to look into it or not

On Tue, 13 Jun 2023, 9:19 pm Matthias Ringwald, @.***>
wrote:

@sanjay900 https://github.com/sanjay900 Sorry, nope, was busy otherwise.

How urgent is this for your project? Could you use a custom solution, e.g.
sending multiple reports in a single notification to get full throughput if
the connection is between two Pico Ws for the time being.

It's unclear what exactly is causing this (stack, interface to controller,
controller itself, radio link). The air trace might narrow this a bit down.

—
Reply to this email directly, view it on GitHub
https://github.com/raspberrypi/pico-sdk/issues/1342#issuecomment-1588891041,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOGYQCSEX2C2XZ4GST4RYTXLAWCBANCNFSM6AAAAAAW3JVOAU
.
You are receiving this because you were mentioned.Message ID:
@.***>

Yeah for the moment I'll do something custom, was just curious if you'd had any time to look into it or not On Tue, 13 Jun 2023, 9:19 pm Matthias Ringwald, ***@***.***> wrote: > @sanjay900 <https://github.com/sanjay900> Sorry, nope, was busy otherwise. > > How urgent is this for your project? Could you use a custom solution, e.g. > sending multiple reports in a single notification to get full throughput if > the connection is between two Pico Ws for the time being. > > It's unclear what exactly is causing this (stack, interface to controller, > controller itself, radio link). The air trace might narrow this a bit down. > > — > Reply to this email directly, view it on GitHub > <https://github.com/raspberrypi/pico-sdk/issues/1342#issuecomment-1588891041>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAOGYQCSEX2C2XZ4GST4RYTXLAWCBANCNFSM6AAAAAAW3JVOAU> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >
mringwal commented 2023-06-13 04:31:21 -05:00 (Migrated from github.com)

@sanjay900 I'm glad to hear. The nice folks at Raspberry will get to this as well, but there's the 1.5.1 release upcoming now - I've heard :)

@sanjay900 I'm glad to hear. The nice folks at Raspberry will get to this as well, but there's the 1.5.1 release upcoming now - I've heard :)
sanjay900 commented 2023-06-14 04:51:32 -05:00 (Migrated from github.com)

@sanjay900 I'm glad to hear. The nice folks at Raspberry will get to this as well, but there's the 1.5.1 release upcoming now - I've heard :)

Nice, good to hear they will get to it at some point

> @sanjay900 I'm glad to hear. The nice folks at Raspberry will get to this as well, but there's the 1.5.1 release upcoming now - I've heard :) Nice, good to hear they will get to it at some point
rppicomidi commented 2023-07-08 18:02:35 -05:00 (Migrated from github.com)

@mringwal Back on April 12, you said

"...which would indicate a single packet with 200 bytes (if DLE is supported and I think it is)."

Have you resolved whether DLE is supported? The documentation for the BlueKitchen stack says "Don't Know" for DLE support for the CYW43439. The file pico-examples/pico_w/bt/config/btstack_config.h does not contain #define ENABLE_LE_DATA_LENGTH_EXTENSION but the BlueKitchen btstack/port/raspi/btstack_config.h directory does. Is there some work to do to enable DLE that requires calling the HCI commands that ENABLE_LE_DATA_LENGTH_EXTENSION enables?

@mringwal Back on April 12, you said > "...which would indicate a single packet with 200 bytes (if DLE is supported and I think it is)." Have you resolved whether DLE is supported? The documentation for the BlueKitchen stack says "Don't Know" for DLE support for the CYW43439. The file `pico-examples/pico_w/bt/config/btstack_config.h` does not contain `#define ENABLE_LE_DATA_LENGTH_EXTENSION` but the BlueKitchen btstack/port/raspi/btstack_config.h directory does. Is there some work to do to enable DLE that requires calling the HCI commands that `ENABLE_LE_DATA_LENGTH_EXTENSION` enables?
mringwal commented 2023-07-10 09:48:58 -05:00 (Migrated from github.com)

@rppicomidi The 43439 supports DLE. I have a HCI trace which contains a LE Data Length Change to 251 bytes, which indicates that DLE has been activated for that connection.

You are correct that pico-examples/pico_w/bt/config/btstack_config.h does not defines ENABLE_LE_DATA_LENGTH_EXTENSION, which is needed for DLE. To enable DLE, you can add it to btstack_config.h yourself.

@peterharperuk could you add ENABLE_LE_DATA_LENGTH_EXTENSION to the default configuration in the pico-examples repo?

@rppicomidi The 43439 supports DLE. I have a HCI trace which contains a LE Data Length Change to 251 bytes, which indicates that DLE has been activated for that connection. You are correct that `pico-examples/pico_w/bt/config/btstack_config.h` does not defines `ENABLE_LE_DATA_LENGTH_EXTENSION`, which is needed for DLE. To enable DLE, you can add it to btstack_config.h yourself. @peterharperuk could you add `ENABLE_LE_DATA_LENGTH_EXTENSION` to the default configuration in the pico-examples repo?
peterharperuk commented 2023-07-10 09:59:03 -05:00 (Migrated from github.com)

Yes - I have raised this so I don't forget https://github.com/raspberrypi/pico-examples/issues/406

Yes - I have raised this so I don't forget https://github.com/raspberrypi/pico-examples/issues/406
rppicomidi commented 2023-07-10 16:51:37 -05:00 (Migrated from github.com)

@mringwal @peterharperuk Thank you!

@mringwal @peterharperuk Thank you!
sanjay900 commented 2023-07-13 23:10:51 -05:00 (Migrated from github.com)

@sanjay900 Sorry, nope, was busy otherwise.

How urgent is this for your project? Could you use a custom solution, e.g. sending multiple reports in a single notification to get full throughput if the connection is between two Pico Ws for the time being.

It's unclear what exactly is causing this (stack, interface to controller, controller itself, radio link). The air trace might narrow this a bit down.

@mringwal
how exactly would one send more than one report in a single notification?

> @sanjay900 Sorry, nope, was busy otherwise. > > How urgent is this for your project? Could you use a custom solution, e.g. sending multiple reports in a single notification to get full throughput if the connection is between two Pico Ws for the time being. > > It's unclear what exactly is causing this (stack, interface to controller, controller itself, radio link). The air trace might narrow this a bit down. @mringwal how exactly would one send more than one report in a single notification?
mringwal commented 2023-07-18 05:21:12 -05:00 (Migrated from github.com)

I've setup a test environment with a CSR8510 as Peripheral connected to my Mac and the Pico W with the CYW43439 in Central role.
The CSR8510 is an older Bluetooth v4.0 USB Bluetooth dongle, which does not support DLE or 2M-PHY, but is able to send the max amount of PDUs per connection interval (hence, it's trustworthy from my side).

The Peripheral is sending GATT notifications of 20 bytes, similar to the HID reports in the original issue, the Central only receives the Notifications.

With the new firmware, I got 500-900 packets per second, depending on the connection interval (30ms, 15ms, 7.5ms). With 15 m I got 850 and with 7.5 ms even 900 packets.
This is a reasonable number of packets per interval, and clearly more than one packet per interval.

@sanjay900 Could you try to repeat this with the firmware @peterharperuk posted above https://github.com/raspberrypi/pico-sdk/issues/1342#issuecomment-1541775040 and use the same settings for GATT Streamer as well as LE Streamer client?

  • le_streamer_client: receive only
    • #define TEST_MODE TEST_MODE_ENABLE_NOTIFICATIONS
  • gatt_streamer_server: 20 byte PDUs
    • limit packet size by changing the size of the test_data arary
    • char test_data[20];
I've setup a test environment with a CSR8510 as Peripheral connected to my Mac and the Pico W with the CYW43439 in Central role. The CSR8510 is an older Bluetooth v4.0 USB Bluetooth dongle, which does not support DLE or 2M-PHY, but is able to send the max amount of PDUs per connection interval (hence, it's trustworthy from my side). The Peripheral is sending GATT notifications of 20 bytes, similar to the HID reports in the original issue, the Central only receives the Notifications. With the new firmware, I got 500-900 packets per second, depending on the connection interval (30ms, 15ms, 7.5ms). With 15 m I got 850 and with 7.5 ms even 900 packets. This is a reasonable number of packets per interval, and clearly more than one packet per interval. @sanjay900 Could you try to repeat this with the firmware @peterharperuk posted above https://github.com/raspberrypi/pico-sdk/issues/1342#issuecomment-1541775040 and use the same settings for GATT Streamer as well as LE Streamer client? - le_streamer_client: receive only - #define TEST_MODE TEST_MODE_ENABLE_NOTIFICATIONS - gatt_streamer_server: 20 byte PDUs - limit packet size by changing the size of the test_data arary - char test_data[20];
peterharperuk commented 2023-07-18 05:28:33 -05:00 (Migrated from github.com)

Thanks @mringwal. Is the new firmware behaving better than the current release firmware?

Thanks @mringwal. Is the new firmware behaving better than the current release firmware?
mringwal commented 2023-07-18 05:30:22 -05:00 (Migrated from github.com)

@peterharperuk To be honest, I didn't go back. As mentioned in the support case, more buffers doesn't hurt. Would it help if repeat the same test with the firmware from master?

@peterharperuk To be honest, I didn't go back. As mentioned in the support case, more buffers doesn't hurt. Would it help if repeat the same test with the firmware from master?
aallan commented 2023-07-18 05:36:09 -05:00 (Migrated from github.com)

Thanks @mringwal. Is the new firmware behaving better than the current release firmware?

Should I replace the UF2 on the currently hosted on the datasheets site with an updated one?

> Thanks @mringwal. Is the new firmware behaving better than the current release firmware? Should I replace the UF2 on the currently hosted on the datasheets site with an updated one?
peterharperuk commented 2023-07-18 05:49:56 -05:00 (Migrated from github.com)

@aallan The firmware was for debug / test purposes only. We would need an official release from Infineon
@mringwal I would like to know how the current firmware is behaving before we spend time getting a new official version of the firmware.

@aallan The firmware was for debug / test purposes only. We would need an official release from Infineon @mringwal I would like to know how the current firmware is behaving before we spend time getting a new official version of the firmware.
👍 1
mringwal commented 2023-07-18 05:53:21 -05:00 (Migrated from github.com)

@peterharperuk I see. I'll re-run the same tests with the other firmware then.

@peterharperuk I see. I'll re-run the same tests with the other firmware then.
sanjay900 commented 2023-07-18 06:27:17 -05:00 (Migrated from github.com)

I've setup a test environment with a CSR8510 as Peripheral connected to my Mac and the Pico W with the CYW43439 in Central role. The CSR8510 is an older Bluetooth v4.0 USB Bluetooth dongle, which does not support DLE or 2M-PHY, but is able to send the max amount of PDUs per connection interval (hence, it's trustworthy from my side).

The Peripheral is sending GATT notifications of 20 bytes, similar to the HID reports in the original issue, the Central only receives the Notifications.

With the new firmware, I got 500-900 packets per second, depending on the connection interval (30ms, 15ms, 7.5ms). With 15 m I got 850 and with 7.5 ms even 900 packets. This is a reasonable number of packets per interval, and clearly more than one packet per interval.

@sanjay900 Could you try to repeat this with the firmware @peterharperuk posted above #1342 (comment) and use the same settings for GATT Streamer as well as LE Streamer client?

* le_streamer_client: receive only
  
  * #define TEST_MODE TEST_MODE_ENABLE_NOTIFICATIONS

* gatt_streamer_server: 20 byte PDUs
  
  * limit packet size by changing the size of the test_data arary
  * char test_data[20];

Just so i can be sure, what are you using for your btstack_config.h?

> I've setup a test environment with a CSR8510 as Peripheral connected to my Mac and the Pico W with the CYW43439 in Central role. The CSR8510 is an older Bluetooth v4.0 USB Bluetooth dongle, which does not support DLE or 2M-PHY, but is able to send the max amount of PDUs per connection interval (hence, it's trustworthy from my side). > > The Peripheral is sending GATT notifications of 20 bytes, similar to the HID reports in the original issue, the Central only receives the Notifications. > > With the new firmware, I got 500-900 packets per second, depending on the connection interval (30ms, 15ms, 7.5ms). With 15 m I got 850 and with 7.5 ms even 900 packets. This is a reasonable number of packets per interval, and clearly more than one packet per interval. > > @sanjay900 Could you try to repeat this with the firmware @peterharperuk posted above [#1342 (comment)](https://github.com/raspberrypi/pico-sdk/issues/1342#issuecomment-1541775040) and use the same settings for GATT Streamer as well as LE Streamer client? > > * le_streamer_client: receive only > > * #define TEST_MODE TEST_MODE_ENABLE_NOTIFICATIONS > > * gatt_streamer_server: 20 byte PDUs > > * limit packet size by changing the size of the test_data arary > * char test_data[20]; Just so i can be sure, what are you using for your `btstack_config.h`?
mringwal commented 2023-07-18 07:10:33 -05:00 (Migrated from github.com)

@sanjay900 btstack_config.h is was not modified.

@sanjay900 btstack_config.h is was not modified.
mringwal commented 2023-07-18 07:23:45 -05:00 (Migrated from github.com)

@peterharperuk As expected/feared, I get pretty much the same throughput values with the firmware on master/v1.0.1

@peterharperuk As expected/feared, I get pretty much the same throughput values with the firmware on master/v1.0.1
mringwal commented 2023-07-18 07:25:32 -05:00 (Migrated from github.com)

@sanjay900 btw. I'm using the 'poll' version of the Pico run loop variants. Please use that as well to minimize the differences.

@sanjay900 btw. I'm using the 'poll' version of the Pico run loop variants. Please use that as well to minimize the differences.
sanjay900 commented 2023-07-18 09:08:53 -05:00 (Migrated from github.com)

I wonder if it's dle related, as I was able to replicate your results, so I went back to hid, and it seems that with a report size of 20 things work, but with a report size of 28 I get limited to the interval again. I'll play around with this more tomorrow, and I'm happy to just shorten my report size and call it a day but it's an interesting result nonetheless.

That also explains why I didn't see this before when I tested previously - I did not shorten test data to 20 bytes when I tried this last time.
@mringwal if you use a test_data size of 28, do you see a reduced rate?

I wonder if it's dle related, as I was able to replicate your results, so I went back to hid, and it seems that with a report size of 20 things work, but with a report size of 28 I get limited to the interval again. I'll play around with this more tomorrow, and I'm happy to just shorten my report size and call it a day but it's an interesting result nonetheless. That also explains why I didn't see this before when I tested previously - I did not shorten test data to 20 bytes when I tried this last time. @mringwal if you use a test_data size of 28, do you see a reduced rate?
mringwal commented 2023-07-18 09:46:29 -05:00 (Migrated from github.com)

@sanjay900 Thanks for the feedback. When you play around a bit more, I'd be interested what's the smallest size where it slows down. Just enabling DLE doesn't cause an issue, right?

If we can find a clear test case, we can report it back.

I haven't tried 28, but that would requires DLE which is not supported by the CSR8510. I'll need/can use a different dongle then.

@sanjay900 Thanks for the feedback. When you play around a bit more, I'd be interested what's the smallest size where it slows down. Just enabling DLE doesn't cause an issue, right? If we can find a clear test case, we can report it back. I haven't tried 28, but that would requires DLE which is not supported by the CSR8510. I'll need/can use a different dongle then.
sanjay900 commented 2023-07-18 16:07:06 -05:00 (Migrated from github.com)

@sanjay900 Thanks for the feedback. When you play around a bit more, I'd be interested what's the smallest size where it slows down. Just enabling DLE doesn't cause an issue, right?

If we can find a clear test case, we can report it back.

I haven't tried 28, but that would requires DLE which is not supported by the CSR8510. I'll need/can use a different dongle then.

20 bytes appears to be the magic number, anything higher and i get limited to the interval

> @sanjay900 Thanks for the feedback. When you play around a bit more, I'd be interested what's the smallest size where it slows down. Just enabling DLE doesn't cause an issue, right? > > If we can find a clear test case, we can report it back. > > I haven't tried 28, but that would requires DLE which is not supported by the CSR8510. I'll need/can use a different dongle then. 20 bytes appears to be the magic number, anything higher and i get limited to the interval
sanjay900 commented 2023-07-18 16:32:57 -05:00 (Migrated from github.com)
  • le_streamer_client: receive only
  • #define TEST_MODE TEST_MODE_ENABLE_NOTIFICATIONS
  • gatt_streamer_server: 20 byte PDUs
  • limit packet size by changing the size of the test_data arary
  • char test_data[20];

As for a test case, this works perfectly. settting test_data to 20 results in a rate of around 15 kB/s, while with it set to 21, the rate drops to 1.5kB/s.
I used two pico ws, and I kept the server running, all i did was change test_data on the client, everything else stayed the same.

> * le_streamer_client: receive only > * #define TEST_MODE TEST_MODE_ENABLE_NOTIFICATIONS >* gatt_streamer_server: 20 byte PDUs > * limit packet size by changing the size of the test_data arary > * char test_data[20]; As for a test case, this works perfectly. settting `test_data` to 20 results in a rate of around 15 kB/s, while with it set to 21, the rate drops to 1.5kB/s. I used two pico ws, and I kept the server running, all i did was change `test_data` on the client, everything else stayed the same.
sanjay900 commented 2023-07-18 16:38:56 -05:00 (Migrated from github.com)

@mringwal Im just glad you somehow picked 20 bytes and that just happend to be the fix haha, don't think i would have figured this out as that wasn't even a consideration on my mind! Weird though that its 20 bytes and not 27, that means something else is at play here i guess.

Also, i can confirm that the run loop doesn't matter, i was replicating these results on the threadsafe-background variant as well.

@mringwal Im just glad you somehow picked 20 bytes and that just happend to be the fix haha, don't think i would have figured this out as that wasn't even a consideration on my mind! Weird though that its 20 bytes and not 27, that means something else is at play here i guess. Also, i can confirm that the run loop doesn't matter, i was replicating these results on the `threadsafe-background` variant as well.
sanjay900 commented 2023-07-19 05:21:41 -05:00 (Migrated from github.com)

I just redesigned all my HID reports to be within 20 bytes and now im getting >850hz between the two picos haha, awesome.

I just redesigned all my HID reports to be within 20 bytes and now im getting >850hz between the two picos haha, awesome.
mringwal commented 2023-07-19 05:29:27 -05:00 (Migrated from github.com)

@sanjay900 Glad we found this workaround for you. The limit is 20 bytes as there's a 3 byte ATT header for notifications and a 4 byte header for L2CAP, so the ACL packet will be 27 bytes, which is the maximum packet size without DLE.

I'll probably re-run the tests with 21 bytes payload tomorrow. If that becomes slow, as in your tests, we might have something to show Infineon.

@sanjay900 Glad we found this workaround for you. The limit is 20 bytes as there's a 3 byte ATT header for notifications and a 4 byte header for L2CAP, so the ACL packet will be 27 bytes, which is the maximum packet size without DLE. I'll probably re-run the tests with 21 bytes payload tomorrow. If that becomes slow, as in your tests, we might have something to show Infineon.
sanjay900 commented 2023-07-19 05:33:01 -05:00 (Migrated from github.com)

@mringwal that makes sense, i figured there were headers in play. It was kinda good cause it gave me an excuse to do some things more properly, so now im sending 7 byte reports instead of 28 byte ones lol.

@mringwal that makes sense, i figured there were headers in play. It was kinda good cause it gave me an excuse to do some things more properly, so now im sending 7 byte reports instead of 28 byte ones lol.
mringwal commented 2023-07-20 08:59:44 -05:00 (Migrated from github.com)

I've tested this again without DLE. The issues shows there as well. Throughput drops from 11 kB/s to 0.7 kB/s when increasing from 20 to 21 bytes. I would have tolerated up to half the throughput (as two packets have to be sent over the air), but the air trace shows that only one 28-byte packet is sends as a 27 bytes and a 1 byte packet is sent per connection interval.

I've tested this again without DLE. The issues shows there as well. Throughput drops from 11 kB/s to 0.7 kB/s when increasing from 20 to 21 bytes. I would have tolerated up to half the throughput (as two packets have to be sent over the air), but the air trace shows that only one 28-byte packet is sends as a 27 bytes and a 1 byte packet is sent per connection interval.
sanjay900 commented 2023-07-20 15:44:28 -05:00 (Migrated from github.com)

Good to have it replicated,.and in a way that's easy to demonstrate

On Fri, 21 Jul 2023, 1:59 am Matthias Ringwald, @.***>
wrote:

I've tested this again without DLE. The issues shows there as well.
Throughput drops from 11 kB/s to 0.7 kB/s when increasing from 20 to 21
bytes. I would have tolerated up to half the throughput (as two packets
have to be sent over the air), but the air trace shows that only one
28-byte packet is sends as a 27 bytes and a 1 byte packet is sent per
connection interval.

—
Reply to this email directly, view it on GitHub
https://github.com/raspberrypi/pico-sdk/issues/1342#issuecomment-1643981652,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOGYQFE2QAXYQIKV3EBSOLXRE2VZANCNFSM6AAAAAAW3JVOAU
.
You are receiving this because you were mentioned.Message ID:
@.***>

Good to have it replicated,.and in a way that's easy to demonstrate On Fri, 21 Jul 2023, 1:59 am Matthias Ringwald, ***@***.***> wrote: > I've tested this again without DLE. The issues shows there as well. > Throughput drops from 11 kB/s to 0.7 kB/s when increasing from 20 to 21 > bytes. I would have tolerated up to half the throughput (as two packets > have to be sent over the air), but the air trace shows that only one > 28-byte packet is sends as a 27 bytes and a 1 byte packet is sent per > connection interval. > > — > Reply to this email directly, view it on GitHub > <https://github.com/raspberrypi/pico-sdk/issues/1342#issuecomment-1643981652>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAOGYQFE2QAXYQIKV3EBSOLXRE2VZANCNFSM6AAAAAAW3JVOAU> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >
Invictaz commented 2024-02-21 12:04:14 -06:00 (Migrated from github.com)

Any updates?

Any updates?
peterharperuk commented 2024-02-21 12:24:52 -06:00 (Migrated from github.com)

No. The issue is still open against the wifi vendor.

No. The issue is still open against the wifi vendor.
👍 1
ricardoquesada commented 2025-01-12 22:03:30 -06:00 (Migrated from github.com)

Any update on this bug ? is there an ETA ? ty!

Any update on this bug ? is there an ETA ? ty!
mitchellcairns commented 2025-02-09 20:53:30 -06:00 (Migrated from github.com)

Also would appreciate an update on this

Also would appreciate an update on this
peterharperuk commented 2025-02-12 13:32:18 -06:00 (Migrated from github.com)

It requires firmware changes which I think means it's unlikely to happen.

It requires firmware changes which I think means it's unlikely to happen.
ricardoquesada commented 2025-02-20 08:18:27 -06:00 (Migrated from github.com)

thanks @peterharperuk

IIRC, Infineon should fix it, correct ?

And also, without this fix, there is no possible workaround, correct ?

ty.

thanks @peterharperuk IIRC, Infineon should fix it, correct ? And also, without this fix, there is no possible workaround, correct ? ty.
mringwal commented 2025-02-20 08:50:51 -06:00 (Migrated from github.com)

@ricardoquesada how does this affect your project?

From going through the comments, I'm not able to fully summarize the issue:

  • when sending 20 byte packets without DLE, the bandwidth is fully used
  • when sending a bit larger packets, so that a packet is split into two, it gets slow. I'm not sure if this is with or without DLE.
    It would be nice to test what happens to e.g. 40 byte packets that have to get split into two almost full packets.
@ricardoquesada how does this affect your project? From going through the comments, I'm not able to fully summarize the issue: - when sending 20 byte packets without DLE, the bandwidth is fully used - when sending a bit larger packets, so that a packet is split into two, it gets slow. I'm not sure if this is with or without DLE. It would be nice to test what happens to e.g. 40 byte packets that have to get split into two almost full packets.
ricardoquesada commented 2025-02-20 09:10:54 -06:00 (Migrated from github.com)

@mringwal

TBH, I don't fully understand this bug.

Some Bluepad32 users reported that some packets are "delayed" (or "lost") when using Pico W. But this bug does not appear on ESP32.

By packets I mean HID reports from Gamepad controllers.... (not sure whether they were BLE or BR/EDR packets... I have to double-check it).

My understanding is that as soon as the packet arrives to HCI, it sends it to BTstack, and BTstack sends it to Bluepad32... and there is no "buffer manipulation": no copies of buffers, not a pool of buffers, etc...

So, Bluepad32 receives the packet "directly" from the "wire".

So, users were concerned with why some packets were "delayed".

A user did some investigation and found this bug. I looked at it and seems similar to what the users noticed.

@mringwal TBH, I don't fully understand this bug. Some Bluepad32 users reported that some packets are "delayed" (or "lost") when using Pico W. But this bug does not appear on ESP32. By packets I mean HID reports from Gamepad controllers.... (not sure whether they were BLE or BR/EDR packets... I have to double-check it). My understanding is that as soon as the packet arrives to HCI, it sends it to BTstack, and BTstack sends it to Bluepad32... and there is no "buffer manipulation": no copies of buffers, not a pool of buffers, etc... So, Bluepad32 receives the packet "directly" from the "wire". So, users were concerned with why some packets were "delayed". A user did some investigation and found this bug. I looked at it and seems similar to what the users noticed.
ricardoquesada commented 2025-02-20 09:13:03 -06:00 (Migrated from github.com)

@mringwal what is DLE ? and how can I test it ?

(I don't have the test equipment with me ATM, but I can try it in about 2 weeks)

@mringwal what is DLE ? and how can I test it ? (I don't have the test equipment with me ATM, but I can try it in about 2 weeks)
mringwal commented 2025-02-20 09:41:52 -06:00 (Migrated from github.com)

@ricardoquesada No Bluetooth HCI ACL packets (e.g. HID) have been harmed / lost!

This issue is about a significant drop in throughput, but no data is getting lost on the receiving side. You would "just" get less HID reports. There might be a question about what the game controller does if it cannot send as fast as it likes. In any case, this behaviour is 100% deterministic and not sporadic.

(DLE is Data Length Extension, which allows to send packets larger than 27 bytes (23 usable for ATT PDUs -> 20 bytes payload for notification)).

@ricardoquesada No Bluetooth HCI ACL packets (e.g. HID) have been harmed / lost! This issue is about a significant drop in throughput, but no data is getting lost on the receiving side. You would "just" get less HID reports. There might be a question about what the game controller does if it cannot send as fast as it likes. In any case, this behaviour is 100% deterministic and not sporadic. (DLE is Data Length Extension, which allows to send packets larger than 27 bytes (23 usable for ATT PDUs -> 20 bytes payload for notification)).
ricardoquesada commented 2025-02-20 10:21:28 -06:00 (Migrated from github.com)

@mringwal

got it. I"ll try to reproduce it locally with some BLE controllers, with some HCI dumps (in case it helps).

but IIUC, there nothing that we can do in BTstack/Pico SDK to mitigate the bug, correct?
(e.g: Tell the gamepad controller to not send packets bigger than 20 bytes, or similar)

For context: this seems to be an important bug for Bluepad32 users. Bluepad32 is used mostly to interface with robots and/or retro gaming consoles, and a 500ms in delay heavily affects the usability.

@mringwal got it. I"ll try to reproduce it locally with some BLE controllers, with some HCI dumps (in case it helps). but IIUC, there nothing that we can do in BTstack/Pico SDK to mitigate the bug, correct? (e.g: Tell the gamepad controller to not send packets bigger than 20 bytes, or similar) For context: this seems to be an important bug for Bluepad32 users. Bluepad32 is used mostly to interface with robots and/or retro gaming consoles, and a 500ms in delay heavily affects the usability.
mringwal commented 2025-02-20 10:34:58 -06:00 (Migrated from github.com)

@ricardoquesada No, there's not much you could do. Please try to reproduce, I don't think this explains your delays. Even with this issue, the Controller can receive one ACL packet per connection interval of 7.5-15 ms, so that's way below 500 ms and no problem to control stuff.

@ricardoquesada No, there's not much you could do. Please try to reproduce, I don't think this explains your delays. Even with this issue, the Controller can receive one ACL packet per connection interval of 7.5-15 ms, so that's way below 500 ms and no problem to control stuff.
👍 1
ricardoquesada commented 2025-02-20 11:25:09 -06:00 (Migrated from github.com)

@mringwal ty. I"ll do that.

(TBH, I don't recall the delay the users reported... perhaps 500ms is too much... in any case, I'll do my own testings and report my findings here... in about two weeks once I got home)

@mringwal ty. I"ll do that. (TBH, I don't recall the delay the users reported... perhaps 500ms is too much... in any case, I'll do my own testings and report my findings here... in about two weeks once I got home)
ricardoquesada commented 2025-04-10 22:23:56 -05:00 (Migrated from github.com)

(better late than never...)

I think I figured it out

When there is a connected device and Pico is in "scanning mode", then it will delivered the packets from the connected device with some delays

However, when I stop "scanning mode", the packets from the connected device don't have any kind of delay

Indeed, disabling scanning mode seems to have more throughput, but the latency increases like ~0.5 when scanning is disabled (?)... But when I re-enable it it does not improve the latency.

I'll attach relevant logs later today.

update:
I have HCI dump working

oudated:
side question: how do I capture/print the HCI packets on Pico ?

Like this ? (it is in my notes, but I don't see any HCI packet on UART)

target_compile_definitions(${PROJECT_NAME} PRIVATE
        WANT_HCI_DUMP=1 # This enables BTstack debug
)
(better late than never...) ~~I think I figured it out~~ ~~When there is a connected device and Pico is in "scanning mode", then it will delivered the packets from the connected device with some delays~~ ~~However, when I stop "scanning mode", the packets from the connected device don't have any kind of delay~~ Indeed, disabling scanning mode seems to have more throughput, but the latency increases like ~0.5 when scanning is disabled (?)... But when I re-enable it it does not improve the latency. I'll attach relevant logs later today. **update**: I have HCI dump working **oudated**: side question: how do I capture/print the HCI packets on Pico ? Like this ? (it is in my notes, but I don't see any HCI packet on UART) ``` target_compile_definitions(${PROJECT_NAME} PRIVATE WANT_HCI_DUMP=1 # This enables BTstack debug ) ```
mringwal commented 2025-04-14 08:54:43 -05:00 (Migrated from github.com)

If the CYW4343 needs to scan for device it reduces the time it can use for the ACL connection, so it's recommended to turn of scanning once you're connected.

If the CYW4343 needs to scan for device it reduces the time it can use for the ACL connection, so it's recommended to turn of scanning once you're connected.
ricardoquesada commented 2025-04-14 09:55:26 -05:00 (Migrated from github.com)

@mringwal yes, thanks. At this point I'm sure what is triggering the bug.

Need to do more tests (had a very week last week, hopefully tomorrow I'll be able to continue with the tests)

@mringwal yes, thanks. At this point I'm sure what is triggering the bug. Need to do more tests (had a very week last week, hopefully tomorrow I'll be able to continue with the tests)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
rpi-connect-preview
ns-alpha
combine-uf2s
powman-fixups
persistent-data-docs
develop
aon-docs-fix
default-uart-fixups
async-context-deinit-freertos
sdk-time-critical
riscv-flag-check
multi-gcc-riscv-scrict-align
multi-gcc-develop
another-sleep-fix
powman-default-tick
bootrom_sysinfo_tweaks
board_header_checks
mbedtls-file-lists
use_count_of
vtable-per-core
stdio-usb-reset-compat
pico-aes
better-package
ditch_pico_pio_version
ns-develop
hardware-header-updates
low-power-ci
pioasm-cflags
lurch-patch-4
lurch-patch-3
rom_version
iar/develop
2.3.1
2.3.0
2.2.0
2.1.0-correct-picotool
2.1.1-correct-picotool
2.1.1
2.1.0
2.0.0
1.5.1
1.5.0
1.4.0
1.3.1
1.3.0
1.2.0
1.1.2
1.1.1
1.1.0
1.0.1
1.0.0
Labels
Clear labels   
bazel

   
bluetooth

   
board settings

   
boot_stage2

   
bug
Something isn't working

  
build

   
c++

   
can't reproduce
Can not reproduce the bug

  
clang

   
clib-interface

   
cmsis

   
code cleanliness

   
code size

   
compiler version issues

   
cyw43_driver

   
debug

   
discussion

   
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
dynamic_clock

   
elf2uf2

   
enhancement
New feature or request

  
errata

   
filesystem

   
flash layout

   
floating point

   
FreeRTOS

   
hardware_adc

   
hardware_claim

   
hardware_clocks

   
hardware_dma

   
hardware_exception

   
hardware_flash

   
hardware_gpio

   
hardware_i2c

   
hardware_irq

   
hardware_pio

   
hardware_pwm

   
hardware_rcp

   
hardware_rtc

   
hardware_spi

   
hardware_sync

   
hardware_uart

   
hardware_vreg

   
hardware_watchdog

   
hardware_xosc

   
help wanted
Extra attention is needed

  
host

   
IAR

   
installation

   
invalid
This doesn't seem right

  
linker scripts

   
lto

   
lwip

   
mbedtls

   
missing API

   
needs reporter detail

   
networking

   
newlib

   
newlib-multicore

   
non-c

   
non-cmake

   
non-gcc

   
openocd

   
orphan PR

   
OS integration

   
pico_async_context

   
pico_base

   
pico_binary_info

   
pico_flash

   
picolibc

   
pico_lwip

   
pico_malloc

   
pico_multicore

   
pico_printf

   
pico_runtime

   
pico_stdio

   
pico_stdio_usb

   
pico_sync

   
pico_time

   
pico_util

   
pioasm

   
port
issues or discussions of porting code/libraries to rp2040

  
question
Further information is requested

  
review

   
review2

   
rtos interop
Consideration for FreeRTOS co-existence

  
runtime init

   
static library

   
svd

   
test

   
tinyusb

   
vscode

   
wifi integration

   
wontfix
This will not be worked on

No labels
bazel
bluetooth
board settings
boot_stage2
bug
build
c++
can't reproduce
clang
clib-interface
cmsis
code cleanliness
code size
compiler version issues
cyw43_driver
debug
discussion
documentation
duplicate
dynamic_clock
elf2uf2
enhancement
errata
filesystem
flash layout
floating point
FreeRTOS
hardware_adc
hardware_claim
hardware_clocks
hardware_dma
hardware_exception
hardware_flash
hardware_gpio
hardware_i2c
hardware_irq
hardware_pio
hardware_pwm
hardware_rcp
hardware_rtc
hardware_spi
hardware_sync
hardware_uart
hardware_vreg
hardware_watchdog
hardware_xosc
help wanted
host
IAR
installation
invalid
linker scripts
lto
lwip
mbedtls
missing API
needs reporter detail
networking
newlib
newlib-multicore
non-c
non-cmake
non-gcc
openocd
orphan PR
OS integration
pico_async_context
pico_base
pico_binary_info
pico_flash
picolibc
pico_lwip
pico_malloc
pico_multicore
pico_printf
pico_runtime
pico_stdio
pico_stdio_usb
pico_sync
pico_time
pico_util
pioasm
port
question
review
review2
rtos interop
runtime init
static library
svd
test
tinyusb
vscode
wifi integration
wontfix
Milestone
Clear milestone
No items
No milestone
2.4.0
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-raspberrypi/pico-sdk#1342
No description provided.