Scan window is sometimes skipped when a device is connected

[goldwake]

I'm currently looking into improving BLE connection reliability in my application by reviewing my connection parameters, scan intervals etc. But have noticed that a scan window is missed reasonably often and I'd like to know why in case there is a problem with my timings

I'm testing my SDK v15.3 s332 v6.1.1 application on a NRF52832 dev kit with the Nordic PPK to visualise the timings.

My application is acting as a central and peripheral and supports up to 5 peripheral connections and 8 central connections.

So 13 connections with an event length of 2.5 ms + tscanReserved, makes 33.75ms (13*2.5 + 0.76 = 33.26ms, round up to nearest 1.25ms).

So my parameters are:

• min/max  conn interval 33.75ms for both central and peripheral connections
• scan interval 33.75
• scan window = 2.5ms * (max_number_central_connections - num_active_central_connections), so it varies between 20ms and 0ms
• adv interval 202.5ms (33.75ms * 6)
• I only advertise while there are free slots for peripheral connections

I also have connection event extension enabled and the new improved advertising option enabled

When nothing is connected, everything looks fine

When i establish a peripheral connection, eveything falls to pieces and I'm missing connection events and scan windows. The amount missed events/windows also seems to vary (0 - 3) and I'm not sure why. Sometimes it works as expected, other times it does not. Sometimes it might not work as expected then I'll add another peripheral connection and it might work as expected or might not, same when I disconnect from a peripheral connection

Here is one that works as expected

What's going on here? How can I improve my design to be more reliable

Thanks

[Edvin]

Hello,

I am not sure whether it is the second or third image that is not as expected. But I guess what you are experiencing is the softdevice scheduling and skipping scan windows, advertisements and/or advertisements. 

Since the nRF only has one radio, it has to switch between different tasks, such as advertising, scanning and connection handling. If nothing overlaps, everything, but it is likely that something will collide eventually. As you may know, the softdevice adds a 0-10ms random delay between each advertisement (required by the BLE spec), so the advertisement slot will slowly drift and collide with other events. 

A central will try to slot a connection into a reasonable space in time so that it doesn't collide with it's other connections, but a peripheral will simply have to accept the timeslot that is given by the central, and can't control this. 

The softdevice has a dynamic scheduler, and if there are two events that are scheduled in the same timeslot, it will have to choose one of them, but the one that is not chosen will have increased priority the next time. You can read about the priorities here. (It is for the S132, not S332, but S332 is based on the S132).

Also worth mentioning is that the scan windows has to be scheduled in whole windows, meaning that the softdevice will not start a scan window, and then stop it because it has to advertise. When it is started, it will continue to scan until the scan window is finished. 

So if you are experiencing problems with the connections, I suppose you could try to increase the connection interval and/or supervision timeout to give it some more slack.

[goldwake]

Hi Edvin, thanks for the reply. The second image is not as expected. You can see that the time between scan windows and connection events is 67.5ms, double what I actually set.

The third image is with the same set up, I just disconnected the phone from my device and reconnected. The time between scan windows and connection events is 33.75, what I expect. 

I'm using nrfConnect on an android phone so can see that the negotiated connection parameters are what I expect in both cases. So why would the scheduling be different?

Thnaks for the reminder about the random advertising delay, that had escaped my mind but shouldn't that only affect the scan/connection events due to happen at the same time as the advertising event? Would the scheduler handle connection events during this random advertising delay or, is it up to 10ms of inactivity?

Yes I can increase the connection interval but minimising latency is an important factor in my application so I'd like to do everything I can to  reduce this

[Edvin]

goldwake said:

The second image is not as expected. You can see that the time between scan windows and connection events is 67.5ms, double what I actually set.

 I see. As you can see, it is because the connection event is in the middle of the planned scan window. 

The negotiated connection parameters are the connection interval and the connection event length, but not the actual timeslot where it should be started (and then repeat each connection interval). I don't think there is any way to prevent this. What you can try when you enter a connection is to stop and start the scanning again. Maybe the softdevice will try to put the scan windows in a better slot. 

However, this may work with one connection. Let's use some simpler numbers to look at this.

Let us say that you want to have 9 connections and scan. Every connection takes up 1ms, and you want a scan window of (9 - n) ms where n is the number of connections. the last ms is used for advertising (lets ignore the random delay for now). So every interval (10ms) is divided up in 10 slots of 1ms. 

From the beginning, you scan 9ms, then advertise for 1ms. 

Then you get a connection from a phone (the nRF is the peripheral in this connection). Let us say it takes up timeslot 3. Now your scan window is 8ms, but timeslot 3 and 10 is occupied, so there is no time to scan for 8ms, 1ms connection and 1ms advertisement in every interval, and hence, the softdevice has to swap between scanning and the connection+advertising. 

The nRF is just following the BLE spec, in order to maintain the connection, and the phone did nothing wrong. It saw an advertisement and connected to it. It is not aware that the nRF is really trying to scan as well. 

Stopping and starting the scan (if we discard the advertisements which will drift either way) may move the scan window for the nRF, but only until you get a new connection which takes up e.g. timeslot 7. So now timeslot 3 and 7 are occupied, and it is not possible to scan for 7ms +2ms connections. 

Being the central in the connection (the device that initiates the connection) doesn't really help either, because it has to reply with a scan request within a certain time of the advertisement in order for the peripheral to respond to the connection request. 

If you have these strict latency requirements, and require this many connections, it doesn't look like BLE is the solution for you. Maybe you can try a proprietary approach? That would not work with "BLE-only" devices, such as phones, though.

Maybe you can look into one of the mesh technologies? The Bluetooth Mesh has a quite low latency, and you can have nodes that can be part of the Mesh network and at the same time be in a BLE connection. Every technology has its downsides, though, so mesh nodes use the radio all the time, and hence has a bit higher current consumption. 

Best regards,
Edvin

[goldwake]

Thanks Edvin, that's really clear and helpful