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

[Mathias]

It's around 5.3 ms when I tested it :) I'm just rounding a little bit. Well, I already once tried with the counting to six but then I got issues that I don't overflow the buffer and thus the next interval is not used to send user made packets because the previous interval the buffer wasn't overflowed (as stated in this question devzone.nordicsemi.com/.../). Indeed, only one connection and no timeslots or other kind of tricks :)

[endnode]

Sorry, I don't see the link with "calling HVX inside radio notification handler". Can you point me exactly to the spot in whole thread? I still believe that using single connection link and 7.5ms works for me in terms of achieving full 6 PDUs (but I can understand that these 1-2ms left for application might not give you enough time to process/prepare these data so going with connection interval in 10-20ms range might be solution, still better then what you use today).

[Mathias]

This comment in the answer to the question states what I mean: "As you already mentioned, the nature of BLE doesn't support realtime requirement. All packet will be transmitted I assume that you want to only update the latest sample on each connection interval, my suggestion for you is to try to keep track of the number of packet in the buffer by using the number of packet you queue, minus the number of packet sent reported in BLE_EVT_TX_COMPLETE. If in one BLE_EVT_TX_COMPLETE you have the number of packet in the buffer is full, you would need to queue at least 7 packets (if the max number of packet per connection interval is 6). This is to make sure you will have at least 1 packet to be sent in the connection after the next one. So that we will not get into the situation with one connection event with packet sent and one without.

But anyway, it will have a 7.5ms latency because you can't have a packet sent immediately but will have to wait for the next connection interval."

So what I'm saying is that to have 6 PDU's every interval, I need to put a 7th as well, that overflows the buffer and makes sure that the next interval is also used to empty the then again refilled TX buffers. And the issue that I'm having is that in the first interval, 7 packets can apparently be tried to send with an 8th overflowing the buffer. If I would just count to 6, the buffer wouldn't overflow and thus I would get interval sending, next not sending, next sending ... If I would count to 7 you might say, then I do overflow the buffer but not in the first interval, that requires 8 packets to overflow... So that's my issue :/

[Mathias]

But you're saying that you get 6 packets each interval without overflowing the buffer but by just counting to six? Because I did try that I while ago and that didn't work. I got the sending, not sending, sending , not sending ... intervals problem so I then starting looking for a solution on the dev zone and bumped into the question I send you..

[endnode]

Yes, I believe that you don't need to overflow anything, simply when connection interval comes stack (Soft Device) will look to Tx buffers and tries to send as many as possible. If it has bandwidth to send 6 and there are 6 prepared by higher application layers they should get through. I'm afraid I don't understand your "sending not sending sending not sending" comment. Does it mean that you got how many PDUs through in case you provisioned how many through sd_ble_gatts_hvx calls? I'm sorry but I don't see any indication in the Q&A you linked that you would need to provision Tx packets up to receiving BLE_ERROR_NO_TX_PACKETS status code from SD to get certain number of packets through on next connection event.