Scheduling of scan window and connection window

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hello,

Is there any documentation on scheduling policy of BLE stack?

The BLE Master needs to schedule connection window as per the established connection parameters.

And, if the scan is enabled on the Master with the conflict timing parameter,

I would like to understand how Broadcom BLE stack prioritizes the conflicting request.

Let's say, the connection interval is 10 ms and the connection window is 2.5 ms.

And, the scanning window is configured as  62.5 ms (100 slots) with around 1 sec scanning interval.

In this case, the Master skips the connection window and give the priority to the scanning window?

0 Likes
1 Solution
VictorZ_46
Employee
Employee
5 comments on blog 25 sign-ins 250 likes received

Mkim, In general connection events have higher priority than advertisements or scanning.  But BT scheduler is extremely difficult components.  Unfortunately exact details of what and how it performs scheduling of TX/RX events is proprietary Broadcom information and is typically not disclosed.

View solution in original post

6 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

79rpm victorz

I believe this is related to the other question Victorz just answered here correct?

Check if bleprofile_sendNotification() was successful

0 Likes
Anonymous
Not applicable

It is related somehow because Master's behavior affects Slave, but I think it is different question.

0 Likes

I don't think this is documented anywhere outside of the BLE spec itself, but I will ask the developers if my assumption is correct.

0 Likes
Anonymous
Not applicable

As I understand BLE and spec.: there are timing constraints, definitions for some parameter such as you are looking for.
And I think I saw also a feature, that master (client) can "configure" device in terms of timing and latency. Master can tell slave with which timing it wants to get something, I guess also for Notifications. I think I have seen something like this: that master can tell slave to "be prepared in advance", timing configs for something "be prepared in advance".

I found here:

http://www.eetimes.com/document.asp?doc_id=1278927

"Advertising intervals can be set in a range of 20 ms to 10 s".

"In particular, this data specifies two important parameters: connection interval and slave latency. The connection interval determines the time between the start of the data packet exchange sequence called connection events."

BTW: often  people talk about "scheduling BLE events" on the FW or App side, when programming, e.g. when sending some commands via BLE to other peer. Not to mix up with BLE timing itself, more related to the nature of the OS, FW and how BLE works.
It is often needed and done due to the nature of "synchronous call" assumed. It can happen that you call an API function, e.g. for BLE WRITE. But code continues after API call done on main thread. A new BLE WRITE there but the first one has not yet completed. It hangs still somewhere in FW stack or the slave device has received but not yet processed the previous WRITE.
Per definition and my understanding: slave device can stop and drop a previous command when interrupted by a new one coming in. Small BLE devices does not need to have a FIFO approach (not a huge stack, just single item processing, very small device memory, not command queues inside slave ...).
So, without "coding tricks" on one peer - you can override the other one, commands can get lost. Here programmers say often "use a queue".

0 Likes
Anonymous
Not applicable

BTW: found this:

http://www.diva-portal.org/smash/get/diva2:445810/FULLTEXT01.pdf

Very nice and helpful doc (masters thesis)

VictorZ_46
Employee
Employee
5 comments on blog 25 sign-ins 250 likes received

Mkim, In general connection events have higher priority than advertisements or scanning.  But BT scheduler is extremely difficult components.  Unfortunately exact details of what and how it performs scheduling of TX/RX events is proprietary Broadcom information and is typically not disclosed.