Hello guys,
I doing a project about 4 anchors with a Tag, I encountered a very strange problem.
I use raspberry pi pico and DW1000 as anchor and Tag and use arduino IDE program them with arduino dw1000 library. When testing the distance to the tag using each single anchor, the results obtained are normal.
for example,
The situation of the strange problem is I set the distance between anchor 1-4 and tag is 1m, and test each anchor to tag is 1m, when I turn on the anchor 1, the distance of anchor 1 to tag is 1m,
turn on anchor 2, the the distance of anchor 1 to tag become 0.9m, anchor 2 to tag is 0.88m,
turn on anchor 3, the the distance of anchor 1 to tag become 0.8m, anchor 2 to tag is 0.6m, anchor 3 to tag is 0.8m,
turn on anchor 4, the the distance of anchor 1 to tag become 0.8m, anchor 2 to tag is 0.4m, anchor 3 to tag is 0.8m, anchor 4 to tag is 0.2m,
Do you know why multiple anchors affect each other when they are tested at the same time?
I have try to recalculate the antenna delay for the anchor, but I change a anchor, the tset disdance of other anchor will also be affected.
How are you controlling which tag replies when? Have you added logic to a) identify which device a given message is from and b) ensure no two devices are ever transmitting at the same time? If not this is a very common issue people hit when moving to multi-tag systems. Please search the forum, this topic has comes up frequently and has already been answered many times.
If you have already done this then please include details since it’s impossible to help further without them.
In this project, I only use one tag and four anchor. In the arduino DW1000 library, each anchor comunicate with tag, the anchor will define a unique MAC address for identification. I think all anchor will transmit in the same time, but i think the tag will comunicate with them one by one because of the unique MAC address. I also search a Successful example in YouTube,
My settings are similar to his. I had ask the author some question about this problem, He said he do not have this problem, So I’m confused about this. Do you have any thoughts on this to go and figure out the problem?
thank you.
If all anchors are replying at the same time then it is purely luck which one you will see. The short version is that if multiple UWB devices transmit at the same time on the same frequency then your system will not work.
The problem you are seeing isn’t antenna delay since that is a constant value and doesn’t depend on which other systems are switched on. However once you have fixed this issue you may well have errors to do with antenna delay calibration.
When calibrating antenna delay for systems with 3 or more devices your calibration process gets more complicated that for point to point systems. You can’t simply assume the error is 50/50 between the two units. You need to measure ranges between at least 3 different devices, that will give you 3 measurement errors which will allow you to solve for the 3 different antenna delays.
As detailed in other threads you have posted in I extend this approach by measuring all possible combinations of ranges between 6 or more devices and then using a least squares optimisation to find the antenna delays that best fit the measured range errors. I posted some python code to do this.
And I wouldn’t trust that video much. He was getting a scale factor error in his range measurements and fixed it by applying a scale factor to the measured ranges.
Adding a fiddle factor to the ranges isn’t the correct way to fix that. The correct way is to fix that is to work out why you are getting that error (it’s going to be due to some factor that you’re not taking into account or not correcting) and then fixing the bug in your code so that the range is correct. If you hack in a fix by adding a constant scale and offset then it’s going to bite you later.
Plus as he does correctly point out, 4 Hz is far too slow an update and he indicates he has changed the timing on the unity output by 1 second to get things to match.
Showing off a little here but it works far better if measure ranges at 200 Hz per tag and get the tag to output position at 100 Hz with a delay of around 60 ms. Then you can record something like this without any postprocessing.
