Forums

Hi Marcel,

You are right, the BLE stack is limited to processing a maximum of 4 packets per connection event. We are currently looking into whether this can be increased in the next revision of the stack.

Best regards,

Karl

Hello Karl,

Thank you for your reply. Can you make any prediction about when a new revision of the stack will be available? 

Best regards,

Marcel

Hi Karl,

Slightly off topic, but is this limitation based on the number of HCI buffers available at the controller?  Is there anyway to increase the number of HCI buffers?  

I found

#define HCI_MAX_NUM_DATA_BUFFERS 0x04
#define HCI_MAX_NUM_CMD_BUFFERS 0x01

in hci_controller.h, but changing these constants doesn't seem to have any affect.

In my solution I have to use a FIFO to buffer packets in the case when GATT_Notification() call fails due to "MSG_BUFFER_NOT_AVAIL".

Thanks,

-Tyler

Hi Karl,

If the BLE stack is limited to processing a maximum of 4 packets per connection event, does this mean that if my application has more than 4 characteristics I cannot write to all of them in the same connection event?

Thanks

There is a bit of confusion around all the forum.

4 notifications per connection event is the maximum if a 20 bytes size is considered. This was an experiment Karl gently gave to the community to test the maximum throughput in BLE, where the connection event was 6 (7.5ms) and the number of notifs = 4 (20bytes each).

If you use a longer connection interval and/or lower packet size, you will be able to send more.

There are threads in the forum with 6 and 7 notifications per connection event.

Bye!

Thanks for your answer, but I have another question: looking at the connection event at channel 0x1F in the below figure

what are the yellow packets which don't have PDUs on them? are these the packets to maintain the connection? Do I have to take them into consideration when calculating the number of bytes that can be sent in a connection interval?

Thanks in advance

I do not see the picture because I'm on my mobile phone but they can be ACKs or polls, depending on your app.

I do not think there are keep-alive packets in BLE but if I do not remember wrong, the connection events start with a poll.

I would not take them into account. In fact, for rapid througput calculations what I do is to take all the packets in a connection event during a second, divide the whole number by two (to discard this short packets). and multiply for the number of bytes.

Adéu!

Kazola,

Thanks for your answer 

If this answers your questions, verify the thread just to keep the forum cleaner :)

Bye!

Hi Hafiz,

A connection event consists of both initiator and peripheral Rx/Tx periods. I.e. they switch back and forth. You can see from the timestamp that they occur 295 µs after the previous packet. This indicates that they are sent by the reciprocating device within the same connection event. Hence they are not interesting for calculating write speed, as they have no relevance.

LLID of 1 indicates empty packet or continuation packet. In this case empty as pdu len is 0.

See the bluetooth core spec (http://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737) Volume 6, Appendix B, Chapters 2.4 and 4.5.6/9 if you are interested.

Best regards,
Aslak