Non-standard position calculation system - what am I missing here

I have a single sided two way range based position system:
Tag sends a poll.
Anchors 1-8 each send a response fixed amounts of time after they receive the poll. Their response includes the last 9 bits of the ideal Tx time.
The Tag receives these replies, corrects the response times for rounding errors and clock rate differences and calculates the ranges.
The ranges are good to within a few cm. Given known anchor locations we can determine tag location and since the result is overdetermined get a good feel for how reliable the position is. All very text book generic system so far.

Here’s the bit that I’m having issues with:

If I put a purely passive UWB device in the middle of the room I can measure the times it sees all the packets.
The time the Listener receives the Poll is the Tag transmit time plus a function of the Tag to Listener distance.
For each anchor the time the Listener receives the Reply is the Anchor transmit time plus a function of the Anchor to Listener distance.
But the system design is that the Anchor transmit time is a the Tag transmit time plus a function of the Tag to Anchor distance plus a known delay.

Rearranging this we get that the time between the Listener receiving the Poll and receiving the Reply minus the known delay for that Anchor is a function of the Tag to Anchor distance plus the Listener to Anchor distance minus the Tag to Listener distance.

Given Anchor locations are known all of these distances between devices are functions of only 6 unknowns, the Tag x,y,z and the Listener x,y,z.

It I have 8 anchors that gives me 8 measurements. 8 data points and 6 unknowns means I should be able to solve for them and purely by listening be able to measure both the tag location and the location of my silent listener.

The problem is that it’s not quite working.
I take the time difference between packets, subtract the delay (corrected for the rounding in the tx time and the clock difference) and convert the resulting time to a distance. Since I know where the tag and listener are I can work out what this value should be. The results I get are about right but are off by a meter or so. So the basic idea works but the values are wrong by enough to ruin the position calculations.

The antenna delays programmed into the system and anchor rx to tx delays must be correct because the tag is getting accurate ranges.
Received signal strength effects are smaller than this, I’ve tried factoring an approximation for them in but that didn’t help.
There has to be some factor or correction that I’m not taking into account on the listening side but I can’t figure out what it could be.

So the question is what am I missing?

Hi Andy,

I did not go into the details, but it sounds to me, that the times are not aligned to a single time base.

All the times including the delays of the Reply messages need to be aligned to a single time base. To do that you need to consider the transmit time, receive time, the clock drifts of each pairs.

I hope it helps.

Cheers,
TDK

All the times are measured on a single unit other than the delay times so there is nothing to be corrected for there. The delays are corrected for the clock difference between the receiving device and the device setting the delay, the correction used is the same as is used for normal single sided ranging and works for that use case.
The exact tag transmit time cancels out in the maths but its differing time of flight to each device is taken into account.
Everything is currently running on sets of measurements all taken within a 5ms period with no smoothing so it’s reasonable to assume no meaningful clock drift over that period, the rates will be at a constant offset. I expect lots of noise in the output at this stage, the issue is that there is a large bias in the results.

The scale of the errors is about right for a timebase issue. But if there is one I’m not sure where it is. Also timebase issues I would expect to see larger errors for the anchors that reply later since the rate difference will have a larger impact on those results. I see fairly constant error across the anchors.

It could also be an antenna delay calibration error but I thought I had those dialled in better than that. I could maybe fix the locations to the correct values and optimise for antenna delays and see how far off they would need to be to make the position come out correct.