Raw 802.15.4 TX/RX on nRF52840 with NCS v3.2.3 — what is the supported approach?

Board: nRF52840 DK (pca10056)
NCS version: v3.2.3
Goal: Send and receive raw 802.15.4 frames with a custom packet format, without using OpenThread, Zigbee, or any other mesh stack on top.


Background

I am developing a proprietary mesh protocol with a custom packet format over raw 802.15.4 on channel 26. I do not need Thread, Zigbee, or any IP stack — just the ability to transmit and receive 802.15.4 frames with a custom MAC payload.


What I have tried

Approach 1 — nrf_802154 direct API

Using CONFIG_NRF_802154_RADIO_DRIVER=y and CONFIG_NRF_802154_SL_OPENSOURCE=y with CONFIG_MPSL=n.

Calling nrf_802154_init(), nrf_802154_channel_set(26), nrf_802154_receive(), and nrf_802154_transmit_raw().

Result: nrf_802154_transmit_failed() callback fires immediately with error code 5 (NRF_802154_TX_ERROR_TIMESLOT_DENIED).

The .config confirms # CONFIG_MPSL is not set, but CONFIG_MPSL_TIMESLOT_SESSION_COUNT=0 and other MPSL symbols are still present, suggesting the driver requires MPSL even in single-protocol mode.

Approach 2 — OpenThread RAW link API

Using CONFIG_NET_L2_OPENTHREAD=y, CONFIG_OPENTHREAD_MANUAL_START=y, CONFIG_OPENTHREAD_NORDIC_LIBRARY_MASTER=y with OPENTHREAD_CONFIG_LINK_RAW_ENABLE=1 set via a custom config header.

Result: Build fails with:

zephyr/include/zephyr/toolchain/gcc.h:87:51: error: expression in static assertion is not an integer
zephyr/include/zephyr/sys/cbprintf_internal.h:565:20: error: '_uv' undeclared

These appear to be compiler incompatibilities between the Nordic prebuilt OpenThread library and GCC 12.2.0 (Zephyr SDK 0.17.0).

Note: CONFIG_OPENTHREAD_LINK_RAW does not exist as a Kconfig symbol in NCS v3.2.3 — only OPENTHREAD_CONFIG_LINK_RAW_ENABLE exists in the OpenThread source headers.

Approach 3 — nRF5 SDK v17.1.0 + SEGGER Embedded Studio

Attempted to use the nRF5 SDK which has a cleaner raw 802.15.4 API. Build failed due to toolchain conflicts between SES and the external GCC toolchain.

Approach 4 — 802154_phy_test reference sample

Attempted to build the NCS reference sample at nrf/samples/peripheral/802154_phy_test for nrf52840dk/nrf52840.

Result: Build fails with undefined references to nrfx_timer_init, nrfx_timer_extended_compare etc. The sample appears to require additional Kconfig options not documented in its prj.conf.


Questions

  1. What is the supported and working approach for raw 802.15.4 TX/RX in NCS v3.2.3 on nRF52840, without OpenThread or Zigbee?
  2. Is TIMESLOT_DENIED from nrf_802154_transmit_raw() expected when MPSL is disabled? If so, is there a way to initialise MPSL for single-protocol 802.15.4 use only?
  3. Is OPENTHREAD_CONFIG_LINK_RAW_ENABLE accessible via Kconfig in NCS v3.2.3, or only via a custom config header? If the latter, what is the correct way to enable it?
  4. What additional Kconfig options does the 802154_phy_test sample require to build for nrf52840dk/nrf52840?
  5. Is the nRF5 SDK still a viable option for new designs requiring raw 802.15.4 on nRF52840, and if so, what is the recommended build environment on Windows?

Why raw 802.15.4

The system uses a fixed packet format that is wire-compatible with an existing production deployment. Using OpenThread or Zigbee would add protocol overhead and complexity that is not needed. The mesh routing, security, and commissioning layers are implemented in application code above the radio.

Any guidance on the correct approach would be greatly appreciated.

Parents
  • For NCS v3.2.3 on nRF52840, I think the better approach for raw 802.15.4 TX/RX is to use the Nordic nrf_802154 radio driver directly, with the normal Nordic service layer/MPSL enabled. MPSL is required for radio arbitration/timing in NCS and does not imply use of Thread, Zigbee, BLE, or any mesh stack.

    I am not an expert in this but grepping shows TIMESLOT_DENIED is expected if the driver is built/configured without the required service layer path. Do not disable MPSL for this use case. Let NCS initialize it through Kconfig.

    Use OpenThread RAW only if you intentionally want to build on OpenThread. In NCS, the Kconfig symbol is CONFIG_OPENTHREAD_RAW, not CONFIG_OPENTHREAD_LINK_RAW. For 802154_phy_test, the missing build option is typically CONFIG_NRFX_TIMER=y; the nRF52840 DK board fragment also enables CONFIG_NRFX_POWER=y, CONFIG_NRFX_RNG=y, and CONFIG_NRF_RTC_TIMER_USER_CHAN_COUNT=3.

    The nRF5 SDK is legacy and not recommended for new NCS-based designs. For a new product, stay on NCS and use nrf_802154 directly.

Reply
  • For NCS v3.2.3 on nRF52840, I think the better approach for raw 802.15.4 TX/RX is to use the Nordic nrf_802154 radio driver directly, with the normal Nordic service layer/MPSL enabled. MPSL is required for radio arbitration/timing in NCS and does not imply use of Thread, Zigbee, BLE, or any mesh stack.

    I am not an expert in this but grepping shows TIMESLOT_DENIED is expected if the driver is built/configured without the required service layer path. Do not disable MPSL for this use case. Let NCS initialize it through Kconfig.

    Use OpenThread RAW only if you intentionally want to build on OpenThread. In NCS, the Kconfig symbol is CONFIG_OPENTHREAD_RAW, not CONFIG_OPENTHREAD_LINK_RAW. For 802154_phy_test, the missing build option is typically CONFIG_NRFX_TIMER=y; the nRF52840 DK board fragment also enables CONFIG_NRFX_POWER=y, CONFIG_NRFX_RNG=y, and CONFIG_NRF_RTC_TIMER_USER_CHAN_COUNT=3.

    The nRF5 SDK is legacy and not recommended for new NCS-based designs. For a new product, stay on NCS and use nrf_802154 directly.

Children
Related