With only two devices doing a point to point range then you only need to change one value.
Whether the delay is on the tag or anchor, transmit or receive doesn’t matter. As long as they all add up to the same the end result will be the same.
I generally work on the idea of splitting the time evenly between all appropriate items, it minimises the risk of things coming out negative at any point. At least in my head it does, I’ve never hit any issues doing it this way so never dug into it much.
When you have multiple devices then you do need to start to work out how much of the delay is due to each device. Since in a TWR each device does as many Tx as it does Rx exactly how the time is split between the two isn’t critical, I put it equally on both. However you do need to get the allocation of the delay to each tag and anchor correct otherwise you’ll only be accurate for certain combinations.
That said we normally only see around 10 cm unit to unit variation so given your requirements you may be able to come up with a fixed value that works well enough. I know antenna delay is a time measurement, I just find it easier to track it as the distance effect it has. It makes the numbers easier to deal with and end result easier to imagine.
This is single side, so like you said every combination will need to be calibrated, or in other words, if we have 1 basestation and 5 tags, All 5 tags need to be calibrated at known distance to make sure the end result is current in actual use.
The ANT_DLY values are programmed into the decawave chip, it then automatically adjusts all of the reported Rx and Tx time values by that amount to compensate for the delay. This is something you could easily do manually but getting the chip to do it makes for simpler code.
With 5 anchors and 1 tag you can assume that the tag is perfect and all the error is on the anchors. At that point you can measure the errors seen with each anchor and set their delays accordingly to compensate.
But this breaks when you have multiple tags, then you would need different per anchor delays for each tag.
What works better is to calculate the error on the tag as well as on the anchors so that you can correctly assign the delay value to every device independent of what it’s talking to. You do this by setting up 3 devices and measuring all of the distances between them. That then gives you 3 error values which allows you to calculate the 3 different delays.
Once you have a correctly calibrated unit you can use that to perform 2 unit point to point calibrations on any remaining units.
You need to do this for either type of TWR.
For our standard production like we use the 2 unit method of measuring to a known unit that has been previously calibrated. It’s simple and reasonably accurate. If we need the best possible accuracy we put 12 units at known locations. Each of them measures 1000 times to all of the others and reports the average. This gives over 60 measurements for 12 unknown delays. We then use a least squares optimisation to find the delay values for each antenna that give the minimum errors.
Thank you for your prompt reply Andy. I’m now confused regarding the antenna delays on either anchor side and tag side.
You see, there doesn’t appear to be, at least in the official example code, a standalone, independent antenna setting/Macro definition for tags, so what should I do?
Should I have an array which stores the ID and antenna information for each single tag? So when I’m ranging one specific tag, I’m using an unique, corresponding antenna delay value? Or there is a simpler way to do this?
Each device only needs to know it’s own delay. If each unit is setting its delays correctly then everyone else can assume the delay is zero. Both the tag and the anchor will have TX_ANT_DLY and RX_ANT_DLY values, you just need to set these to the correct value on each unit.
The way we do it is that we store the delays in a fixed location in the system flash. On the production line we set the values on a device by device basis. On startup the firmware reads this location and sets the delay based on the values.
You could use the OTP storage on the decawave chip itself to do this but we preferred putting it somewhere that we could change it if needed.
For early development before we had this system in place we had a header file that was in effect a big look up table of device antenna delays for each serial number. Obviously not scalable but a lot simpler for when we only had a dozen units.
The transmit time that the chip records is when the signal leaves the internal modulator circuit. It then has to pass through some amplifiers, along a PCB trace and into the antenna. That takes times.
Similarly on reception the signal arrives at the antenna, passes along the circuit board and through some internal amplifiers before getting to the point where it is detected and timestamped.
For time of flight you need to measure the time between the antennas not the time between the transmit logic and the receive logic. That’s what these antenna delays are doing, removing the time the signals spend in the circuits.