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]

There is some clarification needed here. The connection interval of 7.5ms doesn't mean that the peripheral (server) has the full 7.5 ms to communicate with the central (client). 

Interval means interval - the time it takes to the next repeated event. 

The event length on the other hand means the time the peripheral has on each connection event for it. 

So if you set the connection interval to 20ms for all of the links, and set the event length for each of them to 2.5ms for example, then you can serve 8 connections and each of them has 20ms interval. And this mean you can have 8 links with 20ms time between each message.

Please try to set NRF_SDH_BLE_GAP_EVENT_LENGTH to 2 (2.5ms= 2 x 1.25ms) on the central and you will see the magic. 

[T IJ]

Thanks for the clarification, this will help a lot.

I'd assume I have to set the  NRF_SDH_BLE_GAP_EVENT_LENGTH to something that will suite the time for my maximum amount of data to be transmitted in the interval? Roughly 400 bytes.

I will keep you informed what I discover.

Other question,

Is there an option in the blinky example to change from fast to slow advertising?

[T IJ]

Hey Hung,

So I've been testing stuff with the GAP event length and I stumbled upon something which I cannot explain. My PHY is set to 1Mbps.

The GAP length is set to 2.5ms.

I want to transmit 140 bytes of data in this 2.5ms using a notification.

I've read and calculated the amount of time needed to transmit this package.

80µs from the master sending empty PDU

150µs switch over time from RX to TX

1288µs total data time plus overhead

150µs switch over time from TX to RX.

Totaling to 1688µs of time which is within the 2.5ms GAP length, yet the softdevice gives me an error on my data length extension above 72 bytes. 

Is there an explanation for this? 

Kind regards,

T IJ

[Hung Bui]

We need to look into the actual data length that the central assigned to the connection (BLE_GAP_EVT_DATA_LENGTH_UPDATE event) . 

The softdevice can't dynamically schedule based on the actual data and will calculate only the worst case scenario, this includes the max size of TX and max size of RX. Please check the effective RX and TX octets/time you get in  BLE_GAP_EVT_DATA_LENGTH_UPDATE  event. 

[T IJ]

If the data length is set to its default settings if the length is exceeded, it doesn't even send a length request when it results to default.

I did manage to capture an packet with 72 and 50 bytes which is allowed. Something tells me that the Max RX and TX time is not correct in this image because the time is the same when I set the data length to 50 bytes.

[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.