Weird ble timing

[T IJ]

Hello DevZone,

Recently I've been testing connecting multiple servers to one client and fiddling around with some settings regarding timing and packet size.

In the following image I have one to six devices active (set the total count of devices in the client accordingly) with a minimum connection interval of 7.5ms and maximum connection interval of 15ms. I would expect the following things to happen,

• One server one client, time between each message to be 7.5 to 15ms
• Two servers one client, time between each message to be 15 to 30ms
• Three servers one client, time between each message to be 22.5 to 45ms
• Four servers one client, time between each message to be 30 to 60ms
• Five servers one client, time between each message to be 37.5 to 75ms
• Six servers one client, time between each message to be 45 to 90ms

Yet, as the image shows this is not the case. Most packages are transferred below the time I expected it to happen.

I've also tried to extend the connection interval to 30ms minimum and 180ms maximum but this results into something that blew my mind.

Most of the packages are around 360ms (double of maximum connection interval) instead of between 30 and 180ms what I would expect.

Is there any logical answer for the things I encountered or is this part of the unknown Bluetooth magic happening inside the softdevice?

Currently using Segger 4.42, SDK 15.0.0 S132

Kind regards,

T IJ

[Hung Bui]

Hi, 
There is a "Go Private" button that you can convert this thread to private. 

I believe I have tested to set the Length Request to only on TX side and 0 on RX side with no problem. We have the ble_app_att_mtu_throughput example that you can do a lot of different configuration test with it. Following is my test doing 7.5ms interval, 247 bytes ATT_MTU and 180 bytes DLE. 

How do you request the DLE exchange in the 140bytes case ?  Please make sure you only request on TX not on RX. Try to set RX to 0 byte 0 second. 

[T IJ]

Hello Hung,

Thanks for all the information you've provided, but I had a discussion with my colleague about our frames and we'd probably skip the shorter GAP length for now. The standard 7.5ms is time enough to get everything done and within our requirements. If I need to improve my timing I will create a private thread instead.

I shall give answer to my initial question to help people with similar problems.

As can be seen in the first picture in my original post, the timing is off for multiple devices. This is due to the fact that the client side is probably using the 15ms time that was set by the max connection interval. 

When odd number of devices are used I've noticed that one (or more) device(s) is prioritized over the others. E.g. using three servers resulted in a connection interval of 15ms from the sniffed device, the other two devices had a connection interval of 30ms. The central used the following connection scheme, d1, d2, d1, d3, d1, d2, d1, d3 ect.. 

As shown the central does not round robin all devices!

Only when you set the time properly for the central (e.g. set max connection interval to 7.5ms) each device is accessed with the same time interval as between other devices. (see picture below)

 

The second picture in my original post showed data packages being received at double the max connection interval, but in this situation a similar thing is happening what I described using the odd number of devices as an example.

Instead of having an odd number of devices I do believe it is prioritizing something something or someone but I cannot guarantee it. 

So conclusion, if you want strict timing, setup your connection interval timing properly!

[Hung Bui]

Thanks for the information. I agree with you that to optimize the communication one should configure the interval timing properly. This include the connection interval configuration on both side as well as the event length configuration. 

The scheduler on the softdevice is fairly simple and it will only prioritize a connection over the other when the connection is going to be timed out soon. So there will be a chance that a connection will pre-empt other connections just because it's scheduled before others(connection established before the others).
To avoid a connection event being skipped, it's important to configure:

The connection event x Number of connection <= The (common) connection interval