Sextant Video Tutorial

[Hobart Escin]

What I wasn't getting is that the sextant gauge actually does all the calculations AUTOMATICALLY after you take a shot (DUH moment for me ) and returns the distance offset value which you use to plot a LOP. You explained earlier that the sextant gauge in the sim doesn't really know or care about the actual positions of celestial objects in the Flightsim sky itself, but rather acts like a trigonometric calculator using the assumed position data and observation angles you input into it. I'm finally grasping this concept (yay). You are using the tables just as you would IRL for a sextant shot in terms of expected position data for a celestial object, and after you input this data into the gauge it automatically performs the calculations right away instead of the user having to cross reference actual table data and making manual calculations. The sextant gauge is doing all the grunt work at this point to yield the value you need (again, as you explained earlier)

Yup. Glad it's making sense. Practically speaking, this isn't complex, but even though the gauge documentation is very good, I agree it can be confusing until you see it in action a couple times. I was hoping a video would help.

One thing your comment makes me I feel like I should have emphasized in the video - while I believe the gauge DOES do the calculations immediately as you say, the distance offset it returns for a result at the end very much DOES depend on your accuracy at aligning the bubble with the star. That part isn't for fun or for show - every mouse wheel click you are off changes the distance offset returned by 5nm. And it does take some practice - sometimes it'll feel like the sweet spot is between two possible positions, probably because it is. The designers did a great job with this.

Anyway, just wanted to make sure that part was clear. I've been emphasizing how easy and automated the gauge is, and all the ways it lowers workload by doing the grunt work for you, but I want to make sure you understand THAT part is important. A sloppy shot will yeild a less accurate result for sure.

Hi Stearman,

I hadn't realized dynamic accuracy is actually programmed into the gauge when you take a bubble reading , wow, and I will certainly takes this into account when navigating. This just gets more fun all the time!

I wanted to ask a follow-up question about the LOP intercept procedure you described in your Flightsim thread about a flight from Oahu to Johnston Atoll. You described that a specific LOP (161-341 true) would run through Johnston at your zulu ETA over your planned offset point. I input Johnston's lat/long and the same time and date as you listed on that thread into the online Naval Observatory form, getting the exact same LOP result (yay), so I know I'm with you here in concept. What I wanted to ask is how you determined that you actually were at the intercept point toward the end of your flight? Did you simply begin taking a series of sextant shots close to your ETA at your planned offset point until you observed actually being on the 161-341 LOP to Johnston?

Also, how did you determine a proper magnetic heading to fly within the confines of either FSX or P3D? Both sims have a built-in magnetic variation algorithm that's outdated in terms of up to date RW charts, so this seems like it would be challenging!

Thanks again for all of your help and insight with this. Most fun I've had simming in a long time!

[Stearmandriver]

What I wasn't getting is that the sextant gauge actually does all the calculations AUTOMATICALLY after you take a shot (DUH moment for me ) and returns the distance offset value which you use to plot a LOP. You explained earlier that the sextant gauge in the sim doesn't really know or care about the actual positions of celestial objects in the Flightsim sky itself, but rather acts like a trigonometric calculator using the assumed position data and observation angles you input into it. I'm finally grasping this concept (yay). You are using the tables just as you would IRL for a sextant shot in terms of expected position data for a celestial object, and after you input this data into the gauge it automatically performs the calculations right away instead of the user having to cross reference actual table data and making manual calculations. The sextant gauge is doing all the grunt work at this point to yield the value you need (again, as you explained earlier)

Yup. Glad it's making sense. Practically speaking, this isn't complex, but even though the gauge documentation is very good, I agree it can be confusing until you see it in action a couple times. I was hoping a video would help.

One thing your comment makes me I feel like I should have emphasized in the video - while I believe the gauge DOES do the calculations immediately as you say, the distance offset it returns for a result at the end very much DOES depend on your accuracy at aligning the bubble with the star. That part isn't for fun or for show - every mouse wheel click you are off changes the distance offset returned by 5nm. And it does take some practice - sometimes it'll feel like the sweet spot is between two possible positions, probably because it is. The designers did a great job with this.

Anyway, just wanted to make sure that part was clear. I've been emphasizing how easy and automated the gauge is, and all the ways it lowers workload by doing the grunt work for you, but I want to make sure you understand THAT part is important. A sloppy shot will yeild a less accurate result for sure.

Hi Stearman,

I hadn't realized dynamic accuracy is actually programmed into the gauge when you take a bubble reading , wow, and I will certainly takes this into account when navigating. This just gets more fun all the time!

I wanted to ask a follow-up question about the LOP intercept procedure you described in your Flightsim thread about a flight from Oahu to Johnston Atoll. You described that a specific LOP (161-341 true) would run through Johnston at your zulu ETA over your planned offset point. I input Johnston's lat/long and the same time and date as you listed on that thread into the online Naval Observatory form, getting the exact same LOP result (yay), so I know I'm with you here in concept. What I wanted to ask is how you determined that you actually were at the intercept point toward the end of your flight? Did you simply begin taking a series of sextant shots close to your ETA at your planned offset point until you observed actually being on the 161-341 LOP to Johnston?

Also, how did you determine a proper magnetic heading to fly within the confines of either FSX or P3D? Both sims have a built-in magnetic variation algorithm that's outdated in terms of up to date RW charts, so this seems like it would be challenging!

Thanks again for all of your help and insight with this. Most fun I've had simming in a long time!

Hey, glad to hear you're having fun with it! Regarding your questions:

1. How to determine when you're on the LOP through destination? Yep you've basically got it. When you reach a point where you know the next sextant shots you take will be to find that LOP, set your sextant up for it: enter the destination coordinates as your assumed position, and enter the appropriate sun azimuth and elevation (wich it sounds like you understand how to find). And then when dead reckoning tells you you should be close, start taking shots. If your dead reckoning is somewhat close, your first shot should yeild (in the Hawaii-Johnston atoll example) a positive distance offset. Right? Because the LOP you're actually on is closer to the sun (rising in the east) than the LOP running through your assumed position (destination). So ideally you get like a +25nm distance offset. Shoot again a minute later (you won't have to change any settings on the sextant, just click once to clear the last shot then click again to start a new one). You should get a lower positive distance... say +15nm. Keep shooting and watch the distance count down until it reads 0nm when you hit the LOP, (or maybe lead it by +5nm) and turn onto the LOP. Take another shot or two to verify you're staying on the line, and you'll hit destination eventually.

2. Variation - interesting question and one I've wondered as well. I've been using a combination of Google Earth, the ASN flight planner, and a spreadsheet file I found online to plan these. I've noted that the variation ASN uses (which should be read from the FSX file) mirrors current variation (looked up online) closely, within a degree. Either my ORBX global updated my variation file (no idea and would still be a couple years old) or variation in that part of the Pacific just doesn't change much (the online sources report almost nil annual rate of change).

But the real solution, and the one I still need to do too, is to update the variation in the sim. This looks promising:
https://www.aero.sors.fr/navaids.html

[wothan]

Try to use this for flightplanning: https://skyvector.com/

The final flightplan will also show magnetic heading and variation for each waypoint.

Example:
https://www.dropbox.com/s/ks9wvqsi82zhtmw/FP.jpg?dl=0

Please study all the option about weather, aircraft setup etc. and You will find that You can make a complete flightplan that takes care of wind,s magnetic heading etc. with reallife data that closely should resemble what ASN /AS16 (and other realtime weather apps) depicts.

[Stearmandriver]

Try to use this for flightplanning: https://skyvector.com/

The final flightplan will also show magnetic heading and variation for each waypoint.

Example:
https://www.dropbox.com/s/ks9wvqsi82zhtmw/FP.jpg?dl=0

Please study all the option about weather, aircraft setup etc. and You will find that You can make a complete flightplan that takes care of wind,s magnetic heading etc. with reallife data that closely should resemble what ASN /AS16 (and other realtime weather apps) depicts.

The problem with skyvector is that you can't go "back in time" and plan a flight at an earlier day. The problem here is twofold for me: 1. you can't choose a day that ASN doesn't show much weather on your route, and 2. There are problems using time acceleration with ASN in real time, because you accelerate yourself "into the future" where ASN doesn't have any weather data.

I like skyvector's format, but I wish you could enter your own winds / temps. It'd be more useful then. Oh, and I also think I remember it being difficult to input a custom lat/lon as a fix, which is all you have out over the ocean. That seems like it should be doable though, I'll bet I just wasn't finding the right format.

[wothan]

Try to use this for flightplanning: https://skyvector.com/

The final flightplan will also show magnetic heading and variation for each waypoint.

Example:
https://www.dropbox.com/s/ks9wvqsi82zhtmw/FP.jpg?dl=0

Please study all the option about weather, aircraft setup etc. and You will find that You can make a complete flightplan that takes care of wind,s magnetic heading etc. with reallife data that closely should resemble what ASN /AS16 (and other realtime weather apps) depicts.

The problem with skyvector is that you can't go "back in time" and plan a flight at an earlier day. The problem here is twofold for me: 1. you can't choose a day that ASN doesn't show much weather on your route, and 2. There are problems using time acceleration with ASN in real time, because you accelerate yourself "into the future" where ASN doesn't have any weather data.

I like skyvector's format, but I wish you could enter your own winds / temps. It'd be more useful then. Oh, and I also think I remember it being difficult to input a custom lat/lon as a fix, which is all you have out over the ocean. That seems like it should be doable though, I'll bet I just wasn't finding the right format.

I don´t see much of a problem...

1. Using Skyvector will give You a snapshot of the weather as it is known before departure - just what captains had then. ASN/AS16 should give You weather close to what Skyvector sees. Back in old times weather briefings over the Atlantic was not that accurate either and You will have to determine unexpeted drift due to different winds anyway.
Using my Weather Ship Gauge You can get some simplistic weather updates when You get into reception range and adjust accordingly.

2. I would never use time acceleration, since that takes away the immersion, and as You say - cannot not be done with realtime weather.

3. I have no problems setting Lat/Lon.

Only problem with Skyvector I see is that the magnetic variation data might be newer than what we have in FSX/P3D.

[Stearmandriver]

I don´t see much of a problem...

1. Using Skyvector will give You a snapshot of the weather as it is known before departure - just what captains had then. ASN/AS16 should give You weather close to what Skyvector sees. Back in old times weather briefings over the Atlantic was not that accurate either and You will have to determine unexpeted drift due to different winds anyway.
Using my Weather Ship Gauge You can get some simplistic weather updates when You get into reception range and adjust accordingly.

2. I would never use time acceleration, since that takes away the immersion, and as You say - cannot not be done with realtime weather.

3. I have no problems setting Lat/Lon.

Only problem with Skyvector I see is that the magnetic variation data might be newer than what we have in FSX/P3D.

Well yep, sounds like skyvector would work fine for your use then. We all have different usage requirements, and it'll be up to everyone to find a dead reckoning workflow that works for them. I like skyvector, it's a great tool, don't get me wrong... (and your magnetic variation issue is solvable if you look a couple posts up). It just won't quite work for ME, with my requirement for time acceleration (if you have the free time to do 7 hour flights in real time, I'm jealous lol). Oh, and time acceleration works just fine with ASN as long as you start far enough in the past that you don't accelerate into the future. Just designate a historical date/time in ASN and the weather changes realistically over time, and at an accelerated rate if you time accelerate. Works great.

I personally need the ability to fly on a day and time of my choosing in the past, and therefore specify my own winds/temps. I also haven't been using the weatherships or any radio navaids (since I'm roughly trying to simulate clipper flying of the mid 30s, and my understanding is there wasn't much of that available to them then), so accurate dead reckoning is critical, and that means somewhat accurate winds and temps. For realism, I only look up this data over departure and destination and interpolate it myself for intermediate segments, since that's likely how navigators then would have done it.

But, your (and everyone's) mileage will vary. The more different workflows we hear about from different people, the better, because it's likely no one workflow will be perfect for all or even most of us.

[wothan]

I don´t see much of a problem...

1. Using Skyvector will give You a snapshot of the weather as it is known before departure - just what captains had then. ASN/AS16 should give You weather close to what Skyvector sees. Back in old times weather briefings over the Atlantic was not that accurate either and You will have to determine unexpeted drift due to different winds anyway.
Using my Weather Ship Gauge You can get some simplistic weather updates when You get into reception range and adjust accordingly.

2. I would never use time acceleration, since that takes away the immersion, and as You say - cannot not be done with realtime weather.

3. I have no problems setting Lat/Lon.

Only problem with Skyvector I see is that the magnetic variation data might be newer than what we have in FSX/P3D.

Well yep, sounds like skyvector would work fine for your use then. We all have different usage requirements, and it'll be up to everyone to find a dead reckoning workflow that works for them. I like skyvector, it's a great tool, don't get me wrong... (and your magnetic variation issue is solvable if you look a couple posts up). It just won't quite work for ME, with my requirement for time acceleration (if you have the free time to do 7 hour flights in real time, I'm jealous lol). Oh, and time acceleration works just fine with ASN as long as you start far enough in the past that you don't accelerate into the future. Just designate a historical date/time in ASN and the weather changes realistically over time, and at an accelerated rate if you time accelerate. Works great.

I personally need the ability to fly on a day and time of my choosing in the past, and therefore specify my own winds/temps. I also haven't been using the weatherships or any radio navaids (since I'm roughly trying to simulate clipper flying of the mid 30s, and my understanding is there wasn't much of that available to them then), so accurate dead reckoning is critical, and that means somewhat accurate winds and temps. For realism, I only look up this data over departure and destination and interpolate it myself for intermediate segments, since that's likely how navigators then would have done it.

But, your (and everyone's) mileage will vary. The more different workflows we hear about from different people, the better, because it's likely no one workflow will be perfect for all or even most of us.

I fully agree - there is no wrong ways to do this and doing it 100% realistic is hard.
The FSX/P3D Sextant is not fully realistic, since it works without pointing it at the sun or stars and You don´t need to look up an Almanac.
My Weather ship gauge is also just an approximation of how it could have worked back then. The Radio set is oly a best guess of how it could have looked.

But bottom line is that this kind of flying is alot more challenging than just follow a magenta line on a GPS and the satisfactory factor alot higher successfully completing a flight this way. It´s just a matter of finding the method that works best for each of us.

[Stearmandriver]

Exactly!

[awralls]

Apologies for resurrecting an old thread, but I just thought those using celestial navigation might be interested to note the following:

'The Stars Are My Friends' by Eric Holloway is an account of the professional life of a BOAC (and later Laker Airways) navigator from WW2 until his retirement in the 1980s. He became a navigation instructor and an extremely skilled celestial navigator. The book describes in some detail a few of his techniques. One point stood out for me - he mentions being able to use Venus and Jupiter during daylight as well as the Sun and Moon. The section from his time on BOAC B377s reads "Nick Hoy said it was possible to see Venus in daylight on the ground when at its brightest by looking through a long hollow tube pointed in the right direction. I never managed that but often in the air I would pre-compute both Venus and Jupiter in daylight and use their position lines if they were visible, which in cloudless skies, was quite often".

He goes on..."A minute or so before it was needed, the calculated altitude was set on the sextant and the sextant positioned to the required relative bearing. Then, looking almost straight ahead without moving my eyes, the sextant altitude or the relative bearing, the planet would suddenly appear as a tiny pinprick of light that would become brighter as the eye became focused. The trick was not to take the eye off it for a second, but start the sextant running immediately. Once the run was completed, the time was observed at the END of the shot and the position line plotted accordingly."

So, given historical precedent, it seems valid to include Venus and Jupiter as viable daytime objects for observation. Just thought those planning flights during daytime might find this useful.

Cheers,

Andy

[Jacques]

A very interesting book...and very hard to find in the States. Well worth the search, certainly!

[Stearmandriver]

Nice find, thanks! Very welcome to have more than one or two origins for daytime shots!