RADIO — 2.4 GHz radio

A RADIO packet contains the fields PREAMBLE, ADDRESS, S0, LENGTH, S1, PAYLOAD, and CRC. For Long Range (125 kbps and 500 kbps) Bluetooth Low Energy modes, fields CI, TERM1, and TERM2 are also included.

The content of a RADIO packet is illustrated in the following figures. RADIO sends the fields in the packet according to the sequence shown in the figures, starting on the left.

Not shown in the figures is the static payload add-on (the length of which is defined in PCNF1.STATLEN, and which is 0 bytes in a standard BLE packet). The static payload add-on is sent between PAYLOAD and CRC fields. RADIO sends the different fields in the packet in the order they are illustrated above, from left to right.

PREAMBLE is sent with least significant bit first on air. The size of the PREAMBLE depends on the mode selected in the MODE register, and is configured using PCNF0.PLEN.

Radio packets are stored in memory inside instances of a RADIO packet data structure as shown in the following figure. The PREAMBLE, ADDRESS, CI, TERM1, TERM2, and CRC fields are omitted in this data structure. Fields S0, LENGTH, and S1 are optional.

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. The CRC field is always transmitted and received most significant bit first. The endianness, meaning the order in which the bits are sent and received, of the S0, LENGTH, S1, and PAYLOAD fields can be configured via PCNF1.ENDIAN.

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, 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 PCNF1.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 the PCNF1.BALEN register. The base address is truncated from the least significant byte if PCNF1.BALEN is less than 4. See Definition of logical addresses.

The on-air addresses are defined in the BASE0/BASE1 registers and PREFIX0/PREFIX1 registers. It is only when writing these registers that the user must relate to the 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 used. The relationship between the on-air radio addresses and the logical addresses is described in the following table.

Packet whitening and de-whitening is possible with RADIO and is enabled in PCNF1.WHITEEN. When enabled, whitening and de-whitening will be handled by RADIO automatically as packets are sent and received.

The data whitening is done by means of a configurable linear feedback shift register in a one-to-many topology, as illustrated in the following figure. Bit 0 is used to exclusive OR (XOR) the data packet that is to be whitened or de-whitened. The linear feedback shift register is configured and initialized using the DATAWHITE register. The reset value for the DATAWHITE.POLY field is compatible with Bluetooth Low Energy. The initial vector is configured in DATAWHITE.IV.

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

Including the address field in CRC check (CRCCNF.SKIPADDR = Include) is not supported for whitened packets.

The cyclic redundancy check (CRC) generator in RADIO calculates the CRC over the whole packet excluding the preamble.

The device also supports excluding the address field from the CRC calculation, see the CRCCNF.SKIPADDR register for more information.

The CRC polynomial is configurable as illustrated in the following figure, where bit 0 in the register CRCPOLY corresponds to X⁰ and bit n corresponds to Xⁿ. See CRCPOLY for more information.

The figure shows that 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_[0..n] will be initialized with a predefined value specified in the register CRCINIT. After the whole packet has been clocked through the CRC generator, b_[0..n] will hold the resulting CRC. This value will be used by RADIO during both transmission and reception. The CPU cannont read latches b_[0..n] at any time. However, a received CRC can be read by the CPU via the register RXCRC.

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

When the entire packet including the CRC has been received, and no errors were detected, RADIO generates the event CRCOK. If CRC errors were detected, the event CRCERROR is generated.

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

Tasks and events are used to control the operating state of RADIO when in RX mode or TX mode.

A simplified state diagram without the optional states SETTLE and PLL is shown in the following figure.

A second state diagram is shown in the following figure. This diagram only contains the specific transitions involving SETTLE and PLL. This way of operating the RADIO enables keeping the PLL on and locked without enabling RX or TX.

This figure shows how the tasks and events relate to the RADIO peripheral's operation. RADIO does not prevent a task from being triggered from the wrong state. For example, if the RXEN task is triggered from the RXDISABLE state, this may lead to unpredictable behavior. The PAYLOAD event is always generated, even if the payload is zero.

The END to START shortcut should not be used with IEEE 802.15.4 250 kbps mode. Use the PHYEND to START shortcut instead.

The END to START shortcut should not be used with Long Range (125 kbps and 500 kbps) Bluetooth Low Energy modes. Use the PHYEND to START shortcut instead.

Before RADIO can transmit a packet, it must first ramp-up in TX mode. See TXRU in Radio states without PLL and Transmit sequence. A TXRU ramp-up sequence is initiated when the TXEN task is triggered. After RADIO has successfully ramped up, it will generate the READY event indicating that a packet transmission can be initiated. A packet transmission is initiated by triggering the START task. The START task can first be triggered after RADIO has entered into the TXIDLE state.

The following figure illustrates a single packet transmission where the CPU manually triggers the different tasks needed to control the flow of RADIO, meaning 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 PHYEND and DISABLE. As illustrated in the following figure, RADIO will by default transmit an unmodulated carrier between READY and START, and between PHYEND and DISABLED.

The following figure shows a transmit sequence where no delay is introduced. RADIO is configured to use shortcuts between READY and START, and between PHYEND and DISABLE.

RADIO is able to send multiple packets one after the other without having to disable and re-enable RADIO between packets, as illustrated in the following figure.

Before RADIO is able to receive a packet, it must first ramp up in RX mode. See RXRU in Radio states without PLL and Receive sequence for more information.

An RXRU ramp-up sequence is initiated when the RXEN task is triggered. After 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 without PLL, the START task can first be triggered after RADIO has entered the RXIDLE state.

The following figure shows a single packet reception where the CPU manually triggers the tasks needed to control the flow of RADIO, meaning 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 PHYEND and DISABLE. 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.

The following figure shows a receive sequence where no delay is introduced. RADIO is configured to use shortcuts between READY and START, and between PHYEND and DISABLE.

RADIO can receive consecutive packets without having to disable and re-enable RADIO between packets, as illustrated in the following figure.

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

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

Sampling 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, RADIO has to be enabled in RX mode by triggering the RXEN task and the reception has to be started with the READY event followed by START task.

Interframe spacing (IFS) is defined as the time in microseconds between two consecutive packets, starting from when the end of the last bit of the previous packet is received, to the beginning of the first bit of the subsequent packet that is transmitted.

RADIO can enforce this interval, as specified in the TIFS register, as long as the TIFS register is not specified to be shorter than the RADIO peripheral's turnaround time (meaning the time needed to switch off the receiver and then switch on the transmitter). The TIFS register can be written any time before the last bit on air is received.

This timing is illustrated in the following figure.

The TIFS duration starts after the last bit on air (at the PHYEND event), and elapses with the first bit being transmitted on air (just after READY event).

TIFS is only enforced if the shortcuts PHYEND to DISABLE and DISABLED to TXEN or PHYEND to DISABLE and DISABLED to RXEN are enabled. The short READY to START must also be enabled. In these configurations, TXEN or RXEN is automatically delayed to achieve the configured interframe spacing.

TIFS is qualified for use in IEEE 802.15.4 250kbps mode, Bluetooth Low Energy Long Range (125 kbps and 500 kbps) modes, and Bluetooth Low Energy 1 Mbps and 2 Mbps modes, using the Legacy ramp-up mode.

SHORTS and TIFS registers are not double-buffered and can be updated at any point before the last bit on air is received.

The device address match feature is tailored for device filtering in Bluetooth Low Energy and similar implementations.

This feature enables on-the-fly device address matching while receiving a packet over-the-air. This feature only works in RX mode and when RADIO is configured for little endian, see PCNF1.ENDIAN for more information.

The device address match unit assumes that the first 48 bits of the payload are 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 the device filtering procedure.

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 has been transmitted or received.

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

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 bits specified in register BCC. The bit counter will continue to count bits until the DISABLED event is generated or until the BCSTOP task is triggered. After the BCMATCH event, the CPU can reconfigure the value BCC for new BCMATCH events within the same packet.

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

The bit counter will stop and reset for the tasks BCSTOP, STOP, or DISABLE, or the event END.

The following figure shows how the bit counter can be used to generate the 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.

The IEEE standard 802.15.4 differs from the Nordic proprietary and Bluetooth Low Energy modes. Differences include modulation scheme, channel structure, packet structure, security, and medium access control.

To enable RADIO to comply with the IEEE 802.15.4-2020 standard, set MODE = Ieee802154_250kbit.

IEEE 802.15.4 defines an on-the-air frame/packet that is different from what is used in Bluetooth Low Energy.

The following figure provides an overview of the physical frame structure and its timing.

The standard uses the term octet for an 8-bit storage unit within the PPDU. For timing, the value symbol is used, and it has a duration of 16 µs.

The total usable payload (PSDU) is 127 octets, but when CRC is in use, this is reduced to 125 octets of usable payload.

The preamble sequence consists of four octets that are all 0 and are used for synchronizing the RADIO peripheral's receiver. Following the preamble is the single octet start of frame delimiter (SFD), with a fixed value of 0xA7. An alternate SFD can be programmed through the SFD register, providing an initial level of frame filtering when non-standard compliance is chosen. It is a valuable feature when operating in a congested or private network. The preamble sequence and the SFD are generated by RADIO and are not programmed by the user into the frame buffer.

Following the five octet synchronization header (SHR) is the single octet PHY header (PHR). The least significant seven bits of PHR denote the frame length of the following PSDU. The most significant bit is reserved and is set to 0 for frames that are standard compliant. RADIO reports all eight bits which can be used to carry additional information. The PHR is the first byte written to the frame data memory pointed to by PACKETPTR. Frames with zero length are discarded, and the FRAMESTART event is not generated in this case.

The next N octets carry the data of the PHY packet, where N equals the value of the PHR. For an implementation also using the IEEE 802.15.4 medium access control (MAC) layer, the PHY data is a MAC frame of N-2 octets, because two octets occupy a CRC field.

The two FCF octets contain information about the frame type, addressing, and other control flags. This field is decoded when using the assisted operating modes offered by RADIO.

The sequence number is a single octet in size and is unique for a frame. It is used in the associated acknowledgement frame sent upon successful frame reception.

The addressing field can be zero (acknowledgement frame) or up to 20 octets in size. The field is used to direct packets to the correct recipient and denote its origin. IEEE 802.15.4 bases its addressing on networks being organized in PANs with 16-bit identifier and nodes having a 16-bit or 64-bit address. In the assisted receive mode, these parameters are analyzed for address matching and acknowledgement.

The MAC payload carries the data of the next higher layer, or in the case of a MAC command frame, information used by the MAC layer itself.

The two last octets contain the 16-bit ITU-T CRC. The FCS is calculated over the MAC header (MHR) and MAC payload (MSDU) parts of the frame. This field is calculated automatically when sending a frame, or indicated in the CRCSTATUS register when a frame is received. If configured, this feature is maintained autonomously by the CRC module.

In order to determine the presence of activity, IEEE 802.15.4 requires that the received signal power within the channel bandwidth can be sampled.

To prevent the channel signal from being decoded, the shortcut between the READY event and the START task should be disabled before putting RADIO in RX mode. The energy detection (ED) measurement time, where RSSI samples are averaged, is 8 symbol periods, corresponding to 128 µs. The standard further specifies the measurement to be a number between 0 and 255, where 0 indicates received power less than 10 dB above the selected receiver sensitivity. The power range of the ED values must be at least a 40 dB linear mapping with accuracy of ±6 dB. See section 6.9.7 Receiver ED in IEEE 802.15.4 for further details.

The following example shows how to perform a single energy detection measurement and convert to IEEE 802.15.4 scale.

#define ED_RSSISCALE 4 // From electrical specifications
uint8_t sample_ed(void)
{
    int val;
    NRF_RADIO->TASKS_EDSTART = 1; // Start
    while (NRF_RADIO->EVENTS_EDEND != 1) {
        // CPU can sleep here or do something else
        // Use of interrupts are encouraged
        }
    val = NRF_RADIO->EDSAMPLE * ED_RSSISCALE; // Read level
    return (uint8_t)(val>255 ? 255 : val);    // Convert to IEEE 802.15.4 scale
}

For scaling between hardware value and dBm, see Clear channel assessment (CCA).

The mlme-scan.reqprimitive of the MAC layer uses the ED measurement to detect channels where there might be wireless activity. To assist this primitive, a tailored mode of operation is available where the ED measurement runs for a defined number of iterations keeping track of the maximum ED level. This is engaged by writing the EDCNT field of the EDCTRL register to a value different from 0, where it will run the specified number of iterations and report the maximum energy measurement in the EDSAMPLE register. The scan is started with the EDSTART task and the end indicated with the EDEND event. This significantly reduces the interrupt frequency and therefore power consumption. The following figure shows how the ED measurement will operate depending on the EDCNT and EDPERIOD fields of the EDCTRL register.

The scan is stopped by writing the EDSTOP task. It is followed by the EDSTOPPED event when the module has terminated.

IEEE 802.15.4 implements a listen-before-talk channel access method to avoid collisions when transmitting. This is known as carrier sense multiple access with collision avoidance (CSMA-CA). The key part of this method is measuring if the wireless medium is busy or not.

The following clear channel assessment modes are supported:

• CCA Mode 1 (energy above threshold) – The medium is reported busy upon detecting any energy above the ED threshold.
• CCA Mode 2 (carrier sense only) – The medium is reported busy upon detection of a signal compliant with IEEE 802.15.4 with the same modulation and spreading characteristics.
• CCA Mode 3 (carrier sense with energy above threshold) – The medium is reported busy using a logical combination (AND/OR) between the results from CCA Mode 1 and CCA Mode 2.

The clear channel assessment should survey a period equal to 8 symbols or 128 µs.

RADIO must be in RX mode and be able to receive correct packets when performing the CCA. The shortcut between READY and START must be disabled if baseband processing is not to be performed while the measurement is running.

Register EDSAMPLE is updated at the end of the clear channel assessment and can be used to read the energy level measured during the procedure. For CCACTRL.CCAMODE = EdModeEdModeTest1, EDSAMPLE holds the first ED measurement. For the other CCA modes, EDSAMPLE holds the average ED value.

PRF[dBm] = ED_RSSIOFFS + VALHARDWARE

PRF[802.15.4 units] = MIN( ED_RSSISCALE x VALHARDWARE, 255 )

IEEE 802.15.4 uses a 16-bit ITU-T cyclic redundancy check (CRC) calculated over the MAC header (MHR) and MAC service data unit (MSDU).

The standard defines the following generator polynomial:

G(x) = x¹⁶ + x¹² + x⁵ + 1

In RX mode, RADIO will trigger the CRC module when the first octet after the frame length (PHR) is received. The CRC will then update on each consecutive octet received. When a complete frame is received, the CRCSTATUS register will be updated accordingly and the CRCOK or CRCERROR events will be generated. When the CRC module is enabled, it will not write the two last octets (CRC) to the frame RAM. When transmitting, the CRC will be computed on the fly, starting with the first octet after PHR, and inserted as the two last octets in the frame. The EasyDMA will fetch the frame length minus 2 octets from RAM and insert the CRC octets at their correct positions in the frame.

The following code shows how to configure the CRC module for correct operation when in IEEE 802.15.4 mode. The CRCCNF is written to 16-bit CRC and the CRCPOLY is written to 0x11021. The start value used by IEEE 802.15.4 is 0 and CRCINIT is configured to reflect this.

/* 16-bit CRC with ITU-T polynomial with 0 as start condition*/
NRF_RADIO->CRCCNF = ((RADIO_CRCCNF_SKIPADDR_Ieee802154 << RADIO_CRCCNF_SKIPADDR_Pos) |
                    (RADIO_CRCCNF_LEN_Two << RADIO_CRCCNF_LEN_Pos));
NRF_RADIO->CRCPOLY = 0x11021;
NRF_RADIO->CRCINIT = 0;

The ENDIANESS subregister must be set to little-endian since the FCS field is transmitted from the left bit to the right bit.

The transmission is started by first putting RADIO in RX mode and triggering the RXEN task .

An outline of the IEEE 802.15.4 transmission is illustrated in the following figure.

The receiver will ramp up and enter the RXIDLE state where the READY event is generated. Upon receiving the READY event, the CCA is started by triggering the CCASTART task. The chosen mode of assessment (register CCACTRL.CCAMODE) will be performed and signal the CCAIDLE event or CCABUSY event 128 µs later. If the event CCABUSY is received, RADIO will have to retry the CCA after a specific back-off period. This is outlined in the IEEE 802.15.4 standard, Figure 69 in section 7.5.1.4 The CSMA-CA algorithm.

If the event CCAIDLE is generated, a write to the task register TXEN enters RADIO in TXRU state. The READY event will be generated when RADIO is in the TXIDLE state and ready to transmit. With the PACKETPTR pointing to the length (PHR) field of the frame, the START task can be written. RADIO will send the four octet preamble sequence followed by the start of frame delimiter (register SFD). The first byte read from RAM is the length field (PHR) followed by the transmission of the number of bytes indicated as the frame length. If the CRC module is configured, it will run for PHR-2 octets. The last two octets will be substituted with the results from running the CRC. The necessary CRC parameters are sampled on the START task. The FCS field of the frame is little endian.

In addition to the available shortcuts, one is provided between the READY event and the CCASTART task so that a CCA can automatically start when the receiver is ready. A second shortcut has been added between the CCAIDLE event and the TXEN task, when a clear channel is detected, RADIO can immediately enter TX mode.

RADIO must be in RX mode before the receive sequence can begin. After writing to the RXEN task, RADIO will start ramping up and enter the RXRU state.

When the READY event is generated, RADIO enters the RXIDLE mode. For the baseband processing to be enabled, the START task must be written. An outline of the IEEE 802.15.4 receive sequence can be found in the following figure.

When a valid SHR is received, RADIO will start storing future octets (starting with PHR) to the data memory pointed to by PACKETPTR. After the SFD octet is received, the FRAMESTART event is generated. If the CRC module is enabled, it will start updating with the second byte received (first byte in payload) and run for the full frame length. The two last bytes in the frame are not written to RAM when CRC is configured. However, if the result of the CRC is zero after running the full frame, the CRCOK event will be generated. The END event is generated when the last octet has been received and is available in data memory.

When a packet is received, a link quality indicator (LQI) is generated and appended immediately after the last received octet. When using an IEEE 802.15.4 compliant frame, this will be just after the MSDU since the FCS is not reported. In the case of a non-compliant frame, it will be appended after the full frame. The LQI reported by the hardware must be converted to the IEEE 802.15.4 range by an 8-bit saturating multiplication of 4, as shown in IEEE 802.15.4 ED measurement example. The LQI is only valid for frames equal to, or longer than, three octets. When receiving a frame, the RSSI (reported as negative dB) will be measured at three points during the reception. These three values will be sorted with the middle value selected (median 3) to be remapped within the LQI range. The following figure illustrates the LQI measurement and how the data is arranged in data memory.

A shortcut has been added between the FRAMESTART event and the BCSTART task. This can be used to trigger a BCMATCH event after N bits, such as when inspecting the MAC addressing fields.

IEEE 802.15.4 defines a specific time that is allotted for the MAC sublayer to process received data. The interframe spacing (IFS) is used to prevent two frames from being transmitted too close together. If the transmission is requesting an acknowledgement, the space before the second frame must be at least one IFS period.

Using the efficient assisted modes in RADIO, the TIFS will be programmed with the correct value based on the frame being transmitted. If the assisted modes are not in use, the TIFS register must be updated manually. The following figure shows what IFS period is valid in both acknowledged and unacknowledged transmissions.

RADIO uses EasyDMA to read and write packets to RAM without CPU involvement.

As illustrated in RADIO block diagram, the RADIO peripheral'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 register 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 RADIO. The DISABLED event is issued to acknowledge that the DISABLE task is done.

The structure of a 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 listed fields in the frame is configurable (see Packet configuration), and the space occupied in RAM depends on these settings. The size of the field can be zero, as long as the resulting frame complies with the chosen RF protocol.

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 PCNF1.MAXLEN field configures the maximum packet payload plus add-on size in number of bytes that can be transmitted or received by RADIO. This feature can be used to ensure that RADIO does not overwrite or read beyond the RAM assigned to the packet payload. This means that if the LENGTH field of the packet payload exceeds PCNF1.STATLEN, and the LENGTH field in the packet specifies a packet larger than configured in PCNF1.MAXLEN, the payload will be truncated to the length specified in PCNF1.MAXLEN.

If the payload and add-on length is specified larger than PCNF1.MAXLEN, RADIO will transmit or receive in the same way as before, except the payload is now truncated to PCNF1.MAXLEN. The packet's LENGTH field will not be altered when the payload is truncated. RADIO will calculate CRC as if the packet length is equal to PCNF1.MAXLEN.

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