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  
tradio The total time of a Radio Activity in a connection 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)  
tevent 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.
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)
tradio

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

310 to tevent - ~900 - Connected roles

tprep 167 to 1542
tP ≤ 165
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 2017-03-10