Dude, why the hell did you move the thread here?

It's not a mod.

Now you're going to have all sorts of people jumping in here thinking i made something to drop into their game.

One last tidbit.. you can do with the scope as well.

Just use a smaller interval due to the closer ranges.

It's useful for stalking prey at very long distance. Which leads me to the next question: will you support TMA while moving as well?

Started redisnging it.. got the drag handles drawing (though they dont drag yet hehe). Also made the middle area of the bearing wheel fainter. Bearing lines will be thinner as well (not shown).
http://img101.imageshack.us/img101/2674/wip1u.png

Without a range for each bearing .. how would you convert the target's direction of relative of movement (DRM) to an actual course if you dont know it's relative speed?

I just dont see it happening from a static manuevering board type display.

Hmmm, I think what I had in mind was something along those lines (excuse the pun! :03:):

http://www.subsim.com/radioroom/show...50&postcount=2

Especially the last part about relative motion and speed and course vector to obtain true motion. Just with automatic calculation of the latter. I don't know if this is feasible, hence my question.

In that example he had to guess at what the range was to get an estimate of the targets speed on the reatlive track.

Without a "sonar ping" in a Uboat, how do you intend to get this range?

And like i said, without an estimate of the target's speed on the "relative track" you can't convert it to a true course and speed.

That's indeed a tricky one, as there is no course change in the example. But we have a cross bearing, thus getting more or less precise results. Just relative in this case. Then do the vector calculation using initial (!) OS speed and course and the end result target data.

Not sure if we are on the same page, though.

Ok let me get this straight to make sure we are thinking the same.


Lets say you are heading 30 degrees at 5kts.

You plot the three bearings on that static board and get a relative course.

But since you dont yet know the range, you have no way of knowing the relative speed of the target, and thus cannot do the vector cacluation to transform the relative course to a true course and speed.

So... you turn and triangulate the 4th bearing to get the range. Then input that on that board.

It can now caclulate the targets relative speed from that range... and using your heading and speed (which you didn't change when you turned away), it can compute the true course and speed.



did i get that right?

.ie You turn and or change speed to triangulate the predicted bearing... but you leave your original course and speed unchanged on the board?

One other thing I'd add is a GIANT PULSING LETTERS with trumpet fanfare saying "Draw bearing #4 on the map before you move!" :O:

I've so far forgotten to 4 out of 5 times.

Also, this thread has a nice PDF that explains a lot of the methods used here, including moving various speeds to get a course:

http://www.subsim.com/radioroom/showthread.php?t=160817

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.