RADIO — 2.4 GHz radio

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

Not shown in the figure is the static payload add-on (the length of which is defined in STATLEN, and which is 0 bytes long in a standard BLE packet). The static payload add-on is sent between PAYLOAD and CRC fields. The radio sends the different fields in the packet in the order they are illustrated above, from left to right. The preamble will be sent with least significant bit first on air.

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.

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.
• For MODE = Ble_LR125Kbit and MODE = Ble_LR500Kbit the PREAMBLE is 10 repetitions of 0x3C.
• For MODE = Ieee802154_250Kbit the PREAMBLE is 4 bytes long and set to all zeros.

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, CI, TERM1, TERM2 and CRC fields are omitted in this data structure.

The byte ordering on air is always least significant byte first for the ADDRESS and PAYLOAD fields and most significant byte first for the CRC field. The ADDRESS fields are always transmitted and received least significant bit first on air. The CRC field is always transmitted and received most significant bit first. The bit-endian, i.e. the order in which the bits are sent and received, of the S0, LENGTH, S1 and PAYLOAD fields can be configured via the ENDIAN in PCNF1.

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

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 the least significant byte 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.

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.

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.

Tasks and events are used to control the operating state of the RADIO.

An overview state diagram for the RADIO is illustrated in Radio states.

Note: The END to START shortcut should not be used with Ble_LR125Kbit, Ble_LR500Kbit and Ieee802154_250Kbit modes. Rather the PHYEND to START shortcut.

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.

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.

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.

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 .

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, represented with an 'X', from START and until a packet with valid preamble (P) is received.

A slightly modified version of the receive sequence from Receive sequence is illustrated in Receive 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.

The RADIO is able to receive multiple packets one after the other without having to disable and re-enable the RADIO between packets as illustrated in 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 the TIFS is not specified to be shorter than the RADIO's turnaround time, i.e. the time needed to switch off the receiver, and then switch the transmitter back on. The TIFS register can be written any time before the last bit on air is received.

This timing is illustrated in the figure below.

As illustrated, the TIFS duration starts after the last bit on air (just before the END event), and elapses with first bit being transmitted on air (just after READY event).

TIFS is only enforced if END_DISABLE and DISABLED_TXEN or END_DISABLE and DISABLED_RXEN shortcuts are enabled. TIFS is qualified for use in BLE_1MBIT, BLE_2MBIT, BLE_LR125KBIT, BLE_LR500KBIT and Ieee802154_250Kbit mode using the default ramp-up mode. SHORTS and TIFS are not double-buffered, and can be updated at any point in time before the last bit on air is received. The MODE register is double-buffered and sampled at the TXEN or RXEN task.

The device address match feature is tailored for address whitelisting in a Bluetooth low energy 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 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.

The 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.

With the MODE=Ieee802154_250kbit the radio module will comply with the IEEE 802.15.4-2006 standard implementing its 250 kbps 2450MHz O-QPSK PHY.

The IEEE 802.15.4 standard differs from Nordic's proprietary and Bluetooth low energy modes. Obvious differences are modulation scheme and channel structure, but also packet structure, security and medium access control.

The RADIO 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. This pointer should be reconfigured by the CPU each time before RADIO is started by the START task. The PACKETPTR registers is double-buffered, meaning that it can be updated and prepared for the next transmission.

The END event indicates that the last bit has been processed by the radio. The DISABLED event is issued to acknowledge that a DISABLE task is done.

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 (see Packet configuration), 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.

All fields are extended in size to align with a byte boundary in RAM. For instance a 3 bit long field on air will occupy 1 byte in RAM while a 9 bit long field will be extended to 2 bytes.

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 PCNF1.STATLEN and the LENGTH field in the packet specifies a packet larger than MAXLEN, the payload will be truncated at MAXLEN.

If the payload and add-on length is specified larger than MAXLEN, the RADIO will still transmit or receive in the same way as before, except the payload is now truncated to 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.

The END event indicates that the last bit has been processed by the radio. The DISABLED event is issued to acknowledge that an DISABLE task is done.