Hi, I have a set-up where 50 tags localize in two-way ranging mode with 4 anchors every 750 ms. I noticed that rarely (0.04% of cases) distances are shorter than wanted. Tag and Anchor are in a static position.
Can someone tell me if I have to consider a particular module configuration to avoid this problem?
Thanks in advance
Are you indoors in a fairly large area?
Take at look at Indoor ranging errors (received ranges are shorter than real distances) and see if this matches what you are seeing.
There are a number of other threads on the forum about this. It is very environment specific can really throw you when you first encounter it.
Hi Andy, thanks for quick response. My problem is a little different form what is described in other threads. I get shorter distance with random valules and with a 0.02 %rate in 2 types of scenarios:
- 50 tag, with a 750ms second localization period each, performing TWR with 4 Anchor with Many-to-one strategy (one poll, multiple response, one final message)
- 50 tag, with a 5 second localization period each , performing TWR with 1 anchor with classic TWR (on poll, one response, one final message). Anchor is surrounded by fixed obstacles far enough from it, 30 cm around
I try to filter messages with fp_index < 745 but i gained no results. Filter in power
Any other ideas?
Thanks
Federico
I default my filter to rejecting points with a fp_index < 740 rather than 745, the most aggressive my system allows is 743, any higher and I started rejecting significant numbers of good points.
I run a similar system, either conventional DS TWR at 800 measurements/second or multi-anchor DS TWR at 2400 measurements/s. The only difference I’m only using a small number of tags and up to 12 anchors in order to give better accuracy and cope with rapid movements.
Beyond the reflections issue that the fp_index filter fixes I’ve seen intermittent weird results in two other situations:
-
When my range exchange packets weren’t getting correctly indexed and so I ended up using request and response times from two different exchanges. But this generally resulted in a range that was clearly absurd (either negative or huge).
-
When using antennas that were on a 1m cable rather than right next to the transceiver IC and operating at a short range. In this situation the signal would some times get directly coupled in to the circuit rather than going through the antenna and cable. This resulted in the signal skipping the cable delay (that had been calibrated for as part of the antenna delay) and so giving a distance that was roughly a multiple of 25cm short. It would be ~25. 50, 75 or 100 cm short depending on which packets had bypassed the cable. This could be fixed by better shielding, low powers, longer ranges or putting the chip and antenna right next to each other.
I don’t think either of these match your issues but it may be worth checking for something similar.
One additional issue I remember hitting.
Sometimes I would get status flags indicating a valid RX had completed but the leading edge algorithm had gone wrong. I can’t remember the details (they will be in a old post on here somewhere) but the RX timestamp register had a distinctive pattern in it when this happened.
The check for this situation is if the Rx time and the raw Rx time (the value before leading edge detection corrections and delay offsets) were different by more than a certain threshold then reject the packet as invalid.
This happened at around the rate you are seeing but generally gave massive time errors that resulted in impossible ranges.