Jump to content
Sign in to follow this  
Driver170

Overlay approaches

Recommended Posts

Just guessing, but I would presume the difference is because the aircraft in the video is set up to calculate idle descent paths from each crossing altitude, whereas the NGX calculates a continuous geometric descent path (and therefore there is no intermediate T/D point).

Share this post


Link to post
Share on other sites

Just guessing, but I would presume the difference is because the aircraft in the video is set up to calculate idle descent paths from each crossing altitude, whereas the NGX calculates a continuous geometric descent path (and therefore there is no intermediate T/D point).

 

That was my guess, too.


Matt Cee

Share this post


Link to post
Share on other sites

A slight spin on the overlay approaches already mentioned is where the crew 'create' FMS waypoints commensurate with the desired approach and fly them in sequence, with reference to the primary aid.

 

For example, a straight in VOR could easily be coded by the crew and flown using the FMS - but to be legal the aircraft must be navigated by the required navaid - probably goes without saying it can be fraught to do it this way, but its an option if you ever need it I suppose.

Share this post


Link to post
Share on other sites

 

 


For example, a straight in VOR could easily be coded by the crew and flown using the FMS - but to be legal the aircraft must be navigated by the required navaid - probably goes without saying it can be fraught to do it this way, but its an option if you ever need it I suppose.

 

Every airline I have worked for prohibits this.  Approaches flown with RNAV are required to be selected from the database.  Pilot created approaches are not allowed.

 

There may be operators that allow this but it would be rare indeed.

Share this post


Link to post
Share on other sites

 

 


Every airline I have worked for prohibits this.  Approaches flown with RNAV are required to be selected from the database.  Pilot created approaches are not allowed.

 

Its in the FCTM black and white


Vernon Howells

Share this post


Link to post
Share on other sites

Procedures must be in the database; this is not only an airline or manufacturer requirement but is a regulatory requirement.  Very simply, a clearance is required for an approach and unless the approach is published (or otherwise vetted) there is no clearance.  To stretch it, if you are cleared to a VOR approach and you used a pilot-created overlay to take advantage of GPS tracking and do not track the raw-VOR signal then you'll illegally flying an approach.  I cannot imagine a qualified pilot ever doing this.  There's just too many pitfalls.


Dan Downs KCRP

Share this post


Link to post
Share on other sites

A slight spin on the overlay approaches already mentioned is where the crew 'create' FMS waypoints commensurate with the desired approach and fly them in sequence, with reference to the primary aid.

 

For example, a straight in VOR could easily be coded by the crew and flown using the FMS - but to be legal the aircraft must be navigated by the required navaid - probably goes without saying it can be fraught to do it this way, but its an option if you ever need it I suppose.

 

 

Every airline I have worked for prohibits this.  Approaches flown with RNAV are required to be selected from the database.  Pilot created approaches are not allowed.

 

There may be operators that allow this but it would be rare indeed.

 

 

Its in the FCTM black and white

 

 

Procedures must be in the database; this is not only an airline or manufacturer requirement but is a regulatory requirement.  Very simply, a clearance is required for an approach and unless the approach is published (or otherwise vetted) there is no clearance.  To stretch it, if you are cleared to a VOR approach and you used a pilot-created overlay to take advantage of GPS tracking and do not track the raw-VOR signal then you'll illegally flying an approach.  I cannot imagine a qualified pilot ever doing this.  There's just too many pitfalls.

 

This one, as mentioned by Joe is one of those parts of what I call 'greyviation,' where this issue is addressed by regulation, but not directly. The FAA stance on the matter is that any approach to be flown must be loadable from the database directly. No exceptions are made for where the actual reference is: AIM 1-1-19f1(B) Equipment and Database Requirements - For IFR Operations "All approach procedures to be flown must be retrievable from the current airborne navigation database..."

 

I'm sure company OPSpecs make that even more clear. A good example of why this is required is that it's far more common to have pilots fat-finger waypoints than you'd think. That, or they misinterpret their spelling. I was flying around with my old college roommate and good pilot friend one day, shooting the RNAV approach into Harford County (0W3, if anyone is interested in attempting to land a smaller plane on a 40x2000 foot runway). In order to skirt some airspace, he told me to fly to "Lindsay." I translated this to LINZE, when the fix intended was LINSE. Luckily, I knew that I needed to go ENE, and noticed that the GPS wanted to take me due south (LINZE is in Florida). I tried the alternate spelling just as he looked up and realized he should probably spell it out. Stuff like this is actually a big issue on the NATs, too, particularly with the ARINC 424 lat/lon points: N4240 versus 4240N. Which one do you need? Don't know? If you fly across the NATs without knowing, a report of it will likely come across my desk...


Kyle Rodgers

Share this post


Link to post
Share on other sites

 

 


Stuff like this is actually a big issue on the NATs, too, particularly with the ARINC 424 lat/lon points: N4240 versus 4240N. Which one do you need? Don't know? If you fly across the NATs without knowing, a report of it will likely come across my desk...

 

Indeed -- and one of the reasons why I would always recommend entering the long-format lat/long (N42W040) rather than the abbreviated waypoints!

Share this post


Link to post
Share on other sites

This one, as mentioned by Joe is one of those parts of what I call 'greyviation,' where this issue is addressed by regulation, but not directly. The FAA stance on the matter is that any approach to be flown must be loadable from the database directly. No exceptions are made for where the actual reference is: AIM 1-1-19f1(B) Equipment and Database Requirements - For IFR Operations "All approach procedures to be flown must be retrievable from the current airborne navigation database..."

 

I'm sure company OPSpecs make that even more clear. A good example of why this is required is that it's far more common to have pilots fat-finger waypoints than you'd think. That, or they misinterpret their spelling. I was flying around with my old college roommate and good pilot friend one day, shooting the RNAV approach into Harford County (0W3, if anyone is interested in attempting to land a smaller plane on a 40x2000 foot runway). In order to skirt some airspace, he told me to fly to "Lindsay." I translated this to LINZE, when the fix intended was LINSE. Luckily, I knew that I needed to go ENE, and noticed that the GPS wanted to take me due south (LINZE is in Florida). I tried the alternate spelling just as he looked up and realized he should probably spell it out. Stuff like this is actually a big issue on the NATs, too, particularly with the ARINC 424 lat/lon points: N4240 versus 4240N. Which one do you need? Don't know? If you fly across the NATs without knowing, a report of it will likely come across my desk...

Mmm. Greyvi.


Matt Cee

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...