Primary channel scanner timing

The following figure shows that when scanning for advertisers with no active connections, the scan interval and window can be any value within the Bluetooth Core Specification.

Figure 1. Scanner timing - no active connections
Scanner timing - no active connections

The examples in this section demonstrate a Scanner that is configured to listen on one PHY, resulting in one Scanner timing-event. Correspondingly, listening on two PHYs would result in two Scanner timing-events.

Figure 2. Scanner timing when scanning on two PHYs
Scanner timing when scanning on two PHYs

A primary channel scanner timing-event is always placed after the central link timing-events. Scanner timing - one or more connections as a Central shows that when there are one or more active connections, the scanner or observer role timing-event will be placed after the link timing-events. With scanInterval equal to the connectionInterval and a scanWindow ≤ (connectionInterval - (∑ tevent + tScanReserved)), scanning will proceed without overlapping with central link timing-events.

Figure 3. Scanner timing - one or more connections as a Central
Scanner timing - one or more connections as a Central

The following figure shows a scenario where free time is available between link timing-events, but still the scanner timing-event is placed after all connections.

Figure 4. Scanner timing - always after connections
Scanner timing - always after connections

The following figure shows a Scanner with a long scanWindow which will cause some connection timing-events to be dropped.

Figure 5. Scanner timing - one connection, long window
Scanner timing - one connection, long window