Anchor board works with all MAC values, except MAC = 5

I am using several DWM3001CDK boards (1-initiator MAC0 and several anchors). I thought I had everything working and was testing going through each of the MAC numbers for the anchors. I have by default the initiator set as MAC 0 and I was going to have the anchors as MAC 1-8 (8 anchors in total).
The problem I came across is 1 board I can set it as an anchor with a MAC value of 1,2,3,4,6,7, or 8 and it will work normal. However, when I set the board as MAC = 5, then when I view the Initiator stream I see the anchor MAC 5 respond with a value one or two times, and then after that it doesn’t report a distance again? It just shows timeout like the other MACs (nothing attached to them at the moment, only sending info from 1 MAC at a time, just confirming each MAC setting can work).

These are the values sent to the board in the order I send them (programmed for CLI operation).
STOP
RESPF -MULTI -ADDR=5 -PADDR=0
STOP
SAVE
SETAPP RESPF
SAVE

These are the responses I read back from the board during the process of setting it up:

SESSION_STATUS_NTF: {state=“INIT”, reason=“State change with session management commands”}
SESSION_STATUS_NTF: {state=“IDLE”, reason=“State change with session management commands”}
SESSION_STATUS_NTF: {state=“ACTIVE”, reason=“State change with session management commands”}
SESSION_INFO_NTF: {session_handle=1, sequence_number=0, block_index=0, n_measurements=1

[mac_address=0x0000, status=“RX_TIMEOUT”]}
SESSION_INFO_NTF: {session_handle=1, sequence_number=1, block_index=1, n_measurements=1

[mac_address=0x0000, status=“RX_TIMEOUT”]}
SESSION_INFO_NTF: {session_handle=1, sequence_number=2, block_index=2, n_measurements=1

[

ok

RESPF -MULTI -ADDR=5 -PADDR=0
FiRa Session Parameters: {
SESSION_ID: 42,
CHANNEL_NUMBER: 9,
DEVICE_ROLE: RESPONDER,
RANGING_ROUND_USAGE: DS_TWR_DEFERRED,
SLOT_DURATION [rstu]: 2400,
RANGING_DURATION [ms]: 200,
SLOTS_PER_RR: 25,
MULTI_NODE_MODE: ONE_TO_MANY,
HOPPING_MODE: Disabled,
RFRAME_CONFIG: SP3,
SFD_ID: 2,
PREAMBLE_CODE_INDEX: 10,
STATIC_STS_IV: “01:02:03:04:05:06”,
VENDOR_ID: “07:08”,
DEVICE_MAC_ADDRESS: 0x0005,
DST_MAC_ADDRESS: 0x0000
}
ok
SESSION_STATUS_NTF: {state=“INIT”, reason=“State change with session management commands”}
SESSION_STATUS_NTF: {state=“IDLE”, reason=“State change with session management commands”}
SESSION_STATUS_NTF: {state=“ACTIVE”, reason=“State change with session management commands”}
SESSION_INFO_NTF: {session_handle=1, sequence_number=0, block_index=0, n_measurements=1

[mac_address=0x0000, status=“RX_TIMEOUT”]}
STOP

ok
SAVE

ok
SETAPP RESPF

ok
SAVE

ok

This is the output from the Initiator and you can see how I was getting no response, then I plug in the anchor to USB and receive a distance value 2 times from MAC 5, but then after that it never reports a distance value again?

I only see this behaviour when set to MAC = 5

I can change the command to the anchor to MAC 6 as shown below:

STOP
RESPF -MULTI -ADDR=6 -PADDR=0
STOP
SAVE
SETAPP RESPF
SAVE
SESSION_STATUS_NTF: {state=“INIT”, reason=“State change with session management commands”}
SESSION_STATUS_NTF: {state=“IDLE”, reason=“State change with session management commands”}
SESSION_STATUS_NTF: {state=“ACTIVE”, reason=“State change with session management commands”}
SESSION_INFO_NTF: {session_handle=1, sequence_number=0, block_index=0, n_measurements=1

[mac_address=0x0000, status=“RX_TIMEOUT”]}
SESSION_INFO_NTF: {session_handle=1, sequence_number=1, block_index=1, n_measurements=1

[mac_address=0x0000, status=“RX_TIMEOUT”]}
SESSION_INFO_NTF: {session_h

ok

RESPF -MULTI -ADDR=6 -PADDR=0
FiRa Session Parameters: {
SESSION_ID: 42,
CHANNEL_NUMBER: 9,
DEVICE_ROLE: RESPONDER,
RANGING_ROUND_USAGE: DS_TWR_DEFERRED,
SLOT_DURATION [rstu]: 2400,
RANGING_DURATION [ms]: 200,
SLOTS_PER_RR: 25,
MULTI_NODE_MODE: ONE_TO_MANY,
HOPPING_MODE: Disabled,
RFRAME_CONFIG: SP3,
SFD_ID: 2,
PREAMBLE_CODE_INDEX: 10,
STATIC_STS_IV: “01:02:03:04:05:06”,
VENDOR_ID: “07:08”,
DEVICE_MAC_ADDRESS: 0x0006,
DST_MAC_ADDRESS: 0x0000
}
ok
SESSION_STATUS_NTF: {state=“INIT”, reason=“State change with session management commands”}
SESSION_STATUS_NTF: {state=“IDLE”, reason=“State change with session management commands”}
SESSION_STATUS_NTF: {state=“ACTIVE”, reason=“State change with session management commands”}
SESSION_INFO_NTF: {session_handle=1, sequence_number=0, block_index=0, n_measurements=1

[mac_address=0x0000, status=“RX_TIMEOUT”]}
STOP

ok
SAVE

ok
SETAPP RESPF

ok
SAVE

ok

Then with the same board set to MAC = 6 I get the following normal responses:

So why is it this same board will only briefly report the distance when the MAC is set to 5, but any other value it reports fine?
And just to clarify, I have no other boards running other than the 1 Initiator and this anchor board. So there shouldn’t be any reason for interference.

Thanks,
Clint

Hi Clint,
The behavior you described was found to be a bug found in QM33 SDK 1.0.2 and have been corrected since the release of QM33 SDK1.1.0. Please download the latest QM33 SDK to resolve this issue, here is a quick link to the Qorvo website: QM33120WDK1 - Qorvo.

best regards,
-Quan

Hi Quan,
Does the new release “QM33 SDK1.1.0” also include the fix for devices operating on battery power transmitting very slow.
An issue I had already dealt with here:

Akash had posted a solution I was able to follow:

I was able to fix my problem using the .hex file @akash had posted in his tutorial.
I have not been able to open the project files, so I’ve been relying on the file he provided.
I just don’t want to once again have that slow anchor transmitting problem on battery power.

Regards,
Clint

I tried the new rev 1.1.1 software and used the included Binary files.
So I guess I sort of answered my own question, but I thought I would put this on the forum incase someone else had a similar question.

The new DWM3001CDK-CLI .hex file does account for battery operation as I tried the same board I had before, reprogrammed it, and tested communication with a few other boards also reporting to the anchor. I can confirm, no messages lost. The new revision code works great so far!

Regards,
Clint

Hi, Does your anchors battery operated when you get the distance? Did you program every anchors first and operate it by battery or power bank and still get distance?

I programmed all of the boards with the new firmware version 1.1.1. While programming the boards are powered by USB from the PC. Then I used the computer to setup the Initiator board with the appropriate settings, and then disconnected the Initiator board and 1 by 1 I setup each Anchor board with the correct settings using the PC. Then I connected the Initiator board to the PC and connected with HyperTerminal to view the output stream and then I powered on 3 Anchor boards in the example shown (MAC addresses 1, 3 and 5 on battery power). With the old firmware version (before tech support provided me a modified version) I experienced very slow distance reporting when an Anchor was on battery power. This problem does not exist with the newest firmware version.

Hi. Did you successfully finish your project? Did you do a visualization? Like create a virtual environment?

I’ve finished most of my part of the project. The DWM3001CDK boards all work sending distance and the initiator is streaming the distance values out to a PC. So now it’s up to the software guys to write the code to pull the distance values and incorporate them into the product.

I did write a program that can configure the DWM3001CDK as an Anchor or an Initiator with menus to help set it up. This will assist our techs with setting up the boards for production later on.

hi. I tried flashing the new firmware CLI.hex to my 5 uwb module, adn I’m using tera term to set up each modules as iniatiator and anchors. Then when I connected the anchors in power bank and the initiator stay in my pc. this shows for initiator:

while setting up. after flashing cli.hex, I did this for:
Open serial terminal (tera term)

  • Run “stat” command
  • For initiator: run “INITF -MULTI -PADDR=[1,2,3,4]”

STOP

SAVE

SETAPP INITF

SAVE

  • For anchors: Run “RESPF -MULTI -ADDR=5 -PADDR=0”

STOP

SAVE

SETAPP RESPF

SAVE

The image showing the RX_TIMEOUT from the initiator is correct, but that is the typical response from the initiator when the Anchor boards are not transmitting (like when turned off).

It looks like the initiator is correct, so look at your Anchors.
Based on how your Initiator is setup, it is looking for MAC address 1, 2, 3, and 4.

So, on the configuration you send to the Anchor, you need to change the above message.
On the message you show:
RESPF -MULTI -ADDR=5 -PADDR=0

But you need to include that message to each Anchor board but -ADDR must equal 1 on the first Anchor, 2 on the second anchor, 3 on the third Anchor and -ADDR=4 on the last anchor.

With the value currently set to =5 the MAC address will be 5 on that board and the Initiator (looking for 1, 2, 3, 4) will not see it.

Also, after configuring the Anchor or the Initiator, remember you must remove from power and then power the board up again for it to start in the new configured mode.

Thank you so much for your help! It’s now working :slight_smile:

1 Like