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.

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

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

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.