I could probably add some post-processing error checks to invalidate obviously wrong solutions, or maybe even plot a different color or color range for solution confidence, perhaps based on the r^2 result from your line fit? I could blend red and green for instance...

If it were me, I probably wouldn't want to muddle up a nice clean math engine with any sort of AI error detection.

Is it true then to say that this method works with any of the following:

a) two legs

b) one leg and a speed input

c) one leg and a distance input


...and are we making an assumption that the position/bearing plots have to be at equal time intervals? Or did you say that obs time could be variable but would need to be input for each position/bearing plot?

In my implementation any times. It can even be more LOBs from same time. Hm .. I should better try this :rotfl:

Edit: tried .. and it works like charm. At each time there are 2 LOBs now. Now this can be used to limit target distance. You simply add 1 fake LOB to cross the actual LOB at the point of correct distance. Speed does not seem to be so easy anyway.

http://roger.questions.cz/other/AutoTMA2.png

...and I guess we're assuming Ownship maintains a constant speed while collecting the LOBs.

Does the code accept "n" LOB inputs or is it presently hardcoded to accept a specific size matrix?

Ownship maintain same speed in this demo only. It does not have to. It does not have to go straight. It can do anything. Well in fact moving straight at constant speed is the only situation when this does not work :|\\

It can go in circles. It can use other platform's LOB to limit the solution, there are many many uses. Only the solution is limited to constant speed and bearing. Or let's better say, it finds constant speed and heading which matches the LOBs best.

There can be ANY number of LOBs. Well more than two. Matrix is always 4x4. You only have to sum more data while creating the matrix, so the time of the computation depends in linear way on count of the LOBs, which is great. Most least square method applications results in this time requirements.

What are you using as your programming platform? That window icon suggest maybe an older edition of VB or C...

I use the latest Visual Studio suite and favor VB 2005 (aka VB.net) Express edition
(WooHOO! FREE Download! :up:)

Ah, got it. Yeah, that does make it easy.:yep:
So it's position/bearing input only.


Now the only question is... Should I continue bothering with this 1.1 beta or just focus my attention on jumping ahead to 2.0? :hmm:

Well that's yours to decide. I'll guess I'll improve the formulas a bit and I offer any support to put them into your software.

I use old VB beacuse I use at my job, I know it well and it works well in these simple cases. It also has magically small executables and it's runtime is included in all windows installation for few years now.

Anyway in most languages the code should work with more or less copying it as it is, it's really that simple.

This is pretty cool. Now, if you can only convince SCS to use it to replace their Truth-based method of aTMA...

Well convince them to make any new game in the first place :rotfl:

If it's VB-based that'll work fine. :up:

Lemme know when you think you have something...

I've sent you the source codes on your work email, so check if it didn't end up in the spam. :arrgh!:

Hasn't made it yet... but I'll keep an eye out for it.
Sometimes our system is a tad slow with outside email.

Hey, what would you like to call your tool?

"DRT TMA""
"Pos/Brg TMA"
"Least Square TMA"
"Dr.Sid's Magic Medicine"

...or do you have some other preference?

This isn't by chance an implementation of "Ekelund Ranging" is it?

I preffer Least square TMA. While Dr.Sid's magic medicine is not bad at all it does not have that hi-tek sound. :rotfl:

How much was left for 1.1? 2.0 sounds pretty juicy so if you'd rather jump on that then go for it.

Yeah... but if I have two units taking bearings at the same times I don't need the tool. The crossing LOBs indicate the location, etc. I guess it's good that the logic properly falls on the LOB intersections, but I could've used my Mk1 eyeball to figure that out.

I wanted to see a solution with non-uniform LOB points of origin (ie. variable LOB time intervals). I guess I can test it myself when it arrives...

BTW, I'm not seeing it at work. The system may have blocked it.
Can you send a copy to my home email?

Here you are. Ownship moves along a circle, times are random (not even in correct order, but that can't be seen). Note that the green circles at computed at times of the LOBs, to check that they fits them. Both ownship and target move at constant speed on this picture.

http://roger.questions.cz/other/AutoTMA3.png

Now I tried to add some position error to LOBs. Now it can be seen that near-parallel LOBs gives poor solution. I've also checked that stronger leg (bigger heading change) gives better solution, and with more then 90 degrees turn it gives good solutions even with large artificial errors.

Looks good!

I think in MoBo this:
http://www.xl-logic.com/mobo/tutoria...20081108_2.png

Might be implemented like this:
http://www.xl-logic.com/mobo/tutoria...A_20081108.png

Where we would plot a series of LOBs and then run your gadget to plot the course line and put a contact with motion vector on the last LOB.

There should be also some kind of dot stack, and possibility to adjust the solution manually and see what dots does. There should also be NUMERIC average error. My method then would only give you a estimate which you could work on manually.
But it looks great ! Have you got my mail ?