Trek1000: Frequent null measurements when 4th anchor out of plane

Wireless Connectivity Ultra-Wideband
1

Hi all,

I’ve been characterising the Decawave ranging device kit (TREK1000) in a motion capture room to try and determine its accuracy. The set up is as follows: A0 (0,0,0.77m), A1 (0,1.5m,0.77m), A2 (1.5m,0,0.77m), A3(1.5m,1.5m,0.77m) - anchors placed upon tripods in a large, empty room. All these coordinates are within +_1mm (as validated using out motion capture software). The tag then begins its journey from approximately (6m,6m,0.1m) and travels towards the middle of the enclosed square (defined by the four anchors) along the ground (maintaining a height of ~0.1m).

As expected, the x-y plane position estimate is accurate, to within +_ 0.2m (which improves when the tag enters the enclosed area). The z-axis position estimate is much worse, about +_ 1.5m, improving substantially when the tag enters the enclosed space. During this ~60s data collection period, we made ~600 measurements. Of these 600 measurements, about 40 were NaN (null measurements).

Curiously, when I raised anchor 3 (A3) out of plane to (1.5m,1.5m,1.2m), the accuracy didn’t improve (although the z-axis ambiguity was lost), but the number of null measurements increased dramatically (of the ~600 measurements, ~300 were null measurements). These null measurements only occurred when the tag was close to the ground (well below the anchor plane, and did not occur when the tag was at the same height above the plane).

Does anyone have any idea why the number of null measurements increases so dramatically when the fourth anchor is raised out of plane? I’ve attached the figure and data for this test.

Thanks for your help.

2

Just to be clear, when you say “null measurements”, you mean that there are 3 or 4 ranges but the Location Engine cannot calculate/estimate position?

Note, TREK Location Engine is quite basic. This is just an example Location Engine and customers/users can modify the code to improve it or replace it with own.

Z

3

Thanks for getting back Zoran. Yes, that is what I meant. So it seems I’m getting all four ranges fine (I should have noticed that before). It has just occurred to me that we should be able to use these ranges to calculate position. I assume these four ranges cannot be resolved in a location (they give somewhat conflicting ranges), hence the location is an array of NaN’s? I haven’t looked at the source code yet, but I will.

Thanks for your help.