Can you specifically set the amount of packets per interval?

[Mathias]

Hi!

I have an implementation running with a peripheral sending notifications to a central at 27.5 ms. They are both configured with HIGH BW. Sending of notifications is activated by pressing a button. I now see that when the button is pressed, the peripheral is able to put 7 packets into the buffer (and an 8th one overflowing it) in the first interval, but then it changes to 6 packets (+ a 7th that overflows the buffer) for the following intervals.

I actually want be able to achieve 6 packets per interval, for each interval, so also for the first one. So my question is, how is this possible?

The figure below illustrates once more the beginning of notification sending and thus the transitions from 7 to 6. Channel 2 is the radio. Channel 0 indicates putting a packet in the TX buffer and is thus first 8 times and then always 7 times. Channel 1 is I2C measurements of an accelerometer in between.

Kind regards

Mathias

EDIT 1

[endnode]

I believe it actually transports 6 packets over the radio, note that Tx buffers inside SD aren't necessarily linked to number of packets transported over radio link. Do you have some confidence by looking into radio analyzer/sniffer trace that different numbers are going through the link in each interval? otherwise if you push 7 packets to the stack and then 6 of them are "cleaned" so you can push 6 more it indicates that 6 are going over the radio... can you make some GPIO counter on TX_COMPLETED event if their count corresponds to the numbers?

[endnode]

Not sure that I do follow your architecture but I would do it as follow: your FW needs to know what data it wants to send when which translates into number of packets. If you want to send just 6 then count to six and push the next after you receive TX_COMPLETED event or later (e.g. triggered by some application timer well before next event). Note that 6 PDUs of basic size (37B on LL, 23 on ATT, 20 on GATT) will go out within ~5ms (that's what I remember although I didn't run such throughput test recently) so there should be plenty of space to a) lower the connection interval and b) do other long-lasting tasks like UART/SPI/I2C communication. ll assuming this is the only connection you maintain (and no time slots or other tricks which restrict MCU availability)