: Radio Notification signals

Radio notification signals are used to inform the application about radio activity.

The Radio Notification signals are sent right before or at the end of defined time intervals of radio operation, namely the SoftDevice or application Radio Events¹.

Radio notifications behave differently when Connection Event Length Extension is enabled. Radio Notification with Connection Event Length Extension explains the behavior when this feature is enabled. Otherwise, this chapter assumes that the feature is disabled.

To ensure that the Radio Notification signals behave in a consistent way, the Radio Notification shall always be configured when the SoftDevice is in an idle state with no protocol stack or other SoftDevice activity in progress. Therefore, it is recommended to configure the Radio Notification signals directly after the SoftDevice has been enabled.

If it is enabled, the ACTIVE signal is sent before the Radio Event starts. Similarly, if the nACTIVE signal is enabled, it is sent at the end of the Radio Event. These signals can be used by the application developer to synchronize the application logic with the radio activity. For example, the ACTIVE signal can be used to switch off external devices to manage peak current drawn during periods when the radio is ON, or to trigger sensor data collection for transmission during the upcoming Radio Event.

The notification signals are sent using software interrupt as specified in Allocation of software interrupt vectors to SoftDevice signals.

As both ACTIVE and nACTIVE use the same software interrupt, it is up to the application to manage them. If both ACTIVE and nACTIVE are configured ON by the application, there will always be an ACTIVE signal before an nACTIVE signal.

Refer to Radio Notification notation and terminology for the notation that is used in this section.

When there is sufficient time between Radio Events (t_gap > t_ndist), both the ACTIVE and nACTIVE notification signals will be present at each Radio Event. Two radio events with ACTIVE and nACTIVE signals illustrates an example of this scenario with two Radio Events. The figure also illustrates the ACTIVE and nACTIVE signals with respect to the Radio Events.

Figure 1. Two radio events with ACTIVE and nACTIVE signals

When there is not sufficient time between the Radio Events (t_gap < t_ndist), the ACTIVE and nACTIVE notification signals will be skipped. There will still be an ACTIVE signal before the first event and an nACTIVE signal after the last event. This is shown in Two radio events without ACTIVE and nACTIVE signals between the events that illustrates two radio events where t_gap is too small and the notification signals will not be available between the events.

Figure 2. Two radio events without ACTIVE and nACTIVE signals between the events

Two radio events where tgap is too small and the notification signals will not be available between the events

Table 1. Radio Notification notation and terminology
Label	Description	Notes
ACTIVE	The ACTIVE signal prior to a Radio Event
nACTIVE	The nACTIVE signal after a Radio Event	Because both ACTIVE and nACTIVE use the same software interrupt, it is up to the application to manage them. If both ACTIVE and nACTIVE are configured ON by the application, there will always be an ACTIVE signal before an nACTIVE signal.
P	SoftDevice CPU processing in interrupt priority level 0 between the ACTIVE signal and the start of the Radio Event	The CPU processing may occur anytime, up to t_prep before the start of the Radio Event.
RX	Reception of packet
TX	Transmission of packet
t_radio	The total time of a Radio Activity in a connection event
t_gap	The time between the end of one Radio Event and the start of the following one
t_ndist	The notification distance - the time between the ACTIVE signal and the first RX/TX in a Radio Event	This time is configurable by the application developer.
t_prep	The time before first RX/TX available to the protocol stack to prepare and configure the radio	The application will be interrupted by a SoftDevice interrupt handler at priority level 0 t_prep time units before the start of the Radio Event. Note: All packet data to send in an event should be sent to the stack t_prep before the Radio Event starts.
t_P	Time used for preprocessing before the Radio Event
t_interval	Time period of periodic protocol Radio Events (e.g. Bluetooth® Low Energy connection interval)
t_event	Total Length of a Radio Event, including processing overhead	The length of a Radio Event for connected roles can be configured per connection by the application. This includes all the overhead associated with the Radio Event. This means that for a central link the event length is also the minimum time between the start of adjacent central role Radio events and between the last central role radio event and the scanner. Connection Event Length Extension does not affect the minimum time between central links.
t_ScanReserved	Reserved time needed by the SoftDevice for each ScanWindow

The application can configure t_ndist and set the following values (μs): 800, 1740, 2680, 3620, 4560, 5500.

Table 2. Bluetooth Low Energy Radio Notification timing ranges
Value	Range (μs)
t_prep	167 to 1542
t_P	≤ 165
t_ScanReserved	760

The timing range for t_radio depends on the radio activity, as shown in Bluetooth Low Energy Radio Activity (tradio) timing ranges for advertising on LE 1M PHY, Bluetooth Low Energy Radio Activity (tradio) timing ranges for Extended Advertising, and Bluetooth Low Energy Radio Activity (tradio) timing ranges for connected roles.

Table 3. Bluetooth Low Energy Radio Activity (t_radio) timing ranges for advertising on LE 1M PHY
Radio activity	Range
Undirected and scannable advertising - 0 to 31-byte payload, 3 channels	2750 to 5500 μs
Non-connectable advertising - 0 to 31-byte payload, 3 channels	2150 to 2950 μs
High-duty cycle directed advertising - 3 channels	1.28 s

Table 4. Bluetooth Low Energy Radio Activity (t_radio) timing ranges for Extended Advertising
PHY	Radio activity	Range (μs)
LE 1M PHY	Non-connectable and non-scannable advertising - 0 to 255 bytes, 3 primary advertising channels	2250 to 6650
	Connectable advertising - 0 to 238 bytes, 3 primary advertising channels	3300 to 5050
	Scannable advertising - 0 to 255 bytes, 3 primary advertising channels	2800 to 7550
LE 2M PHY	Non-connectable and non-scannable advertising - 0 to 255 bytes, 3 primary advertising channels	2200 to 4550
	Connectable advertising - 0 to 238 bytes, 3 primary advertising channels	2850 to 3750
	Scannable advertising - 0 to 255 bytes, 3 primary advertising channels	2600 to 5150
LE Coded PHY	Non-connectable and non-scannable advertising - 0 to 255 bytes, 3 primary advertising channels	8050 to 40800
	Connectable advertising - 0 to 238 bytes, 3 primary advertising channels	14300 to 28450
	Scannable advertising - 0 to 255 bytes, 3 primary advertising channels	10250 to 45900

Timing ranges for LE 1M PHY in Bluetooth Low Energy Radio Activity (tradio) timing ranges for Extended Advertising are valid when LE 1M PHY is used for both primary and secondary advertising channels. Timing ranges for LE 2M PHY are valid when LE 1M PHY is used for primary advertising channels and LE 2M PHY is used for secondary advertising channels. Timing ranges for LE Coded PHY are valid when LE Coded PHY is used for both primary and secondary advertising channels.

Note: For non-connectable and non-scannable advertising and scannable advertising, the advertiser sends multiple auxiliary packets with data when the number of data bytes is close to the limit of 255 bytes.

For connected roles, the time when the radio is active depends on the PHY. A higher bitrate reduces the radio activity time, while a lower bitrate increases the radio activity time.

Table 5. Bluetooth Low Energy Radio Activity (t_radio) timing ranges for connected roles
PHY	Range (μs)
LE 1M PHY	310 to t_event - 900
LE 2M PHY	230 to t_event - 900
LE Coded PHY	600 to t_event - 900

Based on Radio Notification notation and terminology, the amount of CPU time available to the application between the ACTIVE signal and the start of the Radio Event is:

t_ndist – t_P

The following expression shows the length of the time interval between the ACTIVE signal and the stack prepare interrupt:

t_ndist – t_{prep(maximum)}

If the data packets are to be sent in the following Radio Event, they must be transferred to the stack using the protocol Application Programming Interface (API) within this time interval.

Note: t_prep may be greater than t_ndist. If time is required to handle packets or manage peripherals before interrupts are generated by the stack, t_ndist must be set larger than the maximum value of t_prep.