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

Wireless Connectivity Ultra-Wideband
, , , ,
1

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
3

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

4

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…

5
  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.
6

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.

7

The QorvoOneTWR-2.1.1 is working now, thanks.

8

Hello,

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

Thanks a lot

1 Like
9

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.

2 Likes
10

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,

1 Like
11

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

12

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

13

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?