Is BLE + raw IEEE 802.15.4 TX (PHY only, no Thread/Zigbee) officially supported on nRF52840 with MPSL?

[flcl73]

Hello Nordic team,

I am working on an nRF52840 project using nRF Connect SDK (Zephyr-based, v2.x / v3.x) and I would like to clarify the official support status of a specific multiprotocol use case.

I have intentionally limited this question to two focused points to avoid ambiguity.

1. Target Use Case

• Device: nRF52840

• SDK: nRF Connect SDK (Zephyr)

• Protocols:

  • Bluetooth LE (SoftDevice Controller)

  • IEEE 802.15.4 PHY only (raw TX)

    • No Thread

    • No Zigbee

    • No MAC / NET stack usage

• Radio sharing via MPSL (dynamic multiprotocol)

The 802.15.4 side is used only for custom raw frame transmission (driver-level TX), not for any standardized 802.15.4-based stack.

---

2. Observations So Far

• BLE and IEEE 802.15.4 TX can both be enabled and initialized.

• A single 802.15.4 TX call works while BLE is active.

• However, periodic or continuous TX loops do not behave reliably:

  • TX returns success (0)

  • But repeated transmissions do not appear on a sniffer

  • No explicit runtime error is reported

• All development was done using the nRF IEEE 802.15.4 radio driver + MPSL, not the legacy raw radio HAL.

---

3. Documentation Gap

From available documentation and samples, I understand that:

• nRF52840 officially supports BLE + Thread/Zigbee concurrency via MPSL.

• Multiprotocol support is clearly documented for full 802.15.4 stacks.

• However, I cannot find an explicit statement or reference confirming:

  BLE + custom raw IEEE 802.15.4 TX (PHY only) is officially supported and validated

---

4. Questions (Primary Scope)

1. Is BLE + raw IEEE 802.15.4 TX (PHY only, no Thread/Zigbee) an officially supported use case on nRF52840 when using MPSL?

2. If supported in principle, are there any known limitations or design constraints (e.g. scheduling, TX frequency, timeslot behavior) that would explain why periodic TX may silently stop or not appear on a sniffer?

I am intentionally not asking for code review or full implementation guidance yet.
I would like to first understand the official support boundary and expectations.

---

5. Next Steps

Depending on the answers to the two questions above, I plan to:

• Adjust the architecture (e.g. move to Thread/Zigbee, or dedicated timeslot handling), or

• Continue debugging within the supported configuration and ask follow-up implementation questions.

Thank you for your time and clarification.

Best regards,

Ryan

[Edvin]

Edvin said:

If you stop sending packet after the first nrf_802154_transmit_raw(), do you see any of the interrupts then? You should see either nrf_802154_transmitted() or nrf_802154_transmit_failed() occur once. As far as I know, this is the way openthread and Zigbee uses it.

Did you test queuing up only one packet, and see if you get any of the callbacks?

Best regards,

Edvin

[flcl73]

Yes. transmit_raw() returns success (err=0), but no callback is triggered at all.

Best regards,

Ryan

[Edvin]

Can you please zip and upload the entire application folder (Not just some of the files)? This way I can try to reproduce what you are seeing. Are you only missing the replies when you use the 0xFFFF address? Or is it for all messages?

Best regards,

Edvin

[flcl73]

Sure, I will zip the entire application folder (including all files) and upload it here shortly.

Regarding your question, the issue happens not only with 0xFFFF, but also with unicast messages.
In other words, I am missing replies for all messages.

Best regards,

Ryan

802154_tx_test.zip

[Edvin]

This is the log from the unmodified application that you sent:

So apparently, nrf_802154_transmitted() is being triggered.

However, I do see in your main loop:

        if (!nrf_802154_transmit_raw(tx_frame, &metadata)) {
            LOG_ERR("TX rejected! Attempting driver reset...");                
        }

But if nrf_802154_transmit_raw returns NRF_802154_TX_ERROR_NONE (=0), then it is a success. I did some changes, but mostly in error checking and logging. Try the attached project, and let me know the log output:

802154_tx_test2.zip

Note that I enabled UART logging in prj.conf. Disable it if you don't need it.

Best regards,

Edvin