5

I am currently writing some code to do multilateration using TDOA and currently struggling and wondering if anyone has any reference code that can be used as a test case with some sample data that I have! At the moment I am unsure if it is the code I have written or whether it is the geometry of the points that is off.

One example group of packets that I have received is

station1 = [50.919149572907784,-1.005043823556842,90.729];
station2 = [50.8304,-1.21956,0];
station3 = [51.0569,-1.26224,100];

stations = [station2,station1,station3];
timestamps = [28704.175275109, 28704.175334203, 28704.175334875];

My code currently locates this to 50.910447339754654,-1.2347406519401736 which I am 99% sure is wrong! Does anyone have any code that can verify this at all?

One bit of code I am testing against and get very similar results is https://github.com/bistromath/gr-air-modes/blob/master/python/mlat.py

Martin F
  • 8,948
  • 36
  • 58
Lee Armstrong
  • 53
  • 1
  • 6
  • 1
    I added the [tag:trilateration] tag. You may find relevant questions with it. – Martin F May 20 '14 at 17:24
  • Thanks, I've looked at Trilateration techniques but typically I will have more than 3 stations. Just my test setup has 3 – Lee Armstrong May 20 '14 at 18:31
  • I realise how old this post is now but is there any chance you ended getting a code that can perform multilateration? I find myself in pretty much the same situation. I have a system with 4 detectors at known locations at they accurately time stamp an incoming signal but I'm struggling to use these time delays to work out the source's position. – Alex Gibbons Mar 14 '18 at 17:54
  • If you have a new question, please ask it by clicking the Ask Question button. Include a link to this question if it helps provide context. - From Review – aldo_tapia Mar 14 '18 at 18:20
  • Yes @AlexGibbons I did actually but it became such a big beast and not simple I cannot post any code without it being huge. I suggest starting a question with specific questions and I’ll see if I can help out – Lee Armstrong Mar 14 '18 at 18:47
  • thanks for the response. Unfortunately I'm new to this site so I am not allowed to simply comment under your reply so must reply as an answer here. So my situation: I've got an array of 4 microphones, 3 in a plane and one above out of plane. These microphones are connected to a micro controller which accurately time-stamps a sound when it arrives, in microseconds. Since the time the signal was made is unknown, these 4 time-stamps just give 3 time-difference-of-arrival measurements, i.e. how long after the first detection did the other 3 microphones detect the same signal. From these 3 TDoAs I' – Alex Gibbons Mar 16 '18 at 10:08
  • If you have a new question, please ask it by clicking the Ask Question button. Include a link to this question if it helps provide context. - From Review – aldo_tapia Mar 16 '18 at 11:03

2 Answers2

2

Take a good look at these:

Because it's the more common term (in geomatics), they all refer to "trilateration", and yet they all describe the over-determined cases of "multilateration", like yours, and the so-called "normal equations" required for best-fit (or least-squares) solutions.

Martin F
  • 8,948
  • 36
  • 58
  • I get that but I will have more than 3 points and surely it will get me a more accurate result in future? I am looking for a system that can test my results to check if my code is good. – Lee Armstrong May 28 '14 at 07:56
  • @LeeArmstrong: Yes, generally stated, the more observations you have, the more reliable the combined result will be. And that's what those least-squares adjustment techniques do: provide the best-fit solution from any number of observations. – Martin F May 28 '14 at 16:46
  • I realize i'm just providing concepts/equations, and you want working code, but at least you have alternatives to study and help build confidence in whether your own code is theoretically correct. – Martin F May 28 '14 at 16:47
2

At a first glance, the results make sense to me.

If you want to check, you could use this link to convert the coordinates of your three stations and the coordinate of your point into ECEF XYZ coordinates.

Then it is quite straightforward to verify that the solution is correct:

compute the distance from each station to your point (you did not provide the H) and divide it by the speed of light to get the time. If you have the same difference between the timestamp and the time to each station for each station, then it was correct.

EDIT: After checking, there seems to be a problem. Maybe you could check wgs84 to ECEF in the code that you mention. I think that line 82 should be

z = (n(lat)*(1-wgs84_e2)**2+alt)*math.sin(lat)

it could be useful to test your code based on verified ECEF coordinates to identify the source of error.

As a remark, a possible source of (small) error is the use of the height above sea level instead of the height above ellipsoid, but this does not expla the observed error.

radouxju
  • 49,636
  • 2
  • 71
  • 144
  • Thank you. This is the sort of thing I was after. I will have a go and see what comes out. How did you determine they weren't far away? Using the method in your answer? – Lee Armstrong May 30 '14 at 04:14
  • I just looked at the four coordinates and the position of the result made sense to me (no computation). But this could still mean an error of a few km (which is huge for trilateration). Maybe this was over-optimistic, so I've edited my post. – radouxju May 30 '14 at 07:01
  • Ok thank you, the result I'm pretty sure is quite a few km out which is why I wanted to see if it was the geometry of the receiving stations or my maths! – Lee Armstrong May 30 '14 at 07:51