New release of DW3000 and QM33 SDK: DW3_QM33 SDK v1.0.2

The DW3_QM33 SDK v1.0.2 is now available for download at the link below:

Click here to download

The package is compliant with FiRa™ PHY/MAC specification 2.0, and it enables evaluation, development and manufacturing of products fitting the following following Qorvo and partner parts:

The following UWB chips are supported:
QM33120W, QM33110W, DW3120, DW3110, DW3220, DW3210.

For reference, list of Qorvo UWB ICs.

Main SDK features

  • GUI application to evaluate FiRa ranging over UCI.
  • Python API (UWB Qorvo Tools) over UCI:
    • Perform FiRa ranging between multiple devices
    • Evaluate RF performance over UCI and calibrate/configure the device.
    • Interface with RF instrument for manufacturing
  • CLI for FiRa ranging, calibration/configuration and listener over Virtual COM Port.
  • New calibration method: possibility to adjust using UCI or CLI.

Please refer to your target quick start guides to start your evaluation.

DW3_QM33_SDK_1.0.2
├── Drivers
└── SDK
    └── Documentation
        └──Quick Start Guide
            ├── DWM3001CDK_Quick_Start_Guide_QM33SDK-1.0.0.pdf
            ├── nRF52840_Quick_Start_Guide_QM33SDK-1.0.0.pdf
            └── TYPE_2AB_EVB_Quick_Start_Guide_QM33SDK-1.0.0.pdf

I get the one time link, but using it says not found

I clicked the link here, it generated a new form, whcih then generated the email with the download link.

click the download link (on mac) … and new page opens… and sits… and then comes back to this page… no download

oh, sneaky, downloaded with no visual…

  1. I still cannot get the Qorvo One TWR working with my 2 DWM3001CDK boards with UCI hex.
  2. The Jlink.exe called by the auto flash script can be confused with the Java program if they are both in the environment, it took me a while to figure out.

Hi Billyyiu,

There was an issue in the SDK1.0.0 package with the GUI application, hence we have released a maintenance release 1.0.1 that solves it.

The GUI application shall not operate correctly. Please let us know if you meet any issue with the new package 1.0.1.

The QorvoOneTWR-2.1.1 is working now, thanks.

Hello,

Is there plan to generate the neccessary libraries for cortex-M33 core?

Thanks a lot

1 Like

Can you guys please just put this code on Github or something??

Its very frustrating having to re download a completely new SDK zip file everytime some minor change is done… its also harder to see what has changed, and for us to file and track issues or features…

By having a github repo, we can simple fork it and implement our business logic on top, and then pull in the changes that are non-application specific.

I know you want to track users etc., but have you ever thought that you will actually get more users / customers if you had this on Github for more people to see?? And that your product line would be way easier for people to use if it was on Github/Gitlab??

Thank you for your consideration, and I hope we can take steps towards making this happen.

3 Likes

Hi NicolasMontoya,

We are planning to move to a git hosting platform for our future deliveries and newer products, we’re just not quite there yet and still needed to enable customers with our latest software.

Thank you for being patient,

2 Likes

I am following document by murata (Type2AB DW3-QM33SDKPatch Quick Start Guide) and I am trying to look for the nRF52840DK-DW3_QM33_SDK-FreeRTOS_DW3_QM33_SDK_0_1_1.zip but it’s not available in DW3_QM33_SDK_1.0.2

Hello! Created a Qorvo forums account just because the download link is not functional with my Gmail domain. Can anyone point me in the right direction to get this resolved? I really would like to use the SDK

I’ve been working on TX/RX testing using the DW3000EVB and NUCLEO-L476RG development boards. I referenced the STM32F4 project from SDK v1.0.2 and successfully ran the functions in Src/Examples. However, I’ve encountered an issue:

I have two sets of hardware (DW3000EVB + NUCLEO-L476RG):

  • One runs simple_tx, the other runs simple_rx.
  • Originally, the TX message was:

static uint8_t tx_msg[] = { 0xC5, 0, 'D', 'E', 'C', 'A', 'W', 'A', 'V', 'E' };

  • The RX message was correct:

But I expanded it to:

static uint8_t tx_msg[] = { 0xC5, 0, 'D', 'E', 'C', 'A', 'W', 'A', 'V', 'E', 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b };

During debugging, the received data on the RX end (rx_buffer[]) was:

{ 0xC5, 0, 'D', 'E', 'C', 'A', 'W', 'A', 'V', 'E', 0x01, 0x02, 0x04, 0x06, 0x08, 0x0a, 0x16, 0x55, 0xd6 }

The received data doesn’t match the transmitted payload (missing/corrupted bytes after 0x02).

Interestingly, when I tested the same payload with an ESP32 + DW3000 (Arduino-based receiver), it worked flawlessly. I couldn’t find similar issues reported online.

Any suggestions for issue?

Hi czliguang,
Did you tested locating the distance by connect between ESP32 module and DW3000EVB and it’s working?

I’ve already resolved the issue. In the STM32F4 example, within the platform folder’s deca_spi.c file, the readfromspi function was the problem. I replaced the read part with the official HAL library function HAL_SPI_Receive, and it started working correctly.

Hello. I see QM35 is git hosted but QM33 remains delivered through zip files. Is there any intention to put QM33 into a public repository with issue tracking? There’s very limited availability of QM35 products right now but still a distribution of QM33 products through Digikey and Mouser. Are there any more features to come to QM33 ecosytem? Is QM33 end-of-life or do you intend to continue supporting it? To what extent is QM35 backward compatible with QM33?

I can’t seem to get any ranging data from the DWM3001CDK board. Here is where I’m at:

  1. BLE: Connection and service discovery are successful.
  2. Handshake: The board sends the Accessory Configuration (0x01) packet. My app initializes an NINearbyAccessoryConfigurationsuccessfully (no invalid configuration errors).
  3. Token Exchange: The iPhone generates the shareable configuration data, which I send back to the board via Opcode 0x05(configureAndStart).
  4. Session State: The NISession starts correctly, and the iOS “Nearby Interaction” permission prompt was accepted. The app enters the “Ranging Active” state.

The Problem: Even though the session is active, the nearbyObject.distance remains nil. On the board, the LED remains flashing red.

Question: Is there a final “Start” opcode or a specific bitmask I need to send to the board afterthe 0x05 handshake to physically trigger the UWB pulses and reporting and is the DWM3001CDK supposed to flash a red LED when QUANI is running.

Any help would be appreciated!

I am using the DWM3001CDK as an accessory, and it ported the Qorvo sample app code to use in my setup. I am using Ionic/Vue and the BT stuff is in a plugin… I didn’t change any of the flows and it works fine… I get distance values, but no ranging data cause I can’t use camera for VR assistance

the CDK board LED flashes red when the board is powered on with the QANI fw installed

Hello Qorvo UWB Applications team,

I’m the founder of RJ Innovation Inc., a US company developing a battery-powered ultra-wideband RTLS tag. The tag is built on the DWM3000 (DW3110) driven by a Nordic nRF52833 host over SPI under nRF Connect SDK / Zephyr — equivalently the DWM3001C configuration. Our intended architecture has the tag self-compute its position by passively listening to downlink-TDoA transmissions from fixed, transmit-only anchors (the FiRa DT-Tag role); the nRF52833 runs the multilateration solve from the RX timestamps. Before we finalize the design we need to confirm your software supports this configuration. We anticipate production volumes scaling from thousands toward 100k+ units.

Specific questions:

  1. Does the current DW3xxx & QM3xxx SDK (v1.1.1, Aug 2025) provide a FiRa downlink-TDoA listener (DT-Tag) role on the DW3110 / DWM3000 / DWM3001C, where the device receives DT-Anchor downlink transmissions and the host can compute its own position? Is this production-grade or reference/demo, and which FiRa version (e.g., FiRa 2.0)?

  2. Is the DT-Tag listener supported with an external Nordic nRF52833 host driving the DW3110 over SPI under nRF Connect SDK / Zephyr (your DW3xxx driver), with no Qorvo MCU — i.e., the DWM3000 + nRF52833 two-chip build, equivalently the DWM3001C? Is there an nRF Connect SDK / Zephyr example we can start from?

  3. In the listener path, what does the host receive per measurement round — RX / first-path timestamps, the per-anchor TX timing and clock-offset correction data carried in the DL-TDoA frames, anchor IDs, CIR / first-path diagnostics, and quality/RSSI — i.e., everything needed to run hyperbolic multilateration on the host?

  4. Can the listener acquire a position fix in a short, bounded receive window (sleep → wake → capture one DL-TDoA round → sleep) for coin-cell operation, rather than continuous listening? Roughly how many frames / what window duration is needed per fix?

  5. For the matching anchor side: does the SDK provide synchronized DT-Anchor (downlink-TDoA transmit) firmware, and how is inter-anchor clock synchronization achieved — over-the-air via the DT-Anchor exchange, or external/wired sync? Our anchors are intended to be fixed and transmit-only.

  6. What is the FiRa conformance / interoperability status, and any certification status, for the DT-Tag and DT-Anchor roles?

  7. Is any of the DL-TDoA software NDA-gated or license-restricted? If so, what is the process, and can you point us to the relevant app notes / user-manual sections and an evaluation path (e.g., DWM3000EVB + a Nordic DK, or the DWM3001CDK) to prototype the DT-Tag listener?

  8. If DT-Tag self-positioning is not fully in the current public release, what is available under NDA and the expected timeline?

We’d appreciate being connected with a UWB applications engineer for a short follow-up, and we’re happy to sign an NDA. Thank you for your help.

Blessings,
Bob

Did you get this resolved? You are using configure and start, so it should have started ranging

Is the CDK non-component side facing the phone? Also the UWB has a narrow view angle on the phone (60 degrees)

unless you enable camera assistance (since iOS 16, sept 22) and succeed in getting camera/UWB signal convergence