nRF5340 + DWM3000 for Apple NI: does the dual-core avoid BLE / UWB scheduling stalls?

Wireless Connectivity Ultra-Wideband
1

We run Apple Nearby Interaction on DWM3001C (nRF52833 + DW3110, DW3_QM33_SDK 1.1.1, QANI, S113) with several phones connected at the same time. As reported in topic 25999, BLE advertising during a UWB session makes the FiRa session silently stop scheduling rounds. We have a working recovery (restart the MAC), but we are now choosing the hardware for our next board and would like to avoid the problem by design.

One idea is nRF5340 (certified module) + DWM3000 module: the BLE controller runs on the network core, so advertising and connection events should no longer preempt the application core where the UWB stack runs.

I found a few earlier posts here from people who got NI ranging working on nRF5340 (custom board + Zephyr in 2023, and nRF5340DK + DWM3000EVB with NCS v3.3.0 this year), so I know it is possible. My questions:

  1. Has anyone run long NI / FiRa sessions on nRF5340 + DW3xxx with BLE advertising active? Did you ever see the session silently stop (no SESSION_STATUS_NTF, ranging count frozen)? Even ā€œran for days, never saw itā€ would be very valuable.

  2. For Qorvo: DW3_QM33_SDK 1.1.1 ships Cortex-M33 builds of uwbstack and libniq. Which platform are they intended for? Is nRF5340 (app core) a reasonable / tested target for them, or should we use the M4 builds as earlier posts did?

  3. Practical effort: for those who ported to NCS / Zephyr - roughly how much of the OS abstraction (threads, timers, power management) did you have to write yourself? Is the BLE side (NI accessory protocol glue, like ble_niq.c) straightforward on the Zephyr Bluetooth host?

  4. Timing on the app core: on nRF5340, is anything still able to delay the UWB stack at the wrong moment (IPC with the network core, flash operations, etc.)? Any recommended interrupt priority or thread priority setup?

  5. Calibration: DWM3000 has no per-unit antenna delay in OTP (unlike DWM3001C, as far as I understand). Is that correct, and is a per-unit calibration required to get the same accuracy as DWM3001C?

We are deciding between staying on DWM3001C (with the recovery workaround) and moving to nRF5340 + DWM3000, so any experience is appreciated. Thanks!

1 Like
2

nRF5340 should be a good option using the M33 build.

Correct, DWM3000 does not have antenna calibrated and this needs to be done by the customer.

3

Actually have the exact same problem on DWM3001CDK (nRF52833 + DWM3001C).
Based on QANI project (SDK 1.1.1), the goal is multiple Iphone UWB-ranging at the same time.

The ranging stalls without a recognizable pattern or does not even start properly for more than one connected phone at a time.
The board even completely stalls sometimes, so only Watchdog can restore it.
BLE advertising also stays on, so new phones can keep connecting.

Restarting the MAC does not help in all cases for me.
I tried a complete UWB stack rebuild as recovery but havenā€™t gotten that to work properly. Not sure if the SDK even supports that.

Does only restarting the UWB MAC work for you in all cases?

Iā€™d also appreciate anyone that could share experiences or any improvements found (to either recovery or resolution of the problem)

4

I donā€™t KNOW for certain, but as UCI supports 1-many, and UCI works on the 3001CDK, you could test 1 3001CDK as the controller and multiple others as controlee and see if that works.. the 3001CDK only has 1 antenna so you wonā€™t get angles..

so I ā€˜thinkā€™ the hardware can do it.. I understand that is a diff stack build. (and UCI is USB cable only as found in the SDK)

Many to Many, or Many to One donā€™t have a specification in Fira..

Our business logic only wants 1:1,
Iā€™ve thought over and over about many to 1, but it just is the wrong approach for us.

5

Also the 52833 on the CDK is very memory constrained, I donā€™t know how much memory each ranging session takes. I did see some problems on the 52840 when doing ranging while working on my custom BLE/UCI firmware early this year