Understanding BLE connection and intervals

[Ivan Jug]

I started working with BLE and I have some trouble understanding few things.
The connection interval happens every X ms, that is set by master, usually the default is lowest it can handle. In one interval X packets can be sent master-slave, slave-master. Usually that is 4 packages.
The connection interval, by default it is set by master, in this case not the NRF52840(the chip), because it is GAP peripheral?
So, if I want to change from default from chips side I need to specifically request different interval?
The Android or PC is trying the lowest they can? On PC, I am measuring something around 15 ms but on Android it seems much higher. However, dumping the BT log on
Android and inspecting it in Wireshark I am getting that min interval is 6 (7.5 msec) and max interval is 12(15 msec). On PC I can not confirm because I have no sniffer.

So, this means that new new connection interval is started every 15 ms and all the data in the buffer and new data in the time of interval will be sent?
Or does the new data wait for new connection interval?

For example, I am trying to send data every 10 ms, when I try this with a PC, where I measure around 15 ms for connection interval,
I see that I get 1 packet and then I get 2 packets, and that repeats, because that makes sense, 1st packet done on 10 ms, 2nd on 20ms and 3rd on 30ms.
Which means that on 1st interval 10ms packet will be sent, and on 2nd interval 20ms and 30ms packet will be sent.
Going by this logic I try to lower the interval of sending data to 8 ms, which would mean 2 packets per interval in most cases, every 8 times it would be 1, but not important.
It works most of the time, but every once in a while I actually get the error on the chip. The error I am getting is 0x00000013, which is the NRF_ERROR_RESOURCES. By my understanding, this means that the buffer has filled because most likely I did not get TX confirmation that would clear the buffer. I am not sure why would this happen, shouldn't it be able to
queue 4 packets? So even if 1 interval would not receive the confirmation, the one after would and that would clear the buffer for new data?

On Android, even 10 ms does not work perfectly, I get the NRF_ERROR_RESOURCES error every once in a while because the confirmation is not sent in the connection interval. Does
this mean that even if the connection has min and max set it could still happen that the time between connections or something in the connection interval can be handled wrong
or take more time on Android side? Some default Android interruptions or something?

Just a side note, I am not even trying to maximize the throughput, I am sending only like 8 bytes of data but I am testing on few thousand consecutive packages.

[tesc]

Hi,

The connection parameters are decided, as you write, by the central. In your case the Android phone. What connection interval you end up with, as well as the event length (how many packets back and forth every connection event), is therefore decided by the smartphone.

Also, as you write, packets should get queued up (as long as there is buffer space) and sent at next available connection event.

What type of packets are you sending? Are you writing, reading, notifying, or indicating? I'm thinking if your choice of data transfer needs an ack on some level before sending the next packet, then if the peer for some reason delays the ack until the next connection event then that might explain a lot. Other explanations might be that the peer device does fewer packets per connection event than what you would need, or that packets gets lost due to interference on the 2.4 GHz band.

Note that there might also be other processes going on in parallel with the packets that you send. In particular at the beginning of the connection. E.g. database discovery, connection parameter update, change of mtu size, other characteristics sending/receiving data, etc. In order to figure out what exactly goes on over the air, the best tool is a sniffer trace. If you post the traces here we would be able to look further into what is going on.

Regards,
Terje