The AOB Wheel Users manual

[vanjast]

Just like to check if those interested people can understand this manual (http://www.vanjast.com/SH4Mod/AOBWheel.pdf).

Sometimes the comms link is lost between the writer and it's intended audience.
If you have any problems, let me know :D

[Munchausen]

FYI, there is currently a security issue with PDF files.

[Pisces]

Personally, I'm sure the document (BTW, I didn't get any warning or security issue when I opend it with Foxit reader, version 3.0 build 1301, my AVG kept quiet also... for what it's worth... but like to know more about what Munchhausen means with it ) would make alot more sense if I had something to play with. Just reading it doesn't get the grey matter machinery going as much as spinning your wheel would. Please provide the base and top wheel templates. [EDIT: I mean not embedded in the text]

[Munchausen]

Pisces: ...to know more about what Munchhausen means with it
http://www.symantec.com/norton/theme.jsp?themeid=trojan-pidief-vulnerability

Probably the best bet would be to download the file, scan it, then open it ... after following the instructions in the above link. Leastwise, until the PDF loophole is fixed.

[vanjast]

It's coming - busy 'packaging' it.

Thanks for the info, but I never paid attention to hysteria to sell my product, which is big in the Mcafee, and Semantic world.

If you read that piece it's actually javascript that is the weakness, and this has been know for ... since when java came out. The 'concerned' screamed at MSoft when they adopted java, about it's security issues, but you know Bill :hmmm:

If you 'RUN' - MSCONFIG... and see what's running, you can get rid of at least 90% of that junk. This as well as turning off javascript when my wife and kids browse the net on this PC. I haven't smelt a virus in years.:salute:

[vanjast]

A delay in release - I have to change the sub speed correction factors, and can make space for this on the TopPlate, by placing the AOB correction and ClosestRange on the same scale (as they are identical).
:arrgh!:

[vanjast]

Sub speed correction factors installed into wheel... works like a charm. :yeah:
With all the measurements, calculations, etc..., my ship speed results are within 0.5 knots of ship speed.

A screeny of an unfortunate 'lab mouse'
http://www.vanjast.com/SH4Mod/test.jpg

Now back to the manuals and 'packaging'
:salute:

[Pisces]

Pisces: ...to know more about what Munchhausen means with it
http://www.symantec.com/norton/theme.jsp?themeid=trojan-pidief-vulnerability

Probably the best bet would be to download the file, scan it, then open it ... after following the instructions in the above link. Leastwise, until the PDF loophole is fixed.Ok, then I feel reasonably save since I don't use adobe software itself. Foxit Reader (http://www.foxitsoftware.com/pdf/rd_intro.php) is alot quicker and leaner than bloaty Adobe. Yet still the same functionality.

But AVG doesn't seem to know about this vulnerability/trojan, atleast not by that trojan description. Which doesn't put me at ease. Not opening PDF-files at all, just because there is a risk, is a bit too precautious imho. I read far too many pdfs for that.

[joegrundman]

I note that on this thread you are referring to it as an aob wheel, but on the manual it is referred to as a ship speed calculator. Other than that, it's pretty clever.

It's similar in principle to the inbuilt SH3 notepad speed estimate equipment.

Correct me if i'm wrong, but i think it is not important in this method to know anything about the ship's length. You just need to know when the ship's bow has traversed 1 degree angular distance. This is the same for any ship's length.

I think all you should need is range, aob and time to traverse 1 degree.

[vanjast]

Correct me if i'm wrong, but i think it is not important in this method to know anything about the ship's length. You just need to know when the ship's bow has traversed 1 degree angular distance. This is the same for any ship's length.

I think all you should need is range, aob and time to traverse 1 degree.

The time to transverse one degree is directly proportional to range and ship speed - for any AOB.
2 unknowns is a problem, so if I can ellimate range, I can find speed.
This is why I scaled the ship lengths to 1Nm @ AOB=90. Results from here are AOB corrected (turn the wheel) and the ratio of corrected value, to visual scope value. This is a simple range pespective where things get bigger/smaller according to range.
and as the refernce point is 1Nm, it's easier to find an answer.

There's been confusion about the mast/funnel height method and playing RFB where the allies info on the ship heights was unreliable, I've settled on the AOB/ship length method as this is more consistent.

Another thing is that your accuracy via the ship length method will be better as the ship length:mast height ratio is > 5 in most cases. Couple this with good AOB measurement and your range results will be good, and from this, speed detemination will be good as well.

The wheel uses AOB (and Bearing for Sub Speed correction) as it's easier to place the trig equations required, into chart lines, elliminating the need for you do these calculations. This leaves only 2 divisions and 1 addition to do - hope that makes sense. :D

[Pisces]

About the manual text:

I had some trouble following "the Action".

In the AOB image:
http://members.home.nl/rico.v.jansen/AOB_range.gif

at the end of page 3 you have the red and green circles. I understand the calculations in the text, it makes sense. But that is what you want to do with the tool, right? Not do it on a piece of paper by hand. The position of the green mark makes no sense. I guess you've placed it near the wrong mark/curve. I understand that the 7-degree curve (red mark shown through the gap) ends up just under the 5 mark (4.9 degrees corrected fov ) on the linear scale because of the 45degree AOB correction. But then you want to divide by 2.75 degrees (observed FOV) by looking on that same linear scale at 2.75. But the green circle comes out at at curve mark of roughly 4 degrees. You don't mention that number in the true-range calculation, so it makes no sense to me. What does make sense to me is to locate the 2.75 degree CURVE (in the dark blue area, 1 quarter below the 3rd black curve) and see it line up 'neatly' to the 1.8 mark on the linear scale (below "fishboat (1.4)" and "fishboat(1.1)"). Hey, what was your calculated range? Was it 1.78nm? ;)

Closest range:

http://members.home.nl/rico.v.jansen/closest_range.gif

What's up with the 2nm line you mention on p4? Just to show where 1.8 is roughly at? Ok, 1.3 on the linear range scale is roughly opposite the 1.8 (invisible guestimated) curve. Perhaps you should add some intermediate curve with dashed lines or something. It's a bit tricky to read off. Actually all curves could use a few extra (less conspicuous) intermediate curves.

True Time / Ship speed :

http://members.home.nl/rico.v.jansen/true_time.gif

I'm afraid this makes the least sense. The calculation seems like alien-math. Time (7 seconds measured) divided by range (1.78nm) is another form of time (3.9 seconds). That 3.9 must be some abstract form of speed, it cannot be true seconds in a physical sense. That aside, I cannot find those 23.5 or 22 knots in the image anywhere near the 3.9 value or 7 seconds. The red circle is near the 4th curve, but then what? It's opposite 3.6-ish, which seems meaningless. I suspect there is something seriously wrong with your reasoning here.

[edit]If the curves are supposed to be increasing inwards I can roughly see the 1.8nm value (as an intermediate mark of the curve) is opposite to 22.5-ish knots (linear scale), but the image in the pdf is too much clipped in that area to be sure. Is that what is intended?

I don't mean to be negative or put your work down. But you asked for constructive critisism. And this is what I make of it. I like different ways to look at this manual targeting issue, so please press on with it.

[vanjast]

The red and green dots are just indicators to show the point of focus.
When adjusting the FOv you read off the linear scale (black numbers 1-9)

The range = 1.78 Nm, you now correct again on the Closest range scale, and read off the black scale again.

TrueTime = you take your measured time and divide it by the 1.78Nm to get 3.9 Secs, which you now use on the TrueTime Black scale and read off the approximate speed from the underlying curves....

hope that make it easier... must rush off, be back in a mo for more questions
:arrgh!:

[Pisces]

I've added edited pics in my post above to clarify what I meant.

[vanjast]

This might help
AOB correction for shipFOV
http://www.vanjast.com/SH3Mod/Rotate45.jpghttp://www.vanjast.com/SH4Mod/Rotate45.jpg

AOB correction for closest Range
http://www.vanjast.com/SH3Mod/Crange.jpghttp://www.vanjast.com/SH4Mod/Crange.jpg

True Time
http://www.vanjast.com/SH3Mod/speed.jpghttp://www.vanjast.com/SH4Mod/speed.jpg

With the addition of Sub speed correction, I've combined the 2 AOB corrections (ShipFOV and ClosestRange) into one scale (as they are numerically the same scale - just different terms), thus both base and top plates have changed.
:)

[Pisces]

I see. Much clearer now. There is no-way I could have foreseen those values at those speedcurves. Your sliderule needs some sort of legend there to identify the scale of the curves. [EDIT: WHoops. I didn't look at the top of page 2 good enough, ...how did those scales get in there so quick. :o ]

But here's my main inconvenience (I guess I didn't get across more eloquently before), why manually calculate range based on observed-fov (the 4.9/2.75=1.78; but maybe not neccessary anymore in your next version), or manually calculate the 'true time' (7s/1.78=3.9), if you allready have a (logarithm-based) tool in front of you that should do the job? Those divisions are piece of cake for log-sliderulers. It just needs clever use of scales.

[Pisces]

Hmm, do you really need to make that (ownship)speed/bearing correction? I guess you do for uboots, but the american subs have a positionkeeper. It should allready correct for that once you've entered the range, estimated AOB and speed. (But I must admit I have hardly experience in using that thing, I only understand it's workings from the tutorials and discussions on this forum.)

answered myself: yes it is, since during the measurement you may move somewhat unless absolutely motionless, AND because in the manual you suggest to turn roughly 90 degrees to the target's path. The PK cannot update something if it doesn't have the data yet. So I advise not to turn 90 degrees to track beforehand. Just aim periscope forward and turn your bow right infront of the target. Then do the time measurement and AOB estimation. That saves another calculation and doesn't upset the use of your wheel.

Once you've got your calculations done with the wheel they should be fed into the TDC/PK and any course/speed change you make is taken into account now. Again, as far as this PK stuff is within my limits of understanding. ... Hmm, isn't Rockin Robbins supposed to enter the stage here somehow ;)

[joegrundman]

Correct me if i'm wrong, but i think it is not important in this method to know anything about the ship's length. You just need to know when the ship's bow has traversed 1 degree angular distance. This is the same for any ship's length.

I think all you should need is range, aob and time to traverse 1 degree.

The time to transverse one degree is directly proportional to range and ship speed - for any AOB.
2 unknowns is a problem, so if I can ellimate range, I can find speed.
This is why I scaled the ship lengths to 1Nm @ AOB=90. Results from here are AOB corrected (turn the wheel) and the ratio of corrected value, to visual scope value. This is a simple range pespective where things get bigger/smaller according to range.
and as the refernce point is 1Nm, it's easier to find an answer.

There's been confusion about the mast/funnel height method and playing RFB where the allies info on the ship heights was unreliable, I've settled on the AOB/ship length method as this is more consistent.

Another thing is that your accuracy via the ship length method will be better as the ship length:mast height ratio is > 5 in most cases. Couple this with good AOB measurement and your range results will be good, and from this, speed detemination will be good as well.

The wheel uses AOB (and Bearing for Sub Speed correction) as it's easier to place the trig equations required, into chart lines, elliminating the need for you do these calculations. This leaves only 2 divisions and 1 addition to do - hope that makes sense. :D

OK, you are using ship's length to work around the RFB introduced range inaccuracy.

If you don't like the inaccurate mastheight data, why not just mod it back? Personally i quite like the inaccurate mastheight data. I count the decks and multiply by 8 to get height to top of bridge in feet when i don't trust the info.

The equation that governs this method is:

(sin (bearing change)/sin(aob) x range)/time

and after playing around with it, i realised that it is actually simply a special case of the main method for use of the speed omnimeter with the Submarine Attack Course Finder. The special case being that the collision course is not taken into account.

http://www.hnsa.org/doc/attackfinder/index.htm

and this thread for templates

http://www.subsim.com/radioroom/showthread.php?t=106923&highlight=iswas

still, nonetheless your tool is nicely optimised for this specific procedure, but since i can do the same thing with my trusty Submarine Attack Course Finder, i guess i'll use that!

[vanjast]

joegrundman:
No problem, everybody has their preferences :up:.
I did read up on that wheel, but had my own idea what I'd like to use. :D

Pisces:
I realised after your question that I hadn't put a legend into the wheel, I'll do that with the release version - thanks :up:

With the addition of the sub speed correction, you can be going in any direction, at any speed and determine ship speed. I've done 2 tests on known target speeds, and results are within 0.5 knots of actual ship speed. I must just do a bit more testing on this - just to make sure.

Hmm, isn't Rockin Robbins supposed to enter the stage here somehow :haha: Crash dive...Crash dive.