I recently tried the MDEK1001 Evaluation Kit and was disappointed with its non-line-of-sight performance. As far as I know UWB signals should easily penetrate through obstacles with low power consumption which is why the UWB technology is used by decawave in the first place.
My experiences with the development kit tell another story: if the line of sight is obstructed to only one anchor (i.e. by a human body or a wooden plate) then the position error increases up to +/- 1 m. Stationary detection also does not work anymore. A stationary tag moves around in the android application during partial NLOS conditions.
I used the MDEK1001 Kit User Manual for the setup and followed all necessary steps.
Has anyone made the same experiences? Can I improve the NLOS performance somehow?
Thank you very much.
Hi Siniath,
UWB is fairly robust to multipath and NLOS in comparison to other radio such as BLE for example. But it remains a radio and NLOS will have an impact on performance that can’t be ignored.
The impact of obstacles on performance is very hard to predict. For example, the signal will easily propagate through 15cm wide plasters walls while it will be difficult through 60cm+ concrete walls.
One of the reason we are using 4 anchors in our RTLS scheme to calculate a position is to ensure that the tag will always have good LOS to at least 3 of them, even if the 4th one is shielded by a body for example. It is key to optimize the network deployment.
Maybe give more details about your setup such as picture and I can see if there is any potential optimization.
Thank you,
Regards
Yves
1 Like
[size=medium][font=Arial][color=#111111]Hi Yves, thanks for the reply![/color][/font][/size]
[size=medium][font=Arial][color=#111111]I attached a simple drawing of my office where I tested the evaluation kit with 4 anchors and 1 tag.[/color][/font][/size]
[size=medium][font=Arial][color=#111111]The anchors are mounted to the walls, the position of the anchors is marked with a red arrow. You can also see the x and y distance between the anchors. Every anchor is placed at the same height z = 1.6 m. I used the x, y, z coordinates as input for the Decawave RTLS Manager app (without using auto positioning which is recommended by Decawave). Anchor locations were constrained by their access to a power source.[/color][/font][/size]
[size=medium][font=Arial][color=#111111]The position of the tag is marked with a red triangle. The tag was attached to a radio-controlled vehicle in order to cover most of the office area in small steps.[/color][/font][/size]
[size=medium][font=Arial][color=#111111]NLOS scenarios of the tag are represented by red dashed line triangles which are especially interesting for me. In my case the tag was located under a wooden table. At this moment the app returned chaotic values even in a stationary position (stationary detection was enabled). The position drifts within a 1m radius. Also, it gets worse if a person just walks through the office.[/color][/font][/size]
[size=medium][font=Arial][color=#111111]I don’t understand why. First the accelerometer should detect the stationary state, so the tag shouldn’t change its position at all. Second the drifting which is most likely caused by reflections should not appear in this simple case.[/color][/font][/size]
[size=medium][font=Arial][color=#111111]Decawave and Nordic Semiconductor guarantee on their website that the modules are “Immune to multipath, no issue with operation in dynamic environment”. They also propose to use the technology for collision avoidance between robots and humans in factories. I simply don’t see how this can be achieved with the current hardware and firmware.[/color][/font][/size]
[size=medium][font=Arial][color=#111111]I have studied the “Part 2 NLOS Operation and Optimizations” document which recommends configuring the Preamble length, the NTM_1 and NTM_2 (noise threshold multipliers) for the DW1000. But unfortunately, it is not possible to configure these values with the current API for the DWM1001.[/color][/font][/size]
[size=medium][font=Arial][color=#111111]Do you know if there is a newer firmware version which makes NLOS optimization possible? Or if they are planning to release one?[/color][/font][/size]
[size=medium][font=Arial][color=#111111]Or is there anything else I can do to improve the NLOS performance, considering the anchor/tag configuration or location?[/color][/font][/size]
[color=#111111][font=Arial][size=medium]Thank you[/size][/font][/color]
Hi Siniath,
Thanks for the additional information.
[list]
[*]Regarding the stationary detection, it is used to switch between two update rates depending on if the tag was static or not. So if stationary detection is enabled, the update rate should be reduced but not necessary filtered. If you want to filter the position based on the accelerometer, then you will need to do it in the user application space.
[*] In order to understand the drift, it may be good to have a look at the output of the “les” command. Connect the tag to a pc and setup a serial connection with teraterm (115200 - 8 - n -1). You will see the detail of the anchors the tag is ranging with. What may happen is that the tag is constantly modifying the set of 3 anchors it is ranging to and as a consequence, the reported solution is alternating between a few solutions.
[*]Your setup is challenging as there are NLOS conditions for each range between anchor and tags. In those conditions, the accumulated error will be important and an error can be expected on the position. I’d say for this specific case, the anchor position is not ideal. If you need to track below and above the desk, then I would consider to position anchor at the floor level too. You could alternate with anchors fixed high and some fixed low in order to cover a better 3D area.
[*]We currently don’t have an API allowing to modify the noise_threshold multiplier. It is not possible to modify the preamble with PANS as it would compromise the TDMA scheme and break the system.
[*]If your application contains very challenging non-los condition, you may want to develop a custom firmware that will use the best configuration for non-los. For a POC, you may want to use a TREK kit which is much more flexible in term of radio configuration.
[/list]
Thank you,
Regards
Yves