This blog is to describe more details how to use the Radio Timeslot API usage. The Radio Timeslot API was introduced since Nordic Softdevice S110v6.0 or later. It can be used to implement the concurrent multiprotocol with BLE together. All the timeslot API are based on the framework of Nordic Bluetooth Softdevice stack.

For example, it can run on difference scenarios.

  • BLE (softdevice) + Timeslot api (Observer / Advertiser)
  • BLE + ESB proprietary radio
  • BLE + Zigbee
  • BLE + Bluetooth MESH
  • BLE + Thread

Bluetooth + Bluetooth MESH

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/introducing-nrf5-sdk-for-mesh

Multiprotocol support with BLE/Bluetooth

multiprotocol_dynamic.svg
Dynamic multiprotocol (example of Thread and BLE)

The nRF System-on-Chip supports multiple radio protocols. Applications running on the nRF SoC can use several radio protocols, but only one at a time. You can implement concurrency as either switched multiprotocol or dynamic multiprotocol.

https://infocenter.nordicsemi.com/topic/sdk_tz_v4.1.0/ble_154_multiprotocol.html

Radio Timeslot API

The timeslot API can be found details description on the softdevice specifications.

Also, here is the post from the Nordic Devzone.

Setting up the Timeslot API

https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/setting-up-the-timeslot-api

When you want to use the radio while still maintaining a BLE connection or have a task that you need to do uninterrupted by radio activity, you can set up a timeslot. The timeslot is a period of time from 100 µs to 128 s in which the SoftDevice will render full control over the radio and other restricted peripherals to the user.

Introduction

The application requests a timeslot, which can range from 100 µs to 100 ms. Longer timeslots can be granted by requesting extensions, up to a maximum of 128 s.

Timeslots are requested within a session, which can consist of multiple timeslots. Different types of sessions can be seen in the timeslot usage examples in Infocenter.

When the timeslot is requested, the application needs to tell the SoftDevice to use either high or normal priority for the timeslot. For most applications normal priority should be used to avoid conflicts. If you have an application that is highly time critical, such as a proprietary radio protocol, use high priority.

There are two types of requests: earliest possible and given time.

  • Earliest possible is for one-shot or reactive events and will give a timeslot at the earliest possible time.
  • Given time is for recurring events and is granted an amount of time after the previous timeslot started.

When a timeslot has been granted the application will gain access to the RADIO, TIMER0, CCM, AAR, and PPI(ch 14-15) modules for the duration of the timeslot.

Please refer to chapter 11 of the S130/S132 SoftDevice specification for more in depth information.

Timeslot events and actions

The following are the timeslot functions:

  • sd_radio_session_open() – Open a session
  • sd_radio_session_close() – Close a session
  • sd_radio_request() – Request a timeslot

Timeslot events

In addition to these calls there is a signal handler that is called through the system event dispatcher, it contains these cases:

  • NRF_EVT_RADIO_SESSION_IDLE – The session has no remaining scheduled timeslots. If this event is triggered the application ends the session. Note that it is also possible to request new timeslots here(more on that later).
  • NRF_EVT_RADIO_SESSION_CLOSED – The session is closed and all acquired resources are released.
  • NRF_EVT_RADIO_BLOCKED – The requested timeslot could not be scheduled due to a collision with other activities. The application should request a new timeslot either at the earliest possible, or at the next normal position.
  • NRF_EVT_RADIO_CANCELED – The scheduled timeslot was cancelled by higher priority activity. The application should request a new timeslot.
  • NRF_EVT_RADIO_SIGNAL_CALLBACK_INVALID_RETURN – The last signal handler return value contained invalid parameters. Your application should assert.

Timeslot signals

The timeslot handler is called as an argument when opening a radio session. The timeslot handler will handle these cases:

  • NRF_RADIO_CALLBACK_SIGNAL_TYPE_START – The start of the timeslot. The application now has access to peripherals for the length of the timeslot. Before you start initializing your timeslot you must use a timer(for example TIMER0) that triggers an event 100 µs or so before the timeslot expires. TIMER0 is started automatically from zero by the SoftDevice at the start of the timeslot and is configured to run at 1 MHz. If you do not manage to do graceful shutdown by the end of the timeslot your application will hardfault.
  • NRF_RADIO_CALLBACK_SIGNAL_TYPE_RADIO – Radio interrupt, see the infocenter on the 2.4GHz radio for more information.
  • NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 – Timer interrupt. This is where the interrupt from the graceful shutdown timer that you set up earlier ends up. Here you should deinitialize and prepare to return to SoftDevice activity. This is also where you can request the next timeslot.
  • NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_SUCCEDED – The latest session extension succeeded. Normally no action is needed here.
  • NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_FAILED – The latest session extension failed, attempt to reschedule your timeslot.

The timeslot handler returns some callback parameters, which are used by the SoftDevice. Usage will be documented later.

  • NRF_RADIO_SIGNAL_CALLBACK_ACTION_NONE – Do nothing
  • NRF_RADIO_SIGNAL_CALLBACK_ACTION_END – Signals that the ongoing timeslot event is finished. The SoftDevice can resume its activities. Usually used to terminate an idle ongoing timeslot.
  • NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END – Signals that the ongoing timeslot event is finished, requests a new timeslot before signaling that the SoftDevice can resume its activities.
  • NRF_RADIO_SIGNAL_CALLBACK_ACTION_EXTEND – Attempt to extend an ongoing timeslot

The timeslot handler runs at the highest interrupt priority, 0, therefore you are not able to call functions that have lower priority.

Github example

Example 1: How to use the timeslot API to do the BLE Advertiser or BLE Observer

https://github.com/NordicPlayground/nRF51-multi-role-conn-observer-advertiser

This project utilizes the Concurrent Multi-protocol Timeslot API in Nordic Semiconductor’s S110 v8.0 SoftDevice for the nRF51-series micro-controllers to run a scannable advertiser concurrently with the SoftDevice. The provided build scripts and project files support both the PCA10028 and PCA10031 development boards.

This project also contains an example of how to run a concurrent multi-protocol observer concurrently with the SoftDevice.

The Timeslot advertiser and scanner accept a subset of the HCI command interface to control various parameters of their behaviour.

Scan Requests that arrive at the advertiser are also sent to the application. The scan requests are sent with the address, RSSI, channel and an experimental link quality indicator.

The experimental link quality indicator that counts the number of packets with CRC failures and the number packets with successful CRC has been added. This allows the application to have some awareness of the link quality. The link quality is returned by the observer and by the scannable advertiser.

Example 2: Running micro-ESB concurrently with BLE

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/running-micro-esb-concurrently-with-ble

Using proprietary protocols can be an effective way of addressing shortcomings in BLE. When communicating between two nRF chips, one can for example use a different packet format or different symbol rate to improve throughput or increase range.

Getting started with micro-ESB on nRF51 discusses the ESB protocol and the micro-ESB implementation specfically. Now we will look at how one can run a protocol such as ESB concurrently (interleaved) with BLE (or ANT) by leveraging the Timeslot feature of the nRF5x SoftDevices.

Timeslot API

The Timeslot API allows the application to request slots of uninterrupted time. During these timeslots, the application has access to all hardware, including the radio. We can use these timeslots to run the ESB protocol for example. This opens up some interesting opportunities, as nRF chips can communicate among themselves using a more specialized protocol without breaking BLE connections with other devices.

The “Concurrent Multiprotocol Timeslot API” section of the SoftDevice Specification document describes this feature in more detail, and it’s strongly recommended to read before proceeding.

The Setting up the timeslot API tutorial is also worthwhile to look at, as this looks at the API in more detail than this blog post.