E-mail Subscription

Enter your email address:

Delivered by FeedBurner

Syndicate RSS
Welcome

Mission Statement 

The purpose of FLAPS-2-APPROACH is two-fold:  To document the construction of a Boeing 737 flight simulator, and to act as a platform to share aviation-related articles pertaining to the Boeing 737; thereby, providing a source of inspiration and reference to like-minded individuals.

I am not a professional journalist.  Writing for a cross section of readers from differing cultures and languages with varying degrees of technical ability, can at times be challenging. I hope there are not too many spelling and grammatical mistakes.

 

Note:   I have NO affiliation with ANY manufacturer or reseller.  All reviews and content are 'frank and fearless' - I tell it as I see it.  Do not complain if you do not like what you read.

I use the words 'modules & panels' and 'CDU & FMC' interchangeably.  The definition of the acronym 'OEM' is Original Equipment Manufacturer (aka real aicraft part).

 

All funds are used to offset the cost of server and website hosting (Thank You...)

No advertising on this website - EVER!

 

Find more about Weather in Hobart, AU
Click for weather forecast

 

 

 

 

  FEEDBACK:  

If you see any errors or omissions, please contact me to correct the information. 

Journal Archive (Newest First)

Entries in B737 Flight Simulator (91)

Friday
Aug042017

OEM B737 CDU Conversion - Using SimStacks To Convert The CDU

This article follows on from an earlier post that introduced the concept of converting an OEM CDU to use in flight simulator.  The conversion has now been completed and the CDU operates seamlessly with ProSim-AR.   

LEFT:  OEM CDU fully converted and operational.  The CDU is from a classic 500 series aircraft.  Prior to my ownership, the CDU was used by United Airlines (click to enlarge)

Historical Conversion Techniques

To date, various OEM parts have been converted using Phidget cards, and to a lesser extent Leo Bodnar cards, Flight Deck Solutions system cards, and PoKeys interface cards.  Phidgets provide a stable platform, despite the disadvantage that they, at time of writing, only connect via USB to the server computer.  The primary advantage of using Phidgets is that they have been used in a wide variety of applications, are inherently stable (for the most part), and their configuration is well documented.

The conversion of the CDU was slightly different to the norm, in that a different interface system was used. 

SimStacks by Simulator Solutions

The conversion of the CDU was done in collaboration with Sydney-based company Simulator Solutions Pty Ltd.  Simulator Solutions utilise their propriety interface boards called SimStacks to convert OEM parts for use in commercial-grade simulators

SimStacks is a modular, stackable, and scalable hardware interface that is designed to integrate OEM parts into your simulator with little or no modification.    One of the many advantages in using a SimStack Foundation Board (SFB) is that the interface can connect with either the server or client computer via Ethernet (as opposed to Phidgets). 

To date, Simulator Solution’s experience has been predominately with the conversion of B747 parts and Rodney and John (owners) were excited to have the opportunity to evaluate their software on the 737 platform, with the 737 CDU being the ‘first cab off the rank’.

This article will not delve deeply into the SimStack architecture, nor will it document the wire pin-outs used with the interface card; a future post will tackle this topic in more detail. 

CDU Conversion - Choose Your Poison

There are two main camps when discussing how to convert an OEM part.  The first is to utilise as much of the original wiring and parts as possible.  The second is to completely ‘gut’ the part and convert it cleanly using an interface that connects seamlessly with the avionics software in use (ProSim-AR).  A third option, although expensive and in many respects ‘experimental’, is to use ARINC 429.

With regard to the CDU, the easiest route was option two; everything in the CDU was removed with the exception of the internal shelf divider and keypad.  In hindsight, the pin-outs of the Canon plugs could have been used, but to do so a female Canon plug would have been required, and for the use of a couple of pins, this seemed to be overkill.

Keypad and Screen

The keypad and screen are the two most important parts of the CDU, and it's vital that the connection between the keypad, screen, and the SimStacks Foundation Board is not compromised.  The actual functionality of the CDU is controlled by the avionics suite.

Keypad

The keypad forms part of the lightplate in which 5 Volt incandescent bulbs are strategically located to ensure even backlighting of the keys.  Disassembling and removing the keypad from the main body of the CDU is straightforward; several small Philips head screws hold the keypad in place.  Once the keypad has been removed, any ‘blown’ bulbs can be replaced. 

Table 1: Overview of bulb location, part number and quantity.

The keypad has several wires that connect to a terminus inside the main body of the CDU.  Care must be taken when cutting the strands of wire to ensure the connection between the terminus and the keypad is not damaged.  Depending upon your skill, the terminus can be removed and a longer wire soldered to the keypad connector, or the wire can be lengthened (by splicing).  The wires from the terminus connect with the SimStack Foundation Board.

CRT and LCD Screen

The Classic CDU is fitted with a solid glass cathode ray tube (CRT) screen.  The CRT screen is approximately 2 cm thick and fits snugly within the display frame of the CDU. 

LEFT:  The CRT screen forms part of the CDU casing.  The silver coloured foil indicates the thickness of the replacement glass that needed to be ground (click to enlarge).

It’s possible to make the CRT screen operational, however,  the display would be monochromatic (green) and the screen resolution poor.  Therefore, the CRT was replaced with a custom-sized high resolution colour LCD screen.

To retrofit a replacement screen is not without its challenges.  The LCD screen is not as thick as the CRT screen, and is also not the same shape.  Therefore, the screen will not fit snugly within the display recess.  To rectify this shortfall, a piece of clear glass was ground to correctly fit within the display frame of the CDU.  This piece of glass replaces the 2 cm thick CRT glass.  The thin LCD screen was then mounted behind the clear glass in a central position.

During the design phase, it was thought that the thick piece of glass would cause a refraction problem.  However, although the theory suggests refraction will occur, the practical application has been such that any refraction is not readily noticeable.

Mounting the LCD Screen

Mounting the LCD screen can be done a number of ways.  Commercial grade double-sided sticky tape is the easiest method, but it is rudimentary.

LEFT:  LCD screen is fitted and temporarily held in position by commercial tape and a foam spacer.  Prior to revamping the CDU, this area was used to house the very large square shaped CRT screen.  Note the ribbon cable linking the screen to the screen interface card and the two white cables that connect to the screen controller card and SFB (click to enlarge).

To secure the LCD so that the screen sat firmly against the glass, thin metal plate was used to replace the open space that was left after removal of the CRT screen.  The sides of the metal plate were fabricated to push against the rear edge of the LCD.  This firmly secured the LCD screen against the rear of the clear glass.

LEFT:  The photograph shows the metal plate that was fabricated to replace the original CRT unit.  The edge of the plate pushes against the rear of the LCD screen holding the screen in place.  To remove the plate cover, 2 screws need to be removed.  It's amazing that the CRT screen required the amount of space that it did  - about 5 inches square! (click to enlarge).

Although the use of metal plate appears slightly unattractive, the plate only serves to enclose the CDU.  Once the CDU is slid into the CDU bay, the the casing of the CDU is not visible.

An alterative to using metal plate is to use ABS plastic painted the correct Boeing grey colour.

SimStack Foundation Board, External Wires and Screen Controller Card

To ensure that the CDU is standalone and will function without external inputs other than power supplies, four items need to be mounted inside the CDU.

(i)    The generic Interface card that controls the LCD screen;
(ii)    The LCD screen controller (buttons that control brightness, contrast, etc);
(iii)   The SimStack Foundation Board; and,
(iv)   The wiring to connect the keyboard to the Foundation Board.

Fortunately, there is ample room in the cavernous interior of the CDU to fit these items.

LEFT:  SimStack Foundation Board (SFB) mounted into the lower section of the CDU casing.  The SFB is responsible  for registering the key presses made on the keypad which are then deciphered and communicated to the avionics suite (ProSim-AR).  Click to enlarge.

The SimStack Foundation Board is mounted on an angular metal bracket that is attached directly to the bottom of the CDU, while the LCD interface card has been installed on the upper shelf along with the screen controller.  A ribbon cable connects the LCD screen to the interface card while a standard VGA cable connects the LCD screen to the client computer. 

The SimStack Foundation Board is Ethernet ready and requires a standard Ethernet cable (CAT 6) to connect from the card to an Ethernet switch (located behind the MIP). 

In addition to the Ethernet  and VGA cable, six power wires leave the CDU via the rear of the casing; four from the SimStack Foundation Board (5 and 12 volts +-) and two from the keypad (5 volts +-) to control the backlighting.

Toggle Switch

A standard two-way toggle switch is mounted to the rear of the CDU casing.  This switch is used to control whether the LCD screen, used in the CDU, is always on, or is only turned on when ProSim-AR is activated.  The switch is set and forget, however, access to the switch can be made from the front of the MIP or by sliding the CDU our of the CDU bay.

LEFT:  Toggle switch and wire harness leaving the base of the CDU casing.  The switch position and harness use the existing holes in the casing that were previously used by the Canon plugs.  5 and 12 volt wires are connected to appropriate busbars behind the MIP, while the VGA cable connects with the client computer.  The Ethernet cable connects into the Ethernet switch, also mounted at the front of the MIP (click to enlarge).

Power Supply

To operate the CDU requires a 5 and 12 volt power supply.  The backlighting of the keypad is powered by 5 volts while the SimStack Foundation Board and CDU operation require 12 volts.

Backlight Dimming

On my set-up, to enable the CDU keyboard to be dimmed, the 5 volt wires that leave the lower section of the CDU, are connected to a dedicated 5 volt Busbar located in the center pedestal.  This Busbar is used to connect the backlighting from all OEM panels.  The Busbar is then connected to the panel knob on the center pedestal.  The ability to turn the backlighting on and off is controlled by opening or closing a 12 volt relay (attached in line between the panel knob and Busbar).  Dimming is controlled by a dimmer circuit.

Mounting the CDU to Flight Deck Solutions MIP

The MIP skeleton and CDU bay is manufactured by Flight Deck Solutions (FDS), and is designed to fit FDS’s propriety CDU unit (MX Pro) and not an OEM unit.

The casing for the OEM CDU is much longer than the FDS CDU and measures 24 cm in length.

The FDS MIP incorporates an aluminum shelf (used by FDS to mount various interface cards) that protrudes slightly into the CDU bay.  This protrusion stops the OEM casing from sliding all the way into the bay.  To enable the CDU casing to slide fully into the bay, a small section of the shelf must be cut away.

A small metal saw is used to trim the metal away from the shelf, and although an easy task, care must be taken not to ‘saw away’ too much metal.  Once the piece of offending aluminum is removed, the casing of the CDU slides perfectly into the bay, to be secured by the DZUS fasteners to the DZUS rail.

LEFT:  Using a small metal saw, s small section of the shelf is removed.  This enables the CDU to slide into the CDU bay.  Left image is the shelf projecting into the CDU bay while the right image shows the shelf removed and covered in protective tape (to minimise abrasion).  A small notch was made at the corner to facilitate the safe routing of the wires used to enable the Lights Test (click to enlarge).

Functionality and Operation

The CDU is not intelligent; it’s basically a glorified keyboard that requires interfacing with software for functionality.  The functionality, fonts, colour, etc are provided by the avionics suite (in this case ProSim-AR, but arguably it could also be Sim Avionics or Project Magenta). 

To enable communication between the avionics suite and the SimStack Foundation Board (in the CDU casing), SimStack proprietary software must be installed.

SimStack Software - SimSwitch

SimSwitch is installed on the client computer and when configured interfaces with ProSim-AR on the server computer and the network.  Configuring SimSwitch is straightforward and involves inputting the correct static IP address and port numbers.

LEFT:  Screen grab showing SimSwitch software interface.  This is located on the client computer.  The interface, once configured, is standalone.  The software can easily be opened in minimized mode via a batch file (click to enlarge).

SimSwitch can also be used to monitor all connected OEM panels and provide debugging information if needed.

SimSwitch is a JAR archive executable file.  The file must be in operation to eanable the CDU to communicate with the avionics suite. 

The JAR file and the ProSim CDU .exe file must both be open for the CDU to function correctly.  To expedite a simulator session, the JAR file can very easily be added to a batch file for automatic loading of software prior to a simulator session.  A timer command can be added to the batch file line ensuring the JAR file opens before the ProSim CDU.exe file. 

First Officer CDU

The First Officer CDU will be converted using a similar technique, with the exception that this unit will be converted more ‘cleanly’.  A dedicated plate (rather than an angular bracket) will be fitted to the inside of the CDU casing.  This will facilitate the mounting of the SimStacks Foundation Board and LCD screen controller card.

Additional Photographs and Video

Additional photographs can be viewed in the image gallery.

BELOW: A short video demonstrating the operation of the OEM CDU using ProSim-AR. 

Main points to note in the video are:

(i)    Heavy duty tactile keys;
(ii)   The definite click that is heard when depressing a key;
(iii)  The solid keypad (the keys do not wobble about in their sockets); and,
(iv) Although subjective, the appearance of the OEM CDU looks more aesthetically pleasing that a reproduction unit.

Final Call

This conversion, by using a SimStack Foundation Board (SFB), has enabled full functionality of the OEM CDU using ProSim-AR.  The SFB can also be used to connect with other avionics suites, such as Sim Avionics and Project Magenta.  However, although the wiring of the SFB would be identical, the way in which the card interfaces and communicates with the avionics suite will differ.

Glossary

ARINC429 –  A standard used to  address data communications between avionics components.  The most widely used  standard is an avionics data bus.  ARINC 429 enables a single transmitter to communicate data to up to 20 receivers over a single bus.

SFB - SimStacks Foundation Board.

Standalone – Two meanings.  (i)   Operation does not require an interface card to be mounted outside of the panel/part; and, (ii)  In relation to software, the executable file (.exe) does not need to be installed to C Drive, but can be executed from any folder or the desktop.

Friday
Feb102017

Troubleshooting Power Management Settings and Solving USB Disconnects 

Remember when all that was required to run flight simulator was one display monitor, joystick and a keyboard – those days are long gone.   

LEFT:  High-speed 5 volt powered USB hub.  This hub resides in the Throttle Interface Module (TIM).  Note ferrite choke. (click to enlarge).

Depending upon the level of system complexity, a flight simulator may require a dozen or more ports to connect peripheral items to a server or client computer (s).  Historically, connection of peripherals has been via USB.  

USB is an acronym for Universal Serial Bus and, generally speaking, if only a few peripherals are attached to a computer, there usually is not a problem with communication between the computer and the attached device.  However, as interface cards and peripherals become more complicated and numerous, there is a propensity for disconnects to occur more frequently.  A USB disconnect usually announces itself by the sound card playing the ‘ding-dong’ sound as the peripheral disconnects itself from the computer.

Guidelines (golden rules)

There are several ‘golden rules’ to remember when using USB.

(i)      Try and keep all USB cables as short as possible;
(ii)     Do not join USB cables together;
(iii)    Always use quality USB cables with quality connectors;
(iv)    Do not ‘kink’ the USB cable or wrap the cable so tightly that the wires are at a 90-degree angle;
(v)     Do not lie USB cables beside one another so they are touching, but maintain some space between them;
(vi)     Use a USB cable fitted with noise limiting nodes (NLN);
(vii)    Use a USB cable/port that is rated at the highest output (USB 3 or above); and,
(viii)   Where possible for multi USB connections use a quality powered USB hub.

Noise Limiting Node (NLN)

A noise limiting node (NLN), also known as a 'ferrite choke' is a small cylindrical node that sits at each end of a USB cable.  Briefly explained the nodes are made from a solid ball of ferrite which is magnetic and therefore quite heavy.

LEFT:  Ferrite choke on USB cable.

The purpose of the NLN is to stop electromagnetic interference (EMI) transferring from the peripheral to the computer.  EMI can be produced from any number of peripheral items and a USB cable running between the peripheral and the computer acts as an antenna, picking up and transmitting EMI current.  The current can, but not necessarily always, cause havoc with either the operation of the peripheral or the computer itself.  

Adding USB Ports

As the number of add-on peripherals increase, the number of available ports falls short and additional USB ports need to be added to the computer.  Additional ports can easily be added to a computer via a PCE card which enables (on average) an additional 4 USB ports to be added to your computer.  A PCI card is attached to your motherboard.

Power Requirements

One of the main reasons that USB disconnects occur, relates to the power that is available to the computer’s USB port.  Often the power requirements of the device will be greater than that provided to the USB port; this causes a disconnect.  Additionally, depending upon your computer, it is not uncommon for power to fluctuate between USB ports as the computer’s motherboard directs power to various processes.

Depending upon how your system is set-up, when several devices 'come on line' a minor spike can be generated.  Often, this spike can momentarily exceed the amperage rating of the USB port.  This can cause a disconnect to occur.

It’s important to understand that not all USB ports are made identical.  In general, the ports on the rear of the computer are part of the computer’s motherboard; these ports are rated as high power ports.  However, USB ports that are not part of the motherboard, and usually located on the front of the computer may not receive the same power rating.  

Often a supply company will provide a computer will a dozen or so USB ports, however, to save money will choose to use what is called a ‘front panel USB header’ which has a small piece of circuitry that acts as a hub.  In this case, the power to the front panel USB is reduced.  Furthermore, it is probable that these ports may not be USB 3 and if used for a high-demand peripheral will cause a disconnects to occur.

USB Hubs

Another strong recommendation is to use a high quality powered USB hub rather than connecting several USB cables directly to a computer.  A powered hub should be used rather than an unpowered hub as the former provides its own direct power source which is usually rated at a higher amperage than the computer’s USB port.  

The interface modules that form the core of my simulation system have one or two powered hubs installed to the module.  The interface cards are then connected by very short USB cables to the hub.  A high quality USB cable (with a NLN) then connects the interface module directly to the computer.

Windows Power Management Settings (PMS)

Not all USB peripherals will be required at all times.  Often a device will not need to communicate with the computer until something is required – such as a change to a radio frequency, an input from the control column or a key press to the MCP or CDU.

LEFT:  Screen grab of Windows 7 PMS (click to enlarge).

Windows has a nasty habit of ‘putting to sleep’ a USB connection that is not being used.  It does this to save power.  It is very imperative that you ensure that all power saving modes are turned off with regard to USB.  

To do this open your control panel and search for device manager.  Scroll down until you find Universal Serial Bus.  Under this tab you will find all the USB ports that you have attached to your computer.  Open each in turn and check the power management settings and ensure they are turned off.

Troubleshooting USB Disconnects

It is paramount to try and discover which peripheral is causing the disconnect.  The easiest way to troubleshoot a disconnect issue is to remove ALL the USB cables from the computer, and then one by one re-connect the cables to the allocated port and test.  Make sure you switch your computer off and on as you add each of the cables in turn.  Hopefully, you will eventually discover which cable/device is causing the issue.  The problem device will ‘ding dong’ if a secure connection is not possible.

If USB disconnects continue, try swapping the cables between different USB ports on the computer.  The disconnect issue maybe caused by the USB port/cable combination you are using.  As mentioned, not all USB ports have the same amount of power/amps available to them. 

Try to place peripherals that require minimal power, such as a mouse or keyboard, on lower-powered USB ports, and place more energy-requiring peripherals on powered hubs; perhaps only a few devices on the one hub.  Doing this will ensure that the hub will always have enough power (amps) to power the devices attached (cancelling out possible spikes as discussed above).  

Final Call

Hopefully, if you apply the above-mentioned suggestions USB disconnects will cease.  However, you will eventually reach the limit of USB capability, and at this point the use of Ethernet should be investigated to augment, or to replace the reliance on USB.

This article is but a primer.  I am not an IT expert and welcome any comments.

Tuesday
Sep202016

White Caps for Locking Toggle Switches on Overhead

It has taken a very long time to collect the assortment of OEM needed parts to complete the forward and aft overhead panels.  Finally the build is now in progress and it’s hoped completion will be towards the end of 2016.

LEFT:  Lower electrical panel showing reproduction latex-style cap (ELEC 2) and OEM Honeywell Switch Accessory 15PA90-6W (ELEC 1). Click to enlarge.   For those with keen eyes - yes that is a voice recorder in the lower panel - more to follow in later posts.  Of interest are the two different white caps (read main text). 

Earlier on, I had purchased several dozen Honeywell toggle switches, however, for whatever reason the white caps on the toggles were either missing or damaged.  I was intending to use reproduction white push-on caps (aka white condoms), but the caps failed to  fit snugly to the OEM switches, and their appearance was slightly different to the OEM version - the ends of the caps looked rather bulbous.

My next choice was to use latex caps that are used in automotive industry.  Once again, the appearance was slightly different and the automotive caps sported a small nipple at the end of each cap where they had been connected to the plastic retaining spur; I found the appearance of the nipple disconcerting.

Short of viable options, I purchased the OEM white caps from Honeywell which is the company that supplies Boeing.  If you carefully look at the above picture of the lower electrical panel (click image to enlarge picture), you will observe the nearest toggle switch has been fitted with an automotive style cap; the nipple and joining line is clearly visible.  The second toggle switch is fitted with the Honeywell white cap.

OEM White Cap Anatomy

The reproduction slip-on caps currently available on the market bear little resemblance to those made by Honeywell.

LEFT:   Honeywell Switch Accessory 15PA90-6W showing internal screw thread.  The thread screws onto the stem of the toggle switch (click to enlarge).

Most of the reproduction white caps are either a push-on condom style, or are a white-capped head attached to a slender hollow shaft.  The shaft then slides over the existing switch stem.

The Honeywell caps are not slip-on latex but a solidly-produced head with an internal aluminium thread.  The head is designed to be screwed directly to the shaft of the toggle switches.  Firmly attached to this head is the white latex cap. 

Mounting

To mount the white cap on a toggle, witch you must first gently heat the switch stem which will loosen the head of the toggle.  It then is an easy matter to screw off the head and replace it with the OEM head.

Measurements

Not everyone wants to utilise OEM parts.  As such I have provided the measurements of the switch head (courtesy of Honeywell) for those who wish to try their hand at making their own white caps.

As the overhead build continues, I will be posting more articles that showcase the overhead and the various panels and functionality.

Glossary

Honeywell – Avionics conglomerate that is heavily involved in the defence and aviation industries.
OEM – Original Equipment Manufacture (aka real aircraft part).

Saturday
Jul092016

RNAV Approaches

My previous post provided of overview on RNAV and RNP navigation.  This article will explain what a RNAV approach is, provide incite to the operational requirements for a RNAV approach, and discuss specifically the RNAV (RNP) approach.  I will also briefly discuss Approach Procedures and Vertical Guidance (APV) and RNP/ANP values.

The operational criteria for RNAV approaches is complicated and not easy to explain.  There are a number of RNAV approaches (often different for differing areas of the globe) and each is defined by the accuracy of the equipment used in the execution of the approach.  As such, this article is not all encompassing and I encourage you to read other technical articles available on this website and elsewhere.

LEFT:  RNAV 07 L - one of several RNAV approach charts for Los Angeles International Airport (LAX).  The most important aspect of an RNAV approach is that it is a Non-Precision Approach (NPA).  Note the word GPS is written in the title of the approach plate.

RNAV Approaches - Background Information

The Global Positioning System (GPS) is the brand name owned by the US military.  Initially all RNAV approaches were GPS orientated, however, in recent years this has been updated to include Global Navigation Satellite System (GNSS) applications.  GNSS applications are not owned (or controlled) by the US military.  As such, RNAV approach charts often use the word GPS/GNSS interchangeably.

What is an RNAV Approach

The definition for an RNAV approach is 'an instrument approach procedure that relies on the aircraft's area navigation equipment for navigational purposes'.  In other words, a RNAV approach is any non ILS instrument-style approach that does not require the use of terrestrial navigation aids such as VOR, NDB, DME, etc. 

Rather than obtain navigational information directly from  land-based navigational applications, the aids for the approach is obtained from a published route contained within the aircraft's Flight Management System (FMS) and accessible to the crew by the Control Display Unit (CDU).   The  approach broardly uses signals that are beamed from navigational satellites orbiting the Earth to determine the position of the aircraft in relation to the information presented from the database.

All Boeing Flight Management Systems (FMS) are RNAV compliant and have the ability to execute a RNAV approach.

A RNAV approach is classified as a Non-Precision Approach (NPA).

Non-Precision Approaches (NPA)

Before writing further, a very brief overview of Non-Precision Approaches is warranted.

There are three ways to execute a Non-Precision Approach.

(i)   IAN (integrated Approach Navigation).   IAN is a airline customer option and makes a NPA similar to an ILS approach.  A separate article has been written that addresses IAN.

(ii)   Vertical Speed (V/S).  V/S is not normally used when flying a RNAV approach that uses positional information from the aircraft's database.  However, V/S can be used for other Non-Precision Approaches.

(iii)   VNAV (Vertical Navigation).  VNAV is the preferred method to execute a NPA provided the approach is part of the FMS database. 

(iv)   LNAV (Lateral Navigation).  LNAV is mandatory for all approaches that are GPS/GNSS/RNP based.

RNAV Approach Types

The following are RNAV approaches:

(i)    RNAV (GPS) approach;

(ii)   RVAV (RNP) approach;

(iii)  RVAV (RNP) AR approach; and,

(iv)  RNAV (GNSS) approach.

The RNAV (GNSS) approach covers an additional three possible types of approach with each identified by a different minima.  The approaches are:

(i)    RNAV (GNSS) LNAV;

(ii)   APV Baro VNAV approach;

(iii)  APV SBAS approach.

It's easy to become confused by the various types of RNAV approaches, however, the actual flying of a RNAV approach does not differ greatly between each approach type.  The main difference lies in the level of accuracy applied to the approach and the methods used to enable this accuracy that determines what minima can be flown.

Approach Procedures with Vertical Guidance (APV)

APV refers to any approaches which are designed to provide vertical guidance to a Decision Height (DH).  An APV approach is charactertised by a constant descent flight path, a stable airspeed, and a stable rate of descent.  They rely upon Performance Based Navigation.  For an overview of PBN please refer to my earlier post.

The difference between the two APV approaches is that the APV Baro VNAV approach uses barometric altitude information and data from the FMS database to compute vertical guidance.  in contrast the APV SBAS approach uses satellite based augmentation systems, such as WAAS in the US and Canada and EGNOS in Europe, to determine lateral and vertical guidance. 

I will now discuss RNAV approaches in general and specifically, the RNAV (RNP) approach.

Flying The RNAV (GNSS) Approach

The RNAV (GNSS) approach is designed to be flown with the autopilot engaged.  The recommended roll mode is LNAV or HDG SEL.  The preferred method for pitch is VNAV.  If LNAV and VNAV are engaged, the aircraft will fly the lateral and vertical path as determined by the FMS database; the route is displayed in the LEGS page of the CDU.

The aircraft uses the FMS database to determine its lateral and vertical path.  As such, it is very important that the RAW data published in the navigational database is not altered by the flight crew.  Furthermore, the data presented in the CDU should be cross-checked to ensure it is identical to that presented on the RNAV approach chart.

As discussed previously, a RNAV (GNSS) approach is classified as a Non-Precision Approach.  Therefore, minima is at the Minimum Descent Altitude (MDA).   It is good airmanship to add +50 feet to the MDA to reduce the chance of descending through the MDA.  If a RNAV (RNP) or APV approach is being flown, the minima changes from a MDA to a Decision Height (DH). Whatever the requirement, the minima will be annotated on the approach chart.

RNAV (RNP) Approaches

RNP stands for Required Navigation Performance which means that specific navigational requirements must be met prior to and during the execution of the approach.

There are two types of RNAV (RNP) approaches:

(i)   RNAV (RNP) approach; and,

(ii)  RNAV (RNP) AR approach.

Both approaches are similar to a RNAV (GNSS) approach, however, a RNAV (RNP) approach, with the use of various sensors and equipment, achieves far greater accuracy through the use of Performance Based Navigation (PBN), and can therefore be flown to a DA rather than a MDA.

LEFT:  LIDO chart (Lufthansa Systems) depicting the RNAV (RNP) 01 approach into BNE-YBBN (Brisbane Australia).  Note that this chart has a Decision Altitude (DA) rather than a Minimum Descent Altitude (MDA).  Chart courtesy of NaviGraph (click to enlarge).

RNP/ANP - How It Works

A RNAV (RNP) approach uses RNP/ANP which is the comparison between the Required Navigation Position (RNP) and the Actual Navigation Position (ANP).   If the data becomes erroneous such as from the loss of a GPS signal, the ANP value will exceed the RNP value.    The use of RNP/ANP enables greater accuracy in determining the position of the aircraft.

RNP/ANP Alerts

If an anomaly occurs between RNP and ANP one of two RNP alerts will be generated:

(i)    VERIFY POSITION - displayed in the scratchpad of the CDU; or,

(ii)   UNABLE REQD NAV PERF-RNP - displayed on the Navigation Display (ND) on the EFIS Map. 

It should be noted that different versions of CDU software will generate different alerts.  This is because newer software takes into account advances in PBN.  To determine which software version is in use, press IDENT from the CDU main page (lsk1L) and check OP PROGRAM.  ProSim-Ar uses U10-8a.

The variables for RNP/ANP can be viewed in the CDU in the POS REF page (page 3), the LEGS page when a route is active, and also on the Navigation Display (ND).

A second type of RNP approach is the RNAV (RNP) AR approach.  This approach enables you to have curved flight paths into airports surrounded by terrain and other obstacles. Hence why special aircraft and aircrew authorization (AR) is required for these approaches.  Other than AR and additional flight crew training, the approach is identical to the RNAV (RNP) approach.

Advantages of RNAV and RNAV (RNP) Approaches

The benefit of using a RNAV approach over a traditional step-down approach is that the aircraft can maintain a constant angle (Continuous Descent Final Approach (CDFA)) until reaching minima.  This has positive benefits to fuel savings, engine life, passenger comfort, situational awareness, and also lowers flight crew stress (no step-downs to be followed).   Additionally, it also minimises Flight Into Terrain (CFIT) events.

A further advantage is that the minimas for a RNAV approach are more flexible than those published for a standard Non-Precision Approach not using RNAV.  RNAV approach charts have differing descent minima depending upon the type of RNAV approach.

For example, if flying a RNAV (RNP) approach the MDA is replaced by a DH.  This enables a lower altitude to be flown prior to a mandatory go-around if the runway threshold is not in sight.  The reason that a RNAV (RNP) approach has a DH rather than a MDA (and its resulting lower altitude constraint) is the far greater accuracy achieved through the use of Performance Based Navigation (PBN).

Approach To Land Using RNAV

The following addresses the basics of what is required to execute a RNAV approach.

Prior to beginning the approach, the crew must brief the approach and complete needed preparations. These include, but are not limited to, the following items, which may be included in an approach review card or other type of briefing aid:

(i)     Equipment that must be operational prior to starting the approach;

(ii)    Selection of the approach procedure, normally without modifications from the aircraft's navigation database;

(iii)    For airplanes without Navigation Performance Scales (NPS), one pilot should have the map display in the 10 NM or less range.  This is to monitor path tracking during the final approach Segment;

(iv)    For airplanes with NPS, the map display range may be set as the crew desires;

(v)     TERR display selected on at least the Captain or First Officer side of the ND;

(vi)     The RNP progress page displayed on the CDU (as needed). For airplanes equipped with NPS, selection of the CDU page is at the crew's discretion;

(vii)    The navigation radios must be set according to the type of approach; and,

(viii)   If a RNAV (RNP) approach is being executed, ensure that there is no UNABLE REQD NAV PERF - RNP alert displayed before starting the approach.

In addition to the above, airline Standard Operational Procedures (SOPs) may require additional caveats, such as range rings to be set up on the ND to provide enhanced situational awareness (CDU FIX page).

Select the approach procedure from the arrivals page of the CDU and cross-check this data with that published on the approach chart, especially the altitude constraints and the Glide Path (GP).

If the Initial Approach Fix (IAF) has an ‘at or above’ altitude restriction, it may be changed to an ‘at’ altitude restriction using the same altitude. Speed modifications are allowed as long as the maximum published speed is not exceeded. No other lateral or vertical modifications should be made at or after the IAF.

Beginning the Approach

Select LNAV no later than the IAF. If on radar vectors, select LNAV when established on an intercept heading to the final approach course. VNAV PTH must be engaged and annotated in the Flight Mode Annunciator (FMA) for all segments that contain a Glide Path (GP) angle, as shown on the LEGS page, and must be selected no later than the Final Approach Fix (FAF) or published glide path intercept point.

Speed Intervention (INTV), if desired, can be used prior to the GP.  Good airmanship directs that the next lower altitude constraint is dialled into the MCP altitude window as the aircraft passes through the previous constraint.  When 300 feet below the Missed Approach Altitude (MAA) re-set the altitude window in the MCP to the MAA.

Final Approach using RNAV

When initiating descent on the final approach path (the GP), select landing flaps, slow to final approach speed, and do the landing checklist. Speed limits published on the approach chart must be complied with to enable adequate bank angle margins. 

At minima, or as directed by the airline's SOP, the autopilot followed by the autothrottle is disconnected and a visual 'hands on' approach made to the runway threshold.

Once established on final approach, a RNAV approach is flown like any other approach.

Final Call

The Boeing aircraft is capable of several types of Non-Precision Approaches, however, outside the use of ILS and possibly IAN, the RNAV approach enables an accurate glide path to be followed to minima.  While it's true that the differing types of RNAV approaches can be confusing due to their close relationship, the approach is straightforward to fly.

This short article is but a primer to understanding an RNAV approach.  Further information can be found in the FCTM, FCOM and airlines SOP.

In my next article we will look some of the possible 'gotchas' that can occur when using VNAV.

References

Flight Crew Training Manual (FCTM), Flight Crew Operations Manual (FCOM) and airline SOP.

Acronyms and Glossary

Annunciator – Often called a korry, it is a light that illuminates when a specific condition is met
ANP - Actual Navigation Position
APV - Approach Procedure with Vertical Guidance
CFIT - Continuous Flight Into Terrain
DME – Distance Measuring Equipment
FAF - Final Approach Fix
FCOM - Flight Crew Operations Manual (Boeing)
FCTM - Flight Crew Training Manual (Boeing)
FMA - Flight Mode Annunciator
FMC – Flight Management Computer
FMS – Flight Management System
Gotcha - An unfavorable feature of a product or item that has not been fully disclosed or is not obvious.
GPS – Global Positioning System
GNSS - Global Navigation Satellite System
IAF - Initial Approach Fix
Korry - See annunciator
LNAV – Lateral Navigation
LPV - Localizer Performance with Vertical Guidance
MAA - Missed Approach Altitude
MCP – Mode Control Panel
ND – Navigation Display
NPA - Non Precision Approach
PBN - Performance Based Navigation
RNAV – Area Navigation
RNP - Required Navigation Performance
SOP - Airline Standard Operational Procedure.  A manual that provides additional information to the FCTM and FCOM
SBAS - Satellite based augmentation systems.  In the U.S. called WAAS and Europe called EGNOS.
VNAV – Vertical Navigation
VNAV PTH – Vertical Navigation Path
VNAV SPD – Vertical Navigation Speed
VOR – VHF Omni Directional Radio Range

Thursday
Jun232016

RNAV, RNP, LNAV and VNAV Operations - Overview 

New flyers to the Boeing 737NG often become confused understanding the various terminology used with modern on-board navigational systems.

Although the concepts are easy to understand, the inter-relationship between systems can become blurred when the various types of approaches and departures are incorporated into the navigational system.

LEFT:  Collins Mode Control Panel (MCP) showing illuminated LNAV annunciation (click to enlarge).

This post will not provide an in-depth review of these systems; such a review would be lengthy, confusing and counterproductive to a new virtual flyer.  Rather, this post will be a ‘grass-roots’ introduction to the concept of RNAV, RNP, LNAV and VNAV.  I will also touch on the concept of Performance Based Navigation (PBN).

In the Beginning there was RNAV  

RNAV is is an acronym for Area Navigation (aRea NAVigation). 

Prior to complex computers, pilots were required to use established on-the-ground navigational aids and would fly directly over the navaid.  Such a navaid may be a VOR, NDB or similar device.  Flying over the various navaids was to ensure that the flight was on the correct route.  Often this entailed a zigzag course as navaids could not be perfectly aligned with each other in a straight line - airport to airport. 

When computers entered the aviation world it became possible for the computer to 'create' an imaginary navigation aid based on a direction and distance from a ground-based navaid.  Therefore, a straight line could be virtually drawn from your origin to destination and several waypoints could be generated along this line.   The waypoints were calculated by the computer based on ground VORs and positioned in such a way to ensure more or less straight-line navigation.

In essence, RNAV can be loosely defined as any 'straight line' navigation method similar to GPS that allows the aircraft to fly on any desired path within the coverage of referenced NAVAIDS.

Required Navigation Performance (RNP) and Performance Based Navigation (PBN)

Simply explained, Required Navigation Performance (RNP) is a term that encompasses the practical application of advanced RNAV concepts using Global Navigation Satellite Systems (GNSS).

However, there is a slight difference between RNP and RNAV although the principles of both systems are very similar. 

RNAV airspace generally mandates a certain level of equipment and assumes you have a 95% chance of keeping to a stated level of navigation accuracy.  On the other hand, RNP is performance based and requires a level of on-board performance monitoring and alerting.  This concept is called Performance Based Navigation (PBN).

RNAV and RNP both state a 0.95 probability of staying within 1 nm of course.  But RNP (through PBN) will let you know when the probability of you staying within 2 nm of that position goes below 0.99999.  In essence, RNP and PBN enable an aircraft to fly through airspace with a higher degree of positional accuracy for a consistently greater period of time. 

To achieve this level of accuracy a selection of navigation sensors and equipment is used to meet the performance requirements.  A further enhancement of this concept is the use of RNP/ANP (Required Navigation Performance and Actual Navigation Performance.  Advanced RNAV concepts use this comparative analysis to determine the level or error between the required navigation (the expected path of the aircraft) and the actual navigation (what path the aircraft is flying.)  This information is then displayed to the flight crew.

LNAV and VNAV

LNAV and VNAV are parts of the Flight Guidance System, and are acronyms for Lateral Navigation and Vertical Navigation'.  Both these functions form part of the automation package that the B737NG is fitted with.

LNAV is the route you fly over the ground. The plane may be using VORs, GPS, DME, or any combination of the above. It's all transparent to the pilot, as the route specified in the clearance and flight plan is loaded into the Flight Management System (FMS), of which the Flight Management Computer (FMC) is the interface.

The route shows up as a magenta line on the Navigation Display (ND), and as long as the LNAV mode on the Mode Control Panel (MCP) is engaged and the autopilot activated, the aircraft will follow that line across the ground. LNAV however, does not tell the plane what altitude to fly, VNAV does this.

VNAV is where the specified altitudes at particular waypoints are entered into the FMS, and the computer determines the best way to accomplish what you want.  The inputs from VNAV are followed whenever the autopilot is engaged (assuming VNAV is also engaged).  

The flight crew can, if necessary alter the VNAV constraints by changing the descent speed and the altitude that the aircraft will cross a particular waypoint, and the computer will re-calculate where to bring the throttles to idle thrust and begin the descent, to allow the aircraft to cross the waypoint, usually in the most economical manner.

VNAV will also function in climb and take into account airspeed restrictions at various altitudes and will fly the aircraft at the desired power setting and angle (angle of attack) to achieve the speed (and efficiency) desired.

There is not a fast rule to whether a flight crew will fly with LNAV and VNAV engaged or not; however, with LNAV and VNAV engaged and the autopilot not engaged, LNAV and VNAV will send their signals to the Flight Director (F/D) allowing the crew to follow the F/D cue display and hand fly the aircraft the way the autopilot would if it were engaged.

Reliance on MCP Annunciators

LNAV and VNAV have dedicated annunciators located on the Mode Control Panel (MCP).  These annunciators illuminate to indicate whether  a particular mode is engaged. 

LEFT:  Flight Mode Annunciator (FMA) showing LNAV and VNAV Path Mode engaged.  The Flight Director provides a visual cue to the attitude of the aircraft while the speed is controlled by the the FMC.  CMD indicates that the autopilot is engaged (ProSim737 avionics suite).

However, reliance on the MCP annunciators to inform you of a mode’s status is not recommended.  Rather, the Flight Mode Annunciator (FMA) which forms part of the upper area of the Primary Flight Display (PFD) should be used to determine which modes are engaged.  Using the FMA will eliminate any confusion to whether VNAV (or any other function) is engaged or not.

This post explains the Flight Mode Annunciators (FMA) in more detail.

Summary

In summary, RNAV is a method of area navigation that was derived from the use of VOR, NDBs and other navaids.  RNP through it use of GNSS systems has enabled Area Navigation to evolve to include LNAV and VNAV which are sub-systems of the Flight Guidance System -  LNAV is the course across the ground, and VNAV is the flight path vertically. 

Historically, navigation has been achieved successfully by other methods, however, the computer can almost always do things better, smoother and a little easier – this translates to less workload on a flight crew.  

In my next post, we will discuss RNAV approaches and how they relate to what has been discussed above.

References

The information for this article came from an online reference for real-world pilots.

Acronyms and Glossary

Annunciator – Often called a korry, it is a light that illuminates when a specific condition is met
DME – Distance Measuring Equipment
FMA - Flight Mode Annunciator
FMC – Flight Management Computer
FMS – Flight Management System
GPS – Global Positioning System
GNSS - Global Navigation Satellite System
LNAV – Lateral Navigation
MCP – Mode Control Panel
ND – Navigation Display
NPA - Non Precision Approach
PBN - Performance-based Navigation
RNAV – Area Navigation
RNP - Required Navigation Performance
VNAV – Vertical Navigation
VNAV PTH – Vertical Navigation Path
VNAV SPD – Vertical Navigation Speed
VOR – VHF Omni Directional Radio Range