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)
-
Is BLE + raw IEEE 802.15.4 TX (PHY only, no Thread/Zigbee) an officially supported use case on nRF52840 when using MPSL?
-
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