DWM3001CDK Asynchronous/Synchronous and Flushing Buffer

Hi,

I have 5 dwm3001cdk sensors setup in a 1 Initiator, 4 Responders setup and am reading distance values from the initiator across serial using the CLI. I am experiencing two problems however.

  1. I am receiving the distances values from the initiator at varying frequencies, it appears to me that the CLI sends the values asynchronously. Assuming that is correct, how would I modify the CLI to make it synchronous. If that’s not the case or feasible, what other options do I have to get distances values at a steady rate.
  2. I am sometimes getting a flood of old distance values, presumably from a buffer somewhere, which is throwing off my real time position. I can flush this with the script that reads the serial values however I’d prefer, if possible, to disable this buffer or flush it automatically so I am only receiving current distance values.

Any help with these two issues would be appreciated, thank you in advance.

Hi @Cael,

Have you had a chance to follow this tutorial? Tutorial: How to Use DW3 QM33 SDK for One to Many FiRa Ranging

With one-to-many, you should get the distance from each responder in the initiator’s ranging round report.

Hi @akash,

Thanks for responding, I have followed that tutorial and I am receiving distances from all 4 anchors.

My issue is that I am receiving the distances asynchronously and at a slower frequency than I would expect. Using the CLI I set the SLOT=2400, BLOCK=192, ROUND=24 and RRU=DSTWRNDEF. Which, if I’m not mistaken, should result in a frequency around 20 Hz. Instead I am receiving distance results at about 6 Hz.

I have seen reference in other answers DW3000 limitations and frequency adjustment - #2 by Wassim_Qorvo to delay variables that may be the cause but have been unable to locate them within the SDK.

Any help with locating these delays or with finding another solution to my problem would be appreciated.

Regards,
Cael

Hi @Cael, BLOCK parameter is the block duration, i.e., the ranging interval. So if this is set to 192 [ms], then your update rate will be 1000/192 = 5.2 Hz.

In your ranging, you will need 2*N + 4 slots to do your ranging, where N is the number of responders. So if you have 4 responders, then you need a total of 12 slots. The ROUND parameter is where you define this, i.e., slots per ranging round. Then with slot duration of 2400 RSTU = 2ms, you are taking 24 ms per ranging round, so you can reduce your block duration significantly.

If you want an update rate of 20 Hz, try BLOCK = 50 and ROUND = 15. This should give you sufficient margin.