RADIO — 2.4 GHz radio

The RADIO peripheral uses EasyDMA for reading of data packets from and writing to RAM, without CPU involvement.

As illustrated in RADIO block diagram, the RADIO's EasyDMA utilizes the same PACKETPTR for receiving and transmitting packets, and this pointer can only point to the Data RAM region. See Memory for more information about the different memoryregions.

The DISABLED event indicates that the EasyDMA has finished accessing the RAM.

The structure of a radio packet is described in detail in Packet configuration. The data that is stored in Data RAM and transported by EasyDMA consists of the following fields:

• S0
• LENGTH
• S1
• PAYLOAD

In addition, a static add-on is sent immediately after the payload.

The size of each of the above fields in the frame is configurable, and the space occupied in RAM depends on these settings. A size of zero is possible for any of the fields, it is up to the user to make sure that the resulting frame complies with the RF protocol chosen. For the field sizes defined in bits, the occupation in RAM will always be rounded up to the next full byte size (for instance 3 bit length will allocate 1 byte in RAM, 9 bit length will allocate 2 bytes, etc.).

The sizes of the fields S0, LENGTH and S1 can be individually configured by the S0LEN, LFLEN and S1LEN fields of the PCNF0 register respectively. The size of the payload is configured through the value in RAM corresponding to the LENGTH field. The size of the static add-on to the payload is configured through the STATLEN field in PCNF1 register.

The MAXLEN field in the PCNF1 register configures the maximum packet payload plus add-on size in number of bytes that can be transmitted or received by the RADIO. This feature can be used to ensure that the RADIO does not overwrite, or read beyond, the RAM assigned to the packet payload. This means that if the packet payload length defined by the PCNF1.STATLEN and the LENGTH field in the packet specify a packet larger than MAXLEN, the payload will be truncated at MAXLEN. The packet's LENGTH field will not be altered when the payload is truncated. The RADIO will calculate CRC as if the packet length is equal to MAXLEN.

RADIO packet contains the following fields: PREAMBLE, ADDRESS, S0, LENGTH, S1, PAYLOAD and CRC.

The content of a RADIO packet is illustrated in On-air packet layout. The RADIO sends the different fields in the packet in the order they are illustrated below, from left to right:

Figure 2. On-air packet layout

PREAMBLE is sent with least significant bit first on-air. The size of the PREAMBLE depends on the mode selected in the MODE register:

• The PREAMBLE is one byte for MODE = Ble_1Mbit as well as all Nordic proprietary operating modes (MODE = Nrf_1Mbit and MODE = Nrf_2Mbit), and the PLEN field in the PCNF0 register has to be set accordingly. If the first bit of the ADDRESS is 0 the preamble will be set to 0xAA otherwise the PREAMBLE will be set to 0x55.
• For MODE = Ble_2Mbit the PREAMBLE has to be set to 2 byte long through the PLEN field in the PCNF0 register. If the first bit of the ADDRESS is 0 the preamble will be set to 0xAAAA otherwise the PREAMBLE will be set to 0x5555.

Not shown in the figure above is the static payload add-on (the length of which is defined in PCNF1.STATLEN, and which is 0 bytes long in a standard BLE packet). The static payload add-on is sent between the PAYLOAD and CRC fields.

The RADIO packets are stored in memory, inside instances of a radio packet data structure as illustrated in In-RAM representation of radio packet - S0, LENGTH and S1 are optional. The PREAMBLE, ADDRESS and CRC fields are omitted in this data structure.

Figure 3. In-RAM representation of radio packet - S0, LENGTH and S1 are optional

The byte ordering on the air is always:

• Least significant byte first for the fields ADDRESS and PAYLOAD. The ADDRESS fields are also always transmitted and received least significant bit first on-air.
• Most significant byte first for the CRC field. The CRC field is also always transmitted and received most significant bit first.

The bit endianness, i.e. the order in which the bits are sent and received, is configured in PCNF1.ENDIAN for the fields S0, LENGTH, S1 and PAYLOAD.

The sizes of the fields S0, LENGTH and S1 can be individually configured in the S0LEN, LFLEN and S1LEN fields of the PCNF0 register respectively. If any of these fields are configured to be less than 8 bit long, the least significant bits of the fields are used, as seen from the RAM representation.

If S0, LENGTH or S1 are specified with zero length, their fields will be omitted in memory. Otherwise each field will be represented as a separate byte, regardless of the number of bits in their on-air counterpart.

Independent of the configuration of MAXLEN, the combined length of S0, LENGTH, S1 and PAYLOAD cannot exceed 258 bytes.

The on-air radio ADDRESS field is composed of two parts, the base address field and the address prefix field.

The size of the base address field is configurable via BALEN in PCNF1. The base address is truncated from LSByte if the BALEN is less than 4. See Definition of logical addresses.

The on-air addresses are defined in the BASEn and PREFIXn registers, and it is only when writing these registers the user will have to relate to actual on-air addresses. For other radio address registers such as the TXADDRESS, RXADDRESSES and RXMATCH registers, logical radio addresses ranging from 0 to 7 are being used. The relationship between the on-air radio addresses and the logical addresses is described in Definition of logical addresses.

The RADIO is able to do packet whitening and de-whitening.

See WHITEEN in PCNF1 register for how to enable whitening. When enabled, whitening and de-whitening will be handled by the RADIO automatically as packets are sent and received.

The whitening word is generated using polynomial g(D) = D⁷+ D⁴ + 1, which then is XORed with the data packet that is to be whitened, or de-whitened. See the figure below.

Figure 4. Data whitening and de-whitening

Whitening and de-whitening will be performed over the whole packet (except for the preamble and the address field).

The linear feedback shift register, illustrated in Data whitening and de-whitening can be initialised via the DATAWHITEIV register.

The CRC generator in the RADIO calculates the CRC over the whole packet excluding the preamble. If desirable, the address field can be excluded from the CRC calculation as well

See CRCCNF register for more information.

The CRC polynomial is configurable as illustrated in CRC generation of an n bit CRC where bit 0 in the CRCPOLY register corresponds to X⁰ and bit 1 corresponds to X¹ etc. See CRCPOLY for more information.

Figure 5. CRC generation of an n bit CRC

As illustrated in CRC generation of an n bit CRC, the CRC is calculated by feeding the packet serially through the CRC generator. Before the packet is clocked through the CRC generator, the CRC generator's latches b₀ through b_n will be initialized with a predefined value specified in the CRCINIT register. When the whole packet is clocked through the CRC generator, latches b₀ through b_n will hold the resulting CRC. This value will be used by the RADIO during both transmission and reception but it is not available to be read by the CPU at any time. A received CRC can however be read by the CPU via the RXCRC register independent of whether or not it has passed the CRC check.

The length (n) of the CRC is configurable, see CRCCNF for more information.

After the whole packet including the CRC has been received, the RADIO will generate a CRCOK event if no CRC errors were detected, or alternatively generate a CRCERROR event if CRC errors were detected.

The status of the CRC check can be read from the CRCSTATUS register after a packet has been received.

The RADIO can enter a number of states.

The RADIO can enter the states described the table below. An overview state diagram for the RADIO is illustrated in Radio states. This figure shows how the tasks and events relate to the RADIO's operation. The RADIO does not prevent a task from being triggered from the wrong state. If a task is triggered from the wrong state, for example if the RXEN task is triggered from the RXDISABLE state, this may lead to incorrect behaviour. As illustrated in Radio states, the PAYLOAD event is always generated even if the payload is zero.

Figure 6. Radio states

Before the RADIO is able to transmit a packet, it must first ramp-up in TX mode.

See TXRU in Radio states and Transmit sequence. A TXRU ramp-up sequence is initiated when the TXEN task is triggered. After the radio has successfully ramped up it will generate the READY event indicating that a packet transmission can be initiate. A packet transmission is initiated by triggering the START task. As illustrated in Radio states the START task can first be triggered after the RADIO has entered into the TXIDLE state.

Transmit sequence illustrates a single packet transmission where the CPU manually triggers the different tasks needed to control the flow of the RADIO, i.e. no shortcuts are used. If shortcuts are not used, a certain amount of delay caused by CPU execution is expected between READY and START, and between END and DISABLE. As illustrated in Transmit sequence the RADIO will by default transmit '1's between READY and START, and between END and DISABLED. What is transmitted can be programmed through the DTX field in the MODECNF0 register.

Figure 7. Transmit sequence

A slightly modified version of the transmit sequence from Transmit sequence is illustrated in Transmit sequence using shortcuts to avoid delays where the RADIO is configured to use shortcuts between READY and START, and between END and DISABLE, which means that no delay is introduced.

Figure 8. Transmit sequence using shortcuts to avoid delays

The RADIO is able to send multiple packets one after the other without having to disable and re-enable the RADIO between packets, this is illustrated in Transmission of multiple packets .

Figure 9. Transmission of multiple packets

Before the RADIO is able to receive a packet, it must first ramp up in RX mode

See RXRU in Radio states and Receive sequence. An RXRU ramp-up sequence is initiated when the RXEN task is triggered. After the radio has successfully ramped up it will generate the READY event indicating that a packet reception can be initiated. A packet reception is initiated by triggering the START task. As illustrated in Radio states the START task can, first be triggered after the RADIO has entered into the RXIDLE state.

Receive sequence illustrates a single packet reception where the CPU manually triggers the different tasks needed to control the flow of the RADIO, i.e. no shortcuts are used. If shortcuts are not used, a certain amount of delay, caused by CPU execution, is expected between READY and START, and between END and DISABLE. As illustrated Receive sequence the RADIO will be listening and possibly receiving undefined data, illustrated with an 'X', from START and until a packet with valid preamble (P) is received.

Figure 10. Receive sequence

A slightly modified version of the receive sequence from Receive sequence is illustrated in Receive sequence using shortcuts to avoid delays where the the RADIO is configured to use shortcuts between READY and START, and between END and DISABLE, which means that no delay is introduced.

Figure 11. Receive sequence using shortcuts to avoid delays

The RADIO is able to receive multiple packets one after the other without having to disable and re-enable the RADIO between packets, this is illustrated Reception of multiple packets.

Figure 12. Reception of multiple packets

The RADIO implements a mechanism for measuring the power in the received signal. This feature is called received signal strength indicator (RSSI).

The RSSI is measured continuously and the value filtered using a single-pole IIR filter. After a signal level change, the RSSI will settle after approximately RSSI_SETTLE.

Sampling of the received signal strength is started by using the RSSISTART task. The sample can be read from the RSSISAMPLE register.

The sample period of the RSSI is defined by RSSI_PERIOD. The RSSISAMPLE will hold the filtered received signal strength after this sample period.

For the RSSI sample to be valid, the RADIO has to be enabled in receive mode (RXEN task) and the reception has to be started (READY event followed by START task).

Interframe spacing is the time interval between two consecutive packets.

It is defined as the time (in microseconds) from the end of the last bit of the previous packet received and to the start of the first bit of the subsequent packet that is transmitted. The radio is able to enforce this interval as specified in the TIFS register as long as TIFS is not specified to be shorter than the radio’s turn-around time, i.e. the time needed to switch off the receiver, and switch back on the transmitter.

TIFS is only enforced if END_DISABLE and DISABLED_TXEN or END_DISABLE and DISABLED_RXEN shortcuts are enabled. TIFS is only qualified for use in BLE_1MBIT mode, and default ramp-up mode. The use of shortcuts and timing is illustrated in Ramp up and TIFS Timing Details.

Figure 13. Ramp up and TIFS Timing Details

The device address match feature is tailored for address white listing in a Bluetooth Smart and similar implementations.

This feature enables on-the-fly device address matching while receiving a packet on air. This feature only works in receive mode and as long as the radio is configured for little endian, see PCNF1.ENDIAN.

The device address match unit assumes that the 48 first bits of the payload is the device address and that bit number 6 in S0 is the TxAdd bit. See the Bluetooth Core Specification for more information about device addresses, TxAdd and whitelisting.

The radio is able to listen for eight different device addresses at the same time. These addresses are specified in a DAB/DAP register pair, one pair per address, in addition to a TxAdd bit configured in the DACNF register. The DAB register specifies the 32 least significant bits of the device address, while the DAP register specifies the 16 most significant bits of the device address.

Each of the device addresses can be individually included or excluded from the matching mechanism. This is configured in the DACNF register.

Radio implements a simple counter that can be configured to generate an event after a specific number of bits have been transmitted or received.

By using shortcuts, this counter can be started from different events generated by the radio and hence count relative to these.

The bit counter is started by triggering the BCSTART task, and stopped by triggering the BCSTOP task. A BCMATCH event will be generated when the bit counter has counted the number of bits specified in the BCC register. The bit counter will continue to count bits until the DISABLED event is generated or until the BCSTOP task is triggered. The CPU can therefore, after a BCMATCH event, reconfigure the BCC value for new BCMATCH events within the same packet.

The bit counter can only be started after the radio has received the ADDRESS event.

The bit counter will stop and reset on BCSTOP, STOP, END and DISABLE tasks.

The figure below illustrates how the bit counter can be used to generate a BCMATCH event in the beginning of the packet payload, and again generate a second BCMATCH event after sending 2 bytes (16 bits) of the payload.

Figure 14. Bit counter example