2.4 GHz RF (nRF24, Zigbee, Thread)#

The 2.4 GHz ISM band is globally available without regional frequency planning, making it the default choice for short-to-medium range embedded RF links. The nRF24L01+ from Nordic Semiconductor is the most widely used standalone 2.4 GHz transceiver in hobbyist and low-volume commercial projects — a simple SPI interface, built-in packet handling, and auto-acknowledgment make it straightforward to integrate. For mesh networking and standards-based interoperability, IEEE 802.15.4 radios (used by Zigbee and Thread) provide a more capable but more complex protocol stack. The firmware integration challenge shifts from raw radio configuration (as with sub-GHz LoRa modules) toward protocol management, address filtering, and network topology.

nRF24L01+ Architecture#

The nRF24L01+ is a single-chip 2.4 GHz transceiver with an integrated baseband processor, packet engine, and SPI interface. Key specifications:

The module uses an 8-pin SPI interface plus CE (chip enable) and IRQ (active-low interrupt) pins. CE controls the transition between Standby and active TX/RX states — SPI alone cannot trigger transmission.

Pin Connections#

The breakout modules commonly available on low-cost boards (the green PCB with 2x4 header) include an onboard 3.3V regulator and antenna. A 10 uF electrolytic capacitor across VCC and GND at the module pins is strongly recommended — the nRF24L01+ draws current in bursts during TX that cause supply dips on long jumper wires, leading to erratic behavior.

SPI Register Access#

The nRF24L01+ SPI protocol uses command bytes: the first byte selects the operation (read register, write register, read RX payload, write TX payload, flush), and subsequent bytes carry data. SPI mode 0, maximum 10 MHz clock.

#include "stm32f4xx_hal.h"

#define NRF_CSN_PIN   GPIO_PIN_4
#define NRF_CSN_PORT  GPIOA
#define NRF_CE_PIN    GPIO_PIN_3
#define NRF_CE_PORT   GPIOA

static SPI_HandleTypeDef hspi1;

/* SPI command bytes */
#define NRF_CMD_R_REGISTER   0x00  /* OR with register address */
#define NRF_CMD_W_REGISTER   0x20  /* OR with register address */
#define NRF_CMD_R_RX_PAYLOAD 0x61
#define NRF_CMD_W_TX_PAYLOAD 0xA0
#define NRF_CMD_FLUSH_TX     0xE1
#define NRF_CMD_FLUSH_RX     0xE2
#define NRF_CMD_NOP          0xFF

/* Register addresses */
#define NRF_REG_CONFIG       0x00
#define NRF_REG_EN_AA        0x01
#define NRF_REG_EN_RXADDR    0x02
#define NRF_REG_SETUP_AW     0x03
#define NRF_REG_SETUP_RETR   0x04
#define NRF_REG_RF_CH        0x05
#define NRF_REG_RF_SETUP     0x06
#define NRF_REG_STATUS       0x07
#define NRF_REG_RX_ADDR_P0   0x0A
#define NRF_REG_TX_ADDR      0x10
#define NRF_REG_RX_PW_P0     0x11
#define NRF_REG_FIFO_STATUS  0x17

static uint8_t nrf_read_reg(uint8_t reg) {
    uint8_t cmd = NRF_CMD_R_REGISTER | reg;
    uint8_t val;
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_RESET);
    HAL_SPI_Transmit(&hspi1, &cmd, 1, 100);
    HAL_SPI_Receive(&hspi1, &val, 1, 100);
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_SET);
    return val;
}

static void nrf_write_reg(uint8_t reg, uint8_t value) {
    uint8_t buf[2] = { NRF_CMD_W_REGISTER | reg, value };
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_RESET);
    HAL_SPI_Transmit(&hspi1, buf, 2, 100);
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_SET);
}

static void nrf_write_reg_multi(uint8_t reg, const uint8_t *data, uint8_t len) {
    uint8_t cmd = NRF_CMD_W_REGISTER | reg;
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_RESET);
    HAL_SPI_Transmit(&hspi1, &cmd, 1, 100);
    HAL_SPI_Transmit(&hspi1, (uint8_t *)data, len, 100);
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_SET);
}

static void nrf_send_command(uint8_t cmd) {
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_RESET);
    HAL_SPI_Transmit(&hspi1, &cmd, 1, 100);
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_SET);
}

Enhanced ShockBurst Protocol#

Enhanced ShockBurst is the nRF24L01+’s built-in protocol layer that provides:

• Auto-acknowledgment — The receiver automatically sends an ACK packet after receiving a valid payload. The transmitter waits for this ACK and reports success or failure via the STATUS register.
• Auto-retransmit — On ACK failure, the transmitter automatically retries up to 15 times with a configurable delay (250 us to 4000 us in 250 us steps).
• Dynamic payload length — Payload size can vary per packet (1-32 bytes) instead of requiring a fixed size.
• ACK payloads — The receiver can attach up to 32 bytes of data to the ACK packet, enabling bidirectional communication without explicit role switching.

The retransmit delay must be long enough for the receiver to process the packet and send the ACK. At 250 kbps with a 32-byte payload, the minimum safe retransmit delay is 500 us. At 2 Mbps, 250 us is sufficient.

TX and RX Configuration#

void nrf_init_tx(void) {
    /* Power down during configuration */
    nrf_write_reg(NRF_REG_CONFIG, 0x08);  /* EN_CRC, CRC 1 byte, PWR_UP=0 */

    /* 5-byte address width */
    nrf_write_reg(NRF_REG_SETUP_AW, 0x03);

    /* RF channel 76 (2476 MHz — avoids common Wi-Fi channels) */
    nrf_write_reg(NRF_REG_RF_CH, 76);

    /* 250 kbps, 0 dBm TX power */
    nrf_write_reg(NRF_REG_RF_SETUP, 0x26);

    /* Enable auto-ack on pipe 0 */
    nrf_write_reg(NRF_REG_EN_AA, 0x01);

    /* Enable RX address pipe 0 (for auto-ack) */
    nrf_write_reg(NRF_REG_EN_RXADDR, 0x01);

    /* Auto retransmit: 500us delay, 10 retries */
    nrf_write_reg(NRF_REG_SETUP_RETR, 0x1A);

    /* Set TX address (5 bytes) */
    uint8_t addr[5] = { 0xE7, 0xE7, 0xE7, 0xE7, 0xE7 };
    nrf_write_reg_multi(NRF_REG_TX_ADDR, addr, 5);

    /* RX address pipe 0 must match TX address for auto-ack */
    nrf_write_reg_multi(NRF_REG_RX_ADDR_P0, addr, 5);

    /* Payload width for pipe 0 */
    nrf_write_reg(NRF_REG_RX_PW_P0, 32);

    /* Power up as PTX (transmitter) */
    nrf_write_reg(NRF_REG_CONFIG, 0x0E);  /* EN_CRC, CRC 2 bytes, PWR_UP, PTX */
    HAL_Delay(2);  /* 1.5 ms power-up delay */
}

int nrf_transmit(const uint8_t *data, uint8_t len) {
    /* Flush TX FIFO */
    nrf_send_command(NRF_CMD_FLUSH_TX);

    /* Write payload */
    uint8_t cmd = NRF_CMD_W_TX_PAYLOAD;
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_RESET);
    HAL_SPI_Transmit(&hspi1, &cmd, 1, 100);
    HAL_SPI_Transmit(&hspi1, (uint8_t *)data, len, 100);
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_SET);

    /* Pulse CE high for >10 us to trigger transmission */
    HAL_GPIO_WritePin(NRF_CE_PORT, NRF_CE_PIN, GPIO_PIN_SET);
    HAL_Delay(1);
    HAL_GPIO_WritePin(NRF_CE_PORT, NRF_CE_PIN, GPIO_PIN_RESET);

    /* Wait for TX_DS (success) or MAX_RT (max retries exceeded) */
    uint32_t start = HAL_GetTick();
    uint8_t status;
    do {
        status = nrf_read_reg(NRF_REG_STATUS);
        if (HAL_GetTick() - start > 100) {
            return -1;  /* Timeout */
        }
    } while (!(status & 0x30));  /* TX_DS=0x20, MAX_RT=0x10 */

    /* Clear status flags */
    nrf_write_reg(NRF_REG_STATUS, 0x30);

    if (status & 0x10) {
        nrf_send_command(NRF_CMD_FLUSH_TX);
        return -2;  /* Max retries — no ACK received */
    }

    return 0;  /* TX success with ACK */
}

void nrf_init_rx(void) {
    /* Same configuration as TX, but set PRIM_RX bit */
    nrf_write_reg(NRF_REG_CONFIG, 0x0F);  /* EN_CRC, CRC 2 bytes, PWR_UP, PRX */
    HAL_Delay(2);

    /* Set CE high to enter RX mode */
    HAL_GPIO_WritePin(NRF_CE_PORT, NRF_CE_PIN, GPIO_PIN_SET);
}

int nrf_receive(uint8_t *data, uint8_t max_len) {
    uint8_t status = nrf_read_reg(NRF_REG_STATUS);
    if (!(status & 0x40)) {
        return 0;  /* No data available (RX_DR not set) */
    }

    /* Read payload */
    uint8_t cmd = NRF_CMD_R_RX_PAYLOAD;
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_RESET);
    HAL_SPI_Transmit(&hspi1, &cmd, 1, 100);
    HAL_SPI_Receive(&hspi1, data, max_len, 100);
    HAL_GPIO_WritePin(NRF_CSN_PORT, NRF_CSN_PIN, GPIO_PIN_SET);

    /* Clear RX_DR flag */
    nrf_write_reg(NRF_REG_STATUS, 0x40);

    return 1;  /* Data received */
}

Data Pipes#

The nRF24L01+ supports six receive data pipes (pipe 0 through pipe 5), allowing one receiver to accept packets from up to six different transmitters without software address filtering:

• Pipe 0: Full 5-byte address, also used for auto-ack address matching in TX mode
• Pipe 1: Full 5-byte address
• Pipes 2-5: Share the 4 most significant bytes of Pipe 1’s address, only the least significant byte differs

This design efficiently supports star topologies where one central node communicates with several peripheral nodes. Each pipe can have a different payload width configured independently.

A critical detail: when transmitting with auto-ack enabled, Pipe 0’s RX address must be set to the TX address. If Pipe 0 is also used for receiving data from another source, its address must be restored after each transmission.

IEEE 802.15.4 and Mesh Protocols#

802.15.4 Physical Layer#

IEEE 802.15.4 defines a low-rate wireless personal area network standard operating at 2.4 GHz (globally) and 868/915 MHz (regionally). The 2.4 GHz PHY provides:

• 16 channels (channels 11-26, spanning 2405-2480 MHz)
• 250 kbps data rate (O-QPSK modulation with DSSS)
• -100 dBm typical sensitivity
• Maximum 127-byte frame size (including MAC header)

This standard forms the physical and MAC layer for both Zigbee and Thread protocol stacks. The radio handles CCA (Clear Channel Assessment), frame timing, and automatic ACK generation at the hardware level.

nRF52840 as 802.15.4 Radio#

The nRF52840 from Nordic Semiconductor integrates an ARM Cortex-M4F processor with a multiprotocol 2.4 GHz radio supporting BLE, 802.15.4, and proprietary protocols. For Thread and Zigbee applications, it serves as both the MCU and the radio — no external transceiver needed.

Key 802.15.4 capabilities of the nRF52840:

Development typically uses the nRF Connect SDK (based on Zephyr RTOS) which provides OpenThread and Zigbee stacks.

Thread Protocol#

Thread is an IPv6-based mesh networking protocol built on 802.15.4. Unlike Zigbee, Thread does not define an application layer — it provides a reliable, secure, low-power mesh network that carries standard IPv6 traffic. Key characteristics:

• No single point of failure — Any router can relay traffic; the network self-heals around failed nodes
• Border Router connects the Thread mesh to external IP networks (Wi-Fi, Ethernet)
• Sleepy End Devices poll their parent router periodically, achieving uA-level average current
• 6LoWPAN header compression maps IPv6 over 802.15.4’s 127-byte frames
• MLE (Mesh Link Establishment) handles neighbor discovery and link quality tracking

Thread’s main advantage over Zigbee for new designs is native IP compatibility — devices are addressable with standard IPv6, simplifying cloud integration.

CC2530 / CC2652R (Texas Instruments)#

The CC2530 is an older 8051-based 802.15.4 SoC commonly found in legacy Zigbee devices. The CC2652R is its modern replacement, based on an ARM Cortex-M4F core with a multiprotocol radio (BLE + 802.15.4). Both are supported by TI’s Z-Stack (Zigbee) and the SimpleLink SDK.

Module Comparison#

The nRF24L01+ excels at simple, low-cost, point-to-point sensor links where mesh networking is unnecessary. For products requiring interoperability with smart home ecosystems (Apple Home, Google Home, Amazon), Thread on the nRF52840 is the current standard path.

Channel Selection and Wi-Fi Coexistence#

The 2.4 GHz ISM band is shared with Wi-Fi (802.11b/g/n), Bluetooth, microwave ovens, and numerous other emitters. Coexistence requires careful channel selection:

• Wi-Fi channels 1, 6, and 11 (in North America) each occupy 22 MHz of bandwidth
• 802.15.4 channels 15, 20, 25, and 26 fall in the gaps between Wi-Fi channels 1, 6, and 11
• nRF24L01+ channels above 2.4835 GHz (channel 83+) are technically outside the ISM band in some regions

For the nRF24L01+ at 2 Mbps data rate, each channel occupies approximately 2 MHz of bandwidth. Selecting a channel in the 2.475-2.480 GHz range (channels 75-80) avoids most Wi-Fi interference while staying within the ISM band.

Tips#

• When the nRF24L01+ consistently reports MAX_RT (max retries) on every transmission, verify that the receiver is powered, in RX mode with CE high, and configured to the same channel, data rate, address, and address width as the transmitter — any single mismatch causes total communication failure with no error indication
• Add a 10 uF capacitor directly at the module’s VCC/GND pins — the cheap green breakout boards have minimal onboard decoupling, and the 11 mA current pulses during TX cause brownouts on breadboard setups with long jumper wires
• Use 250 kbps data rate for maximum range — the sensitivity improves by 12 dB compared to 2 Mbps mode, roughly tripling effective range at the cost of 8x longer airtime
• Channel 76 (2476 MHz) is a commonly recommended default that avoids the three standard Wi-Fi channels; the address {0xE7, 0xE7, 0xE7, 0xE7, 0xE7} is the factory default — change it in production to avoid cross-talk with other nRF24 devices in the vicinity
• For Thread development on the nRF52840, start with the OpenThread CLI example in the nRF Connect SDK — it provides a serial interface for inspecting network state, routing tables, and neighbor information without writing custom firmware
• Save the Pipe 0 RX address before transmitting if the same device both sends and receives — the TX function overwrites Pipe 0 with the TX address for auto-ack, and forgetting to restore it causes the device to stop receiving on its own address

Caveats#

• The nRF24L01+ is not 5V tolerant — Connecting VCC to 5V destroys the module permanently; the SPI pins are also 3.3V logic, though some modules tolerate 5V logic levels briefly due to input protection diodes, this is outside specification and unreliable
• Clone nRF24L01+ modules are widespread — Modules marked “nRF24L01+” may contain Si24R1 or other clones that behave differently at edge cases: 250 kbps mode may not work, sensitivity is 3-5 dB worse, and some clones lack proper auto-retransmit timing, leading to intermittent failures
• Auto-ack has a hidden dependency on Pipe 0 — When transmitting with auto-ack enabled, the radio temporarily switches Pipe 0’s address to match the TX address to receive the ACK; if Pipe 0 was configured for something else, that configuration is silently overwritten
• 802.15.4 mesh stacks consume significant Flash and RAM — A minimal Thread stack on the nRF52840 consumes approximately 180-220 KB of Flash and 40-60 KB of RAM, leaving limited resources for application code on smaller parts
• Zigbee and Thread cannot coexist on the same 802.15.4 radio simultaneously — Despite using the same PHY, the MAC and network layers are incompatible; a single radio must choose one protocol at a time (though time-slicing implementations exist in some SDKs)

In Practice#

• An nRF24L01+ that works on short wires but fails when moved to a PCB often reveals a power supply issue — the module’s current transients during TX create voltage dips that reset the radio; adding bulk capacitance (10-47 uF) at the module VCC pin and keeping supply traces wide and short resolves most cases
• Intermittent packet loss that worsens during evenings and weekends typically indicates Wi-Fi interference from residential routers — switching the nRF24 to a channel above 2470 MHz or below 2410 MHz (avoiding Wi-Fi channels 1, 6, 11) usually eliminates the pattern
• A receiver that works for the first few packets then stops responding commonly results from the RX FIFO filling up — if received packets are not read and the FIFO is not flushed, the third unread packet blocks all further reception; reading the RX payload and clearing the RX_DR flag on every interrupt prevents this
• Thread devices that form a network in the lab but fail to route traffic in a real building often expose insufficient router density — Thread recommends that every router be within radio range of at least two other routers for reliable mesh operation; a single router in each room with concrete walls between them produces a fragmented network
• nRF24L01+ modules that report successful TX (TX_DS flag set) but the receiver never gets the data usually indicate that auto-ack is disabled on the transmitter side — without auto-ack, TX_DS asserts immediately after the packet is sent, regardless of whether any receiver heard it