S130 SDS v2.0: Radio Notification Signals

The Radio Notification signals are sent prior to and at the end of SoftDevice Radio Events or application Radio Events ¹, i.e. defined time intervals of radio operation.

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 Table 1.

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 Table 1 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. Figure 1 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.

When there is not sufficent 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 Figure 2.

Figure 1. Two radio events with ACTIVE and nACTIVE signals

Figure 2. Two radio events where t_gap is too small and the notification signals will not be available between the events

Table 1. Notation and terminology for the Radio Notification used in this chapter
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_event	The total time of a Radio 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. Important: All packet data to send in an event should have been 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. BLE connection interval).
t_EEO	Minimum time between central role Radio Events (Event-to-Event Offset).	The minimum time between the start of adjacent central role Radio events, and between the last central role radio event and the scanner. t_EEO-C0 can be different for different connections, and it depends on the bandwidth configuration of the connection. See BLE role configuration for more information on the BLE stack configuration.
t_ScanReserved	Reserved time needed by the SoftDevice for each ScanWindow

Table 2. BLE Radio Notification timing ranges
Value	Range (μs)
t_ndist	800, 1740, 2680, 3620, 4560, 5500 (Configured by the application)
t_event	2750 to 5500 - Undirected and scannable advertising, 0 to 31 byte payload, 3 channels 2150 to 2950 - Non-connectable advertising, 0 to 31 byte payload, 3 channels 1.28 seconds - Directed advertising, 3 channels Slave bandwidth LOW : 2050 Slave bandwidth MID : 4000 Slave bandwidth HIGH : 6900 Master bandwidth LOW : 1900 Master bandwidth MID : 3850 Master bandwidth HIGH : 6725 Note: Master and Slave t_event values are for full duplex transfer of full packets.
t_prep	167 to 1542
t_P	≤ 165
t_EEO	Bandwidth LOW : 2100 Bandwidth MID : 4025 Bandwidth HIGH : 6900 Note: These values are for full duplex transfer of full packets.
t_ScanReserved	1125

Based on the numbers from Table 2, 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 API within this time interval.

Important: t_prep may be greater than t_ndist when t_ndist = 800. If time is required to handle packets or manage peripherals before interrupts are generated by the stack, t_ndist must be set larger than 1550.