How to check distance data in the CLI of DWM3001CDK?

Wireless Connectivity Ultra-Wideband
1

Hello.

I purchased MDEK1001 and 10 DWM3001CDK this time. (For comparison of two types)

I want to make the following configuration, but I want to check if it is possible.

  1. 4 Anchors (called RESPF or Controlee) are installed in any space.
  2. 1 Tag (called INITF or Controller) is within Anchor’s range.
  3. 1 Listener receives the Tag’s location in a separate space.
  4. Listener is connected to the PC and sends data to the serial.

(First of all, I’m starting with DWM3001CDK)
As above, I would like to receive the data by PC through a board connected separately (probably outside 10 to 20M) outside the scope of the UWB positioning.

However, what I have confirmed while reading the manual and testing is that Listener can only give roles to the CLI, and some of the contents of the data received by Listener are encrypted.

JS00D7{“LSTN”:[49,2B,00,00,26,13,00,FF,18,5A,08,08,08,08,08,08,08,08,2A,00,00,00,CA,A6,C2,57,00,3F,D9,10,C9,20,6A,17,C4,3C,58,95,ED,91,DA,CA,52,57,D9,A3,8C,A7,27],“TS4ns”:“0x47F2D4D8”,“O”:1224,“rsl”:-64.71,“fsl”:-64.95}

I think “LSTN” contains distance information among the messages I received, is there a way to decipher that data in a UWB positioning environment that consists of CLI?

And how can I find the ID that starts with JS at the beginning of the message on the board? (I think it’s a unique ID for each board, but what is it?)

3

Hello,

Thanks for choosing Qorvo UWB! I’d like to help you move forward with a few key points.

I understand you’re using the Listener to collect the Tag’s location using the SDK features. It’s important to note that the Listener receives all UWB packets that match the expected format. If the Anchors and Tag are actively communicating, the Listener will capture those exchanges.

About the Listener and LSTN

The Listener is a Qorvo-provided example application built on the CLI framework. It’s designed to help customers develop their own solutions by showing how to receive and process UWB packets.

The LSTN field in the JSON output contains the data payload of received UWB packets, along with some metadata. Depending on the message type and your setup, parts of this payload may be encrypted according to the IEEE 802.15.4z standard.

Since the Listener captures all matched packets, you’ll need to decode the payload at the byte level to understand the message type and extract meaningful data.

For example, in a typical FiRa TWR (Double-Sided Two Way Ranging, one-to-many, deferred mode) ranging exchange with 4 Anchors and 1 Tag, you will observe:

  • 1x RCM (Ranging Control Message)
  • 1x RIM (Ranging Initiation Message)
  • 4x RRM (Ranging Response Message)
  • 1x RFM (Ranging Final Message)
  • 4x MRM (Measurement Report Message)
  • 1x RRRM (Ranging Result Report Message)

Among these, MRM has the information to calculate the ToF (Time of Flight) and RRRM contains the calculated ToF result. - but only if you decode it correctly. Other messages serve different roles and contain different types of data.

About the JSxxxx Prefix

The JSxxxx prefix is a message framing format, not a board ID. The xxxx part is a 4-digit hexadecimal number indicating the length of the JSON log data that follows.

If you can share more details about your target use case, I’d be happy to provide more specific guidance. I hope this helps you move forward with your development!

Thanks again.