Flight Tutorial

Addendum
For The

iFly Jets: The 747-400

2 November 2015
http://www.iflysimsoft.com/

Contents

Introduction

Virtual Address Space (VAS)

iFly 747-400 Configuration Tool VAS Reduction Options

Fluctuating Frame Rate (fps)

Setting Up FSX and Other Information

System Simulation Refinements

REMAINDER OF PAGE BLANK

Introduction

The purpose of this addendum is to provide users with up to date information important to the operation of
the iFly Jets: The 747-400 aircraft simulation. Users should continue to study the basic tutorial, which leads
them through the steps required to simulate a scheduled airline flight.

The separate Aircraft Operating Manual (AOM) covers all onboard systems in great detail and should be
studied to gain a complete understanding of the simulation.

THIS TUTORIAL ADENDUM IS ONLY FOR THE IFLY JETS: THE 747-400, AN ADD-ON FOR
MICROSOFT FLIGHT SIMULATOR. IT IS STRICTLY FORBIDDEN TO APPLY ANY INSTRUCTIONS
CONTAINED IN THIS TUTORIAL TO ANY SITUATION WHICH INVOLVES REAL AVIATION.

REMAINDER OF PAGE BLANK

The iFly Developer Team

Virtual Address Space (VAS)

The Team is seeing an increasing number of posts at flight sim internet sites and support forums, including
our own , on the subject of OOMs. The majority of these errors occur in FSX and P3D, but FS9 can also be
involved.
So what is an OOM and how does it happen? First, we need to have a brief look at Windows memory
management. What follows is from https://msdn.microsoft.com/enus/library/windows/desktop/aa366779(v=vs.85).aspx There are more details there if you wish to immerse
yourself in details.
Windows Memory Management
Each 32-bit process (FS9, FSX or P3D) on 64-bit Microsoft Windows has its own virtual address space that
enables addressing up to 4 gigabytes of memory. All threads of a process can access its virtual address
space. However, threads cannot access memory that belongs to another process, which protects a process
from being corrupted by another process.
A virtual address does not represent the actual physical location of an object in memory; instead, the system
maintains a page table for each process, which is an internal data structure used to translate virtual
addresses into their corresponding physical addresses. Each time a thread references an address, the
system translates the virtual address to a physical address.
We recommend using Windows 7 64-bit as it provides the full 4GB block of VAS to FSX and P3D. 32-bit
Windows provides only a maximum of 2GB of VAS. 32-bit Windows VAS can be increased to 3GB by using
the 3GB switch. See this post for more information:
http://ifly.flight1.net/forums/forum_posts.asp?TID=838&title=accessing-more-memory
Nonetheless, the result of the tweak is 1GB less VAS than with 64-bit Windows. Therefore, OOMs and OS
errors will be more likely.
An item to remember for the future: a 64-bit process on 64-bit Windows has a virtual address space of 8
terabytes.
Another great source of information on this topic is Mark Russinovichs blog:
http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
Implications for FS
Everything running as a part of Flight Simulator consumes part of the 4GB allocated to the process. So all
of that complex scenery, AI aircraft, clouds, high definition textures, etc., etc. along with complex aircraft
models and the manner in which Flight Simulator and Windows handle memory can combine to exceed
4GB. Thats when you see the infamous Windows has run out of memory and will shut down error
message.
So whats to do? There are many discussions around the internet on this topic. One of the more relevant
may be seen at:
https://kostasfsworld.wordpress.com/fsx-oom-and-addon-vas-usage/
For P3D, http://www.robainscough.com/Prepar3D_Settings_2.html provides different settings to test. P3D
users should be aware that the simulation seems to be more sensitive to factors which cause OOMs.

The iFly Developer Team

iFly 747-400 Configuration Tool VAS Reduction Options

The iFly 747-400 Service Pack 1 provides a tool for users to reduce the amount of VAS which the simulation
uses:

Note the Panel and model mode (FSX and P3D only) selections just above the list of installed aircraft. In
the screenshot, Only 2D Panels no Virtual Cockpit is selected, which will minimize the amount of VAS used
by the simulation. Note this reduction applies only to the VAS used by the iFly 747-400. The other settings
are self-explanatory and users who experience OOMs should test to see which setting produces the best
result on their pc.
Do not forget to click Update to make your selection effective.

REMAINDER OF PAGE BLANK

The iFly Developer Team

A couple of usage notes:

1. If FSX or FSX SE is set to load the aircraft with the VC, you will see missing landing gear with the
iFly 747-400 Configuration tool set to use only 2D panels. The dummp panel needs to be called to
show the gear. The solution is to switch the FSX or FSX SE Default cockpit view to 2D
instrument panel. Also, remember to set the 2 D panel transparency to 0%.

The FSX or FSX SE Default cockpit view must be the same as that selected in the iFly
Configuration tool. 2D+VC selected in the Configuration Tool does not require any change in FSX
or FSX - SE.
P3D does not have an option for a default 2-D panel. If you select 2D only in the iFly Configuration
Tool and do not see a panel and/or landing gear when the 747-400 is loaded in P3D, cycle the
view using the S key and the 2D panel and gear will display.

2. There may be an issue when changing view modes: you may be unable to get back to the 2D
panel if you cycle the view using the S or A keyboard shortcuts. If this happens, right click and
select Cockpit or VC depending on what you have setup in FSX, FSX SE or P3D and the
Configuration Tool. Or change to a Left or Right view using the HAT or keyboard.

REMAINDER OF PAGE BLANK

The iFly Developer Team

Fluctuating Frame Rate (fps)

There is discussion in the support forums about fluctuating fame rate in FS and questions about why that
happens.
The fps counter in FS jumps and does not give a steady count because the iFly gauges use multithreading.
When the iFly gauge threads update the data, FS may not update at the same time. The fps display comes
from FS.
In laymans terms this means that because we running a multithreaded process and the FS main process is
single threaded, the FS frame rate counter shows a variation. FYI, FSX/P3D can run the ground scenery
texture process in multiple threads.
Also, FSX Box and FSX - SE may freeze when the pc has a cpu using more than 4 cores. The FSX core
tries to load balance threads, which may lead to a system freeze. One of the ways for users to counteract
these freezes is to restrict the number of cores used by FSX and FSX - SE to 4 or less by using the
AffinityMask setting in the FSX or FSX SE configuration file.
So fluctuating frame rates are not a fault with the aircraft per se, but it is more that the FS core cannot
process the multithreaded data it gets from the iFly gauges into a steady fps display.
If you run something like FRAPS or NVida ShadowPlay and look at the overlay frame counter you will get
the proper stable counter value.
Finally, the Team believes that the fps display variation is more noticeable when the user tries to run the sim
with too many addons with high fps locked or unlocked fps. The system tries to keep up with the demands
but texture loading like clouds, terrain, AI and external add ons are too demanding for the locked fps
required and the pc starts lagging. There is only one solution to this and it requires the user to balance FS
settings and addons. The Team also suggests locking FS frame rates at a level where smoothness is
displayed and then ignoring the fps display.

REMAINDER OF PAGE BLANK

The iFly Developer Team

Setting Up FSX and Other Information

Much has been said about how to set up and tune FSX. And an improperly set up and tuned FSX can
cause even the most powerful home FMC to grind to a halt.
The Team suggests that all users set up FSX as suggested by NickN. Please see this wide-ranging
discussion on the topic:
http://www.simforums.com/forums/the-fsx-FMC-system-the-bible-by-nickn_topic46211.html
Battery Power
Many flight simmers have experienced the FS feature which causes aircraft batteries to lose charge after a
rather short period of time. The only solution to the issue is to use a registered version of FSUIPC and set
the option to Extend Battery Life to 0 (indefinitely).
Eye Point
Some have noticed that the eye point in FS seems to move. Another FS feature is that the world is flat or
cylindrical in FS9 and pseudo round with some parts flat in FSX and P3D. This causes the eye point to
move depending on the LAT/LON. iFly has no control over this but we do make a best effort to position
the eye point correctly. The following screenshots (each with the same eye point) illustrate this feature:

DIAP

EGLL

REMAINDER OF PAGE BLANK

The iFly Developer Team

System Simulation Refinements

There are some refinements to the modeling of 747-400 systems, two of which are particularly important for
users to recognize in order to fully enjoy the simulation: Flap Speed Logic and VNAV Logic.
1. FLAP Speed Logic
The PFD command airspeed bug (CAB) follows commands by the FMC when in VNAV PTH. In
other words, it follows what is programmed in the FMC.
In the descent and while above the speed transition point (240/10000) the CAB will usually point to
ECON descent speed. The speed below 10000ft is 240KTS and, as the descent continues, the
CAB will move to the next speed constraint or a speed/alt restriction at a waypoint as required by
an approach procedure or entered by the flight crew.
If FLAPS are inadvertently selected when the airspeed is above the FLAP placard speed, the CAB
will move to the placard speed less 5KTS, if this speed is less than the next speed constraint.
So if the aircraft is descending at 240KTS with the CAB on 240 and FLAP20 is selected, the CAB
will go from 240 to 225 (5KTS less than the flap 20 limit of 230KTS). This is assuming that no other
deceleration is immediately necessary to meet the next constraint.
If the CAB is driven below minimum maneuver speed (top of the PFD Speed Tape Amber
Band) the A/T will increase thrust to maintain speed above the amber band. However, the speed
bug will not move from where it was below the amber band. This speed protection is not
dependent on where the CAB is pointing and the CAB will not move.
So why is this important? Lets say the aircraft is past the approach speed restriction point with FLAPS up.
The real world is modelled and the CAB will drop to, for example an approach speed of 179KT, only a few
knots above the Red Bricks. The airspeed will now decay from 240kts, flight crew entered DES speed
restriction or the waypoint speed restriction. However, A/T airspeed protection logic will keep the airspeed
5KTS above the top of the Amber Band (Min Maneuver Speed). As FLAPS are selected the Amber Band is
driven down until airspeed reaches the CAB, in this example 179KTS, at which point the airspeed holds. Its
also important to recognize what is happening if FLAPS are inadvertently applied, during cruise for example.
2. VNAV LOGIC
It is important to understand that in normal operation in the descent when in VNAV PTH the CAB is
set according to what is programmed in the FMC. The programmed speed will usually be ECON
SPD, or a flight crew entered descent speed, when above the speed transition altitude and 240KTS
when below transition altitude.
The FMC then looks at either the next large font airspeed on the LEGS page, and at what
waypoint it occurs (example: EMRAG 210/3000A), or a SPD RESTR entered by the crew on the
VNAV DESCENT (LSK 5L) page, such as 230/4000. The FMC also looks at the deceleration
requirements and, if the two constraints are close to each other, then the system will drive the CAB
to the speed of the constraint requiring the greatest deceleration.
For example, if flight crew entered a speed restriction of 230/5000 and there is also a following
waypoint restriction of 180/4000A, the FMC would command a speed of 240KTS until the aircraft

The iFly Developer Team

needs to decelerate to meet the 230/5000 restriction. But looking ahead the FMC sees that the
180/4000A is very close, so instead of going to 230KTS the CAB would probably be driven straight
to 180KTS with perhaps a very momentary pause at 230KTS.
When the aircraft is in the DESCENT in VNAV PTH mode and the MCP speed knob is pushed the
window will open at the FMC programmed descent speed (What is showing on the FMC VNAV
DES page) and the CAB will remain at or move to that speed. The pitch mode will change to VNAV
SPD as the elevators are now controlling the speed set in the MCP window and are no longer
attempting to maintain the calculated VNAV Path.
If the knob is pressed when the aircraft is below the speed transition of 240/10000, the window will
open at 240KTS, and the CAB will move to (or remain at) 240KTS.
IMPORTANT: The ONLY time that the aircraft will remain in VNAV PTH when the MCP speed
window is opened is when the aircraft is in the CRUISE phase of flight or On Approach mode
(meaning that it meets the conditions of On Approach mode).
The FMC transitions to On Approach mode, which is not annunciated, when one of the following
conditions are met:
1. A VFR approach is created and the aircraft has sequenced the FAXXX, or the aircraft is enroute
to a direct-to or intercept-to the RWYYY waypoint and is within 25 nm of the runway threshold
2. A published instrument approach is selected and incorporated in the active flight plan and the
aircraft is two (2) nautical miles from the first waypoint in the APPROACH. IMPORTANT: This
waypoint may be confirmed when the Approach (not the Approach transition) is selected as it is
shown at on the CDU at LSK 6R. This is the first approach waypoint in the airac. If there is
disagreement with a chart, be certain to use the airac defined waypoint, as it will be where the
On Approach mode procedure will start.
3. Air traffic control redirects the aircraft to a course direct to the Final Approach Fix (FAF) and the
aircraft is on that course and is two (2) nautical miles from the FAF.
The FMC transitions out of On Approach when any of the following occurs:
1. TOGA is selected
2. the aircraft lands
3. the aircraft flies beyond the last waypoint in the approach (missed approach waypoint or
runway) and the VNAV page title changes from "ACT xxxxxx DES" to "ACT END OF DES"
When the FMC is in On Approach mode:
the IAS/MACH window on the MCP can be opened and a command speed can be set while
VNAV remains in the VNAV PTH descent; VNAV commands the set speed
the MCP altitude can be set above the aircraft altitude to be ready for a missed approach.
VNAV continues to command a descent when the MCP altitude setting is at least 300 feet
above the current aircraft altitude.
VNAV remains in VNAV PTH and continues to follow the descent path unless the aircraft
accelerates to within 5 knots of the current flap placard speed and the aircraft is more than
150 feet above the path. In this case, VNAV PTH changes to VNAV SPD.

The iFly Developer Team

10

If the aircraft does not meet the On Approach conditions, the vertical mode will revert to VNAV SPD
and then later automatically change to VNAV PTH when the ON Approach conditions are met.
This automatic change to VNAV PTH can come as a surprise for the crew! When On Approach
conditions are met, if the speed window is closed the CAB will move to the speed commanded by
the FMC. This speed could be higher or lower than what was set in the MCP speed window, and
may cause the A/T to apply a very large amount of thrust, thereby killing your fuel economy and
most likely upsetting the folks in the back.
So the art of using speed intervene in the descent is to set a speed in the MCP window which is
similar to what the FMC has programmed for the current situation that speed may be seen on the
CDU DES and/or LEGS pages. This avoids the large amount of thrust applied or removed
scenario. When in the later stages of a descent, and just prior to flap extension, real world crews
use speed intervene to give more control until the aircraft meets the On Approach mode conditions.
In addition to the conditions listed above, another method to determine if the aircraft is in the On
Approach mode is the check the RNP value on PAGE 2 of the CDU POS REF page. When the
RNP value is 0.30 the aircraft is in the On Approach mode (assuming of course some other value
was not manually entered!).
How does all this information apply to the iFly 747-400? The following screenshot shows an approach to
LIRF RWY16C:

The red square (added for emphasis) around the green donut on the ND indicates where the aircraft will
reach the DECEL point for approach speed. If the MCP SPD window remains closed at the decel point, the
FMC will drive the CAB down to a speed which is into the amber band and just above the Red Bricks. It is
also below FLAP UP maneuver speed.
The green speed reduction donut may appear on the ND before the first waypoint in the approach. In that
case, open the SPD window 1 NM prior to reaching the SPD reduction point. If above the transition altitude,
the FMC will set the SPD to the programmed descent speed. Set SPD after that as required. If the aircraft
is below the transition altitude, the FMC will set 240KTS, or whatever speed restriction was entered by the
crew or any CDU-specified waypoint speed restriction. Then set SPD and FLAP as required.
If the MCP Speed window is left closed, the airspeed will decay until the A/T commands a large application
of thrust in order to keep airspeed protected. Then the A/T will command airspeed to follow the Min

The iFly Developer Team

11

Maneuver Band down as flaps are selected, until the airspeed to which the CAB points is reached. If APP
was armed the G/S will be intercepted and the SPD window will open on its own. If the aircraft is left to
descend in VNAV PTH with the SPD window closed, the CAB will finally go to VREF+ Wind Correction.

The following screenshot shows the aircraft just prior to the decel position. Note that crew pressed the
SPEED BUTTON to open the SPD WINDOW, and the FMC set airspeed to 240KTS. The vertical mode on
the FMA changed from VNAV PTH to VNAV SPD:

The yellow circle (also added to the ND for emphasis) indicates where the FMC will enter On Approach
mode. Note the 2NM circle around MIKSO, the first approach waypoint which will sequence. Remember,
the FMC will enter On Approach mode 2NM prior to the first approach waypoint, and the CDU FIX function
was used to draw the circle as a reminder to the crew.
This screenshot show how the crew is managing SPD prior to reaching the On Approach mode position.
The SPD WINDOW is now set at 221KTS, which is the just below the PFD SPD TAPE FLAP UP speed. It
also anticipates the 215KT FMC specified speed at MIKSO, the first waypoint on the approach. Note that
although the FMA Mode is VNAV SPD, descent path deviation is still being displayed on the ND.

REMAINDER OF PAGE BLANK

The iFly Developer Team

12

This screenshot depicts the situation just after the FMC enters On Approach mode, 2NM prior to MIKSO.
Look at the FMA. The FMC has automatically changed back to VNAV PTH while the SPD WINDOW
remains open. The crew has set the SPD to 215KTS. The FAF, F116C, is 4.9NM ahead.

Finally, this screenshot shows the crew has set 186KTS as the SPD prior to reaching F116C, the FAF. The
LOC is captured and the G/S is alive. From this point on, what remains is to ARM APP, get the GEAR down,
set VRef+Wind Correction and lower FLAP on schedule. Set ALT as appropriate for the MISSED
APPROACH.

If there is no SPD reduction prior to the first approach waypoint, just draw the green circle around that
waypoint and proceed as outlined above.
VNAV descent now follows the correct logic when the aircraft deviates from the path. VNAV PTH will
automatically change to VNAV SPD if the aircraft deviates more than 500FT from the path. VNAV PTH will
automatically annunciate when the aircraft is within 400FT of the path.
3. Miscellaneous:
A. With no RWY/APP loaded, the CDU might now display DASHES (------) on the right hand side of
the LEGS page for waypoints which are after a FMC calculated non-displayed descent point.
Under this condition, there will not be a T/D or E/D drawn on the magenta line. Once the RWY/APP
is loaded, the T/D will be recalculated and displayed on the ND magenta track. Also, all waypoints

The iFly Developer Team

13

will be populated with SPD/ALT as required. Crews may estimate that the VIRTUAL T/D will be
between the last waypoint on the CDU LEGS page that has a CRZ FL and the first waypoint which
shows dashes on the right hand side of that page.
B. The CDU will not accept SPD/ only restrictions. The 747-400 FMC requires all SPD restrictions to
have an associated ALT. The entry format is XXX/XXXXX
C. Provided that the crew uses the FMC recommended BEST SPD for a hold, entry, tracking and exit
from the hold is now improved.

The 747-400 is much more hands on than the newer Boeing transport category aircraft during the
DESCENT and APPROACH phases of flight. Users of the simulation should carefully note the interaction of
FLAP application, airspeed and VNAV logic. Some retraining will most likely be needed in order to fly the
aircraft correctly. The Tutorial flight description now incorporates these changes.

REMAINDER OF PAGE BLANK

The iFly Developer Team

14