Open bistromath opened 13 years ago
What is the status of the mlat code? Was it completed and just needed some testing or did it never quite get completed?
It needs some work. The multilateration resolver itself (mlat.py) has a bug due to making an incorrect assumption, and needs a rewrite. I got halfway through that rewrite and walked away from it. I should probably devote some time to it, maybe while I'm traveling out to GRCon this year.
The client/server part of it is rudimentary, but it did get some testing and appears to work OK.
--n
On Thu, Aug 25, 2016 at 9:20 AM az-developer notifications@github.com wrote:
What is the status of the mlat code? Was it completed and just needed some testing or did it never quite get completed?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bistromath/gr-air-modes/issues/4#issuecomment-242449217, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYZq0huBLK0l00p4byGLI013B8Jr97Mks5qjcDPgaJpZM4JtQDP .
I'd be willing to help out that if you wanted to somehow post where you are on your rewrite. I'm also going to be at GRCon this year.
Let's meet up and talk about it there. I'm very interested in getting mlat finally working.
On Thu, Aug 25, 2016 at 2:50 PM az-developer notifications@github.com wrote:
I'd be willing to help out that if you wanted to somehow post where you are on your rewrite. I'm also going to be at GRCon this year.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/bistromath/gr-air-modes/issues/4#issuecomment-242553197, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYZqwg2uUwE7Jw-PQeiQodBqCf-A8tdks5qjg4KgaJpZM4JtQDP .
@bistromath Just noticed the same issue with the mlat resolver code.
The issue seems to be with the both the base code (calculating pseudorange-obs, the pseudorange-est will not correctly converge to pseudorange-obs unless the airplane is right over one of the stations) and the test timestamps (which are modeled similarly to the pseudorange-obs method)
Is that right? And wondering what change you were making to resolve this issue. Just trying to understand different approaches to mlat math, and would appreciate your insight here.
The test relies on an incorrect assumption and makes use of the absolute time in a non-obvious and incorrect way. I started several times on fixing it from scratch but don't have working code yet.
collect sample data, normal text from modes_print will do, run through mlat solver.
when validated, write simple client-server app to pull timestamped data out from E100s and run the solver at a central location.