Strange ranging errors indoors

I have built a system using DW1000s that implements a symmetrical 2 way ranging algorithm.
I’m only interested in LOS applications and so all testing and results are with a clear and unobstructed view.

When testing outdoors everything works perfectly.
I haven’t implemented compensation for the receive power level and so get range errors that almost exactly match those described in app note 11 section 3. Other than that things work well, ranges are reliable and have a noise level of a few cm.
This includes some fairly nasty outdoor environments e.g. over the tops of some cars parked next to a metal skinned building.

When testing indoors over shorter ranges in a range of buildings everything is fine.

When testing indoors over ranges of 45 m or more I get a very weird effect. My range measurements are intermittently coming in at 58 m short.

Sometimes this only effects one direction of my ranging resulting in an output that is 29 m short, this is fairly easy to detect because the two measured ranges are clearly different and so the data can be discarded.
Other times both measurements are impacted, easy to detect if the true range is under 58 m but when over 58 m apart this looks like a valid range measurement.
It is a very deterministic error, it’s always the same distance error to within the measurement noise no matter the physical separation.
All of the receive signal strength related registers give similar values for good and bad results.

The effect is intermittent, with things stationary in the worst spots it only impacts about 25% of measurements. It is very position dependent, move 10 cm and if can vanish completely.

We only have one building we can test in that is sufficiently large to test ranges like this and access to that is a little restricted so random trial and error isn’t an option.
The building is brick and metal construction with a metal roof and concrete floor with a ~50cm wide trench down the middle covered by metal plates.
It seems that the problem only happens when the path between the two radios passes over the section of floor with the plates in however that may be misleading, given the size of the building there are limited opportunities to get the required separation without passing over them.

It happens on all channels (e.g. moving from a centre of 4 GHz to 6.5 GHz doesn’t have any effect).
It happens on all preamble codes.
It happens using both the standard and Decawave SFD codes.
I have only tried 6.8 Mb/s and a PRF of 64 MHz (16 MHz is on the list of things to try)

The radio configuration is all fairly standard and as recommended in the manual / app notes.

The position dependency of the problem would indicate that it is multipath related but the ranges are coming out shorter rather than longer which just seems weird.

Any ideas / suggestions would be greatly appreciated, this one really has me scratching my head as to what is going on.

Hi Andy,

What you’re witness could have various reasons like Multipath caused by reflections from the ground and walls, but of course also the impact of the metal plates.
It describes the phenomena of multipath handling and the effect of attenuation characteristics of certain materials.
APS006 part 2 will help you to understand your NLOS situation and to manage them.
Bit documents can be downloaded from under “Range and Accuracy”



The second line of my post was: “[color=#333333][size=small]I’m only interested in LOS applications and so all testing and results are with a clear and unobstructed view.”[/size][/color]
[color=#333333][size=small]To which you reply [/size][/color][color=#333333][size=small]"[/size][/color][color=#333333][size=small]APS006 part 2 will help you to understand your NLOS situation"[/size][/color]

The app notes all claim that if you have direct line of sight with sufficient link margin you will get the correct timestamp.
As stated I have direct line of sight between antennas.
I am at a range that completely reliable outside, I can operate at >20 m longer ranges both indoors and out so I have no reason to believe that the link margin is low.

The app notes also indicated that any multipath or indirect path effects will increase the time of flight and so increase the distance measured.
As stated I have a decrease in measured distance. A very constant decrease in measured distance, I can move everything around and when things go wrong they will always go wrong by 58.1 m.

I feels like a multipath issue but the consistent quantized error, the direction of the error, and the frequency independence are all at odds with what I would normally expect to see from multipath.

The multipath mitigation methods listed in app note 6 don’t help, that’s exactly what I’ve been doing from the start.

If it is possible, use the lowest data rate (110kbps) and channel 4. This should give you better long-range performance overall. Goodluck!

I’m not sure if you read the original post or why you dug out a 3 year old post to add this comment but 1) it was never a range issue 2) the lower data rate would have required slowing the system down too much.

The actual cause of the issue was found to be long distance reflections as detailed in TN006.