Weird ble timing

RE: Weird ble timing

Hung Bui — Tue, 03 Mar 2020 14:04:40 GMT

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

RE: Weird ble timing

T IJ — Mon, 02 Mar 2020 12:15:27 GMT

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!

RE: Weird ble timing

Hung Bui — Fri, 28 Feb 2020 15:46:29 GMT

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.

RE: Weird ble timing

T IJ — Fri, 28 Feb 2020 07:19:48 GMT

devzone.nordicsemi.com/.../2.5ms-50-bytes.pcapng devzone.nordicsemi.com/.../2.5ms-72-bytes.pcapng devzone.nordicsemi.com/.../2.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.

RE: Weird ble timing

Hung Bui — Thu, 27 Feb 2020 17:03:55 GMT

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

RE: Weird ble timing

T IJ — Thu, 27 Feb 2020 14:26:56 GMT

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.

RE: Weird ble timing

Hung Bui — Thu, 27 Feb 2020 13:59:46 GMT

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.

RE: Weird ble timing

T IJ — Thu, 27 Feb 2020 09:47:16 GMT

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

RE: Weird ble timing

T IJ — Tue, 25 Feb 2020 15:41:06 GMT

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.

RE: Weird ble timing

Hung Bui — Tue, 25 Feb 2020 15:30:30 GMT

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.

RE: Weird ble timing

T IJ — Tue, 25 Feb 2020 15:03:06 GMT

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

RE: Weird ble timing

Hung Bui — Tue, 25 Feb 2020 14:40:48 GMT

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.

RE: Weird ble timing

T IJ — Tue, 25 Feb 2020 10:41:23 GMT

Just to add to my post,

I've changed my maximum connection interval from 15 to 7.5ms resulting in the following behavior

One server one client, time between each message is 7.5 ms
Two servers one client, time between each message is 15 ms
Three servers one client, time between each message is 22.5 ms
Four servers one client, time between each message is 30 ms
Five servers one client, time between each message is 37.5 ms
Six servers one client, time between each message is 45 ms

I'm now more flabbergasted as what I was one hour ago.