ble_enable_params is "memset" in softdevice_enable_get_default_config() so your settings did not get applied. Should work if you place "ble_enable_params.common_enable_params.p_conn_bw_counts = &conn_bw_counts;" after softdevice_enable_get_default_config() in ble_stack_init.

I tried with the same settings here and got 7 packets per connection @30 ms intervals with an iphone 7.

as far as I understand, delta time is the time between 2 packets and here I got 27ms, which is pretty much what I expected when I set interval connection is 30 and using iPhone which have interval connection is 24 after negotiation.

More Data mean there is more packet in that interval, so base on this, I assume most of the time there is only 1 packet per interval connection? So basically it's not work?

May I ask is this because I set sd_ble_opt_set(BLE_COMMON_OPT_CONN_BW, &ble_opt); inside the ble_advertising_start();? Where should I put those code then?

Looks like you have correctly enabled high BW mode for the connection now. To maximize throughput it is also important to keep the notification/write queue full, are you doing that in your code? Attached is the project I used for test (modified ble_app_uart example in sdk 12.3.0).

Thank you very much, I have achieved it. Turn out it is because on the mobile phone, it is in write with response mode, so it can not achieve multiple packets per interval connection. When I switched to write without response, it's okay now.

But the thing is, because of the consistency and security, I need to keep the mode write with response, is there any way else I still can achieve this multiple packets?

Thank you very much for your help, I really appreciate it, it's very valuable to me.

I didn't notice that you were sending write requests before now. Write requests are significantly slower compared to Write commands as the requests need to be acknowledged by server at the application layer before next write can be requested (both are acknowledged at the link layer). In other words, you will only get one request per connection event. So I'd recommend to use write command to improve throughput.

Hust said:

What do you mean here? How can I do it? Please be patient with me.

I could have been more clear. I have limited experienced with app development on the iphone, but the "write" API should be asynchronous - write packets are added to an output queue by the write API and later de-queued by the BT stack when the packet is sent on air. So I meant that you should make sure to have multiple packets in the output queue in order to allow the stack to send multiple packets per connection event.

Unfortunately, it's not possible to get more packets per event if you use write requests. That said, you could consider using a combination of these two to both achieve higher throughput and acknowledgment at the application layer. Possibly something similar to the BLE DFU transport where we have one "control point" characteristic for commmands and another characteristic for receiving the data. Then you could send write requests to the control point for enabling reception of x number of bytes on the data characteristic.