RADIO — 2.4 GHz radio

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

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

Figure 2. On-air packet layout

Not shown in the figure 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:

• 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 PCNF0.PLEN 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 must be set to 2 bytes through PCNF0.PLEN. If the first bit of the ADDRESS is 0, the preamble will be set to 0xAAAA. Otherwise the PREAMBLE will be set to 0x5555.

Radio packets are stored in memory inside instances of a RADIO packet data structure as illustrated below. The PREAMBLE, ADDRESS and CRC fields are omitted in this data structure. Fields S0, LENGTH, and S1 are optional.

Figure 3. Representation of a RADIO packet in RAM

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

The on-air addresses are defined in the BASE0/BASE1 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 being used. The relationship between the on-air radio addresses and the logical addresses is described in the following table.

RADIO can do packet whitening and de-whitening which is enabled in PCNF1.WHITEEN. When enabled, whitening and de-whitening will be handled by 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. The linear feedback shift register is initialized via DATAWHITEIV. See the following figure.

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

The CRC generator in RADIO calculates the CRC over the whole packet excluding the preamble.

If useful, the address field can be excluded from the CRC calculation as well. See the CRCCNF register for more information.

The CRC polynomial is configurable as illustrated in the following figure, 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

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₀ through b_n will be initialized with a predefined value specified in the CRCINIT register. After the whole packet has been clocked through the CRC generator, b₀ through b_n will hold the resulting CRC. This value will be used by RADIO during both transmission and reception. Latches b₀ through b_n are not available to be read by the CPU at any time. However, a received CRC can be read by the CPU via the RXCRC register.

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

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

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

A state diagram showing an overview of RADIO is shown in the following figure.

Figure 6. Radio states

This figure shows how the tasks and events relate to RADIO's operation. 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 behavior. The PAYLOAD event is always generated even if the payload is zero.

Before RADIO can 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 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, 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 the following figure, RADIO will by default transmit 1s 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

The following figure shows a slightly modified version of the transmit sequence where 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

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.

Figure 9. Transmission of multiple packets

Before RADIO is able to receive a packet, it must first ramp up in RX mode. See RXRU in Radio states 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, the START task can first be triggered after RADIO has entered into the RXIDLE state.

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

Figure 10. Receive sequence

The following figure shows a modified version of the receive sequence, where 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

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

Figure 12. Reception of multiple packets

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, 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 (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 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 following figure.

Figure 13. IFS timing detail

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 the shortcuts END to DISABLE and DISABLED to TXEN or END to DISABLE and DISABLED to RXEN are enabled.

TIFS is qualified for use in 1 Mbps and 2 Mbps Bluetooth Low Energy modes, using the default 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 MODE register is double-buffered and sampled at the TXEN or RXEN task.

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

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 RADIO and 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. After a BCMATCH event, the CPU can reconfigure the BCC value 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 on either the BCSTOP, STOP, or DISABLE task, or the END event.

The following figure shows 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

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

As illustrated in RADIO block diagram, 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 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 a 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 above 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 exceedes 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 still 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 an DISABLE task is done.