Initiator timing

This section introduces the different situations that happen with the Initiator when establishing a connection.

When establishing a connection with no other connections active, the Initiator will establish the connection in the minimum time and allocate the first central link connection event 1.25 ms after the connect request was sent, as shown in Figure 1.

Figure 1. Initiator - first connection

When establishing a new connection with other connections already made as a Central, the Initiator will start asynchronously to the connected link timing-events and position the new central connection’s first timing-event in any free time between existing central timing-events or after the existing central timing-events. Central link timing-events will be placed close to each other (without any free time between them). This minimum time between start of two central role timing-event is referred as tEEO. tEEO is proportional to the payload size and the number of packets exchanged (bandwidth configuration) in timing-event, because more time is required to exchange more and larger packets. Refer to Table 2 for tEEO timing ranges. Figure 2 illustrates the case of establishing a new central connection with one central connection already running.

Figure 2. Initiator - one central connection running

Important: The Initiator is scheduled asynchronously to any other role (and any other timing-activity) and assigned higher priority to ensure faster connection setup.

When a central link disconnects, the timings of other central link timing-events remain unchanged. Figure 3 illustrates the case when central link C1 is disconnected, which results in free time between C0 and C2.

Figure 3. Initiator - free time due to disconnection

When establishing a new connection in cases where free time is available between already running central link timing-events, best fit algorithm is used to find which free time space should be used. Figure 4 illustrates the case when all existing central connections have the same connection interval and the initiator timing-event starts around the same time as the 1st central connection (C0) timing-event in the schedule. There is available time between C1 - C2 and between C2 - C3. Timing-event for new connection, Cn, is positioned in the available time between C2 - C3 because that is the best fit for Cn.

Figure 4. Initiator - one or more connections as a Central

Figure 5 illustrates the case when any free time between existing central link timing-events is not big enough to fit the new connection. The new central link timing-event is placed after all running central link timing-events in this case.

Figure 5. Initiator - free time not enough

When establishing connections to newly discovered devices, the Scanner may be used for discovery followed by the Initiator. In Figure 6, the Initiator is started directly after discovering a new device to connect as fast as possible to that device. The Initiator will always start asynchronously to the connected link events. The result is some link timing-events being dropped while the initiator timing-event runs. Link timing-events scheduled in the transmit window offset will not be dropped (C1). In this case time between C0 - C1 is available, and is allocated for the new connection (Cn).

Figure 6. Initiator - fast connection

Documentation feedback | Developer Zone | Subscribe | Updated 2016-12-09