Number of packets transmitted per connection event after updating conn params


Hi @guohui , i’ve performed some experiments with two RB-DUO, one acting as Peripheral and the other acting as Central. at a certain instant after both devices are connected, i update the connection parameters from the Central device with the ble.updateConnParams() command in order to set a min and max value for the connection interval to 0x00FF. after this command is executed, i can see from the captured ble packets that the number of packets transmitted per connection event varies from 6-7 to even 14-15 with the same code running. However, in case i update the connection parameters from the Peripheral device with the ble.requestConnParamsUpdate() command in order to set the same min and max value for the connection interval, i always see that the number of packets transmitted per connection event is 6-7. does it make sense? i woud appreciate any help on this issue. thanks


Hi @fbt, The packets transferred per connection event is not determined by the connection parameter. The connection parameter only maintain the connection interval and connection timeout. What I can tell is that, the parameters, also known as PPCP on peripheral side, will apply only if the central side accept these parameters when peripheral initiates the request. While if the central initiate the parameter update sequence, it should pass in the connection parameters as you have already done. The packets transferred per connection is a very under layer stuff, so it is out of my research.


Thanks @guohui … any comment from the btstack library @mringwal?. thanks in advance


The Connection Interval obviously results in an upper limit for the number of packets transferred per connection interval (if it’s shorter, less packets can be transferred).

Interestingly, most devices like iOS have some kind of fixed upper bound for the number of packets per connection interval, and in this case, reducing the connection interval (shorter) increases throughput.

Without this per connection interval limit, the connection interval does not have much impact on throughput (well, very short interval and long packets results in lots of unused radio time).

If the number of packets doesn’t change when trying to change the connection interval, maybe the connection parameter update request fails. Speaking of which: the code in BTstack that did process connection parameter updates was buggy until earlier this week. There’s a good chance this is causing your update to fail. See

@guohui could you see if this fix could be applied? :slight_smile:


Hi @mringwal … great to hear from you! … the behavioral y report on this post is not affected by that issue, since we detect it when the requests to update the connection parameters from the Peripheral where always rejected by the Central device, and modified the code for the function l2cap_le_signaling_handler_dispatch in l2cap.c file:

            uint16_t le_conn_interval_min = little_endian_read_16(command,4);
            uint16_t le_conn_interval_max = little_endian_read_16(command,6);
            uint16_t le_conn_latency = little_endian_read_16(command,8);
            uint16_t le_supervision_timeout = little_endian_read_16(command,10); 

… and after this local update the request where accepted by the Central, and it sends the connection update command.


Ah. Great - it’s the same fix.
You could have reported this issue on the BTstack Issue tracker btw…

It helps to use a BLE Sniffer (based on nRF51 or CC2540) and check why there are not more packets transmitted. If a larger ATT MTU (e.g. 158 like on iOS) and a few packets are buffered, the Bluetooth Controller should always have enough packets to sent. I do experience this “only parts of connection interval” is used with many different controllers and it also somehow depends on the remote side - like iOS to A is faster than iOS to B, however A to A slower than B to B.


Hi @mringwal … beleive It or not, we faced the issue related to the requests for updating connection parameters two days ago, and se were still validating the modifications se did. Thanks a lot for tour answer. We Will validate the updated btstack anyway. Best regards and we will be un contact.


@mringwal @fbt Awesome work :+1: ! We are going to catch up the BTStack library for the Duo, so hopefully this bug will be fixed in the next release.

Best regards,


Hi @mringwal … another question we are experiencing, in case it can be related to an issue on the BTstack and report it if you consider. we have implemented a central and a peripheral device on DUO devices from BTstack in order to check the max available throughput … in all cases, the peripheral request an update of the connection parameters to the central device, in one case to set a connection inteval of 30ms, and the another one to set a value of 100ms. In this last case, everything works as expected (at least, we expected), but in case we try to update the connection interval to 30ms (despite it is the default initial value), the central accepts the request, but a bad behavioral is seen when notifications are enabled and sent, since there are a lot of packets aparently resent (because unexp. NESN), and and abnormal number of packets sent per connection event. this behavioral is almost the same in case we try to set the connection interval to other low values, and as we increase the connection interval, i.e. to 80ms, the observed behavioral gets “better”. does it make sense?. Attached you can find the captured data from a ble sniffer. wewould greatly appreciate any help oin this issue … and we thanks your support, as always. thanks


EDIT(1). FYI we are not using recent versions of BTStack.
EDIT(2). when we try to update the connection interval to 30ms, at first it works ok, but after a while, the unexpected NESN errors appear and retransmissios begin … @mringwal, can it be a problem related to the reception buffer at the central device? how can i check that?