Using the XCVR_DWM3000TR13 IC for iPhone connectivity

Subject: DW3_QM33_SDK 1.1.1: UWB stack and NIQ builds for ESP32-S3 host (Park.Easy)

Hello,

I’m a firmware developer at Park.Easy Co. in San Diego. We’re building a parking-facility beacon that ranges to customers’ iPhones (and later Samsung Galaxy phones) over UWB, using Apple Nearby Interaction in background mode.

We’re evaluating with the DWM3001CDK and DW3_QM33_SDK 1.1.1 (the QANI firmware works with your iOS apps). Our production board, however, uses an ESP32-S3 (Xtensa LX7) as the host MCU, with an XCVR_DWM3000TR13 module on SPI. There is no Nordic part on the board, and the ESP32-S3 also handles the phones’ BLE connections.

In the SDK, the FiRa UWB stack (Libs/uwbstack_libs) and the Nearby Interaction library (Libs/niq) are supplied only as prebuilt Cortex-M4/M33 archives, so we can’t link them on the ESP32-S3. Before we choose between this architecture and a DWM3001C-based design, could you help with the following:

  1. Can Qorvo provide builds of the UWB stack (uwbstack_bundle / uci_bundle) and libniq for the ESP32-S3 (Xtensa, FreeRTOS/ESP-IDF), or source under NDA? If not, is there any supported path for running Apple NI and FiRa ranging on a DWM3000 with a non-ARM host?
  2. If that isn’t possible, do you recommend the DWM3001C (nRF52833) as a UWB/BLE coprocessor reporting results to our host over UART? Is there a reference host interface for this, such as UCI, alongside the QANI application?
  3. Can one DWM3001C run Apple Nearby Interaction and FiRa (Android) sessions concurrently, or only by switching? How many iPhones can it range with at once in background mode?
  4. Licensing: may we ship modified QANI firmware in a commercial product, and use the iOS sample app source from the Qorvo Nearby Interaction package as the basis for our own App Store app (rebranded, Qorvo notices retained)?
  5. Does a product built on Qorvo’s NI-enabled stack require us to join Apple’s MFi program, or is that covered on the chipset side?

Our volumes are initially pilot deployments in parking structures, growing with rollout. I’d be glad to set up a call with a field application engineer if that’s easier.

Thank you,

Bill
Park.Easy Co.
San Diego, CA

I’m just another user, but have built an Android firmware interface that is similar to the IOS QANI.

currently the QANI design is 1:1, one phone at a time, once BLE connected, no other device can scan it. You can ‘fix’ the BLE OOB side, but then run into problems using the UWBMAC hardware.. UCI does it differently (as the only hardware owner) but that is hidden in the binary libs

I also have a custom UCI interface, which shares(/single access at a time) hardware access between QANI, Android/NI-like, and UCI.. (all over BLE) but only on the 52840 (Murata Type 2AB), due to lack of memory on the 52833

I think 4 is answered with the terms on the DW3_QM33_SDK 1.1.1 SDK

UCI and QANI cannot run concurrently. they both assume exclusive ownership of the UWBMAC

I have an implementation of UCI over BLE on 52840(controller), that does ranging to other 52840 (controlee) and passes the ranging info to our phone app that provides ranging to users (similar style info as QANI provides to the app layer, the ranging component doesn’t know. I had written IONIC plugins to do the UWB ranging prior to this). the entire interface is over BLE. all the processors are Cortex except the phone

In my current IOS only deployment I have an ESP32 colocated that does all the non-UWB BLE operations, and then the app kicks off the UWB ranging to the specific DWM3001DK board.