yea i already linked to that on the first page.



also, as per my last post... im not sure it would work. You would have to draw the predicted bearing in your future location (of your original course) on the map to triangulate it after you turn.

That was about 90% right! Except that we do change course and speed for triangulation, but but for relative/true conversion we still calculate with the course and speed we initially had when taking the readings (in this case 30°, 5 kts), as these are the ones that will matter. We're basically using old data for OS and fresh data for target. Just ignore course and speed of the final leg, as this just serves for obtaining the cross bearing! I will try to set up an example tonight. It should work already by utilizing Mobo for the final step. You can try this yourself if you like.

What im saying is that in order to "triangulate" the predicted bearing on the in-game map... you are going to have to draw it from where you will be in the "future" if you were to stay on course. .ie if you are doing 6kts and using 10minute intervals.. you'll hve to draw the predicted bearing from a point 300.8 meters in front of you before you turn.

then turn, triangulate it, and send the range back to the tool so it knows what the relative speed was for the first three sightings. then it can finally transform the targets relative course to a true course using your original course & speed before turning,.


how to make this process easier?

The idea behind this tool was to make it simple and quick. which is why its using a static display.

No wait, I think I know what the problem is: you think you do this while tracking the target! That's not necessary! Here is an example how it will work now, using Mobo for the final step (or use a pocket calculator):

1. track the target, triangulate, do what you usually do until you are completely finished! All data is now collected!

2. Don't touch it any more!

3. Fire up Mobo

4. Set up OS with (to stick to the example) 30° 5 kts (important!)

5. set up contact using the final data once you are completely finished: bearing, distance, relative course and speed!

6. Finally, use the subtract vector tool to convert target course and speed from relative to true! There!

You're right, it should be kept simple, but there is only one final step involved to convert from relative to true! ATM it's a bit more complicated because two different programs are utilized. But with your TMA tool it could be much easier. We would merely enter our initial OS data when we begin. That will be the only additional required step by the user. The program does the rest once all data has been collected! No need to fiddle with Mobo and vectors, then.

you dont need mobo to do the vector calculation.. you can just draw it.

And you dont need the bearing/distance.

All you need is the two vectors and their magnitude (direction and speed).

Of course! I figured this might be a simple way for proof of concept! And the concept is to add one more step for vector magic to make the tool even more versatile! And you want it simple and user friendly, right?! :03:

I still fail to see how you are triangulating the predicted bearing without taking the extra step of plotting it in-game where you "will be" given your speed and time intervals.

If you want to do it moving you need 2 sets of 3 bearings as you need to make a significant course and/or speed change in between to alter the relative motion. And both 'target courses' need to be translated to the head of your own speedvectors. Where they cross is the endpoint of the actual target course and speed vector.

Read here:

http://www.filefront.com/13598315/bearingsonly_TMA.pdf

Also, for better accuracy in course, just take longer periods between the bearings. Waiting for 4 degrees bearing change is really too short. I guess you could average it out like that (first three bearings and last three bearings out of a set of 4), but it still has a large margin of error which doesn't go away doing that. You think the bearing is exact when it is reported, but it could be a full degree of. So the difference between 2 bearings has a total margin of error of 2 degrees.But since this method depends on 2 bearing differences the margin of error doubles again. Compare the following bearing sets:

B1=11, B2=15, B3=22, which makes target course 177
(from the original post example)

B1=11.00, B2=15.99, B3=22.00, which makes target course 150
B1=11.99, B2=15.00, B3=22.99, which makes target course 186

186-150=36 degrees margin of error.

I'm not too happy about that!

Yes, that can utlimately happen if you rely on crew reports that are not taken when the bearing crosses the exact degree.

Now lets say you wait longer, like until bearing has moved 7 degrees:

B1=11, B2=18, B3=37, which makes target course 177.1 (our reference)

Then taking worst case margins of error:

B1=11, B2=18.99, B3=37.00, which makes target course 173
B1=11.99, B2=18, B3=37.99, which makes target course 182

182-173=9

Much better, and if you do the math (which I'll spare you) those 7 degrees only took 50% longer, so 22 an a halve minutes per interval.

Very handy tool Gutted. Look forward to trying it out. :up:

The whole process remains the same! Mind you, I just add an additional step at the very end of the process: the conversion from relative to true! Whatever happens before that doesn't matter in this case!

Oh, and it doesn't matter if the sub moves at 1 knot or 10 during tracking! The data will always be relative! When you treat 1 knot as 0 knots, there will always be a error in the end result! So by doing the vector calculation for any speed above 0 kts should also increase the presicion! Another benefit. :D

Anyway, we can discuss this all day long and won't get anywhere if we don't try in in game.

@pisces

dude, that pdf example was priceless.


Next version of the tool will work beautifully. :D

The thing is.. unless i can picture what you're saying, it's futile. :DL

So do you think im wasing my time adding support for more than 3 bearings and averaging them?

in other words... we should just use bigger intervals between sightings intead?

He he! It's about dinner time, so one more try before I'm gone! Let's assume that your boat is creeping along with 2 kts while you track that lone merchant far away. You collect bearings, then make the final triangulation, do the drawing stuff on the in-game map, etc. Then you're done! Or are you? You sit there, about to plan your intercept course. But you hestitate, raising your eyebrows and wonder how precise your calculation might be! While you sit there, still scratching your head, you realize that the result may be skewed due to OS movement. It was very slow, but still.

Then you wonder how you can correct for this error! Ahhh, there is the answer: you need to do this weird vector calculation stuff to un-skew your result! And so you do and when done you are happy, because you now have a much more precise result than before!

And then it dawns on you: it doesn't matter whether you were moving with 2 kts or 15 kts! The calculation for error correction remains the same! So you figure out that you don't need to sit still, you can just go at any speed, and then just correct for the error afterwards!

Now you are happy because you are getting better results than before and add this function to your program!

LOL! Just kidding, but I couldn't resist! :har:

Hope this helps!

I fully read it, and i understand it all the way to the last step, and then i can't follow.

R2-M is the relative speed on the second set of observations (28.4kts). Z-Y is 2 hours total.. so the distance of Z-Y is 56.8 miles.

So.. uhh.. what determines how far along Z-Y that A is being placed to find B?