LOS channel but wrong distance estimates

Recently I am using MDEK1001 to test single-side two way ranging by using the examples from GitHub (https://github.com/Decawave/dwm1001-examples). However, I found that in many cases, the distance estimates are terribly wrong. Here is the setup of the test:

I used two MDEK1001 mounting on 1-meter height tripods, and did a series of tests in a corridor. The corridor is 120 meters long. One MDEK1001 was put on one side of the corridor and I moved the other MDEK1001 to different distances. The two devices were facing each other all the time and all the tests were LOS without anyone passed by. I was sitting on the ground on one side behind the device and my head was lower than 1 meter. I loaded the exact codes from the GitHub (ss_twr_init and ss_twr_resp) to the devices and use Tera Term to display the estimated distance.

I found that when the true distances were less than 10 meters. The device provided relative correct estimates. The error is about 0.5 meter.

However, when the distances were larger, there were some negative distances such as -40 meters. For example, when the true distance is 36.62 meters, I got 98 readings and only 18 readings were about 37.11 meters. There were 34 readings which were around -4 meters and there were 46 readings with the number about -45.18 meters.

Then I modified the code to display the channel impulse response (CIR) data and I found that there were large 2 peaks before ~750’s sample. Please see the attached figures. By using dwt_readdiagnostics(), I can find that the -4 meters were estimated because the algorithm detected the wrong leading edge.

I found the similar question was asked before (Link: https://www.decawave.com/decaforum/showthread.php?tid=1025&highlight=CIR), but no one answers it. I hope someone could help me why there are two peaks before the direct path in the CIR data and how to avoid the wrong estimates.

Thanks and regards,


In some scenarios delayed reflections can give rise to these “early” peaks, and hence negative distances, as pointed out in (https://www.decawave.com/decaforum/showt...hlight=CIR). One of the ways to mitigate would be to ignore/remove timestamps if First Path index is < ~700… this can be tuned in your application. Also the threshold above which the FP signal is detected can be increased. Please review NLOS app notes which provide details on this.

Hi Zoran Skrba,

Thanks for your prompt reply. Could you specify which NLOS app notes you referred to?

Moreover, you said the “early” peaks were caused by the delayed reflections. Do you mean the reflections from current transmission or the previous transmission?

In AndyA’s post (https://www.decawave.com/decaforum/showthread.php?tid=1025), he assumed that the “early” peaks were the delay reflection path from the previous transmission. But in the CIR figures I showed, I don’t think the “early” peaks were from the previous transmission, because I set the interframe delay as 10 seconds. I do not think the power of a path through multiple reflections and traveling 10 seconds can remaining that high.

Please advise.


Each radio packet transmission consists of a series of radio pulses at a fixed interval. What we are seeing is the previous one of those pulses still echoing when the next pulse is sent.
So previous pulse I meant an earlier part of the same transmission rather than a prior data packet. Sorry for any confusion.

Hi chang,
You mentioned you have modified the code to display the channel impulse response (CIR) data. We want to do it too. But I don’t know how to do? Can I use the DW1000 API guide’s example? Could you please share how you got these data? I really need some help. PLZ~
Thank you!