3

I'm having some issues figuring out multilateration. I'll start by saying I'm not a math whiz, but I am usually able to figure most things out, but this one has confused me. I got to this point after reading up on Time Difference of Arrival.

I have four wifi adapters. Each one takes a point in a three sided pyramid, so this should be able to take height into account, I believe. The relative positions to each other are fixed as well.

What I'm attempting to do is listen for wifi signals and find their origin. In theory, I believe I should be able to use the difference in time between each wifi adapter "hearing" a packet to find the origin of the packet.

I've paired a GPS into this. It allows me to give each wifi adapter an actual position (with a little math).

So here's what I have when I receive a packet:

  • wlan1 (X, Y, Z, timestamp)
  • wlan2 (X, Y, Z, timestamp)
  • wlan3 (X, Y, Z, timestamp)
  • wlan4 (X, Y, Z, timestamp)

X and Y are lat/lng. Z is the altitude in meters, and the timestamp is reflecting microseconds.

Some assumptions to make are that the XYZ are accurate. For all practical purposes, if they're off, then they're all consistently off, which should be reflected in finding the source.

I haven't been able to figure out how to apply any math to this, and am seeking an example. I can provide some actual data if necessary. The end goal is working on a robotics project that'll let a robot follow you, or more accurately your cell phone. The reason I'm taking this approach is that it lets me log things in a way that in the end should be extremely easy to debug visually on a Google Map.

I believe that by taking a difference in time from each point and comparing it across the adapters, I should be able to have a somewhat accurate shot at the origin location, but this math is just too far beyond me right now.

I have cross-posted this question to the Mathematics site.

halfer
  • 19,824
  • 17
  • 99
  • 186
John Sly
  • 763
  • 1
  • 10
  • 31
  • An interesting question. This should probably asked on the Math Stack Exchange, since it is pretty much pure geometry. They actually know that sort of math there ;) – bcdan Jul 10 '15 at 18:40
  • Also, in order to get time difference, the clock on the WiFi and the packet would need to be synchronized _exactly_ -- which is technically speaking very difficult. Even using an atomic clock synchronization would be inaccurate in distances larger than a few meters, since the signal takes extra time to reach one relative to the other proportionately to the distance separating them along the axis of the signal's travel. – bcdan Jul 10 '15 at 18:44
  • Thanks, just posted it there too. Honestly, I'm just hoping someone can help me on this one. been wracking my brains on it for a few weeks, but haven't been able to get anywhere. – John Sly Jul 10 '15 at 18:44
  • the time clocks I don't think for this should need to be synchronized since I'm not taking a timestamp from the packet (is that possible?). I have one device controlling all 4 wifi adapters, and that's taking the timestamp upon receiving them. That should keep the times consistent to measure the difference. Nothing should fall out of sync, I mean nothing SHOULD, i haven't done enough tests to see if anything can throw this off yet. – John Sly Jul 10 '15 at 18:47

2 Answers2

0

There are various algorithms for this, I found a simple paper here that looks helpful, but there are also more advanced least-squares algorithms in various journals.

Just as a warning, multilateration is very sensitive to position errors of the sensors and errors in the time difference of arrival. So your results might not be particularly good -- you've said your clocks are not synchronized (they need to be) and that you are using GPS for location (which have a ±3 m error). For what it's worth, you can use GPS for time too, but I'm not sure of the error on that.

rlbond
  • 65,341
  • 56
  • 178
  • 228
  • I'll have to check on the gps accuracy. Since I'm a programmer, I was already looking at excluding results that didn't have gps with high enough accuracy at the moment of the received signal. The times should be synchronized though. I am taking the reading from a single device with 4 positioned adapters. All times will be based on the single device. – John Sly Jul 10 '15 at 19:13
  • Honestly, you would probably get better results using array algorithms like [Beamforming](https://en.wikipedia.org/wiki/Beamforming), [MUSIC](https://en.wikipedia.org/wiki/Multiple_signal_classification), or, if you can arrange the four antennas into quadrants, [Monopulse](https://en.wikipedia.org/wiki/Monopulse_radar) -- although you wouldn't get distance with these algorithms, just angle. But they are far more robust than TDOA algorithms. – rlbond Jul 10 '15 at 19:20
  • just reading a bit, MUSIC looks like it might be the right choice. I just don't understand nearly enough to know yet. I see that it says it can find the emitter location, but no real details on that specifically. do you know more about that specific approach? I'd like to hear more from someone knowledgeable on it. – John Sly Jul 13 '15 at 15:31
0

A couple of (unfortunately negative) points:

If your timestamps are computed when the signal hits the antennae then all you'll be able to work out is the direction to the source and not the distance. After all, a signal the comes from a million miles away will have the same propagation delay between 2 antenna as one that comes from a meter away.

Unless your robot is very large I would be surprised if the deltas between the timestamps were not completely dominated by factors other than signal propagation delay. EM radiation goes quite quickly, so there is very little room for error. For example:

  • the wifi adapters will have some kind of onboard processing firmware - how quickly does it report new signals? Is the delay constant or does it depend on arcane details of the 802.11 spec? Will you be notified of the arrival of a signal, or the arrival of a complete packet which may have been the result of a whole series of acks and retransmissions?
  • Your device is linked to the adapters via some kind of IO bus - Even if we assume that the adapters are perfect there's going to be contention on this bus when a new pulse is received - which adapter wins and gets processed first?
  • Your device may have a single-core CPU - how quickly can a signal from an adapter be processed and given a timestamp? The delay between events will determine the fidelity of your timestamps, and thus the maximum accuracy of the system.
  • Is the device completely to-the-metal dedicated to putting timestamps on signals, or is there other software running too? What if some other event pre-empts your signal processing?
  • If you're in an indoor environment you will get indirect propagation - assuming that the system itself is perfect, how do you detect the case where the signal detected on one adapter took a longer path by bouncing off a wall or two?
ryanm
  • 2,979
  • 18
  • 22
  • On the direction. That part I'm aware of. As for the direction, I think with multiple antennas, it's a matter of figuring out how to find the overlapping lines of direction to pin point the source. I think you hit the point that I'm worried about more though. The testing hardware just may not be up to the task to record things accurately enough. right now this is a "what if" project, so if it fails, it's not the end of the world. but I like the idea. – John Sly Jul 15 '15 at 15:47
  • for the dedicated hardware, it would ONLY be recording the signals/timestamps. I'd have other hardware processing the data. I get that missing one clock cycle would throw things off, and just a little error in timing would result in big errors in the end. A simple answer though to the indoor signal bounce. I'm tracking packets. So if a receiver receives two identical packets, then I'd only use the first once, operating under the assumption that the most direct path is the shortest and therefore the first one I'd receive. I'd need to work out some acceptable levels of accuracy too obviously. – John Sly Jul 15 '15 at 15:53