Radio Notification Signals

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

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 the presented material 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 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 (tgap > tndist), 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 sufficient time between the Radio Events (tgap < tndist), 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 tgap 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 tprep before the start of the Radio Event.
RX Reception of packet.  
TX Transmission of packet.  
tevent The total time of a Radio Event.  
tgap The time between the end of one Radio Event and the start of the following one.  
tndist 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.
tprep 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 tprep 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 tprep before the Radio Event starts.
tP Time used for preprocessing before the Radio Event.  
tinterval Time period of periodic protocol Radio Events (e.g. BLE connection interval).  
tEEO 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. tEEO-C0 can be different for different connections, and it depends on the maximum packet payload size and the bandwidth configuration of the connection. See BLE role configuration for more information on the BLE stack configuration. Connection Event Length Extension does not affect tEEO.
tScanReserved Reserved time needed by the SoftDevice for each ScanWindow  
Table 2. BLE Radio Notification timing ranges
Value Range (μs)
tndist 800, 1740, 2680, 3620, 4560, 5500 (Configured by the application)
tevent

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 : 1700

Slave bandwidth MID : 3650

Slave bandwidth HIGH : 6550

Master bandwidth LOW : 1575

Master bandwidth MID : 3500

Master bandwidth HIGH : 6375

Note: Master and Slave tevent values are for full duplex transfer of 27 byte long packets, Connection Event Length Extension disabled.
tprep 167 to 1542
tP ≤ 165
tEEO

Bandwidth LOW : 1750

Bandwidth MID : 3700

Bandwidth HIGH : 6560

Note: These values are for full duplex transfer of 27 byte long packets.
tScanReserved 760

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:

tndist – tP

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

tndist – tprep(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: tprep may be greater than tndist when tndist = 800. If time is required to handle packets or manage peripherals before interrupts are generated by the stack, tndist must be set larger than 1550.
1 Application Radio Events are defined as Radio Timeslots, see Multiprotocol support.

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