Like the title says, I've started the endeavor of rebuilding the RNP (AR) approaches of the Alaskan Milk Run. However, instead of just translating the data that was used for the PMDG to the iFly format, I'm updating them to include radius-to-fix (RF) legs based off of real ADS-B data from FlightRadar24. I thought it would be fitting to announce this here since this was the place where simmers of yore (lol) published the original navdata estimates that I am partially basing this upon. Credit goes to @M_Sauce and Trevor Lahey (whose forum username I could not find) for their outstanding work for the NGX.

To date, I've completed a handful of SIDs and approaches, so I want to showcase one of them that's out of Wrangell, AK, which I'm calling the ETOLN1. This should be representative of what the SID for a southerly departure off of RW10 should look like.

Here's a YouTube video to see the procedure in action.

When I first started working, I quickly realized that finding the center point of the circle that makes up the RF leg is actually waaaayyyy harder than I first thought, because latitude and longitude points are not like the X and Y coordinates that you would use on a graph, but are actually angles on a sphere. What that means in practice is that instead of simple algebra, I'd need to use things like vectors, spherical trigonometry, and other types of semi-complex mathematics to calculate the center point of the circle. A bit of research, coding, and beefy equations later, I now have a method that gets me the RF arc with an accuracy of less than 0.02nm from the actual path. However, to avoid any possibility of some nice people in fancy suits coming to my door with some scary paper, I've changed the waypoint names and moved the path ever so slightly, so don't expect this to be exactly like the real deal.

For those who are curious, I am not planning to program this into the PMDG at this time, but I will leave the door open for anyone who is crazy enough to do so.

I know that there are/were ASA people on this forum (*cough* @Stearmandriver *cough*) that had access to the real procedures when they were authored for the NGX. Are there any still around that would be willing to check my work? Any feedback/comments from anyone would be appreciated!

That looks familiar for the WRG departure.  I've built almost all of these already in the iFly; it does them much better than the new PMDG navdata implementation can handle them.  It's not perfect, but they work.  The PMDG will put you into the mountain every time on the RNVM 05 into PSG for instance.  (I hesitate to share my work publicly though as sharing it is clearly a violation of corporate IP policy.  Probably wouldn't matter but I'd rather not be the guy to test it.)

I use a different method of finding the center of the arc.  What I'm doing is using the circle portion of the measure tool in Google Earth.  I plot both end waypoints, then draw a circle of the correct radius, then drag it around until it overlays the end points correctly, then drop a pin on the center.  Then you've got the center coords.  It's been astonishingly accurate.  It helps to create the two waypoints that bookend THOSE as well, then you can draw segments between the waypoints, then you've really got something to line the circle edges up with.

In case you aren't aware, all of the custom waypoints (if you have access to the charts and know the names) are actually in the FAA 's navdata lookup tool.  They're just in a weird format; I've been creating a point in Google Earth and pasting in the coords and then replacing the dashes with spaces, and they'll be recognized. 

https://nfdc.faa.gov/nfdcApps/services/ajv5/fixes.jsp

I would love to give these a try in the sim!
Looks really nice on that ND going through the valleys..

I guess it is not really necessary to change the waypoint names if they are listed in an official publicly accessible FAA database?

 

Regards,
Sylvain

3 hours ago, Stearmandriver said:

That looks familiar for the WRG departure.  I've built almost all of these already in the iFly; it does them much better than the new PMDG navdata implementation can handle them.  It's not perfect, but they work.  The PMDG will put you into the mountain every time on the RNVM 05 into PSG for instance.  (I hesitate to share my work publicly though as sharing it is clearly a violation of corporate IP policy.  Probably wouldn't matter but I'd rather not be the guy to test it.)

I use a different method of finding the center of the arc.  What I'm doing is using the circle portion of the measure tool in Google Earth.  I plot both end waypoints, then draw a circle of the correct radius, then drag it around until it overlays the end points correctly, then drop a pin on the center.  Then you've got the center coords.  It's been astonishingly accurate.  It helps to create the two waypoints that bookend THOSE as well, then you can draw segments between the waypoints, then you've really got something to line the circle edges up with.

In case you aren't aware, all of the custom waypoints (if you have access to the charts and know the names) are actually in the FAA 's navdata lookup tool.  They're just in a weird format; I've been creating a point in Google Earth and pasting in the coords and then replacing the dashes with spaces, and they'll be recognized. 

https://nfdc.faa.gov/nfdcApps/services/ajv5/fixes.jsp

Thanks for the heads up about the PMDG. Guess we're stuck using the old approximations until they decide to update their systems to modern standards. I've wondered if I could do the same thing for the Fenix A319, but I would have to look at what their format is, and I still need to finish them for the iFly first. I've been troubleshooting some weird path drawing behavior for the RW10 SIDs that requires putting in the direct-to-fix again when you get on the runway before you can enable LNAV, and not being able to program in SID transitions for some reason.

Your method for finding the center point seems much easier, and way more elegant than mine lol. Rather than estimating the point first, I grab the two endpoints in Google Earth from the KMLs I got from FR24 (or just use the waypoints themselves if they're close enough) and then the midpoint so I can put it into my code which spits out the center point. I spent a few nights banging my head against a wall trying to correct for the fact that the earth isn't exactly a sphere, which I didn't really have to do at such small distances, but in the end, it's worth it for the many decimal places of accuracy, even with the very slight inaccuracies that come with using floating point math.

That FAA tool will definitely be helpful for cross-checking the waypoints I'm using from the old data. Unfortunately, I don't have access to the charts, so I'm stuck with guesstimating, or even just creating new waypoints. One thing that I've always wondered about is the MDAs for the approaches, since I haven't been able to find any information on those anywhere. I assume since Alaska has procedures that have (to my knowledge) as low as 0.15 RNP, I'd assume they'd be pretty low. I know that you wouldn't be able to say exact numbers publicly, but would you be able to give a ballpark figure I could use? 

1 hour ago, Sylle said:

I would love to give these a try in the sim!
Looks really nice on that ND going through the valleys..

I guess it is not really necessary to change the waypoint names if they are listed in an official publicly accessible FAA database?

 

Regards,
Sylvain

I'm finishing WRG and PSG first, so I'll think about putting those up when they're done and republish once I fully complete the project. 

I agree that changing the waypoint names is unnecessary since now I know they're in a publicly available database, but sometimes it's a little more fun to create and name your own 😄.

6 hours ago, LizardDoggo said:

I've been troubleshooting some weird path drawing behavior for the RW10 SIDs that requires putting in the direct-to-fix again when you get on the runway before you can enable LNAV,

Yup, I think that's because the sim's magnetic variation is slightly out of date.  What I've been doing in these cases is creating a CA waypoint (course to altitude) to maybe 300ft, then TF to the first waypoint.  Then you can arm LNAV off the ground and you'll never notice the small correction. 

6 hours ago, LizardDoggo said:

One thing that I've always wondered about is the MDAs for the approaches, since I haven't been able to find any information on those anywhere. I assume since Alaska has procedures that have (to my knowledge) as low as 0.15 RNP

We have procedures in most of Southeast that get down to .10 RNP.  Mins are ILS-ish at that point, a little different on every approach, maybe 250agl as a good average.

Your method is exactly why I don't think there's the same need for secrecy around these procedures that there used to be - anyone can look at an ADS-B track and view lateral pathing and altitudes at various points, so while it's obvious that sharing charts is a no-no, it *seems* that re-created approaches themselves shouldn't be such an issue.  But knowing this place and their attitude towards this data, I am confident the powers that be do not agree.

Oh, and note that it is a good idea to manually set RNP to some tighter value in the iFly as you would in reality (you have to use a leading zero which took me a bit to figure out haha.). It makes a difference in both the visual representation of the nav performance scales, and the sensitivity of the lateral deviation pointer, as it should.  What I've found is that the autopilot can not always maintain the tighter arcs within .10 RNP, especially with challenging winds, but it gets close.  If you hand fly though and stay in the FD for the most part, with some scan of the ND to lay the "white noodle" turn predictor over the arc, you can remain perfectly on course with only very minor deviations out of the flight director. 

Contrasting this with PMDG - they have brought their updated navdata format to the 737 and I've built many of these same approaches in their navdata, and it's just not handled as well.  There are a couple approaches into PSG and JNU where the path transitions from an RF arc in one direction immediately into an RF arc the other direction, and that seems to break the PMDG.  It also cannot accept an RF leg to a runway waypoint (necessary in WRG and JNU) so you need to create a pseudo waypoint 10 ft prior to the runway threshold and arc to that... Basically, given the current state of both aircraft, if you want to do Southeast Alaska RNP stuff in a 737 in the sim, the iFly is the better choice.

That’s really cool stuff guys.  
 

I’d love to give these a shot when they’re all done! 

On 12/26/2024 at 8:00 PM, LizardDoggo said:

Like the title says, I've started the endeavor of rebuilding the RNP (AR) approaches of the Alaskan Milk Run. However, instead of just translating the data that was used for the PMDG to the iFly format, I'm updating them to include radius-to-fix (RF) legs based off of real ADS-B data from FlightRadar24. I thought it would be fitting to announce this here since this was the place where simmers of yore (lol) published the original navdata estimates that I am partially basing this upon. Credit goes to @M_Sauce and Trevor Lahey (whose forum username I could not find) for their outstanding work for the NGX.

To date, I've completed a handful of SIDs and approaches, so I want to showcase one of them that's out of Wrangell, AK, which I'm calling the ETOLN1. This should be representative of what the SID for a southerly departure off of RW10 should look like.

Here's a YouTube video to see the procedure in action.

When I first started working, I quickly realized that finding the center point of the circle that makes up the RF leg is actually waaaayyyy harder than I first thought, because latitude and longitude points are not like the X and Y coordinates that you would use on a graph, but are actually angles on a sphere. What that means in practice is that instead of simple algebra, I'd need to use things like vectors, spherical trigonometry, and other types of semi-complex mathematics to calculate the center point of the circle. A bit of research, coding, and beefy equations later, I now have a method that gets me the RF arc with an accuracy of less than 0.02nm from the actual path. However, to avoid any possibility of some nice people in fancy suits coming to my door with some scary paper, I've changed the waypoint names and moved the path ever so slightly, so don't expect this to be exactly like the real deal.

For those who are curious, I am not planning to program this into the PMDG at this time, but I will leave the door open for anyone who is crazy enough to do so.

I know that there are/were ASA people on this forum (*cough* @Stearmandriver *cough*) that had access to the real procedures when they were authored for the NGX. Are there any still around that would be willing to check my work? Any feedback/comments from anyone would be appreciated!

This is super cool. Is there a way for others to use your waypoints?