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, 

Could you try to capture a sniffer trace ? You can use our sniffer here. It can only follow one connection at a time. But it still can reveal a lot of valuable information. 

As suggested in section 15.10 in the S132 SDS v6.0 the connection interval is suggested to 20ms when you have multiple peripherals (8 connections with 2.5ms event length each). 

We need to look at how you setup the event length of each connection. Please look for NRF_SDH_BLE_GAP_EVENT_LENGTH in the sdk_config of the central code. If possible please provide us the project code. You can convert the case to private if needed. 

[T IJ]

Hello Hung,

I'm currently using 3 devkits as ble sniffers (running 3 wire shark instances to sniff 3 servers) I'm using the multilink and blinky example to do some testing regarding timing.

What I can conclude so far is that timing and Bluetooth do not really add up together, well only if you set up things properly.

Apparently the maximum connection interval is most of the time dominant in telling how much time each device gets, which is set in the client, the servers apparently do not have a any saying on timing.

Just as I explained in my original post, I was expecting timing to be a lot tighter than it actually is, the timing I got in my reply is the time I expected in the first place.

The NRF_SDH_BLE_GAP_EVENT_LENGTH  you mentioned is set to 6, I did not changed this.

Could you explain the 20ms with 8 devices with 2.5ms event length to me? I do not understand this as I thought each device has a minimum of 7.5ms to communicate? If I am able to decrease the amount of time from 7.5ms to a lower value I will be happy.

So far, I am able to, with my new settings, communicate with six devices and each having 7.5ms time to talk. In this configuration I am also able to send up to 400 bytes (tested so far) of data per server per connection interval of 7.5ms.

Kind regards,

T IJ

[Hung Bui]

Please upload a full sniffer trace file so I can have a look. You can convert this case to private if you want. 

[T IJ]

2.5ms 50 bytes.pcapng2.5ms 72 bytes.pcapng2.5ms 140 bytes.pcapng

Somewhere in my mind I might have found the reason I'm not able to set the data length to 140 because to my believe the TX and RX time must be equal to each other, because the master does not only send an empty packet but also needs the time to send data as well.

To me this makes, after a lot of thinking all the sense of the world. 

I do believe I have to find a different method to (mis)use the Bluetooth connection to a way it suits my purposes. 

If you can tell me how to privatize this thread I will be happy to explain in a bit more detail what my need is.
 

[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