SUBSIM Radio Room Forums

SUBSIM Radio Room Forums (https://www.subsim.com/radioroom/index.php)
-   Wolfpack (https://www.subsim.com/radioroom/forumdisplay.php?f=277)
-   -   Slide Rule Targeting Series (https://www.subsim.com/radioroom/showthread.php?t=241541)

derstosstrupp 06-19-19 06:57 AM

Slide Rule Targeting Series
 
Always wanted to make a detailed series of videos on the use of the attack disk and speed side, so here we go!:Kaleun_Cheers:

derstosstrupp 06-19-19 07:01 AM

Part I: Intro to Attack Disk and Speed Disk

https://youtu.be/xbhfMwnqLgI

Part II: Calculations at Distance

https://youtu.be/II_9sVn162E

Part III: Target Speed Calculations

https://youtu.be/_1yMeX6zJIE

Part IV.I: Correction to Aspect Ratio Calc

https://youtu.be/dCUKpsZMIsU

Part IV.II: Calculations to Position for Shot

https://youtu.be/KFiXDSGnX18

Pisces 06-19-19 09:44 AM

Sorry Matt, but you are not getting of the hook that easily with the aspect ratio AOB video. ;) You got your observed sizes wrong. If you find that the resulting angle is supposed to be right of 90 degrees on the angle disk then you need to re-asses them. The nominator (observed aspectratio) must be smaller than the denominator (real aspect ratio). Fudging by flipping the numbers may have worked here to get close but does not solve the problem.

Real aspect ratio: 150(.0)m over 28m (using 280 seconds or 4m40s on the time disk) points to 5.357-ish on the distance scale.

Observed aspect ratio: you took 14.6 length vs 2.7 height. You shifted the disks a bit too far resulting in 5.44. Proper placement of the marks would be 1460 distance against 4m30s time, pointing to just over 5400 on the index. 5.407 according to a calculator. Your nominator being larger than the denominator does not allow to compute the inverse sine. The division of observed over true aspect ratio must be below 1. I don't blame you though. I am sure it is hard to keep a good focus while making videos and providing commentary on what you are doing. Mistakes are easily made.

Personally I eyeball the observed length at 10m33 to be 14.3, and height at 10:59 to be 2.8. Resulting in a aspect ratio of 5.1(07) (using 1430 against 4m40s on the time disk) Making my inverse sine calculate to 72-ish degrees. But one has to keep in mind that the same inverse sine result applies to angles equally distant to 90 degrees. The sine of 80 degrees is the same value as the sine of 100 degrees. So the AOB based on my measurements could also be 108 degrees.

Now, me being able to compute a result does not mean that I am right in my measurements. From the view to the target when you can see that is showing the backside of the forward bridge structure. Indicating AOB is larger than 90 degrees, so close to 108. But infact a little time later the map shows the AOB to be 99. Which goes to show this method is not really appropriate to AOB angles close to 90 degrees. You will only get a ball-park result. On-bow or on-aft AOBs work out more precisely. But then beam-width also comes into play. Yeah, science is messy.

And if people have not noticed yet. It really helps to know your tables of 6(0 seconds) to come up with the equivalent mark on the time-disk representing desired numbers. Like 28 not having a mark on the time disk. But considering a full lap on the disk is a multiplication by 10, it is the same mark as 280. Knowing that 280 = 240+40 = 4*60 +40, it is then located at 4 minutes and 40 seconds.

derstosstrupp 06-19-19 09:57 AM

Good deal Pisces what you say makes perfect sense in hindsight. I will correct in my next couple videos using a smaller AOB. Thanks for pointing that out!

Pisces 06-19-19 10:08 AM

My trick for calculating range with the attackdisk backside:

1: lookup mastheight in meters in the recognition manual
2: measure centiradians in the periscope view. Try to gauge it down to a 6th centiradian. Remember which zoom level you use.
3: locate the mark on the inside scale of the (light yellow) distance disk which best represents the mastheight (28m, so 2800 in your example)
4: Locate the centi-radian value as a minute-mark on the time-disk. The centi-radian fraction is then equivalent to a multiple of the 10 second intermediate marks. 2.7 is just over 2+4/6, so also just over 2m40s.
5a: For low zoom, look over at the distance value against 10 minutes (this is equivalent to 1 minute): 28m/(2.666 centi-radians)= 10.5 (hundred meters)
5b: For high zoom, look over at the distance value against 4 minutes (4 times the 1 minute mark): 28m / 2.666 *4 = 42 hundred meters.

By using centi-radians as minutes on the time disk you get to see the distances for both zoom levels all at once. Much quicker than guesstimating and approximating with the in-game distance table.

[EDIT]: And for centi-radians below 2 you look to the beige/tan disk showing down into the minute and seconds. All second marks line up with the multiples of 10 seconds on the white minute scale.

derstosstrupp 06-19-19 10:22 AM

That’s also very helpful! I’ll add rangefinding to the videos as well using this. I hadn’t thought of converting denominator values to the minutes scale on the time scale but makes perfect sense for more precision!

Pisces 06-19-19 12:19 PM

And while I'm at it:

Calculating turn radius for (submerged) dead-reckoning:

1: Line up the Odometer distance moved during the turn on the distance scale (light yellow disk inside scale), with turn degrees in seconds on the time disk. (360 degrees is 6 minutes)
2: Locate the 'Magic value' 180/pi on time-disk at 9m33s.
3: Read turn radius on the distance disk across the 'magic value' (180/pi) at 9m33s.

Example:

Odometer distance: 250m
Turn angle: 43 degrees

Align 250(.0)meters to 43s (or 7m10s).
Read radius as 333(.1) meters against magic value 9m33s
--------------------------

Calculate chord distance (to locate end of turn with shortcut line)

(Or in laymen's terms: The straight line across pizza-slice crust corners)

Note: This calculation assumes a inside turn, i.e. the shortest corner. If taking an outside turn (the turn is larger than 180 degrees) then use the complement of it instead: 360 - turn angle. Example: turn =215 degrees; use 145 as turn angle and 72.5 degrees as halve of the turn in step 2.

1: Align calculated turn radius to 90 degrees (index on the dark brown disk).
2: Locate the halve turn angle on the brown disk angle scale
3: Read the semi-chord length opposite to the halve turn angle.
4: Turn the semi-chord length mark to 30 degrees (that is a 'magic number' for 0.5) on the brown sine-angle disk.
5: Read the actual chord-length opposite to 90 degrees.

[EDIT] Example:
Turn radius 333(.1) meter against 90 degrees
Halve turn angle is 21.5 degrees
Semi-chord length is opposite to 21.5 degrees at 122(.1) meter .
Turn 122(.1) meter to 30 degrees
Full chord length is 244(.2) meters opposite to 90 degrees.


P.S. I don't see why people actually bother with calculating this chord-length. But it's is provided anyway to complete the toolset.

I think it is much easier to draw a line perpendicular to own course at the start of the turn towards the center of the turn. Make it's length the turn radius. Then draw another line (or circle) from there to the angle of the end of the turn (length as radius). And start the new own-course track from that endpoint.

derstosstrupp 06-19-19 12:58 PM

Pisces you are on a roll! Great stuff - I’ll need to practice this last part before putting it in a video as I only just learned how to plot underwater myself.

You can rest assured that I will give you full credit in there for correction/additions!

One question on the alternative method at the end to using a chord line. When you plot the second line at the end of the first perpendicular line, is that second line drawn using the newly established course? And is the length the same as the first, I.e. also equal to turn radius?

gutted 06-19-19 01:09 PM

Why are the buttons on the bottom bar of your solution solver program off kilter?

My only guess is a DPI scaling issue. Do you use DPI scaling for your desktop? If so try right clicking the program, going to compatibility, and then clicking "Change High DPI settings" and turning it off for the solution solver program.

Also, why would you not report that?

derstosstrupp 06-19-19 01:35 PM

Quote:

Originally Posted by gutted (Post 2614888)
Why are the buttons on the bottom bar of your solution solver program off kilter?

My only guess is a DPI scaling issue. Do you use DPI scaling for your desktop? If so try right clicking the program, going to compatibility, and then clicking "Change High DPI settings" and turning it off for the solution solver program.

Also, why would you not report that?

No need to get testy. I have no idea what DPI scaling means and frankly don’t care. I didn’t notice it so there’s your answer as to why it wasn’t reported.

Great tool by the way.

Pisces 06-19-19 01:50 PM

Quote:

Originally Posted by derstosstrupp (Post 2614886)
...
One question on the alternative method at the end to using a chord line. When you plot the second line at the end of the first perpendicular line, is that second line drawn using the newly established course? And is the length the same as the first, I.e. also equal to turn radius?

I had a feeling I wouldn't be that clear to understand on that part. No, it is the end of turn radius of the turn circle. The new course is perpendicular to that. And yes, same radius length.

Old course track.
Point of start of turn.
Perpendicular line as radius of turn circle to the turn center.
From turn center a line outwards to the end of the turn, rotated relative from the start of the turn by the turn angle.
From end of turn radius a line perpendicular to it as the new course.

This turn circle plot leaves a bit room for error with non-constant rudder deflections and turn rates, or speed changes in the turn. But should work well enough for government work.

Though I must say, still not done this in a multiplayer session with other crew. I perish the thought of a captain that cannot make up his/her mind as to what course to hold.

derstosstrupp 06-19-19 02:06 PM

Quote:

Originally Posted by Pisces (Post 2614892)
I had a feeling I wouldn't be that clear to understand on that part. No, it is the end of turn radius of the turn circle. The new course is perpendicular to that. And yes, same radius length.

Old course track.
Point of start of turn.
Perpendicular line as radius of turn circle to the turn center.
From turn center a line outwards to the end of the turn, rotated relative from the start of the turn by the turn angle.
From end of turn radius a line perpendicular to it as the new course.

This turn circle plot leaves a bit room for error with non-constant rudder deflections and turn rates, or speed changes in the turn. But should work well enough for government work.

Though I must say, still not done this in a multiplayer session with other crew. I perish the thought of a captain that cannot make up his/her mind as to what course to hold.

Perfect- thanks! If I get into a convoy I don’t even have Nav bother plotting underwater. The rudder commands come so fast and furious we are practically writing our names in the water! There are times though when I like to have it done.

derstosstrupp 06-19-19 11:51 PM

Post 2 edited to add Part IV videos!

Elphaba 08-13-19 06:07 PM

Quote:

Originally Posted by gutted (Post 2614888)
Why are the buttons on the bottom bar of your solution solver program off kilter?

My only guess is a DPI scaling issue. Do you use DPI scaling for your desktop? If so try right clicking the program, going to compatibility, and then clicking "Change High DPI settings" and turning it off for the solution solver program.

Also, why would you not report that?

Maybe your app should take DPI into account then?

gutted 08-14-19 02:35 PM

Quote:

Originally Posted by Elphaba (Post 2622705)
Maybe your app should take DPI into account then?

That was just a guess. Seeing as he never tried to resolve it or get with me for a fix... it's going to stay that way.



The program scales just fine on my end no matter which display scaling i have windows set to. So go figure.


All times are GMT -5. The time now is 02:11 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © 1995- 2024 Subsim®
"Subsim" is a registered trademark, all rights reserved.