Setup and its effect on noise and accuracy

Hi I have a few questions about the setup. I couldn’t find a proper information on it in the manuals. Please point me to the right one if this is more convenient. I am using MDEK1001 dev kit and I am trying to make it as accurate as possible.

  1. Manual anchor setup: what point of the device to measure from. Somewhere in the middle or on the height of the antenna?
  2. This actually points me to another question which is: should the anchors be in upright position with battery slot on the bottom, or it doesn’t matter?
  3. How important is it to keep the anchors away from obstacles? I have read somewhere to mount it at least 15 cm off the walls and metal objects. I have seen in the quick setup videos that the anchors where on the walls.
  4. I try to track person in a space of roughly 6x6m room. I found when the person turns the position is jumping (high noise). Is human body attenuation relevant here? I added extra 4 anchors, so had 8 in total, but the result was similar or worse. Is it better to place the anchors in a grid, e.g. suspended from the ceiling or on a perimeter?

I also have some questions about the operation:
5. Assuming I just want to track one person, is it possible to increase the frequency of reporting position? Would it require reprogramming the dev board? What’s the max output frequency on the core antenna chip and is it possible to get the updates with a higher frequency than 10 Hz using the same dev kit?
6. Are the values reported in shell UART averaged or instantaneous?
7. Can I get the reliability rate associated with each sample? Something like tracking status.

2 Likes

Hi,

since no one responded so far I try to answer some of your questions. But unfortunately more from a theoretical perspective than from a practical perspective since we are using our own software stack and localization system.

  1. Typically you want to measure from the point where the electromagnetic wave is propagated. So typically I am measuring from the center of the antenna. But this is not so critical as this would be a deterministic error source and you could easily calibrate the error.

  2. Yes, the orientation is critical. As mentioned in the DWM1001 Datasheet (Section 6) the used antenna is vertically polarised, which means (simply said) that the anchors and tags should be orientated in the same direction (in contrast to circularly polarized antennas). Note: Turning it by 180° might not be such a big deal.

  3. This of course depends on the required precision of your system. But in theory, yes, you should keep the anchors at least 15cm off the walls to avoid a distortion of the UWB pulses. For example in a multipath-assisted localization system we have developed a while ago https://grosswindhager.com/pubs/grosswindhager2018salma.pdf
    it is very critical to have ‘nice’ pulses. In your system it might not be such an issue. Still, if possible keep some distance to the walls.

  4. Yes, as with every electromagnetic wave, the human body has an impact on the wave propagation (mainly because of the water in our body). But as we have figured out in measurements, Decawave/UWB is actually pretty robust in setups with people walking around.

5-7 I cannot comment on them, because we are using a different software stack.

Hope that helps.

Best,
Bernhard
TU Graz, Austria

Bernhard_Grosswindha covered most of it but here’s my 2 cents:

  1. Ideally the middle of the antenna. However if they are all oriented the same way then as long as you are consistent the exact point you measure won’t make a huge difference.

  2. Yes keep them all the same way up, either pointing up or down and also the same orientation, e.g. the front of the board facing into the middle of the room.

  3. Anything close to the antenna will have an impact on the antenna pattern. Any asymmetry in the antenna pattern will result in deflection angle related errors. Meaning that if you were to move in a perfect circle around the anchor you would measure slightly different ranges at different locations.
    You can’t completely eliminate this effect but keeping the antenna ~15 cm away from anything else does help reduce it.

  4. The decawave software picks 4 anchors to use for a position calculation, it has no way of telling if your body is going to be blocking the path to one of them or not. As soon as something blocks the direct path accuracy is going to drop, a human body is basically a sack of salt water and is very good at blocking the UWB signals.
    Often the best solution is to avoid the signal getting blocked in the first place by putting as much as possible above peoples heads.

You can start getting clever, measure to all 8 anchors and discard measurements that don’t fit the consensus for where the tag is. But that requires a custom position routine rather than the decawave one.

  1. 10 Hz is the maximum for the decawave positioning system. Far higher rates are possible but require you to write your own software for doing the ranging and position calculation.

Thank you for the responses. Bernhard it’s actually quite impressive what you can do just with one anchor! However, I would like to see if it’s possible to go down with error to 3-5 cm consistently and low noise.
Only after some research and your responses I realised how of an impact have people’s bodies on RF propagation, also on TOF. I might try put the tag on person’s head then.

As to the data frequency, we need something like 25 Hz minimum as it might be used for video production. Could you tell me what is the bottleneck here? Would it be possible to get 60 or 90 Hz with custom software?
Would it be possible to have the tag sending just ranges to anchors (or even the raw impulse responses) and having the trilateration done on a PC? Assuming the hardware is the bottleneck.

Thanks,
Maciej

The 10 Hz limit is due to the radio protocol used. The system splits the time up into 100 ms blocks which is then subdivided into sections for different uses (network management, position calculation etc…) Each tag can only calculate a position once in each of those 100 ms blocks.

Running custom software 100 Hz or faster positions are completely possible. You don’t need a PC for the position calculation at that rate, if you use a simple algorithm an ARM M4 at 200 MHz or so should do it. Of course there is no real upper limit on how much processing time you could throw at it, there are all sorts of ways of filtering and smoothing the data to improve performance.

Hi Maciej,

I just add the comments which are missing:

  1. In PANS the system tries to select one anchor from each quadrant to reduce the chance of hitting the obstacles with multiple measurements. That can help to make the position estimation more robust. But if you want accuracy of sub 10 cm then the antenna should be kept away ~15 cm or higher from any obstacles.

  2. In PANS max. update rate for a Tag is 10 Hz. That is not physical limitation of UWB but the limitation of the software stack, MCU performance and the compromise between the features PANS provides.

  3. Yes, it has an internal moving average of 3.

  4. There is a Quality Factor value (QF) for each measurement. However it is only an estimate. For the accuracy you need it might not be relevant.

Cheers,
TDK

Is the moving average on 10 Hz samples or it’s averaged lower down in stack on some more frequent data?
I am asking because now the delay is too big for my purpose. It’s roughly a second. Could be my implementation as well, because I am reading the shell responses (LES) getting to the listener node.

Is there a way to use TLV commands (generic mode) to get position of a wireless tag through the listener? Would it work potentially faster than shell?

Hi Maciej,

the average is of the last 3 values. So when looking at the shell of the Tag you might see at maximum delay of ~300ms. When looking at the listener it would be ~400ms.

Using TLV it would not be faster. The delay which you observe could be caused by something else. Which program or language do you use to read the data? Python and Java are not ideal if you need low latency and performance.

Cheers,
TDK

It’s C++, however the code might not be optimal. I don’t think a simple code like that could make such a difference as 500ms, no matter if it’s Python, Java or C++.

Hi @machey,

sorry for my late response.

The reason why the accuracy is at about 30cm is basically a physical limitation of the transceiver/UWB as the resolution of the CIR is ~1ns (~30cm in the time domain). But of course with some filtering (e.g. averaging position estimates, Kalman, Particle,…) the error can be reduced to a few centimeters. Also combining it with accelerometer, gyro,… would help a lot.

Best,
Bernhard
TU Graz, Austria