Problem with Generic Dwm_Get_Pos command on DWM1001C - PANS2 firmware

I have a micro processor set up as host to DWM1001 using Generic mode TLV commands.
I have set the TAG update rate for both Active and stationary mode to 0.1 seconds and enable stationary updates.

My code continually issues the GET_POS (cmd 0x02) and waits for uart reply to get position.
When I first reset the device on power up the first read is all 0x00 (which is fine).
Then I start getting valid positions.

The problem is that when I move it out of range of the Anchors, it keeps sending back the LAST position read and never resets or indicates no available position. My controller then determines it is still in the old position when it is not.
Is this how the DWM1001 module works according to PANS 2?
What can I do about this?

The other questions related are:
Is there a TLV command that can set up DWM1001 to stream valid positions to the uart?

Can an interrupt pin be set up to indicate when a valid position is available (at the moment my uart waits for data and times out if none received)


Hi @david
with PANS 2 it is working in the exact same way. I would recommend you to update to PANS 2.0 as it contain many updates / bugfixes.

It the regard of position it is recommended to use the IRQ for getting notification about a new measured position. It will actually also solved your issue - when there is no now position you will not get an IRQ from module. How ever you can also check dwm_status_get for
bit 0: loc_ready: new location data are ready
bit 1: uwbmac_joined: node is connected to UWB network


Thanks for your reply. I have programmed the modules with PANS R2.0.

Do I need to issue get_location command and wait for int each time or is the location available every 100ms - the update rate (ie. The interrupt occurs, you read to clear and then another int occurs 100ms later)?

Below I outline my setup. At the moment it works but updated location is slow (1-2 seconds) and I need it around 250ms or less. I am wondering if it would be due to the way I continuosly look for new location (I have not implemented irq yet) or whether I should maybe get the list of TAG locations from Anchor 0 and tansmit them as a list to the Tags?

I have 4 anchors (set in area 9m x 8m) and 2 Tags. Anchor 0 is set as initiator and others and normal anchors.
I have 2 Tags that have updates for dynamic and stationary set to 0.1sec that I request Location continuously. As long as location data shows at least 3 anchors, I use the position as latest valid position.
Then the Tags transmit their own position with rf link.
Both tags then compare the last valid position with last valid received rf position from other Tags and if within the X and Y limits set, an alarm is generated. ie. I my application is used to prevent Tags getting too close to each other.
I suspect that because I am continually sending uart commands to the dwm1001 that I am getting old data often and not updated data? My routine does wait after each location command for a valid received packet before requesting location again.

Can you please clarify for me if this is correct way to get location from a Tag.

  1. Issue Get_Location command
  2. wait for Interrupt line (go high? or low going?)
  3. read status to clear interrupt
    Data would have already been received on UART and Interrupt indicates position is valid?

OR, do I not have to keep issuing the get_location command and simply wait for interrupt, read status then issue get_loaction to read position?

Hi @david
the best way is to register interrupt for location ready (dwm_int_cfg_set) and once you get an interrupt via GPIO you need to read dwm_status_get to clear the interrupt (GPIO) and then read the position (get_location). You dont need to call the get_location before you get the interrupt.

You can also read the position and then clear it by calling dwm_status_get - the order is not important.


Thanks again,
I am getting close to having a more comprehensive understanding of the API.

To clarify, Once I have set node as TAG and I have set INT pin to enable position ready, the interrupt will occur every time a new position has been detemined but I must do a read status each time to clear that flag.

So, If I want to do a simple test to see how often an update occurs (without yet being concerned about reading the actual location), I simply do below and should see int around every 100ms?

  1. Wait for int
  2. Read status
  3. Print line to show I had int.

I assume when int has occurred that when I do a read_location, the data will come back immediately and not have large delay. (Assuming the only int I enable is position ready)

  1. Wait for int (READY pin goes HIGH)
  2. read status
  3. read location
  4. do stuff until next int.

Hi @david
yes that is correct. You can read location first and then read status if you need to have the newer location asap.


Thanks Again.

I set up the interrupt then check status on rx to make sure updated location flag is set then issue get location.

It runs every 100ms for around 50 or 80 times then stops and starts up againg maybe 10 seconds later, gets a few mesurements then stops again.

I suspect my software has some glitch in it somewhere but apart from that, is there any reason the Tag would stop updating the location. (I am testing with it fixed location on my bench with 4 Anchors set in rectangle 9m x 8m.

Further to my last post.
I notice that although I set the gpio_int value to 0x01 that I also get interrupt when the status flag register value is 0x02 (uwbmac_joined), I wonder if I get a clash when it generates interrupt for uwbmac_joined and while I am processing the response, it has immediately got loc_ready flag set and it gets skipped over?
I assumed that because I set gpio int like this → 0x34 0x02 0x01 0x00 that ONLY the loc_ready condition would set the int flag and nothing else?

My interrupt routine is based on positive edge trigger.

Hi @david
there should not be any relevance between uwbmac_joined and loc_ready in the term of generating IRQ. But the UWB join is typically followed by TWR measurement so this two situations could occur at the same time.


I seem to get them very close together but not at the same time.
My code sends the get_status command in response to an Interrupt then the uart fires on response to the Get_Status and passes through a Switch case below.
If loc_update flag was not set, it will ignore the interrupt and wait for next. It runs for a while well at 100ms intervals and then for some reason stops. I wonder if I should disable the interrupt once it triggers and do the uart processing before re-enabling it? I wonder if I get some sort of “race” condition.

Do you have any C code examples showing how you do this?

case dwmSTATUS_TYPE: //if change if position interrupt then get location
if(buf[5] & 0x01)
printf(“Status Reply: Position Flag Received\n”);
} else printf(“Not updated postion\n”);

I think there is something happening in the Module.
What I see is interrupt every 100ms and get location OK. I get around 30 readings perfectly fine and then it suddenly changes and I get interrupt every 10 seconds.

It looks like dwm1001C is defaulting back to stationary update rate of 10 seconds after it has been running for a while.

I found the problem.
When I first configured the device I set as tag, set the update rate and interrupt and then comment them out so on boot it uses values sored.
What I found is that the interrupt and update settings stayed in flash but NOT the tag configuration. Fo some reason they change value if I do not set the tag config each time I power up.
I checked the values after SET and found they were correct but when powering up, if not set again, the values change.

Hi @david
I would recommend to double check your code as the device sores its update rate in flash. You can try that in the shell.

I have reviewed local test codes and there is unit test that test persistence of update rate in Flash.

If the stationary mode is enabled then when the TN detect no movement for a certain period then it switch to stationary mode update rate. Try to jiggle it a bit and you should see the transitron to normal update rate.