Twin Otter Extended: Inside Out

An Almost Aviation guide

by
Mark Hurst
Copyright © 2016 Mark Hurst. All rights reserved.

Mark Hurst has asserted his moral right to be recognised as the author of this work in
accordance with the Copyright, Designs and Patents Act of 1988.

www.almostaviation.com
Prologue: My Twin Otter Cockpit

About two years ago I decided to build a home cockpit. I’d tinkered with FSX for about five years
and I went through many combinations of third-party panels for controlling the radios and other things,
but none of it was that great. Although I had a good set of flight controls and a tried and tested three-
screen display my flying still lacked a certain satisfaction and I wished for something that didn’t need
me to keep the mouse within arm’s length and fly with a keyboard on my lap.

This all remained an idle fantasy until I acquired Aerosoft’s Twin Otter Extended. I recall buying this
without knowing too much about it but I was excited by how detailed the simulation appeared to be. It
looked as good as Aerosoft’s PBY Catalina and on first impression it modelled enough systems to
make it both interesting to fly and challenging enough to want to keep flying it. Crucially, I also
discovered there was a way to hook up the buttons and switches to hardware panels and that someone
had already done a lot of the work. This was the spark I needed to begin making real plans.

Over the next four or five months I designed a set of panels for the Twin Otter that preserved most of
the functionality but changed the layouts to fit into a simplified three-dimensional cockpit layout. The
result is reminiscent of the Twin Otter Extended virtual cockpit but while some panels are clearly
identifiable, the layouts are shuffled around. The main reason for this was that my panels were to be
input-only – with the exception of the Garmin GNS530, I wouldn’t have any gauges on the panels and
hence I would need to rely on using the virtual cockpit for the instrument displays.
This turned into a much bigger project than I expected and the sheer scale was, in retrospect, quite a
surprise. The final cockpit has nine panels with about 179 switches, all of which make things happen
in the Twin Otter Extended, although not all of which are equally useful. Some of the controls have no
real function but work like they should – the windscreen wipers, for example, can be on or off, slow
or fast and need to be parked when you switch them off. Each of these switches is there and works,
even though the windscreen wipers don’t actually do anything useful!
Along the way I discovered this was a great way to learn about the simulation. Although I had
discovered Gunter Steiner’s LINDA library for the Twin Otter Extended, I soon realised it was far
from complete and to create the extra software I needed required me to look closely at each set of
Twin Otter functions in turn and then to figure out how to hook them up. This was mostly
straightforward, but I was assisted in the more tricky steps by very responsive technical support from
Aerosoft.

Once I had completed my cockpit, I then had to learn to fly the Twin Otter. It makes such a difference
to have real buttons and switches for everything and to have them laid out in a logical way. It
completely frees you up to start learning about the aircraft and systems, rather than learning cryptic
FSX key combinations, and then about how to put everything together and actually fly the aircraft.
Here is a trivial example. You may or may not know that the Bendix King ADF radio panel has a
countdown timer function built in. This is faithfully simulated in the Aerosoft model but it is so fiddly
to operate with the mouse it’s unlikely I would ever use it that way. But with buttons and a real dual
concentric knob on the panel, this is no longer just a simulation – it is, literally, the real thing.
By now I have realised that a cockpit such as this is never complete and it’s probably true to say I
have spent more time tinkering with my cockpit than I have actually flying it. Nevertheless, my
tinkering has generally been connected to refining the operation of some function or other and I have
continued to learn a lot – about the Twin Otter and about Aerosoft’s implementation of it. The result is
a reservoir of hard-won information and that makes up the bulk of what I have written about in this
book.

The Twin Otter Extended is a fine simulation that has enough depth to be challenging but without
being overwhelming. It is easy enough to jump in and fly, but it is difficult to fly well. To learn to fly
it well requires patience, persistence and the willingness to explore the nuances of the aircraft and its
systems. Having a hardware cockpit makes this a much more exciting prospect but it isn’t a
requirement. Indeed, on reflection I think it was the process of building the cockpit that really drove
me to a better understanding of the simulation and this is rewarding in its own right. You can, of
course, dig deeper without building anything and the knowledge you will gain can bring you just as
much satisfaction.

If you do want to build, there is some sense in limiting the scope by creating a ‘minimum equipment
list’ (MEL) for a hardware cockpit to fly the aircraft with minimal recourse to the mouse and
keyboard. I will resist the temptation to do this in any detail because it will depend on the kind of
flying you prefer. For example, if you have no interest in flying on instruments and you don’t use Air
Traffic Control, you may as well leave out all of the radios. For me, a great starting point would be a
complete panel for the GNS530, the autopilot and altitude alerter, with everything else left to mouse
clicks in the virtual cockpit.

Hardware panel or not, there is no doubt that to get the most out of the simulation you need to put in a
bit of time to explore it. I hope you will find the things I have written about inspire you to pursue
explorations of your own.
A note on source code listings

Some chapters make reference to source code that you might optionally want to use in your own Twin
Otter experiments. Reproducing source code on Kindle devices is a wearisome task because there are
so many variations of target devices. I have done my best to format the listings for legibility and they
are designed to be displayed with a mono-spaced font in 70 columns.

If you have difficulty reading the code you can try setting your device to landscape mode to get as
much width as possible. However, the best option is to use the Kindle for PC viewer (or presumably
its equivalent if you have a Mac) and run it full-screen. This will also allow you to cut and paste the
text, if somewhat laboriously.

I will make the source code available at the Almost Aviation forums but I have included it here
because I cannot guarantee that the forum will continue to exist indefinitely. You ought to be able to
reconstruct the code from the Kindle book if you need to. You can also get things from me by email if
need be.

Mark Hurst
January 2016
markh@keysound.com
Table of contents
Prologue: My Twin Otter Cockpit
A note on source code listings
1. The DHC-6 Twin Otter
2. The electrical system
Starting and ignition
The buses
3. All about propellers
Fully-featherable props
Beta system and reverse thrust
Engine failure
Reality check
Water operations
Prop governor over-speed
4. The fuel system
Fuel tanks
Controls
Endurance and fuel management
Fuel pumps
Cross-feeding fuel
Wing tanks
Stretching the fuel
5. Hand-flying the Twin Otter
Standard settings
Power affects pitch
Experiment 1 – fly by hand
Experiment 2 – watch the autopilot
Horizon lines
Experiment 3 – piston vs. jet vs. turboprop
6. The autopilot
Flight director
Autopilot
Altitude alerter
Autopilot hacking
7. Icing conditions and the Twin Otter
Ice formation in FSX
Ice formation in the Twin Otter
Icing experiments
Anti-icing vs. de-icing
De-icing measures
Engine icing
Recovery from engine failure
Going further with structural icing
Tools to explore icing
8. Bits and pieces
Flight data recorder
Head-up display
Acknowledgements
Appendix A: Sample HUDCA configuration file
Appendix B: HUDCA LINDA functions
Appendix C: LINDA functions for enhanced icing
Appendix D: Installing the icev10 gauge
Appendix E: icev10 gauge updated XML
1. The DHC-6 Twin Otter
The de Havilland name has distinctly British connotations but in the late 1920s de Havilland
established an outpost in Canada, initially to assemble DH.60 Moths shipped from England. During
the war de Havilland Canada built over 1100 examples of perhaps the most iconic de Havilland
aircraft of all, the DH.98 Mosquito, but the end of the war marked a turning point when it began
working on its own designs, initially the DHC-1 Chipmunk trainer and the DHC-2 Beaver bush plane.

The Beaver was a rugged aerial truck with a superb STOL performance but its payload was modest
and in 1951 DHC addressed this with the introduction of the DHC-3 Otter, originally named the King
Beaver. The Otter doubled the Beaver’s payload capability while retaining the same impressive
STOL performance from the same runways. DHC had long mooted the idea of a light twin with the
same basic high-wing layout as the Otter but on a smaller aircraft the drawback was always the heavy
engines. The designs floundered for a decade or more while the company pursued other priorities,
including the DHC-4 Caribou and its turboprop evolution, the DHC-5 Buffalo.

Meanwhile DHC continued to push the STOL envelope and even experimented with a jet engine in the
fuselage of an otherwise-conventional Otter to provide reverse thrust in flight. Although this
experimental Otter retained its original Pratt & Whitney R-1340 piston engine for much of its life, it
is noteworthy for our present discussion because its final evolution was the removal of that giant
radial engine and its replacement with two Pratt & Whitney PT6A turboprops mounted on the wings.
For the last two years of its useful life, the X-Otter looked very much like the DHC-6 we know today.

And yet, the DHC-6 was not an evolution of the X-Otter, it came from a new initiative intended to
woo the military as had the Otter and Caribou. In 1963 DHC began the DHC-6, a modest effort to
capitalise on the Otter’s success by mating twin PT6As with a DHC-3 airframe. It was a shoestring
project at the outset and purists argued vehemently against the many engineering compromises
inherent in tweaking a legacy design. The military, as it turned out, showed little interest and yet the
Twin Otter went on to tap an unexpected market with the emerging commuter airlines, most of which
operated this short-field bush plane from long, hard runways.

* * *

The DHC-6 Twin Otter was the last of de Havilland Canada’s bush planes and production ended
shortly after DHC was acquired by Boeing in 1988. The company’s new direction was building
regional airliners which, while still nominally STOL aircraft, were a breed apart from the ‘animal’
planes of the company’s heyday. It seemed like a definitive ending as much of the specialist tooling
was reported destroyed by Boeing.

But that wasn’t quite that. In 2006 Viking Air of British Columbia acquired the Original Type
Certificates and remaining tooling for the entire DHC-1 to DHC-7 lineup – that’s all the ‘animals’ and
the Dash 7. Since 1983 Viking had been the exclusive spare-parts manufacturer for the Beaver, Otter
and Turbo Otter and had later supplied structural sheet metal parts and assemblies for the Twin Otter.
If anyone was going to build a new Twin Otter, it was going to be Viking. And build them it did. In
2010 Viking began production of an all-new Twin Otter, the 400 Series, and production continues to
this day.

Curiously enough, the Viking 400 Series isn’t the Twin Otter’s only legacy. When China bought three
Twin Otters from DHC it insisted on having a team of inspectors observe aircraft’s construction from
start to finish. Not long after that it also acquired a boat-load of PT6A turboprop engines from Pratt &
Whitney Canada and in 1984, an aircraft suspiciously reminiscent of the DHC-6 appeared on the
Chinese radar. This aircraft, the Harbin Y-12 IV, achieved FAA certification in 2006. The Y-12 sells
for half the $7m ticket price of the Twin Otter 400 and for the Western market is designated the ‘Twin
Panda’.
2. The electrical system
The Twin Otter Extended has a custom electrical system which borrows very little from the one built
into FSX, although there are a couple of crossovers. The DC Master switch, for example, is standard
and turns the FSX DC Master on as well. I know this because my Elite radios and my Saitek radios
come on when I switch on the Twin Otter’s DC Master. We also have an External/Battery switch to
select between internal and external power. We will look at the innards of the electrical system in
more detail later, but first I want to talk about the Starter panel.

The Twin Otter has turboprop engines and at the heart of a turboprop engine there is a gas turbine – a
jet engine, essentially. We start this by spinning up the gas generator turbine, pumping fuel into it and
then introducing a spark to ignite it. Once the engine is lit it’s self-sustaining, so we can turn off the
starter motor and also the igniter. In fact the starter motor is also the generator, so once we switch it
over, the engine is turning the generator instead of vice-versa. This generates electrical power that we
can use. More on that later too.
Starting and ignition

To achieve all that we have a switch on the Start panel – two switches in fact, as this is a double-
header switch, one for the left hand starter motor and one for the right-hand starter motor.

We also have a few other switches, the use of which isn’t immediately obvious. Although the engine
is self-sustaining once it’s lit, there are circumstances under which it can go out, such as intake icing
or a major disruption to the airflow into the engine. This is called a flame-out and obviously it’s
something we want to avoid. In circumstances where this is more likely to happen we can arrange to
fire the igniters continuously, so if we get a flame-out the engine should re-light again before it has a
chance to spin down.

That is the purpose of the Manual ignition switch, sometimes referred to as ‘continuous’ ignition,
which makes a little more sense. This is a two-position switch (under the red guard) and under
normal circumstances we leave it set to ‘Normal’. Under circumstances where we might expect to
encounter disrupted airflow through the engines, particularly with low power settings, we can flip
that switch to ‘Manual’ for continuous ignition in case of a flame-out. The conditions under which we
would do that would be outlined in the aircraft flight manual, but typically it will be situations such as
descending on low power through heavy turbulence.

We also have two other switches labelled ‘Engine Igniter’ left and right, ‘No. 1’ or Both. I am
assuming that each engine combustion chamber actually has two igniters and that usually we run both
in tandem, presumably for more reliability. By flipping the switches we have an option to use only
one of those igniters. I don’t really know what the purpose of that is, and as far as I have been able to
determine this function isn’t simulated in the Twin Otter Extended. (If you know differently, I would
like to hear about it!)

In spite of my best efforts I have been unable to induce a flame-out in the Twin Otter engines by
messing up the airflow – whether flying through turbulence, deliberately throwing it into a spin or
generally trying to induce aerodynamic chaos, the engines will resolutely keep on running. Continuous
ignition, however, is simulated and you can check this out by switching off a fuel pump and waiting
for the engine to flame out. If you have ignition set to Manual, you will hear the igniters firing
continuously as the engine flames out and switching the fuel pump back on immediately will cause it
to re-light. It won’t do this if the ignition is set to Normal. Incidentally, you can (and quite often do)
get a flame-out in the Twin Otter Extended if you fly in icing conditions, so the Manual ignition setting
is a useful precaution in that case.

To go through the startup sequence, make sure the fuel levers are on the OFF position, turn on the fuel
pumps and then press and hold one of the starter switches (it is conventional to start the right engine
first). You will hear the ‘tick-tick-tick‘ sound of the igniters firing. For a successful start, monitor the
RPM of the Gas Generator turbine and only move the fuel lever to the ON position after it passes
12%, otherwise you will likely get an uncontrolled engine fire.

Gas generator gauges.

If you do get an engine fire you can put this out by following the instructions on the FIRE panel in the
cockpit, although it will render the engine useless and there is no way to repair it except to re-load
the aircraft. This is one of those areas that is only partially simulated, as the Twin Otter Extended
does not have persistence between flights in the aircraft model. That said, engine fires in flight are
also simulated and being able to extinguish the fire and continue on one engine is a useful part of the
simulation.

Once we’ve introduced fuel, the engine lights and you can release the Starter switch. If this doesn’t
happen, make sure you have remembered to switch on the fuel pump. (And if you haven’t, make sure
you remember to move the fuel lever back to cutoff before trying again, or you will get an engine
fire!)
The buses

Let’s have a closer look at the electrical system. We have two independent 28V DC buses, the left one
powered by the left engine’s generator and the right one powered by the right engine’s generator. We
also have a third DC bus, which is the Battery and External Power bus, and this is connected to the
left main DC bus only. That may sound a bit lop-sided but under normal operational conditions the
buses are tied together, so if the left generator fails, both buses are powered by the right generator and
if the right generator fails, both buses are powered by the left generator. If both generators fail,
everything is powered by the battery. Of course if the battery fails as well (or runs down), that is a
problem!

The bus system (simplified).

We have two gauges for monitoring the DC system. The one on the left is a voltmeter, which is
connected to the left main DC bus. This will show the condition of the battery if the generators are
off, or the voltage available from the generator or generators if they are switched on (and the engines
are running). This gauge reads up to 30 volts. If we are running on the battery we should expect to see
up to 28 volts and if the generators are on we should see something between 28 and 30 volts.

The other gauge, on the right, is a load meter and there is a switch beside it which is normally in the
centre position. If it is in the centre position the meter is indicating the load on the battery. If the
generators are running (as they are here), the battery load should read zero all the time, although if the
battery is depleted it will be showing a charging current. Incidentally, I think this gauge actually reads
backwards – if it is charging the battery we should see a positive deflection, while if we’re running
on battery alone the gauge should deflect to the left, showing a discharge. However, if you turn the
generators off you will see that the gauge actually deflects out to the right:

Battery load (load meter indications are reversed).

If we ignore the reversal the gauge works as we expect. If we move the switch to the right, the meter
indicates the load on the right generator and if you move it to the left, you’ll be seeing the load on the
left generator.
 Right generator load.

I had assumed that if the buses are tied together the generators would show the same load, but that
doesn’t appear to be the case and there usually seems to be a slight discrepancy. I have read that there
should be no more than 20 amps difference between the left and right generator loads, which suggests
that there is a logical reason why they might differ.

That load meter scale, by the way, is calibrated differently according to whether we are monitoring
the battery load or the generator load. It is marked from -1 to +1 and each division represents 10
amps if we are monitoring the battery load. If we are looking at the generators, each division – that’s
each 0.1 on this scale, between 0 and 1, represents 20 amps. Hence full-scale deflection (+ or -) is
100 amps for the battery load or 200 amps for the generator load.

Some equipment in the Twin Otter is powered by AC, so we also have two AC buses, one running at
115V AC and the other at 26V AC. These are powered by two independent inverters, one connected
to the left main DC bus and one connected to the right main DC bus. The inverters don’t run at the
same time, so one is active and the other is available as a standby. An implication of this is that under
certain conditions it is possible if we lose one of the generators to also lose AC power, at least
momentarily, and we have to manually select the other inverter to restore AC power. Incidentally, the
Twin Otter 400 Series has dispensed with AC power altogether, so everything runs off DC. (There
are a lot of other differences too – the 400 Series is 21st Century aircraft.)

The circumstances that would lead to use losing AC power are fairly contrived and would require the
Bus Tie switch to be set to ‘Open’. This is something that we would only do under a fault condition
but it is quite instructive to think about the consequences of untying the buses on all the electrics.
Incidentally, although dual bus systems are common, in modern designs they tend to be redundant
rather than complementary, in which case the buses are usually untied by default. This is safer
because a failure on one bus can’t take out equipment on the other bus with it.

With an asymmetric bus system like the Twin Otter’s, some equipment is powered by one bus and
some equipment is powered by the other, so if we untie the buses and we have a generator failure we
will lose some systems as well. There is generally a logic to which systems are powered by which
bus – for example, you will find that the indicator light for a right generator failure is powered by the
left DC bus, while the indicator light for a left generator failure is powered by the right DC bus,
which makes a lot of sense if you think it through.

I’m not going to go through a whole list of which equipment is powered by each bus in any detail –
you can explore that for yourself if you want to, by untying the buses, switching the External/Battery
switch to Off so the battery is disconnected, and then systematically switching off the right and left
generators and observing what shuts down. But as an example, if we come back to what I was saying
about the AC equipment, if we open the Bus Tie switch, set Inverter No.2 and then switch off the right
hand generator, that should take out all the AC equipment. If you try this you’ll see a lot of things in
the virtual cockpit go off and we also get a specific ‘400 cycle’ warning light on the annunciator
panel to say that the AC buses are offline. Then if we switch the Inverter switch to No.1, that warning
light goes out and we get all the equipment back. This is the sort of experiment you can do for
yourself if you want to explore things in more detail.
 Indicator shows loss of AC power.

By and large it all seems to work logically, although my own experiments did turn up one anomaly.
With the Bus Tie switch open and the Battery/External switch set to Off, if we switch off the left
generator we get warning lights for the fore and aft primary boost pumps, which is to be expected, but
then the engines stop – which is not to be expected! What should happen is when the main boost
pumps go offline, the standby pumps should start. That doesn’t happen, which suggests that the main
and standby boost pumps are powered by the same bus – and that doesn’t seem logical. [In fact this
turned out to be a bug which Aerosoft fixed when I pointed it out.]

These systems do seem to be faithfully modelled in the Aerosoft Twin Otter Extended but you have to
wonder how relevant that is for day to day flying. There are no failure modes implemented other than
engine failures and icing, so in practice none of our tap-dancing with generators going offline and
untying the buses and so on really has any relevance. Because it is all custom-implemented, the FSX
failure modes don’t have any logical effect either. Nevertheless, we can in some sense simulate
failure modes by switching things on and off as we have been doing here. Let’s have a brief look at an
example of that.

We can simulate a failure of both the generators just by switching them off. We’ll start with a fully-
charged battery – if we look at the battery load meter it’s showing zero, which means it’s not
charging, which in turn means it is fully-charged. If we switch off the generators see about 28V
showing in the voltmeter, which is what we’d expect. Now the load meter indicates a discharge,
which is going to start to run the battery down.
 Battery discharging.

To make things worse we can add in some equipment that we wouldn’t normally have switched on,
just to prove a point. If we switch on some heavy-drawing equipment such as the windshield heater,
intake anti-ice and prop de-ice, we’ll pretty much get a full-scale deflection (100 amps) of the load
meter. If we leave thing like this for a while, eventually we see the battery voltage starting to decline.

Major load, and the battery voltage is going down..

We have another gauge that is relevant here, which is a battery temperature gauge down on the lower
console. We also see that start to rise steadily and eventually we’ll get a warning light if the
temperature gets too high. That’s all this gauge does – there are no apparent ill effects of the battery
temperature getting too high.

At this point if we switch a generator back on we’ll see two noteworthy things on the gauges. First,
the voltmeter immediately rises to near 30V (it shows the generator voltage, remember), while the
load meter swings dramatically from one side of the scale to the other. This shows that we have
removed the load from the battery but now we also see a substantial charging current of about 20
amps. If we let some time go by the battery will charge back up.

Battery is charging. (Remember, the deflection is reversed.)

If instead of switching the generators back on we just let things run, when the battery voltage falls
below 20V everything shuts down. That includes the engines, by the way, which should not happen.
(More on this when we look at the fuel systems.) At this point everything is off and we can’t get it
back – with the exception of the panel lights and cabin lights. Presumably these are powered by a
separate battery, as they also respond when the Battery switch and/or the DC Master switch is off.
3. All about propellers
The first thing we need to appreciate about this aeroplane is that it has constant speed propellers.
Because everything else essentially follows from that it’s probably worth spending a bit of time
reviewing what it means. As you probably know, the blades of a propeller have an aerofoil section
just like a wing, and hence they generate lift as they spin. Because the propeller is mounted vertically
we generally call that thrust instead of lift. But there’s immediately a problem with a fixed-pitch
propeller, such as the one we’d have on a Cessna 172, let’s say. If we imagine the aircraft standing
still and the propeller spinning through the air, the angle of attack of the propeller blade is just the
angle that the blade is offset from the vertical.

The problem with this is that as soon as the aircraft starts moving through the air, the net airflow now
has another component.
The relative wind, instead of being just in the vertical direction is now inclined backwards to the
direction of flight and we can see that the angle of attack – the angle at which the blade meets the
relative wind – diminishes. As the forward speed increases, at some point the angle of attack will be
zero. At this point the propeller blade will be producing no thrust at all. (Just a quick note on
terminology here. I will use the word ‘pitch’ in its colloquial sense, or synonymously with ‘blade
angle’. Technically the propeller pitch is the distance the prop moves forward through still air in one
revolution.)

From this we can infer that the prop’s effectiveness changes with speed. Indeed a fixed-pitch
propeller has only one ideal angle of attack and everything else is a compromise. This, of course, is
why it is useful to have a propeller where we can vary the angle of the blades during flight. Having
such a propeller means that we can increase the angle as the speed increases, to maintain the same
angle of attack – that’s angle of attack of the propeller blades to the relative wind, remember, not the
angle of attack of the wing. And because the angle of attack varies in proportion with the RPM we
generally set a given RPM from the cockpit, using the prop lever, and this is maintained by a device
in the propeller hub. This is called the governor and it works by increasing or decreasing the blade
angle if the prop speeds up or slows down, thereby maintaining a constant RPM.
 Propeller RPM levers (these would usually be in the same positions).

That’s a fairly simplistic account of how a constant-speed propeller works. In practice we vary the
prop pitch by setting various RPMs for different phases of flight. We know the ideal settings because
we read them from tables in the flight manual. The Aerosoft Twin Otter Extended manual has a
collection of such tables in an appendix.

The Twin Otter Extended uses the built-in FSX propeller system so it inherits all the advantages and
disadvantages of that system, but it is by and large a passable simulation. We can observe the effects
of different prop RPM settings by monitoring the fuel flow gauges and a genuine effect on fuel
economy is one of the reasons to pay attention to the prop settings. You will recall that I said the
governor maintains the RPM by varying the blade angle and of course this has other consequences.
The engine has to work harder to spin the prop when the blade angle is higher, or coarser, and the
limiting case of this is if we were to feather the props, which means that the they are positioned edge-
on to the oncoming air or, in other words, they’re flat on to the direction of rotation. This is why we
see the torque gauge rise as we select a coarser pitch. When making power adjustments it is
conventional to increase the RPM setting before adding power and conversely, to reduce the power
before selecting coarser, or higher, blade angle. This helps us avoid over-torqueing the engines.

In adjusting the propeller pitch in flight we are maintaining a balance between five different
parameters – the RPM, the torque being generated, the speed of the aircraft, the fuel flow and the
aircraft attitude. Some of these we can influence directly – the attitude, by using the flight controls, the
propeller RPM, which we can select with the prop lever and the torque, which we can select directly
by moving the power lever. Changes in the other values are secondary consequences of changing
these ones.
Fully-featherable props

The next thing to say about the propellers in this aircraft is that they are fully featherable. This is
important in the real aircraft, particularly if we get an engine failure because the prop windmills in
the airflow and keeps the engine turning over, creating a significant amount of drag. These are
turboprop engines and they are of a split-shaft or free turbine design, so the amount of drag created
certainly isn’t as much as we’d get on a piston-engined aircraft, but it’s still a lot. We can feather the
prop by pulling the prop lever all the way back.

A feathered propeller.

It is instructive to walk through a couple of experiments with the aircraft to observe what happens
when we manipulate the engine and propeller controls. We can see the results by watching the RPM
and the torque gauges. If you want to follow along, pick an engine and keep an eye on the gauges. (The
gauge below prop RPM is the gas generator RPM but we’re not too interested in that for now.) If we
spool the engine up a little way we see the torque gauge and the prop RPM rising. The prop RPM
gauge doesn’t show the RPM directly, it shows a percentage of the maximum RPM.

Propeller RPM gauges.

When the engines are idling we should have the prop levers all the way forwards. With the levers in
this position we get 100% on the RPM gauge once the torque rises to about 20psi. Moving the power
lever to idle now causes the prop RPM to drop until it stabilises at around 60%, and we’ll see
between 5% and 10% on the torque. The precise indicated idle torque will depend on things like the
outside air temperature and the density altitude.

The green arc on the RPM gauge is the governed range, so when we’re out of that green arc (as we
are with idle torque), the prop RPM is out of the direct control of the governor – the engine basically
isn’t producing enough torque to spin the props up to the selected RPM. If we feather that prop, by
moving the prop lever all the way back, we see that the RPM falls and the torque rises to about 40psi,
with the RPM settling at about 20%. In this configuration the engine is not producing any thrust at all
(or at least negligible thrust) because the feathered blades are more or less flat on to the direction of
rotation. If we now un-feather the prop, the opposite happens. The torque falls, as the blades are now
much easier to turn against the air resistance.

If we spin the engine back up and also watch the fuel flow, we see that it also varies with torque and
RPM.
 Right engine fuel flow gauge.

Starting as before with the power set to about 20psi and props fully fine, we’re starting with 100%
RPM. If we now select a lower RPM by pulling the prop lever back part of the way we’ll see that the
torque increases, while the RPM decreases. At the same time the fuel flow goes down. You may have
expected the fuel flow to go up because the torque is going up, but in fact we’re selecting a more
efficient blade angle. This is just a glimpse of the interactions of that complicated web of variables
we are manipulating when managing the engines.
Beta system and reverse thrust

Something else that is characteristic of turboprop engines is that the propeller blade angle can be
moved beyond the feather position and into reverse pitch. This means the engine will be producing
reverse thrust, in other words pushing forwards against the direction of travel. This is most useful for
slowing down once we’ve landed, although it can also be used to aid manoeuvring on the ground,
including taxiing backwards. Reverse thrust is a valuable asset for operating on short runways but it
also aids safer braking when the runway is wet or otherwise slippery.

To talk about reverse thrust in any detail we need to look at the beta system. ‘Beta’ is often used
interchangeably with reverse thrust but that is not technically correct. The beta range corresponds to
those situations where the prop blade angle is between +17 degrees and -15 degrees. The blade angle
when the engines are at idle is +11 degrees, so we can see that the beta range covers part of the
forward thrust range as well. This all gets fantastically complicated so I’m just going to say enough
about the details to put the Aerosoft Twin Otter’s features in perspective.

The beta range is for ground operations and it manages the props when the torque is low enough that
the propeller governor is inoperative. The blade angle is controlled by oil being pumped into a
chamber in the propeller hub and in the so-called ‘alpha’ range, which covers air operations, the
pressure of that oil is controlled directly by the position of the prop lever. In the beta range, the oil
pressure in the hub is controlled by a complicated tap-dance between three different oil valves – the
main prop governor pilot valve, a thing called the beta reverse valve and yet another valve called the
beta backup valve.

Leaving aside the details, the net effect is that for blade angles below +17 degrees the propeller blade
angle responds directly to the power lever and this allows faster changes of thrust for taxiing and
manoeuvring on the ground. Pulling the power levers back through the gate cycles the blade angles
through flat and into reverse pitch and then progressively as we pull them further back, begins
dumping more fuel into the engines so we get progressively increasing reverse thrust.
The finer details of this are not really relevant to the Twin Otter Extended. This is a theme I will
come back to from time to time because it addresses what is and isn’t simulated in this package. The
beta backup system is, unsurprisingly, a fail-safe system that is supposed to prevent us going into
reverse if the beta system fails – for example if the beta reverse valve gets stuck open. But there’s
nothing you can do in the Aerosoft Twin Otter to make that system fail. This means that in practice the
beta backup system is an irrelevance and it really isn’t modelled at all. That said, there is one thing
you can do to invoke the beta backup system and that’s to flip the beta range test switch.
 Test panel.

With the test switch in the On position, pulling the levers into reverse shows the beta range indicator
lights flashing. In the real system those flashing lights are direct feedback showing the blade angle
cycling backwards and forwards around a limit of +9 degrees as the beta backup valve opens and
closes. In the simulator that’s really meaningless and there’s nothing actually happening under there. It
lets us go through the checklist and perform the test in an authentic manner, but this is purely ritual.
The test, of course, will never fail.
 The beta range indicators flash to show the beta backup system operating.

You will find a detailed description of the beta system in the Aerosoft Twin Otter manual but really
it’s interesting background reading material and not relevant to flying the simulated Twin Otter.
Engine failure

Losing an engine is a contingency we always need to plan ahead for and in short takeoff and landing
(STOL) operations the margins are a lot tighter. The Twin Otter was designed as a STOL aircraft
from the outset and as a twin, we have additional factors to pay attention to. If we lose an engine on
takeoff in the Twin Otter we’re going to need to do something immediately to keep the aircraft flying.
We’re going to get a drastic reduction in speed and in climb performance but we’re also going to get a
drastic yaw and a secondary roll towards the failed engine because of the asymmetric thrust.

Unique to twins is a value called the Minimum Controllable Airspeed (Vmc), which is the slowest
speed we can fly with maximum asymmetric thrust and still have enough rudder and aileron assertion
to counter the asymmetry. (This is the speed marked with a blue line on the ASI.) There are a couple
of factors that come into play here, the first of which is the rated power of the engines. The Twin Otter
300 Series has PT6A-27 engines but de-rated to 620hp. What that means is we have to treat these
engines as if they produced a maximum of 620hp even though they are capable of producing 680hp.
The reason for this is that if we were taking off with the engines outputting more than 620hp and we
lost an engine, we would be more or less guaranteed to lose control of the aircraft and crash.

The other crucial factor we need to consider is the need to feather the propeller if we have an engine
failure – particularly on takeoff, which is why we have an auto-feather system. Not all Twin Otters
have the auto-feather system, but this one does. The auto-feather is important when we’re doing STOL
operations, particularly because it allows us to operate close to or even below Vmc, the minimum
controllable airspeed (or formally Vmca, the minimum controllable airspeed while airborne).

The auto-feather system is simple to operate. All we need to do is before we take off to activate the
system by pushing a button on the control panel. An indicator on the button illuminates to confirm that
the system is selected. To arm the system we just go ahead and proceed with the takeoff. This is
because the system auto-arms according to the Gas Generator RPM. We can see when it arms because
we get an additional indicator on the auto-feather selector button.
 Auto-feather system selected and armed.

Formally, the auto-feather system arms when the Gas Generator RPM (Ng) rises above 86%, although
in the Twin Otter Extended it happens at a lower percentage. I think that’s because in the original
release that was faithfully modelled but a lot of people couldn’t hold the aircraft on the brakes while
performing the auto-feather test, which is something we’ll look at in a moment. Aerosoft released a
patch to fix that and the result is it arms the system at a lower Ng.

Under normal operations, once that system is armed it will detect if either of the engines falls below
20psi on the torque for at least two seconds while the power lever remains advanced – a condition
which is then deemed to be an engine failure. If the system detects that condition it will do two things
– it will automatically feather the propeller on the engine that has lost torque, and then it will inhibit
the auto-feather system on the other engine. The purpose of this is to get the failed engine’s propeller
feathered as early as possible in the emergency without manual intervention, which leaves the pilots
free to do other things they need to be doing to keep the aircraft flying.

We have a system for testing the auto-feather system on the ground, which I will run through now. We
start by flipping on the auto-feather test switch and select the auto-feather system to on. Then we arm
the system by advancing the props until we see the arm indicator. As I do it here I see the system arm
when the torque gauges show about 30%. The prop RPM gauges, as we saw earlier, should be
reading 100%. To simulate an engine failure we simply retard one of the levers to idle, at which point
we should see a couple of things. First, the prop feathers, which we can see by the prop RPM
dropping to 20%. The torque gauge shows some oscillation and then rises to about 15psi as we saw
in our earlier feathering experiments, which obviously is because this is really a healthy engine. The
second thing we see is that that arm indicator on the auto-feather selector button goes out, denoting
that the system will not auto-feather the other prop.

The last part of the test sequence is to check that the feathered prop un-feathers when we retard the
other power lever to idle. As before, we should see the propeller RPM on that engine come back up
to its idle position of about 60% and the torque fall to its idle value. This process reassures us that
the auto-feather system is going to work if we need it. In real life, the only thing the auto-feather test
does is to inhibit a micro-switch on each power lever that detects when the lever is retarded, so we
can be assured that it is a valid test of the system.

Critical engine
Incidentally, in real life it makes a difference which engine fails because of another prop effect. A
rotating propeller is inherently asymmetric and when the relative wind is inclined to the propeller
disc – when the aircraft is pitched up or down – the thrust axis of the propeller is displaced inboard
or outboard due to an effect called p-factor. In this aircraft, as in many twin-engined aircraft, the
propellers rotate in the same direction and so the overall effect is asymmetric.

The detail of that for the Twin Otter is that because the props rotate clockwise, p-factor displaces the
thrust axes out towards the right. A consequence of this is that losing the left engine gives a
significantly bigger yaw than if we lose the right engine. The left engine is therefore referred to as the
critical engine. The recorded Vmca presumes the worst-case scenario, which is losing this engine.
That’s the theory, but my experiments suggest this is not modelled in FSX. You will find p-factor on
the Realism menu, but as far as I can tell that only applies to single-engine aircraft.

STOL operations

It is also worth giving a little bit of attention to STOL operations. We can’t just push the power levers
to the stops for the takeoff, as you may be in the habit of doing in a piston-engined aircraft. As we saw
earlier, in the 300 Series we would risk catastrophe in the event of an engine failure but we would
also be putting extra stress on the airframe if we fly beyond the rated power. Of course we also risk
exceeding the engine torque and temperature limits.

With the Twin Otter Extended package we also get the 100 Series and for more of a challenge it is
worth flying the 100 because it has the original PT6A-20 engines with only 550hp. These engines are
not de-rated and we have nothing in reserve. The other thing about de-rated engines is that if we’re
taking off from a higher strip or on a hot day (the density altitude is higher, in other words) the engines
can continue to make the full rated power in spite of the thinner air. With the 100 Series, performance
will decrease with density altitude just as it will in a normally-aspirated (non-turbocharged) piston
engine.

Coming back to the point, we’re not supposed to just ram the power levers to the stops and take off.
What we are supposed to do is read the takeoff torque from a chart in the flight manual, which factors
in the outside air temperature and pressure altitude. There is also a circular slide rule you can buy for
the Twin Otter that does the same job, but in the simulator we can do the obvious thing which is to
advance the power levers until we get to either the torque redline or the T5 redline, or shortly before.
The real flight manual says specifically that we’re not to do this, and that we have to calculate the
takeoff torque to the conditions. In the simulator it works just fine.

If we do go into the red, we will get an engine failure sooner or later whether we are over-torquing or
over-temping the engines. It’s not instantaneous, but to demonstrate it we can push the power levers
all the way home and leave the engines to overheat. Another option is to dial in a high power setting
and then feather the props, which will push the torque off the scale. If we leave it like that, the engines
will eventually explode. As far as I can tell there is no persistent damage modelling of either over-
torque or over-temp conditions, in the sense that if we stop over-stressing the engine before it catches
fire, the engine will continue to function with no ill-effects.
Reality check

I just want to make some comments on some of the things I’ve been talking about in this chapter with
respect to the propellers and particularly to the feathering behaviour. You will find that feathering is
not fully implemented in FSX and therefore in the Twin Otter Extended. When we make changes to the
propeller pitch this does affect the pulling power and so all the comments I made about efficiency and
about fuel flow are generally relevant. In other words, it has an impact on the performance of the
aircraft. The limit case is when we feather the propeller we have no thrust at all, but there is no drag
effect.

If you want to do your own experiments with this you can go up to altitude and experiment with
feathering or un-feathering while the engines are at idle. You will find that there are no differential
drag effects. There are some transient effects while the prop is feathering or un-feathering but to this
behaviour doesn’t appear to work logically and it is only transient. Once the prop is feathered or un-
feathered, the net drag does not seem to be any different whether a prop is feathered or un-feathered.
There also seems to be no drag effect connected to selecting different pitches for the prop.

These observations render a lot of what we’ve talked about in this chapter irrelevant. In particular,
the need to feather a propeller if we have an engine failure simply goes away. This, in turn, renders
the entire auto-feather system redundant.

Again, we have something that appears to be simulated in a lot of detail; we can go through the
motions of doing the tests for the auto-feather, we can go through the motions of selecting the auto-
feather on and then off during the takeoff but there is really no point.
Water operations

The last thing we’re going to cover on the props is something specific to the float version, which is
the use of start locks (also called blade latches). The problem with water operations is, normally
when we shut the engines down the props feather when the oil drains out of the governor in the prop
hub, even if we haven’t selected the levers to feather manually. That’s a problem when we come to
start up because as the props un-feather they go through coarse pitch all the way to fully fine and they
generate thrust in the process. Unless we’re moored to something, thrust when we’re on the water
means that the aircraft is going to move. It’s worse than that because we start one engine at a time so
we’re not even going to move in a straight line. We get thrust on shutdown too because the prop goes
through coarse pitch as it gradually feathers.

To get around that problem some aircraft have start locks fitted. With start locks, when we shut down
the aircraft the props go slightly into reverse pitch and then are engaged by locking pins. This latches
the prop blades beyond the fully-fine position (effectively, with a flat pitch) and the props don’t
feather even when the oil drains from the hubs. This means we don’t get any residual thrust as the
props move into the feather, and because the props remain in the flat position we don’t get any
forward thrust either on startup.

We don’t need any special control to engage the start locks, we just leave the prop levers in the fully
forward position when shutting down the engine. To shut down we just pull the fuel cut-off levers and
the engines start to spin down. The prop RPM gauges fall to zero, although in practice they would
wind down slowly as the un-feathered props take a long time to spin down in the absence of air
resistance. The other difference is that the beta mode caution lights come on, which tells us that the
start locks are engaged.

To try this out we can shut down each engine in turn and then re-start while floating un-tethered close
to a fixed reference point such as a dockside or a boat. We are looking for an absence of thrust on
startup or shutdown, but also for differences when the blades are latched or un-latched during
shutdown. There is one other thing to note, which is that the start locks will still be engaged after we
start the engines. If we advance the power levers without releasing them, nothing will happen because
the blades are essentially edge-on to the air. (In fact we get a silly sound effect that presumes we have
forgotten to release the locks!) To release the start locks we need to move the power levers slightly
into and then out of reverse. We can see the effect of this because the beta indication warning lights go
out.

In practice these thrust effects are rather small and are quite difficult to demonstrate convincingly, at
least on the water. The residual thrust effects do exist, but ironically the only effective way to
demonstrate them is to park the amphibious Twin Otter on a hard surface with the brakes off and try
all the same tests again. Although Aerosoft has modelled the system faithfully, given that the startup
thrust effects are fairly negligible, once again you have to question whether there is any real point in
using the start locks.
Prop governor over-speed

For completeness, there is one last test we can do, which is the prop governor over-speed test. There
is a dedicated switch for this on the test panel and to run the test we flip it on, advance the power
levers and monitor the RPM gauge. All that happens is that after a period of oscillation the prop RPM
stabilises at 70%. This is a pre-selected test setting that the governor test switch imposes. Again, it’s
really just a fake and it doesn’t make any difference to flying the simulator. We can’t over-speed the
prop, it’s just not simulated.
4. The fuel system
In this chapter we are going to review the Twin Otter’s fuel system and the controls we have for
working it. We’ll do this with reference to an endurance flight, for which purpose you can now
imagine we are in Canada, on the ground at Goose Bay (CYYR). You can make the trip in your own
Twin Otter if you would like to follow along. The plan is to fly the second leg of a transatlantic ferry
flight – this leg will not be taking us out over the Atlantic, it will fly us up the East coast of Canada to
a strip called Iqaluit (CYFB), a transatlantic gateway for ferry flights.

From Iqaluit, if we were completing the flight we would set out over the Atlantic to Greenland, then
on to Iceland and then Scotland. We are flying the second leg because it is the longest leg of the trip
and we will be pushing the Twin Otter close to the limits of its endurance, at least without the
installation of specialist ferry tanks. We are going to fly 677 nautical miles, which is about 100
nautical miles short of our absolute endurance under ideal circumstances. Of course circumstances
are rarely ideal and that range is highly dependent on lots of variables, notably the weather and what
we have loaded on the aircraft.
Fuel tanks

We should start by having a look at the Twin Otter’s fuel tanks and the controls we have to manage
them. The Twin Otter Extended makes use of FSX’s built-in fuel storage system, which models up to
eleven fuel tanks in any aircraft. So in the general case an FSX aircraft can have main left and right
tanks, which are normally wing tanks, and three fuselage tanks, designated as centre1, centre2 and
centre3. It can also potentially have two wing-tip tanks, two auxiliary tanks and two external tanks,
making a total of eleven. Not all of those tanks are modelled in the Twin Otter. The 100 Series has
only two tanks, both in the fuselage – the forward tank is mapped onto FSX’s centre1 tank, while the
aft tank is mapped onto FSX’s centre2 tank.

The aft tank conventionally fuels the left engine and the forward tank conventionally fuels the right
engine. We can change that, as we’ll see later. Interestingly, these two tanks are not the same size – the
forward tank has a capacity of 181 US gallons, or about 1,250 lbs, but the aft tank is bigger, with a
capacity of 197 US gallons, or 1,320 lbs. I presume the discrepancy is because of centre of gravity
limits, but given that one tank fuels each engine we are obviously going to run into a problem when
we are low on fuel because one tank will run out before the other. We will look at cross-feeding later.

The 300 Series has the same tank setup but it has two additional wing tanks, which are mapped onto
the FSX wing-tip tanks (although they aren’t actually in the wing tips). These are basically long-
distance tanks for use in reserve and each tank has a 37 US gallon capacity, or about 250 lbs, so they
do add significantly to the range. Because the main fuel tanks are in the fuselage and the engines are
up on the wings, there is no gravity feed and so we need fuel pumps running constantly to push fuel to
the engines.
Controls

The first controls we have are the main fuel cut-offs up on the throttle quadrant. These are actually on-
off switches, in the real aircraft as well as the simulated one, so although I have them mapped to
analogue levers in my cockpit, they don’t need to be. You may be used to having condition levers with
‘ground idle’ and ‘flight idle’ positions but we don’t have that in the Twin Otter – the fuel is either on
or off.

We have two additional fuel cut-offs on the fire panel for use in emergency situations. I am not sure
what the difference is between these and the main fuel cocks but I suspect that the emergency switches
cut off the fuel closer to the engines, so we are not left with unburned fuel in the fuel lines to get to the
engines in the event of an emergency.
 Fuel emergency cut-offs are on the Fire panel.

We have a fuel selector switch, which I will talk about later, and boost pump switches for each of the
forward and aft fuel tanks. The main boost pump switches have three positions – ON/OFF and a Test
position. In practice the Test position doesn’t serve any purpose beyond going through the checklist
sequence authentically. In addition we have standby boost pumps for each of the those two fuel tanks.
These are simple ON/OFF switches and I will talk about those in operation later. On the Twin Otter
300 Series we have two additional boost pumps for the left and right wing tanks. These are located
low down on the centre console.
 Fuel controls and gauges on the main engine panel.

On the main engine panel we have quantity gauges for the aft and forward fuel tanks and we also have
a fuel gauge test button. Pressing this causes the indicated fuel quantities to drop to zero, so it appears
to work. All this button does in real life is disconnect the power from the gauges while you hold the
button down so you can verify that they are operating. In the Twin Otter Extended, it serves no useful
purpose. We have additional fuel quantity gauges for the wing tanks, low down on the centre console.
We also get red warning lights next to each gauge when the tanks are approaching empty. Finally, on
the main panel we have fuel flow indicators, which I will say more about as we go.

Wing tank gauges and fuel pumps.

Endurance and fuel management

On this trip we are going to be coming close to stretching the Twin Otter to the limits of its endurance,
so it is vital to manage the fuel flow. We should have a hundred nautical miles or so in reserve, which
sounds a lot but remember that we are pushing into wilderness here, at the start of an essentially
wilderness ferry flight to Europe and even though we are over land for this leg it is essentially
deserted so we have very few alternatives if something goes wrong. In fact close to our destination
there is no real alternative. We need to be looking carefully at the weather and the fuel situation, and
then we will reach a point of no return, at which point we need to decide whether to proceed or to
turn around and come back.

Aerosoft has provided a fuel planning application with the Twin Otter Extended. This lets us put in
the point of origin and the destination, some parameters about the weather and details of the aircraft
load. It then calculates the fuel requirement and optionally loads this into the aircraft. This is kind of
useful, assuming we are flying between airports that exist in FSX’s database, but we don’t need it for
this trip because we are simply going to load as much fuel as we can carry. That will not be too far
over the estimates that the fuel planner will give us.

Aerosoft fuel planner.

What is most important en route is that we pay close attention to managing the engine performance in
the cruise for best economy of fuel. We do this by setting different combinations of the cruising
airspeed, the power we command using the power levers and the RPM we command from the prop
governors, all the while monitoring the fuel flow gauges. Although we can experiment with
performance settings manually generally we set these based on tables of standard combinations in the
flight manual.

The Aerosoft Twin Otter Extended manual includes some sample tables, and these give a number of
alternatives for optimal cruise, depending on whether we want to fly faster or more fuel-efficiently.
For example, we find one table gives economy cruise with the props set to 75% on the RPM gauge
(1650rpm). The table gives the fuel flow in pounds per hour for different combinations of pressure
altitude and indicated airspeed. For example, cruising with 75% rpm at 12,000ft and an IAS of 123kts
we can expect to burn fuel at a rate of 460pph. (That’s a net figure for both engines.) So what we need
to do is find the most favourable combination of settings and in this situation our priority is
minimising the fuel burn.

Obviously the weather is going to be a factor too and in the real world we would look carefully at the
detailed forecast of the winds aloft. Today we will just going to check the ATIS for our departure
airport and in the absence of anything too scary just set off and see how we get on! As it happens we
have a surface wind of 29 knots, which is pretty high but it is from the South, which is in our favour. I
have set Iqaluit as a Direct-to course on the GPS and the distance shows as 677nm. We will plan to
cruise at 10,000ft, 75% rpm and 130kts, which should give us a fuel burn of about 460pph.

* * *

Established in the cruise now, we are cruising at 135kts and checking the fuel flow gauges we are
getting 440pph, as planned. That said, looking at the GPS tells us we have a pretty brisk headwind, at
47 knots. I have the Reality XP GNS530 installed, so we can read the headwind directly off the
screen. In the built-in GPS we need to calculate it by subtracting the ground speed from our indicated
airspeed.) The GPS also tells us our estimated time en route at the current ground speed, and it is
currently showing 5 ¾ hours. At 440pph for 5 ¾ hours will use up about 2,500lbs of fuel, which is all
we are carrying in the main tanks. We need to hope that headwind is going to diminish so we can
arrive with a healthy fuel reserve.
Fuel pumps

Let’s talk about the fuel pumps. Remember that because the engines are on the wings and the main fuel
tanks are below us in the fuselage, we need our boost pumps to be running all the time so we can get
fuel to the engines. We also have a standby boost pump for each tank in case of a failure. The standby
system works automatically – if a boost pump fails, a pressure sensor in the fuel line detects that and
automatically switches in the standby pump for that tank. So in principle we never need to do that
manually. The only contingency that would mean we would need to flip the standby boost pump on
manually is if the automatic changeover system failed.

In practice the automatic system will never fail, because this isn’t a real Twin Otter and pump failures
are not simulated. So we never actually need the standby boost pump. But we can play with it and the
system works consistently. For example, if we switch off the aft boost pump, we get a caution lights
on the annunciator panel for ‘boost pump1 aft pressure’. (If you’re going to try this, don’t leave the
pump off for more than a couple of seconds.) We also get a ‘boost pump2 aft pressure’ caution light
because switching off the main boost pump doesn’t count as a failure and the standby pump doesn’t
switch on.

However, if we turn off the main boost pump again and switch on the standby pump manually, the
pump2 caution light goes out and we’re now feeding the left engine from the aft tank but using the
standby pump. So it works, but in practice that will never happen unless we do it artificially.

So although we have four boost pumps, we only ever need two. There is another wrinkle to mention
here. If you remember back to when we looked at the electrical system you may recall we discovered
that if the main boost pumps failed the engines would stop (after a short delay). That shouldn’t happen
– in real life there are two engine-driven low-pressure fuel pumps that, once the engines are going,
will continue to feed fuel to them, within certain limitations, regardless of the operation of the high-
pressure boost pumps. That means we can switch off all the boost pumps and if the engines are
running they will continue to run. There are some limitations – we are only supposed to use those fuel
pumps for short periods of time and there is an altitude restriction of (I think) 8,000ft. If we rely on
the low-pressure pumps they actually wear out quickly because of cavitation (bubbles). This is just
another feature that isn’t modelled in the Twin Otter Extended, although it isn’t something that causes
us problems in normal operation.
Cross-feeding fuel

Coming back to the main fuel tanks, we saw earlier that the capacities of the tanks are different, and
you will see if you look closely that the gauges are marked differently to indicate this. The obvious
issue with this is that when we are running low on fuel, one tank is going to run out of fuel before the
other. This is one of the reasons we have a fuel tank selector on the panel. Under normal operating
conditions the fuel selector is set to the ‘Normal’ position, so the aft tank is feeding the left engine and
the forward tank is feeding the right engine.

We can switch that to run both engines from either the forward tank or the aft tank. If we switch it to
both on forward, we get caution lights for both of the aft tank boost pumps to show that they have gone
offline, which is to be expected. This is just a caution, it’s not a problem because only the forward
tank is feeding both engines via the same pumps. Likewise, if we switch the fuel selector to ‘both on
aft’ we get caution lights for the forward boost pumps and everything happens automatically.

Switching the fuel selector to the forward tank

switches the aft tank boost pumps off.
 Aft tank boost pumps offline – this is a reminder, not an error.

This is what we would do as we were getting low on fuel – as we got close to emptying the forward
tank we would switch to run both engines on the aft tank. There are probably other situations where
we might want to do that. If there was a failure or a fuel line blockage, for example (although it will
never happen in the simulator), but also depending on the load pattern in the aircraft we may want to
adjust the centre of gravity. But by and large we just leave the fuel selector set to Normal.

* * *

On our long cross-country flight it proves impossible to get rid of that headwind, and even after
experimenting with the altitude we find we are still flying into a 30 knot headwind at the half-way
point. Checking in at 200 miles to run, we still have a 20 knot headwind and the estimated en route
time is still 90 minutes. Looking at the fuel situation things don’t look so good. We are showing
240lbs in the forward tank, which is pretty much what we are burning per hour, and in the aft tank we
have about 300lbs. So it looks like we have an hour’s fuel left in the main tanks at the current fuel
burn, which isn’t going to be enough – if we stick to the main tanks we will run out of fuel half an
hour short of our destination, even without any contingency.

En route.
Wing tanks

Thankfully we have those wing tanks in reserve, so now is the time to start using them. All we need to
do is to switch on the wing tank boost pumps and these will start feeding the engines. We don’t see
any immediate difference – nothing changes on the fuel flow gauges and so from this we can conclude
that the fuel flow gauges measure downstream of the fuel feed system, at least in the simulator, and
they give us a net fuel flow regardless of the source. We might have expected to see annunciators
showing the main and standby boost pumps going offline but we don’t see anything. I don’t know how
this system operates in the real world but it doesn’t seem correct to have the main boost pumps and
the wing tank pumps both pushing fuel to the engines at the same time. Regardless, the system operates
correctly in the simulator and we find that fuel is taken from the wing tanks until they are exhausted, at
which time the main tanks resume supplying fuel again.

We can try switching off the main boost pumps manually, in which case we do get the annunciators
and the engines continue to get fuel from the wing tanks. Now, of course, we need to remember to
switch the boost pumps back on again when we’re about to drain the wing tanks, otherwise the
engines will stop as we discovered earlier. In practice, we may as well leave the main boost pumps
on when using the wing tanks as there is no apparent penalty for doing so.
Stretching the fuel

The other thing we can do to make the most of our remaining fuel is to reduce the speed. Remember
that we have the inverse square law working in our favour, so for any given speed reduction the drag
on the aircraft reduces proportionally more and so we ought to get more range for a give fuel load. To
experiment with this we need to find a new combination of power lever setting, prop RPM and
trimmed airspeed to give us a net lower fuel flow but hopefully with a longer range.

Checking this out isn’t quite straightforward, because while we find that reducing speed to 120kts
IAS reduces the fuel flow to 180pph on each engine (total 360pph), the GPS reminds us that we’re
going to need more hours to cover the remaining distance – about an hour and 45 minutes as I do it
here. If we crunch those numbers, we’ll find that this means we need 630lbs of fuel. Checking the
gauges, we have 540lbs left in the main tanks and although we can see the wing tank gauges starting to
fall they’re still pretty much full (close to 500lbs) so that should be enough!

We made it!
5. Hand-flying the Twin Otter
In this chapter we are going to look at hand-flying the Twin Otter. There are a number of thing we are
going to be looking at, most of them connected to managing the power. These are very powerful
engines, turboprop engines, and we’ll see some of the consequences of that in a little while. But first,
there are a number of things we need to keep an eye on in order to fly the Twin Otter precisely. It’s
easy enough to jump in this aircraft, get it up in the air, barge it around and even land it. But to fly it
accurately and to put it were we want it is tricky. We are going to look at some of the reasons for that.

As we fly there are two sets of gauges we want to be keeping an eye on. The torque gauges give us a
direct readout of how much power we’re commanding from the engines. You will notice there’s a red
line on these – we don’t want to go over that red line, otherwise things will start to fall apart. We’re
unlikely to over-torque the engines on a warm day, or a mild day even, because our limiting factor on
a warm day is the inter-turbine temperature, labelled on these gauges in this aircraft as T5. That will
top out long before the torque gauges do. We don’t want that to go into the red for more than a couple
of seconds, otherwise we will very likely have an engine fire and something will break. On a cold
day, or flying at high altitude or at night, we risk the other way of destroying the engines, which is
over-torquing them.

To get an accurate readout of how much power the engines are producing, the torque gauges are what
we need to look at and in my home cockpit I’ve marked up the throttle quadrants with some
approximate settings. The torque gauges in this aircraft are read in pounds per square inch (psi) and
the numbers on my power levers match roughly what is shown in the gauges. I’ve marked them at 5,
10, 20, 30 and 35psi and if I position a power lever at 20 on the quadrant I get approximately 20 on
the torque gauge. These settings are independent of other parameters such as outside air temperature
or weight and balance.

It’s not a good idea to monitor the gauges too slavishly when making power adjustments because they
lag. For example, if we have 35psi on the torque gauges and we move the levers abruptly to 20psi,
the needles will drop below 20 and then start to creep back up. Presumably this accurately models
some feature of how a turboprop engine responds. In practice it means we don’t want to chase the
needles when making power changes.
Standard settings

The next thing I have done is to establish a set of standard configurations for the aircraft. For
example, when we fire up the Twin Otter Extended in its default configuration – a full fuel load but
only the two pilots as cargo – setting 20psi torque with neutral trim and 90% RPM on the props gives
a straight and level cruise at about 110 knots. That’s useful to know as a baseline. Remember, the
torque readout will vary with propeller RPM because prop RPM is a consequence of selecting a
coarser or finer blade pitch. If we select fully fine pitch by moving the prop levers all the way
forward, the torque gauges drop as the RPM rises, and if we increase the blade pitch by pulling the
prop levers back the torque gauges rise as the RPM falls. Think of it this way – as we increase the
blade pitch, the props get more of a purchase on the air and because the air resistance to the
propellers turning is greater, the engine needs to supply more torque to maintain the RPM we have
selected.

Something else to note when we’re working this aircraft by hand is that we have the advantage of a
yaw damper, which we can turn on and off with a button on the Pitch and Turn panel on the yoke
pedestal. If we switch that on it’s essentially an auto-rudder function, so with the yaw damper on we
don’t need to bother about coordinating the rudder and ailerons when making turns. There are other
reasons for having a yaw damper but they need not concern us here. We’re going to leave the yaw
damper off for today as we are looking at hand-flying from the ground up.
Power affects pitch

The first thing we are going to look at is the effect of changing the power setting on the pitch of the
aircraft and, consequently, on the speed. If you have done any real-world flight training you have
probably heard the basic rule of thumb that we ‘pitch for speed’ and ‘power for altitude’. What that
means is that on a basic training aircraft such as a Cessna 152 or 172 we can set a particular attitude
using the elevator trim and this, as a consequence, sets a particular speed. That speed tends to remain
fairly constant regardless of power changes. We’ll get momentary changes – if we increase the power
we might get a momentary pitch up, but once it settles down we’ll find that the aircraft is moving
through the air at pretty much the same speed regardless of the rate of ascent or descent.

That behaviour is quite important because there are stages of flight where we want to maintain a
particular speed critically, such as on the approach. It will also be significant in the cruise, for flight
planning purposes. However, it doesn’t work quite that way the Twin Otter because we get significant
changes of pitch – and consequently of speed – as a response to changes in the power settings.
Experiment 1 – fly by hand

If you want to experience this, you can try the following experiments. I suggest you set things up on
autopilot first so the aircraft will settle itself down. Right now I’m flying straight and level at 1700
feet, at about 130 knots, props set at 90% RPM and about 30psi showing on the torque gauges. We
can take it off autopilot once things are settled and the first experiment is that we are going to push the
power levers abruptly to maximum. (Forgetting for now that this is never good form, because we
could risk over-torquing!) As we do this we’re going to watch the attitude indicator, the view out of
the front window and also the airspeed indicator. We might need to put in a bit of right rudder to
prevent the aircraft rolling.

When we do this we note that the aircraft immediately pitches down and the speed goes up
dramatically, initially to about 155 knots. If we do nothing else (apart from controlling the rudder),
the attitude levels out and then starts to pitch up again, while the speed falls back off, approaching our
starting speed of 130 knots. This is followed by a period of oscillation but the aircraft eventually
settles down with a net higher speed and nose-down attitude compared to where we started.

The converse is also true, which we can demonstrate with the same experiment in reverse. For my
experiment I’ve set up straight and level at 135 knots, with 25psi on the torque gauges and I’m going
to pull the power levers to idle. The pitch change here is less dramatic – we get a slight pitch up, but
the speed drops all the way to 115 knots. Then we get a major pitch down and the speed starts
climbing again to where it started, followed by an oscillation that settles down to a significantly
slower speed and with a higher nose attitude.
Experiment 2 – watch the autopilot

We can explore these effects more rigorously using the autopilot. This time I’ve set up straight and
level with 20psi on the torque gauges, then I hit the IAS button on the autopilot panel and select the
autopilot on. For me this is holding about 115 knots. What is most interesting is that if I make abrupt
power changes the autopilot is going to make trim changes to try to maintain that speed and it is
instructive to watch the trim wheel as it does that. In this configuration the trim wheel is showing
slightly forward of neutral, but when I push the power to maximum the autopilot aggressively trims
backwards to counter that pitch down and then immediately reverses that and trims back to neutral
before finessing it and hunting for a new stable position. This position is aft of where we started.
Remember that this is a slightly different version of the experiments we did manually above, as we’ve
ended up with a change of trim to preserve the initial attitude and speed of the aircraft in spite of the
change of power setting.

Again, we can do the experiment in reverse; after resetting the power to about 20psi and waiting for
things to settle down we can pull the power to idle and watch the trim wheel. This time, as we expect,
the autopilot responds with an aggressive nose-down trim change, then it re-centres the trim and starts
winding it forward until it finally settles down to a position slightly forward of where it started.

Those autopilot trim changes are telling us what we need to do to react manually to counter the effects
of changing the power settings. We can repeat the experiments we did manually but this time reacting
so that we preserve the attitude and speed. In the first case, pushing the power levers forward we
need initially to pull back quite hard to counter that nose-down pitching action, then relax the pull and
make a slight rearward trim change as things settle down. Conversely, if we drop the power to idle
we need to push forwards to counter that pitch-up tendency, and then shortly stop pushing and trim a
little forwards.

Reality check

It is probably wise at this stage to remind everyone that I do not fly a Twin Otter in real life and that
my actual piloting experience is pretty meagre. This means a lot of what I say here was discovered
empirically by flying the simulator and the relationship to actual operating procedures, let alone to
correct theory, will be largely coincidental! With that in mind, I have found that in managing these
pitch changes we always have to accept and an initial excursion in either pitch or speed before things
settle down to a new stable state and we can decide which one is more important in how we respond
with the controls. In my experience, that most critical situation to practice these changes in is flying
slowly on the approach, particularly in STOL operations where margins are tight and we cannot
afford large excursions in speed.

The reason we get those pitch changes is because of the aircraft’s high-wing design, with the engines
mounted on the wings. After the DHC-1 Chipmunk de Havilland Canada employed a high-wing
design for all of its aircraft, primarily because this gives a high sink rate and minimises the float on
landing. With wing-mounted engines a consequence of this is that the thrust axis is significantly above
the centre of gravity of the aircraft. Depending on the amount of thrust being generated this gives a
pitching moment around the centre of gravity as the engines try to accelerate the aircraft. This is most
unfortunate on the approach, where the last thing we want is to be making assertive power changes
and to get dramatic fluctuations in the speed.

For most of us this is probably more difficult in the simulator than in real life because in the sim we
generally can’t feel those pitch changes through the controls. That will be different if we have a yoke
or joystick equipped with force feedback because the pitch changes will be transmitted through the
controls and we can counter them by feel. In the absence of force feedback it is difficult to manage the
speed effectively without constant reference to the instruments. (This is one reason I have installed a
head-up display in my Twin Otter.)
Horizon lines

As in flying real aircraft, it also stands us in good stead to create a picture of the correct aircraft
attitude with reference to the outside world. In the Twin Otter my rules of thumb for straight and level
flight are represented in the following pictures, which show some prominent features of the virtual
cockpit related to the horizon. Of course this relies on a particular virtual seat height, or in other
words the eyepoint in the virtual cockpit. I can move my seat height up and down using a knob on my
panel, but my home position is when I can just see the two screws on the top of the glare shield
(indicated by the arrow in the first picture).

Flying straight and level. The ‘home’ seat height is

when the two screws (arrowed) are just visible.

This picture shows how I use the centre of the windscreen wiper and/or the top of the flap indicator
as markers to line up with the horizon. This keeps the aircraft approximately straight and level.
Because the pilot’s seat isn’t on the centre line, we need different markers when we are turning.
 Making a left level turn.

For a left turn, I use the flat spot in the glare shield as the horizon marker. For a right turn, we need a
different marker again.

Making a
right level turn.
Experiment 3 – piston vs. jet vs. turboprop

The next thing I want to talk about is turboprop engines. To introduce this we’re going to swap planes
to the BN-2 Islander. I’m flying the Flight1 Islander but really any piston-powered aircraft will make
the point. For the purpose of experiment I’ve positioned myself a few miles from the airport and I’m
going to fly it in manually, putting it down as close to the numbers as possible.

I’ve chosen the Islander because it’s a similar class of aircraft to the Twin Otter, a medium-sized
cargo aircraft – twin engines mounted on a high wing, but the Islander has conventional piston engines
and we’re going to see what difference that makes. Like the Twin Otter this is a STOL capable
aircraft so it should be quite easy to put it down where we need it. It can land slow and short and we
have flaps to help us out with that, but what we’re interested in here is how precise we can be in
controlling power changes. Don’t forget we’ll need to be managing those pitching tendencies too, but
this experiment is about how quickly the engines are going to do what we ask them to do.

On the approach we’re on full flaps at about 70 knots and we set up a nice stable descent by setting
the elevator trim appropriately for the power setting. As we get closer to the runway we’ll need to
finesse things by rolling on and off the power and in this aircraft we see a fairly instant response
when we do this. This means we can be a lot messier and still maintain good control of the descent
rate with excellent precision. Of course, for a conventional approach to an airport with adequate
runway length we would generally expect to need very little adjustment to the power during the
descent, but the Islander was designed to drop into short, unprepared strips as short as 1200ft. The
approach can, therefore, often be much more demanding, particularly in gusty weather.

In the Islander we have no problem in putting the aircraft down where we need it. By way of contrast,
we’ll now jump into the FSX default Learjet and try the same exercise. This is a whole different bird
and we need to be cautious of drawing too-close comparisons, but for our purposes the main
difference is that it has two jet turbine engines instead of piston engines. These are mounted on the
fuselage near the tail, which is pretty much on the longitudinal axis so we’re largely going to escape
the pitching tendency under changes of power. These are, however, very powerful engines and we
also need to pay heed to the Learjet’s much higher approach speed, which is about twice the speed of
the Islander.

What is immediately apparent is that the kind of finesse we experienced in the Islander is almost
completely absent in the Learjet. Rolling on and off the power has no immediate discernible effect
and this has two consequences (both of which are further compounded by the high approach speed).
First, the time between noticing a need for a power adjustment and then actually getting it means that
deviations in the descent rate are much larger than they are in the faster-responding piston-engined
aircraft, but second, this encourages us to over-control the power settings, This further compounds the
problem by producing exaggerated changes when the engines finally do respond.

This adds up to a real problem. There’s no problem with the amount of power on tap but the problem
is commanding it. It’s like we have a very long, sloppy chain of command between the power levers
and the engines, which means we have to think a long way ahead with little possibility of making
responsive adjustments to the power.

We’ll switch back to the Twin Otter now. The reason for doing this comparison is that the Twin Otter
has a different kind of engines again. These are turboprop engines and a turboprop is essentially a jet
engine like in the Learjet, but instead of being used for propulsion directly, the jet exhaust drives a
secondary turbine which drives a propeller. That may sound complicated but it’s useful because we
get to retain some of the benefits of propeller drive, and most significantly the rapid response to
changes in power settings. Or that’s the theory – what we’re trying to establish is the extent to which
it is borne out in practice.

Now we’re flying the same approach in the Twin Otter and trying to put it down on the numbers,
compensating for pitch changes when we roll on and off the power. It is instructive just to listen to the
engine note as we do that and it’s clear there is something of a delay. We adjust the power lever and
wait for it to have an effect, although the wait is not as evident as it was in the Learjet. In practice,
although we still have that discontinuity between commanding the power change and receiving it, the
disconnection is less severe than in the jet. Nevertheless, we have lost the instant response of the
piston-engined Islander and we need to adjust our flying to suit. Notably, as before we need to resist
the urge to over-control and again we have no effective control over urgent power adjustments such
as blipping the power in the flare to correct for a sudden departure.

The real question is to what extent this is a reasonable and realistic simulation of a turboprop engine.
It’s generally accepted that FSX doesn’t do a very good job with turboprops. The turboprop model in
FSX is supposed to be based on the Pratt & Whitney Canada PT6A, which is the kind of engine fitted
to the Twin Otter, but there is a general consensus that it is not very well modelled. This seems to be
borne out in practice. This simple test shows a clear difference from flying a jet, but the main stated
benefit from the turboprop is that it’s supposed to give us much more precise control of the power
settings.

In practice it’s actually quite a pain to fly this because of the lag. We have to adopt a different style of
flying – thinking further ahead, which is no bad thing, and making power changes with finesse. But it
does mean that particularly if we’re landing in gusty conditions it is very difficult to be responsive to
the aircraft. Perhaps this is realistic – I have never flown a turboprop aircraft, so I can’t say how
realistic it is. But it is certainly difficult. Anyone who says the Twin Otter Extended is easy to fly
hasn’t spent enough time with it!
6. The autopilot
In this chapter I will be making reference to three different things – the autopilot, the flight director
and the altitude alerter – and I’ll explain these as I go along. They all work together as parts of the
autopilot system. The autopilot in this aircraft is a Collins AP-106 and the flight director is a
subsystem of this. The flight director is the brains of the autopilot, if you like – it monitors the
aircraft’s position and orientation and when we put a command into the autopilot, for example to
follow a particular heading, the flight director decides what needs to be done to act on that command.

It’s probably worth saying a bit about the basic autopilot functions at this point. These are divided
into vertical and lateral modes. A vertical mode would be altitude hold, for example, and a lateral
mode would be heading hold. We also have more complex lateral modes such as NAV hold, which
can fly to a VOR. There are also more complex modes still, such as the Approach mode, which
combines lateral and vertical sensing to fly down an ILS, tracking a localizer and a glide-slope at the
same time.
Flight director

To start with we’re going to leave the autopilot master switch off. We can still select the various
functions on the panel and the flight director stays active (or becomes active) behind the scenes. In
this aircraft we also have a flight director head fitted, which essentially gives us more sophisticated
ADI (Attitude Direction Indicator) that can display extra information from the flight director. This is
called the FD-112V, and this is just the indicator for the flight director, the flight director itself is built
into the AP-106 in this aircraft. If you examine the ADI you will see that it has two intersecting
yellow bars, one vertical and one horizontal. These are controlled by the flight director when it is
active and they give us cues about how to fly the aircraft.

Enhanced ADI displays cues from the FD-112V.

Let’s walk through some flight experiments to illustrate how this works in practice. Imagine that
we’re sitting on the runway with the autopilot off and the flight director inactive. We know it’s
inactive because the ADI has a red flag (labelled ‘steer’) showing. If we select heading hold mode by
pressing the HDG button on the autopilot panel, the red flag disappears. This tells us that the flight
director is now active, even though we have the autopilot master switch in the off position. The light
under the HDG button is also now illuminated to tell us that heading hold is active.
 Heading hold selected on main autopilot panel (note master switch is off).

Flight director cues in lateral modes

If you are following along with the experiment in your own Twin Otter you may have noticed that the
instant we switched on HDG mode the vertical flight director bar moved out to one side and then
back to the centre. This bar is going to give us information according to the heading we select using
the heading bug, but it’s centred at the moment. The reason for that is that when we activate HDG
mode the selected heading is initialised to the current aircraft heading and hence you will also note
that the HSI’s heading bug is at the 12 o’clock position. If you didn’t notice any of those things you
can try them out again – just deactivate HDG mode by pressing it again, then move the heading bug
and then press HDG again to select it.
 Heading bug snaps to current heading when we select HDG.

With the flight director now active and HDG mode selected, we’re going to move the heading bug to
indicate a course we want to follow. Let’s imagine that after takeoff we want to turn off on a heading
about sixty degrees to the right of where we’re currently pointing. We dial the heading bug around to
the right and as we do so the vertical flight director bar moves out to the right.

Flight director calling for a right bank.

That’s telling us something about how we need to fly the aircraft to attain that heading. It’s not going
to do it for us automatically but it’s making a suggestion about what to do while flying the aircraft
manually. Keeping in mind that the ADI is an attitude indicator instrument, the flight director bars are
going to tell us something about what we need to do to the attitude of the aircraft. You might be
tempted to regard that vertical bar as a course deviation indicator (CDI), like on the VOR instrument,
but it’s not. It’s telling us how far we need to bank the aircraft.

Once we’ve taken off we can think about turning onto the selected heading. As we fly the runway
heading initially we’re well off course with the vertical bar on the ADI well out to the right. To centre
the bar we need to bank the aircraft to the right, at which point we’ll see it move towards the centre.
If you try this out you will find that the distance the bar moves towards the centre depends on how
much bank you apply – so a shallow bank will leave the bar still away from the centre, while setting a
very steep bank will cause it move out the other way. In other words, the flight director is directing a
specific bank angle. I’m not sure how this angle is determined but for large course deviations it’s
probably calculated to achieve a Rate 1 turn, which is the standard ‘two-minute turn’ (3 degrees per
second) used for IFR manoeuvres. For smaller deviations you will notice that the FD directs smaller
bank angles. The flight director will never command a bank angle greater than 25 degrees. Again,
remember that this is about attitude, not course – for example we can centre the bar by banking the
aircraft but holding our present course with opposite rudder.
 Holding the directed bank.

So that’s how it works when we use the heading hold lateral mode, but we can choose another lateral
mode and try the same thing. For example, let’s choose a nearby VOR and set that up on the NAV1
radio, then select NAV Hold mode by pressing the NAV button on the autopilot. We also need to make
sure the NAV/GPS switch is set to NAV, which we can verify by looking for the VLOC indicator at the
lower left of the Garmin GNS530 display. If it says GPS we just press the CDI button to switch to
VLOC. Then as we centre up the OBI, the FD vertical bar will deviate from the centre to a distance
and in a direction that depends on where we are relative to the VOR.
 Flying in NAV mode to a VOR.

From here on we should observe the same behaviour of the FD bar as we did when playing with the
HDG mode. If you want to reassure yourself that the FD bar behaves differently to the course
deviation indicator (CDI), you can set the OBS off-centre, so the FD will direct turns to intercept a
particular radial. The CDI is the split yellow pointer on the ADI – when the central portion is lined
up with the outer portions we are flying the selected course; when the central portion is displaced to
one side we need to turn towards it to intercept the selected course.

Flight director cues in vertical modes

So that’s how the flight director functions with the lateral modes. Everything works analogously for
vertical modes, only this time the horizontal bar is displaced to cue us on whether we need to pitch up
or down. This isn’t quite so straightforward to demonstrate because we can’t easily set up a situation
with a vertical mode where the FD bar is deviated from the centre. This is because when we activate
the two main vertical modes, ALT hold and IAS hold, the target altitude or speed is set to the current
altitude or speed of the aircraft, and so the horizontal bar is centred. We can only observe the FD
giving us directions once we begin to deviate from the held value.

Taking altitude hold as an example, we can set the aircraft up an altitude that’s easy to remember, say
3000 feet, and then press ALT to activate altitude hold. The FD will now cue us to hold this altitude,
so if we deviate by diving, the bar will rise above the aircraft datum, signalling that we need to pitch
up. Conversely, if we rise above the target altitude, the FD bar moves down, directing us to pitch
down.

Flight director commanding pitch up in ALT mode.

If you are familiar with other autopilots such as the Bendix King KFC series you may expect to be
able to change the target altitude using the ‘SET ALTITUDE’ window and see the FD bar move, but
this isn’t how it works with the AP-106. We’ll look at this in a bit more detail when we talk about the
altitude alerter.

Although it isn’t completely intuitive, IAS (indicated airspeed) hold also functions as a vertical
mode. In this case the FD directs us using the horizontal bar to alter the pitch up or down to achieve a
particular selected airspeed, and assuming we’re starting in level flight the aircraft climbs or
descends as a consequence of this. Again, we can easily demonstrate that it is the airspeed, not the
climb or descent, that is the significant value, for example by varying the speed during a descent,
where we can cause the FD to indicate a pitch up or down while still descending.
Autopilot

Returning now to the NAV1 radio, we still have the VOR dialled in and the flight director bar is out to
the right, indicating that we need to put the aircraft into a right-hand bank. This time we’re not going
to do that because we’re going to look at the next logical step. This is an autopilot after all, we want
it to fly the aircraft for us, so having set that up and having observed the cues that the flight director’s
presenting to us on the ADI, all we have to do is move the autopilot master switch to ‘engage’ and
then aircraft will then bank of its own accord. Again, if you’re following along you’ll notice that the
flight director bars centre and the aircraft holds a bank as it moves to intercept that radial.

For the purposes of demonstration I’m flying towards Queenstown in New Zealand, with the Slope
Hill VOR dialled in on NAV1. The autopilot has us established on the 110 radial (more or less),
although depending on the conditions you will likely see that it’s not exactly steering that course – in
my case I have a crosswind from the right.

We’re pretty much always going to flying in moving air so we’ll usually have a discrepancy between
the desired ground track and the heading flown, but the autopilot compensates for this with reference
to whichever fixed ground reference we’re navigating by. In this case it’s the VOR but we can also do
this much more flexibly with the GPS. For reference purposes I’ve also set up a direct-to course set
up to Queenstown on the GPS. If we look at the GPS display we can see that the direct-to course
terminates at the airfield, but the VOR we’re flying to is the little blue icon to the left of the airfield,
so they’re not coincident.
 The VOR is not on the airfield.

If we go over to the GPS and press the CDI button, that switches the autopilot to follow the GPS
instead of the VOR. You can see the VLOC flag at the lower left of the GPS display change to GPS to
denote this. The aircraft immediately banks to the right because it’s now going to intercept that GPS
direct-to course, which is more or less parallel to but offset from the course we were flying to the
VOR. If we look at that on the GPS display we can see the autopilot initially flies an intercept
heading and it treats the GPS course in just the same way as a VOR radial. Once we start to intercept
that it will then steer us back on to track and then fly us along that to the airfield.
 NAV mode is now flying us to intercept the GPS track.

Manual mode

You might be wondering (or you might have noticed) what happens if we’re flying a lateral mode on
the autopilot and we try to make pitch changes to the aircraft. If you try that out you’re going to find
that the autopilot resists the changes. In fact you’ll see auto-trim indications on the autopilot panel and
if you watch the trim wheel you’ll see that it moves to compensate for the changes. What’s happening
is that when we’re flying a lateral mode the autopilot is holding the pitch that was set when we turned
the autopilot master switch on. If we turn the lateral mode off and we try to bank the aircraft, again
we’re going to find that the autopilot also resists that and tries to restore it to the bank attitude that
was in operation when we engaged the autopilot.

We can see this more clearly if we disengage the autopilot, put the aircraft into a bank and then re-
engage the autopilot. The autopilot will now hold the bank angle. Likewise, if we do the same but add
a bit of pitch up or down as well, the autopilot will continue to hold that attitude until either we
disengage the autopilot or we select a specific lateral and/or vertical mode. Essentially, when we
engage the autopilot it performs an attitude hold function in the absence of any selected lateral or
vertical mode.

The attitude hold mode is referred to as ‘manual mode’ in the AP-106 and we have controls to vary
the attitude set. These are on a thing called the ‘pitch and turn panel’, which is located on the top of
the yoke pedestal. This is basically two nudge switches, in the form of a dial and thumbwheel, for
modifying the bank and pitch angles. If we nudge the bank dial to the right, for example, the vertical
flight director bar initially moves out to the right and the autopilot then banks the aircraft until the bar
centres.

Pitch and turn panel, on the yoke centre pedestal.

We can nudge the dial repeatedly to get a steeper bank, although once again we’re limited to 25
degrees left or right. Likewise, nudging the pitch thumbwheel initially moves the horizontal flight
director bar and then the autopilot pitches the aircraft until the bar re-centres. There is a limit of 10
degrees on the amount of pitch-up and pitch-down we can command in this way.

In manual mode we can change the attitude quite precisely by nudging the controls on the pitch and
turn panel. This is fairly convenient for making small changes to the attitude but if we want to make
larger changes we have to disconnect the autopilot, put the aircraft into the attitude that we want and
then re-engage the autopilot. In the real aircraft we can do that more flexibly – if you look on the
right-hand handle of the control yoke there is a button labelled ‘CWS’, which stands for Control
Wheel Steering.
 Control Wheel Steering button (not implemented).

If you hold down that button it temporarily disconnects the autopilot while the button is held down, so
you can adjust the attitude and then let the button go to reinstate the autopilot. Unfortunately we don’t
have that function available in the Twin Otter Extended, although we can fake it by mapping the
autopilot engage and disengage functions to the up and down actions of a button on the joystick.
Altitude alerter

The last piece of the autopilot jigsaw is the United Instruments 5506L Altitude Alerter. This is
controlled by the ‘SET ALTITUDE’ dial to the left of the autopilot panel and the three buttons to the
left of that, labelled MDA, GO AROUND and ALT ALERT. The mode we’ll make most use of in
normal flight is ALT ALERT. This combines the function of a regular altitude alerter with the ALT
HOLD function built into more conventional autopilots such as the Bendix King series.

Set altitude window.

The basic function of the altitude alerter is, as the name suggests, to improve our altitude awareness
by alerting us when we approach a pre-set altitude. To use this we simply dial in an altitude in the
window and then press the ALT ALERT button. The button has an indicator that illuminates to tell us
the altitude alerter is active. Note that the altitude alerter only functions when the autopilot master
switch is on. The altitude alerter works both in climbing or descending to the target altitude.
Whichever direction we are approaching the target altitude from, when we get to within 1000ft of it
we get an audible tone and a warning light illuminates next to the SET ALTITUDE window. That light
stays on until 300ft from the target altitude (although the Aerosoft manual says 200ft).

Altitude alert functions.

Unlike a simple altitude alerter, the 5506L in this aircraft is connected to the autopilot and will also
select the ALT mode when it achieves the target altitude. The ALT ALERT function is then
disconnected and the aircraft holds the target altitude. If you are used to other autopilot systems you
might expect that just changing the altitude selected in the SET ALTITUDE window would start a
climb or descent. In this aircraft it’s not so simple, although it is logical. To initiate a climb to the
target altitude, for example, you first need to press ALT ALERT. This disconnects the HDG mode if it
was active and arms the ALT ALERT function. You then need to initiate the climb manually, typically
by nudging the pitch wheel on the pitch and turn panel. Again, unlike a more conventional autopilot
there is no direct control of the ascent or descent rate, so you set this as a secondary consequence of
changing the pitch. Note that if you disengage the autopilot with the ALT mode in operation, it will
retain the current altitude as a target and climb or descend to it when you re-engage the autopilot.
The MDA (Minimum Descent Altitude) and GO AROUND buttons are associated with approaches.
GO AROUND sets the aircraft up for a missed approach by cancelling any lateral and vertical modes
in operation and setting up a wings-level 8 degree nose-up attitude on the flight director. The Twin
Otter has no auto-throttle, of course, so you also need to push the power levers forwards to actually
execute the go-around. The MDA button has a similar function to the ALT ALERT but it works in the
descent only and is used to ensure the minimum decent altitude is not breached when making non-
precision approaches where no glide-slope is available.

The autopilot implementation in the Twin Otter Extended is a fairly complete one that compares well
to the real thing. I have documentation for the real AP-106, although it’s for a different aircraft, the
Beechcraft C-12. This is a similar class of aircraft, a twin turboprop, and it has the same autopilot
fitted. Although this is a detailed description of the real-world autopilot and its operating procedures,
pretty much everything it says applies to the Aerosoft implementation. Only one thing appears to be
missing, which is an extra function in the NAV mode called Linear Deviation (LD). With LD, if we’re
tracking a VORTAC instead of a basic VOR we can actually fly a parallel track to a radial, so we can
be tracking the radial but flying parallel to it a fixed distance off track. That would be a really useful
function, but we can’t do that in the Aerosoft Twin Otter as far as I can tell. But everything else is
there.
Autopilot hacking

It’s tempting to outline further scenarios to demonstrate the autopilot in practice but really this starts
to deviate from the Twin Otter Extended as such and moves more into real-world navigation and
approach techniques. I’m not going to do that because there is already a wealth of instructional
material out there to be found. But there are all sorts of ways we can innovate and use the various
navigation aids to our advantage. We’ll just look at one example of this here.

For this example I’m still in New Zealand and I’ve flown out to the coast looking for a little strip at
Martin’s Bay. This is a very narrow gravel strip out in the middle of nowhere so we have no actual
weather information. Of course in real life we’d have some visual indications of the wind speed and
direction by watching the trees and the waves on the water surface but we aren’t so well-served in
the simulator. So we need another way to estimate the wind and we’re going to use the autopilot and
the GPS in combination to do that.

This strip runs 02 / 20 and we’re going to make out approach towards the North East, on runway 02.
So first we’ll set up straight and level at about 700ft agl and fly a perpendicular track over the
runway threshold with the autopilot on IAS hold. It’s not crucial how fast we fly, only that we don’t
change this until we’ve flown the reverse leg.

The trick is to watch the GPS as we cross the runway threshold and note the aircraft’s ground speed.
In my case this is 125 knots, and I overflew the strip on a track of 290 degrees. I’ll write that down as
the right-to-left ground speed.
We have a couple of options here – just compare this with the indicated airspeed, or fly it in the
opposite direction (110 degrees) and note the ground speed again. Either way, a simple subtraction
now gives us a crosswind component at the runway threshold. Of course this tells us nothing about the
net wind direction, so it’s possible we’re also going to have a 20-knot tailwind! We could repeat the
process, flying up and down the runway to get an accurate estimate of the total wind, but in practice
we’ll be able to gauge the overall direction by watching the aircraft’s drift as we overfly the strip. In
the absence of high winds it’s the crosswind component that we really need to worry about.
7. Icing conditions and the Twin Otter
Ice is a real problem for aircraft, particularly when flying in IMC (Instrument Meteorological
Conditions). In this chapter we will look at some of the problems we can encounter, to what extent
those are simulated in the Twin Otter and what we can do to combat icing.

We’ll start with a run-through of what icing can do to an aircraft and to what extent those things are
simulated in FSX. The thing most people will be aware of, particularly flying piston-engined aircraft
is carburettor icing. Carburettor icing is the icing of the intake to the carburettor and it can happen
when the temperature is well above freezing. This is because the carburettor, by its nature, has a
cryogenic effect on the incoming airflow. We don’t have carburettors in this aircraft but we do have
air intakes and because the air is restricted as it is diverted through the intakes, they are prone to ice
formation.

Another thing common to many aircraft, and usually the first sign of icing, is that the pitot tube will
block and so the airspeed indicator will stop working. The pitot tube measure ram air pressure and is
directly exposed to the oncoming air and precipitation. In FSX this effect happens abruptly and we
just see the airspeed indicator fall to zero. Another effect of icing is a build-up of ice on the propeller
blades and this too is modelled in FSX. Over time there is an accumulation of ice on the prop blades
and this reduces the efficiency of the propellers. If you remember back to our discussion of the
propeller angle of attack and the RPM, as we accumulate ice on the propeller blades the efficiency of
the prop changes and that delicate balance of the RPM and angle of attack is upset. The net effect of
that is, over time we get an increase in the fuel burn. This too is simulated in FSX.

Beyond that we need to look at structural icing, by which we generally mean the build-up of ice on the
wing and tail surfaces. This is modelled in FSX but there are two problems with it. The first problem
is that there is no visible sign of that happening. In a real aircraft we would look out of the window at
the wings and see fairly obvious signs that ice was accumulating. We don’t have that in FSX. The
other problem is, by general consensus, that the model of structural ice accumulation in FSX is fairly
weak. It is weak in the sense that it is quite rare to encounter ice and when we do encounter it the
build-up is fairly slow. Nevertheless it does happen and over time the effect is that the weight of the
aircraft increases significantly, and perhaps (eventually) critically. If we accumulate too much ice
we’re going to be overloading the aircraft just the same as if we had loaded too much cargo.

The other effects of ice accumulation in real life are twofold. We get a significant increase in the
drag, which is modelled to some extent in FSX, and also it changes the profile of the wings and tails
surfaces, which can upset the aerodynamic properties. In other words the wing will fly less
efficiently, the angle of attack to the relative wind changes, and so on. Again, these effects are
reportedly modelled to some degree in FSX but the effects are rare and subtle.
Ice formation in FSX

To understand something about why these effects are so subtle in FSX and so elusive we need to say
something about the conditions under which icing will occur. We need two things for ice to form – we
need low temperature and we need moisture. In the real world, flying through clouds or through rain
when the temperature is within a sufficiently low range we are more or less guaranteed to get ice. In
FSX too, icing follows the weather and whichever scheme we are using to control the weather will
have a big effect on whether or not we encounter icing, how frequently we encounter it and how
severe it is.

Essentially FSX produces icing conditions when we have a cloud layer that has an icing attribute set.
There is also a severity parameter – if we look in the weather dialogs under FSX settings, when we
set icing on for a particular cloud layer we have the option of making it light, moderate or severe. If
we are flying in a cloud layer that has one of the icing attributes set and the temperature is below
zero, we are going to start accumulating ice. If we are using a weather engine such as Active Sky or
REX to manage real-world weather this process will depend crucially on how effectively that
program associates those flags with the cloud layers it produces.

At the moment we are still talking about basic FSX default modelling of the different forms of ice
accumulation. The last thing to say about that is that the FSX SDK provides a set of de-icing and anti-
icing tools that can be incorporated into the aircraft models and these are implemented to some extent
in some of the default aircraft. You probably know about the carburettor heat control, which is
actually a more generic control under the skin called ‘engine_anti-ice’. This control can be directed
to each engine of a multi-engined aircraft independently. You probably also know that there’s a pitot
heat control to warm up the pitot tube and prevent icing. Beyond that we have various de-icing
controls and usually these operate things called de-icing boots, which are on the wing leading edges
and sometimes the tailplane. These expand when we operate them and break the ice off.
Ice formation in the Twin Otter

It appears we are fairly well provided-for in FSX for baseline ice formation and for measures we can
take to deal with the ice. But what about the Twin Otter? If you read about it in the Twin Otter
Extended manual, Aerosoft acknowledge the shortcomings of the FSX default icing models and has
implemented its own model of ice accumulation to sit alongside FSX’s. It is an additive model in the
sense that the Twin Otter will accumulate ice if it encounters a cloud layer with one of the icing
attributes set and the temperature is sufficiently low, but there are also some extra rules that allow the
formation of ice under other conditions.

For example, if we were flying through rain and the temperature was sufficiently low, but even if
there was no icing attribute set on the particular cloud layer we were in, the Twin Otter Extended
would accumulate ice – specifically, if it is flying through rain or snow and the temperature is
between -11 degrees and +1 degrees Celsius, we will accumulate ice. However, if we are not flying
through rain but if we are flying through a cloud layer that has an icing attribute set it will still
accumulate ice in the manner of default FSX behaviour. The net effect of this is that we are much
more likely to encounter ice formation in the Twin Otter than we would be in a default FSX aircraft
and indeed it’s quite likely that when we do encounter icing conditions, the ice will accumulate faster.
Icing experiments

To have a look at those things in action, follow along as we take a test flight into icing conditions. We
are going to try to get a sense of what the icing accumulation does to the aircraft and then we can look
at what we can do to combat it. I have set things up so that icing is guaranteed – we’re going to be
flying into cloud layers with icing attributes, but I have also made sure it is raining and that the
outside air temperature is just above zero at ground level. Don’t forget that the temperature will fall
by about 2 degrees Celsius (the ISA environmental lapse rate), so we aren’t going to need to climb
very high to start freezing. For now we’re not going to take any protective measures and we’ll just
observe the effects on the aircraft.

The first thing we notice is that within a minute of taking off, the airspeed indicator stops working and
falls to zero. This is due to pitot tube icing, which we can verify by turning on the pitot heat control.
Once we turn that on, it takes about five seconds for the ASI to start working again. That’s un-
dramatic and I would guess the way that fails and un-fails on command is more predictable than the
real thing. But it is modelled, and in an aircraft that isn’t equipped with a pitot heater we would be
flying without an ASI from here on.

The next thing we are going to notice is not a default feature, but something modelled specifically in
the Twin Otter Extended. That is that we will see ice start to accumulate on the windshield and if we
don’t do anything about it we are eventually not going to be able to see anything out of the forward
windshield. We don’t get icing on the side windows. The first signs will appear around the margins of
the window.
 The windshield is starting to ice up.

Meanwhile we have levelled off at about 5500ft, which in the test conditions we have set up is still in
an icing layer but above the rain. We have no other visible signs of icing beyond the two effects we
have already seen. The only way we can keep track of icing is a very artificial way, by bringing up
the Twin Otter Extended checklist, which has an ice build-up gauge on the configuration tab. It would
have been nice if Aerosoft had built that gauge into the virtual cockpit as some kind of indicator, but
they didn’t and we have to look here.
In my cockpit the gauge is showing 12% of maximum ice load, so we are definitely picking up ice on
the structure. But there are, so far, no obvious untoward effects on the handling of the aircraft.

Meanwhile, the windshield has accumulated more ice until now it’s completely opaque, although we
can still see out of the side windows perfectly well. We have windshield wipers so we can try those
to see if that can help us. You might expect that these would have some effect on the ice build-up, but
in fact they don’t. The windshield wipers in the Twin Otter are nothing more than a special effect. To
be effective, the windshield wipers would rely on the aircraft virtual cockpit having some internal
model of the windshield and how it interacts with precipitation, but it doesn’t and in fact I don’t know
any FSX aircraft that such a thing is implemented.

We can’t see out the front windshield at all now, so we’ll switch on the next de-icing measure we
have available, and that’s the windshield heater. Then we just need to wait a while and hope we
aren’t about to bump into anything in the meantime. Pretty soon the heaters have an effect and we get
an obviously step-wise reduction in the ice layer. So the visual rendition of ice formation and
dispersal isn’t especially realistic, but it is there.

The heater is useful, the wipers aren’t.

If we check in again with the ice gauge on the checklist page it now shows about 18%, although still
with no obvious impact on the aircraft handling. And this is how it will be – over time and quite
gradually the drag will increase, the weight will increase and we are going to find it harder to stay
aloft. We will need to use more power to keep flying, in other words. A better test would be to start
off with the aircraft fully loaded, as the ice weight will become critical before we get to 100% ice
load. You will note that the ice load is expressed as a percentage rather than an absolute weight. This
reflects the general FSX way of tracking ice, which calculates the absolute ice load of any aircraft as
5.5% of its empty weight and then tracks the load as a percentage of this value.

The other thing we won’t see directly in the Twin Otter Extended is the effect of propeller icing. It is
happening but we don’t know it is happening because there is no direct way to observe it. There is no
indication in the cockpit and no obvious physical effects. In real life it may be that we would notice
some asymmetry on the propeller and hence some vibration but no such effects are modelled. The
only indication we get is that over time if we were looking very carefully at the fuel burn and perhaps
the airspeed gauge we would see some difference.
Anti-icing vs. de-icing

We should make a distinction here between de-icing and anti-icing. What we did with the windshield
heat was what you might consider a de-icing measure – we had ice build-up, we did something and
the ice was removed. Likewise, at the moment structural ice is accumulating and when we look at
what we can do to fix that, it will involve things aimed at shedding ice from the aircraft – also de-
icing. This is in contrast to an anti-icing measure. Anti-icing would be doing something up front to
prevent the formation of ice in the first place. We can regard the pitot heater as an anti-ice measure.
The windshield heat, if we switch it on at the outset, would also be an anti-ice measure. Propeller de-
ice too, which we will switch on now (although to no obvious effect), is typically used as a
preventative measure if we know we’re going to be flying into icing conditions. This heats up the
propeller blades to prevent the formation of ice.

Checking in on our experimental flight we are currently flying on altitude hold at 5600 feet, still in
icing conditions, and the ice load is still increasing. We currently show about 35% of the maximum
structural ice load and according to the ASI we are making just under 155 knots. We shall just going
to leave it there and let some time go by while the ice continues to build up and as it does so, try to
observe any change in the aircraft’s performance.

* * *

Still on course, we are now just passing 70% on the icing gauge and looking at the speed, we have
dropped now to about 142 knots. Let’s keep going and see what happens as we approach maximum
icing.

* * *

Checking in again, the ice load is approaching 95% and the speed has dropped significantly now, to
about 132 knots. We are clearly getting a detrimental effect, whether it is due to the increase in
weight, the increase in drag or both. We are flying on autopilot of course, so if we had been watching
more carefully no doubt we would have noticed the autopilot making trim changes to maintain the
altitude, with the net result of a more nose-up attitude. (We will also presume that there is no
significant change in the centre of gravity as we expend fuel.)

It is clear over time that ice accumulation on the airframe has an effect on performance, but the effects
are subtle. If we come off autopilot, even at approaching 100% ice load, the aircraft still responds
normally to all the flight controls. Of course, under our experimental conditions with light loading we
are not approaching the limits of the aircraft. If you plan to do your own experiments with ice
formation you might want to start off with the 100 Series, which has the lower-powered engines, and
make sure you are fully-loaded before you take off. With a 100% structural ice load you should
approach the limits of the aircraft’s ability to stay in the air. For now, we are just slowing down,
getting a bit more sluggish and burning more fuel.
De-icing measures

The next thing to do is to have a look at what we can do about structural icing. We have a number of
options. On the wings and on the tailplane we have de-icing boots. These are rubberised tubular
devices on the leading edges than can expand and contract as we pump hot air into them. The hot air
comes from the bleed air system, which taps hot air from the engines.

We can control the bleed air from each engine independently and if we have both bleed air switches
off we get a pneumatic low-pressure warning light on the annunciator panel.

With either or both bleed air switches on we have bleed air available to operate the de-icing boots.
We have various controls for operating the boots and the only way to monitor the effectiveness of
these directly is to monitor the ice gauge on the checklist page. Looking at the panel with the de-icing
boot controls, we have manual and automatic controls, and also a slow/fast switch. With the switch
set to manual, we can blip four different sets of boots independently – that’s the left and right inner
wing boots, the left and right outer wing boots and each of the left or right horizontal stabilizer
(tailplane).
 The de-icing panel.

With the main switch set at manual and the rate switch to fast, if we pulse the wing inner boots we get
a roughly 1% drop in the ice load on the gauge and we see a similar drop by pulsing the left or right
stabilizer boot. Actually, the distinction between left and right stabilizer, wing inner and outer is
meaningless. The detail of that isn’t simulated and in practice any one of those controls simply
removes ice from the net structural ice load that the aircraft is carrying. With the main switch set to
manual, when we’re not touching the other switches no de-icing is happening, the boots are un-
inflated and the ice can continue to accumulate.

In passing I will note that in this experiment I have climbed to avoid some mountains, so the outside
air temperature has decreased to around -18 degrees Celsius. Under these conditions I note that the
ice load is no longer increasing even though we are still in an icing cloud layer. This is because the
temperature is below -11 degrees Celsius and it is now too cold for ice to form.

We shall now take a quick look at the other options we have for de-icing. We can move the main
switch to automatic, in which case we note that the ice load shown on the gauge falls continuously.
Setting the rate switch to slow or fast does seem to affect the rate of reduction but it’s not clear that
there is any penalty for setting it to fast. Presumably in the real world there is a cost/benefit trade-off
that makes this distinction useful, perhaps to avoid shedding large chunks of ice too quickly or some
other such practical consideration. But again, in the simulator there appears to be no reason not to just
set this to fast and leave the system on automatic.

For now that is all we need to say about structural icing, although we will revisit this later because
there are some things we can do to make it more of a challenge to fly the aircraft in icing conditions.
Engine icing

Beyond structural ice accumulation we also need to consider what ice formation can do to the
engines. There are a number of different ice-related things that can go wrong with the engines. In the
meantime we have the de-icing boots on automatic so that should keep the effects of structural de-
icing at bay. We also have pitot heat, propeller de-ice and windshield heat on, but the engines are not
protected.

It is convenient to describe the kinds of engine failures we can encounter in terms of the protection
measures that the Twin Otter gives us to guard against them. We have three different protections
against engine icing and we can regard these all as anti-icing rather than de-icing measures. The first
is the intake heaters, labelled ‘intake anti-ice’ on the panel. Next we have an inertial separator,
labelled ‘intake deflector’, which opens a duct that diverts the air around a 90-degree bend in the
intake system. This ensures that any large particles of ice don’t make it around the bend and are
ejected through an aperture in the engine structure. Don’t forget this is a turbine engine, which has
very high-speed components rotating at up to 45,000 rpm and having large chunks of ice hitting the
turbine blades can be catastrophic. In practice the inertial separator is also used on the ground for
protection against ingestion of other foreign-object debris (FOD), although there is no specific
simulation of this in FSX or in the Twin Otter Extended. There is also a third ice protection measure,
which we will come back to later.

There is a random element to how ice-related engine failures happen but in my experience it is fairly
likely in the absence of protective measures. As we did with the airframe icing we can use the engine
anti-ice controls pre-emptively, so we can put them on to guard against the possibility of engine
flameout due to ice ingestion. With the standard Twin Otter Extended there is no reason not to do that
– in other words, there is no penalty to switching on the intake de-icers or extending the inertial
separator.

If you explore what is going on under the hood you will find that Aerosoft’s implementation of these
two systems is independent of the FSX ‘engine_anti-ice’ function. (I discovered this, incidentally,
using the Tracer facility built into LINDA, which is free software I use to program all of my cockpit
buttons and switches.) The engine_anti-ice function, you may recall from earlier, is the function
behind the carburettor heat switch in piston-engined aircraft and you probably know that using this
incurs a penalty because it reduces the density of the air flowing into the engine. This, in turn,
significantly reduces the amount of power the engine is producing.

This power reduction doesn’t happen when we use the intake anti-ice function in the Twin Otter
Extended and I think that is wrong. Having done a bit of research I have discovered some accounts of
turboprop engine anti-ice measures that cause a significant loss of torque. One account noted a 14%
drop in torque associated with the use of the inertial separator. If we look at how the default FSX
engine_anti-ice function behaves, it appears to impose the same power hit for a turbine engine as it
does for a piston engine (about 15% reduction in torque). All things considered, I think it is a fair
addition to the simulation if we switch this on whenever we switch on the Twin Otter’s intake anti-ice
or the inertial separator.
I have done this in my own cockpit and it makes the aircraft more challenging to fly because there’s
now a significant penalty for using either of these anti-icing systems. Because I use LINDA to manage
all my cockpit functions I have done this by simply adding some extra lines to the Lua functions that
are hooked up to the intake anti-ice and inertial separator switches. I have reproduced these modified
functions in an appendix in case you want to try something similar.

The introduction of a performance penalty to the engine anti-ice measures increase the richness of the
simulation because now we have decisions to make that balance safety against being able to do what
we need to do. For example, if we are flying at close to our performance limits we may not be able to
afford to take a 15% power hit and this will constrain our flight planning. In practice we should
probably get a compound hit by using intake heaters and the inertial separator at the same time, but
there is no convenient way to simulate this.

There is more to say about the inertial separator here. When we activate this it doesn’t turn on
instantly, because in real life it actually swivels some mechanical ducts inside the engines. We can
see the progress of the extension or retraction by watching the two ‘dolls-eye’ indicators on the
instrument panel. You might wonder why we have two different engine anti-ice measures that seem to
do the same (or similar) job. In fact there is a measure of redundancy here, in that one of these
systems is electrical and one is pneumatically operated. The system that swivels the duct for the
inertial separator is controlled by bleed air. If we turn off both bleed air switches we find it is no
longer possible to extend the inertial separator or to retract it if it is already out. Having an
independent anti-ice system guards against a failure of the bleed air system.

Intake deflector ‘dolls-eye’ indicator (extended).

Recovery from engine failure

We shall now simulate an engine flame-out from ice ingestion and see what we can do to respond to
it. Let us presume we are flying along with no engine protection measures switched on and an engine,
say the right one, flames out. We can simulate this by pulling the fuel lever back and then pushing it
forwards again. The engine stops, which we can see because the torque gauge falls to zero, but we
still have fuel flowing through the engine. If you look at the prop RPM gauge you will see that we still
also have a high prop RPM, and if we push the prop lever forward we will see close to 100% as the
propeller is windmilling in the airflow. We can get that engine to re-start simply by going go the start
panel and setting the ignition switch to manual, or continuous. Once the engine re-lights, we can put
the ignition switch back to normal. At this point we may want to consider switching on some engine
anti-ice measures!

Incidentally, I have noticed that when we restart an engine like this, sometimes the recovered engine
settles at a much higher torque that the other engine, in spite of the power levers both being set
equally. Sometimes this persists and sometimes it settles down after a few changes in the power
setting. I have a feeling this is that the initial setting of the power lever when the engine starts is of
some significance here, but I haven’t quite been able to make sense of it. Perhaps it is just a bug.

You should see from this discussion that we can regard the use of continuous ignition as a third
protection from and ice-related flameout. As far as I know this is the only situation in which the Twin
Otter Extended can suffer a spontaneous flameout (other than through running out of fuel). We can
switch on continuous ignition as a preventative measure that should immediately re-start the engine in
the event of a flame-out.
Going further with structural icing

We have now examined all the features of the Twin Otter Extended in terms of icing and you might
consider that it is still a bit lacking, particularly the airframe icing. We will now have a look at
something else we can do to improve that.

The most obvious criticism of the icing model – both the one built into FSX and the extended one
modelled by Aerosoft in the Twin Otter Extended – is the lack of any visual indication of structural
ice build-up, so it is actually difficult to know when icing is starting to accumulate. You can argue
(with some merit) that the onset of windshield ice is a useful indication but you might consider that
Aerosoft missed an opportunity by not including an ice gauge in the virtual cockpit.

The other criticism is that even when we get heavy icing on the airframe the only effects that we get
are increased drag and increased weight, we don’t see any noticeable effect on the aerodynamic
performance of the wing and specifically, there is no interference with the flight controls. There is a
prominent placard in the virtual cockpit (on the yoke crossbar) that cautions against using the flaps in
icing conditions, which is a clue that in the real aircraft ice can interfere with our control surfaces
too.

icev10

While researching icing in the Twin Otter I discovered a fairly well-known resource for improving
icing effects. This is in the form of a small gauge, written for Flight Simulator 2004 (a.k.a. FS9) by a
man called Charles Owen. This is packaged with a moderately detailed description of both the effects
of ice formation on an aircraft and an analysis of the shortcomings of how this is modelled in FS9.
The package is called simply ‘icev10.zip’ and you can find it in all the places you normally look for
free downloads.

Because FSX uses the same model of ice formation as FS9 we can also use this gauge in FSX. It does
two different things – the first is to give us a visual indication in the cockpit of the onset of icing, and
also of the severity of ice build-up. Bearing in mind that a gauge in FSX or FS9 can also be a
repository for code that does arbitrary and not necessarily ‘gauge-like’ things, this one also adds extra
features to the icing simulation in parallel to the FSX model.

The icev10 gauge’s extra features add two different extensions to the FSX icing model. First, it notes
the accumulation of structural icing and once that accumulation reaches a particular threshold it starts
to do things to try and simulate effects on the performance of the wing and the tailplane. Specifically,
we get stalls of the wing and stalls of the tailplane – or at least the gauge tries to simulate the effects
of those things, essentially by interfering with the flight controls. That is a huge innovation compared
to what we get built into the default model and also into the Twin Otter Extended because it really
means if we let the ice build up too much we are going to lose control of the aircraft.

The second thing that the icev10 gauge does to extend the icing model is that alongside the regular
FSX model it accumulates a separate ice weight which is intended to represent the effects of freezing
rain. This is, of course, similar to what Aerosoft does in its own extension of the model, so there is
some duplication of functionality here. The icev10 gauge treats the two ice weights as additive – in
other words, the regular accumulation of ice that FSX is tracking and the freezing rain ice that is being
accumulated by the gauge add up to a total ice weight. It is this total which is used to determine
thresholds.

One significant difference between icev10 and the Aerosoft model is that the latter accumulates ice if
you’re flying in sub-zero conditions through snow as well as rain. The icev10 documentation
specifically points out that flying through snow doesn’t cause the same effect as flying through
freezing rain. The rationale here is that freezing rain accumulates not only on the flight surfaces, but
also all over the fuselage as the water runs down the fuselage and freezes. Another crucial difference
is that the icev10 ice that comes from freezing rain isn’t cleared by any of the de-icing systems. That
is authentic, since in real life there are no systems generally speaking that can clear ice accumulated
on the fuselage from freezing rain. This adds another layer of realism because the only way to get rid
of the effects of freezing rain is to get out of the rain as quickly as we can.

Good news, bad news

There is good news and bad news about the icev10 gauge. The good news is it exists, it is free and
easily-installed, it will work in FSX and with a bit of fiddling you can even install it in the virtual
cockpit. Once installed, the visible gauge is just a small rectangle with the words ‘WING ICE’ on it,
that changes colour from its default grey to blue, amber and red according to when and how much ice
has accumulated. By and large it does what it claims to do and the freezing rain model is a
particularly interesting innovation. It will work in any aircraft, not just the Twin Otter.

icev10 gauge installed on top of the transponder in the VC.

The bad news with the icev10 gauge is that it kind of works but in its original form it really doesn’t
work all that well because it has lots of bugs in it. Normally that would have been the end of it but in
poking about I was surprised to discover how simple it is in its execution. I know very little about
gauges and gauge construction but the entire implementation for this gauge is a short XML script that
only runs to about two pages of text. I was sufficiently encouraged by this to spend some time figuring
out how it works and then to go on to figure out what was wrong with it. I have fixed it to work pretty
much as intended and I have also rewritten the script with some commentary in case others might
want to take up the challenge of making it more sophisticated. I have included the modified text in an
appendix.
Correct de-icing with icev10

We are not done yet, because you will find that operating the Twin Otter’s de-icing boots does not
shed FSX-accumulated ice. I think this tells us that the Twin Otter's structural icing model is entirely
internal. This means if we are going to use icev10 we need to make sure we operate the FSX de-icing
functions in parallel with the Aerosoft functions if we want to dump the ice. We could do this just by
mapping different buttons or keys to do it if since I use LINDA I have added the requisite commands
to the Lua functions so that they operate both the Aerosoft de-icing functions and the FSX ones. I have
reproduced the Lua functions I use in an appendix so you can see what is required. If you are going to
do this I suggest you integrate these functions into the full LINDA library file for the Twin Otter
Extended, which you can find at the LINDA download forum.
Tools to explore icing

In case you want to do your own experiments with icing I will point you at some tools I have found
useful. The first is LINDA’s excellent Tracer tool, which lets you explore Lvars, the local variables
used in XML gauges. In the context of our present discussion this is useful for watching the variables
inside the icev10 gauge. The variables worth monitoring are ‘RegularIceLoad’,
‘FreezingRainIceLoad’ and ‘TotalIceLoad’, which I hope are self-explanatory. The XML code works
by comparing ‘TotalIceLoad’ with the values ‘OnePercentEW’ and ‘TwoPercentEW’ (fractions of the
empty weight). I should also mention that I have changed all the variable names in my version of
icev10. You can have a look at the source code for more details.
The next tool is an excellent little program called AFSD (Advanced Flight Simulator Data), which is
available for free from www.aero.sors.fr/designer_pilot_utilities.html. This is a deceptively trivial-
looking program that allows you to look at all of the things going on inside of FSX and the aircraft
model currently loaded. For our present purposes, the ‘Weights and CoG’ section monitors a value
called ‘ice weight’, which is the FSX-maintained structural ice load.
8. Bits and pieces
Flight data recorder

In the development of new technology, the ‘killer app’ is an established meme. It doesn’t matter how
cool or clever your new invention is, people aren’t going to notice until it does something they really
want. It wasn’t until the invention of the digital spreadsheet that the business market really began to
take notice of the personal computer, and the business model that emerged surprised everyone.
Businesses weren’t buying the Apple II – they wanted VisiCalc and they just needed an Apple II to
run it on.

At first sight the Twin Otter’s flight data recorder is uninspiring. The FDR is also found in Aerosoft’s
Airbus products and on closer inspection is actually a slimmed-down version of the ‘black box’ that
ships with FS Flight Keeper, a commercial product in its own right. Essentially it’s an event recorder
that notes what you do with the aircraft’s systems as you fly, in sequence and with times stamps. You
can look at the log afterwards in an event viewer that runs outside of FSX, so you can review what
you did and when. You can also punctuate your logs in a crude way as you fly, by pressing the ‘Test’
button to insert a user-defined event. But what is it for?

I think the Twin Otter’s Flight Data Recorder has been overlooked by many as a solution in search of
a problem. It doesn’t make a lot of sense to the casual simmer until you discover that it also tracks
your position and that it can export your recorded track to Google Earth. This is much more
interesting because it means you can review a visual record of your flight, in three dimensions.
Although I knew this and I tried it out, it still didn’t seem all that useful until I started flying on
PilotEdge. PilotEdge is an online network offering real air traffic control. It’s a paid-subscription
service and they take things very, very seriously.

It is difficult to over-state the immediate difference that flying on PilotEdge makes to your FSX-ing.
As well as knowing how to talk on the radio you need to pay very close attention to the airspace and
treat it with the kind of respect that we generally don’t do in casual flight simulation. And that
airspace is complicated! PilotEdge is based in Southern California, which is some of the busiest
airspace in the world. Even a simple general aviation VFR flight can have you running the gauntlet
through huge invisible canyons and beneath overhanging cliffs, all of which you have to figure out
from a two-dimensional representation on the Sectional chart.

Have a look at the bit of airspace above. Imagine we want to get out of Fullerton (KFUL, at the upper
left), fly to the South East and then off down the coast. Let’s imagine we’re going to take off from
runway 24, then make right downwind departure to the East. The KFUL traffic zone goes up to 2500ft
so we can punch through the top of it pretty quickly into uncontrolled airspace. But we have to be
damned careful! The KFUL ATZ lies under a wedge of the Los Angeles Class B airspace, so we need
to stay below 6000ft. And if we stray too far North before turning downwind that comes down to
4000ft. Okay so far, but as we depart Fullerton to the East we’re going to want to climb past 4400ft
before we turn South East because there’s a big chunk of Class C airspace in the way. And so on.
And the magic is, all that airspace data is freely available for Google Earth as annotated three-
dimensional objects. (You can get it from www.3dairspace.org.uk.) So now we can review our
flights, or rehearse them or even plan them with reference to the Google Earth data. Killer app!
Head-up display

As we have seen, the Twin Otter’s speed is very sensitive to changes of power and this, combined
with the lag in those turboprop engines, can make it a handful when flying a manual approach. In the
absence of physical feel, it is only with by maintaining a good eye for the pitch attitude and frequent
reference to the airspeed indicator that we can maintain precise control. Glancing down at the
instruments is one thing if you have them on a dedicated monitor (or are zoomed out in the virtual
cockpit view), but having done a little research I chose to add a head-up display (HUD) to my
cockpit.

The HUD I chose is a free FSX gauge called HUDCA (Head-up Display Commercial Aircraft
edition), written by Dietmar Loleit, which is based on the Rockwell Collins Head-up Guidance
System as fitted to the Bombardier CRJ 700. You can download this from all the usual outlets. It
comes with a 30-page manual, which explains its operation and configuration. Be warned, though,
because this is not quite plug-and-play – you will likely need to do bit of head-scratching to set it up.
I will give some guidance about how I installed it in the Twin Otter.

The HUD has a few configurable things that you can read about in detail in the manual. The visual
display is composed of two parts, the glass on which the display appears and a solid frame. I have
chosen to omit the frame, which to my eye looks a bit ugly. However, if you do this it means that the
clickable controls for setting the mode, glass transparency and dark/light display will not be
available. Nevertheless, you will be able to manipulate these by binding them to buttons or switches
if you know how. (See later.)

Installing the HUD in the Twin Otter

The installation instructions in the HUDCA manual have defeated a lot of people, so I have created
the following sequence that works for me. (I am assuming that, like me, you use the Virtual Cockpit. If
you don’t, then you may need to innovate.)

(1) Follow the HUDCA installation instructions from the manual to the letter. If you want to make
sure you don’t mess up your Twin Otter you can, as Dietmar suggests, try installing this in the
default B737-800 first. Once that works you can do it again, this time editing the appropriate
panel.cfg for the Twin Otter model you want to modify.

(2) Move (i.e. don’t copy) the 'gauge40' line from the Window00 definition to the end of the
VCockpit01 definition. You can leave the ‘gauge41’ line where it is.

(3) Create a configuration file called something like 'TwinOtterConfig.ini' in the gauges/HUDCA$
folder under your main FSX folder. This specifies the appropriate V speeds and so on, which is
(among other things) how the HUD knows to switch modes in AUTO mode. This is all explained
in the manual but I have given a partial configuration file that will work in an appendix.

(4) Optionally, comment out the 'HUDCA-Frame' line in the Window10 definition (or whatever
window number it is for you). (If you do this you will only be able to control the HUD settings
using Lvars – see below.)

Notes on the above steps

The ‘gauge41’ entry in [Window00] puts a clickable ON/OFF icon at the top left of the 2D main
window, which is what comes up when you press SHIFT+1. You can use this to turn the HUD on and
off if you want.

The ‘gauge40’ line runs the HUDCA configuration program when the window it is installed in is
shown. If we leave it in [Window00] it will not run if we have not pressed SHIFT+1. If we then turn
the HUDCA gauge on it will give errors because it has not been initialised. By moving this line to
VCockpit01 we ensure that the configuration program runs when the aircraft loads.

Setting the correct size and position

The gauge is now installed, but to set the appropriate size and shape for your screen you need to
calculate the 'window_size' and 'window_pos' values for the Window10 and Window11 definitions.
Although the original size of the gauge is noted in the panel.cfg as 768 x 640, that doesn't seem right to
me as the gauge is squashed (circles aren't circular). I have calculated my sizes assuming 768 x 480,
which gives the correct proportions. You need to express these dimensions as a proportion of your
screen width and height. My screen dimensions (in pixels) are 4066 x 1024, so I calculate the values I
need like this:

Width = 768 / 4066 = 0.189

Height = 480 / 1024 = 0.469

Then the position, also expressed as a proportion of screen dimensions:

x = ((4066 - 768) / 2) / 4066 = 0.406

y = 0.125

This centres the gauge horizontally and puts it 1/8 (y=0.125) of the way down from the top of the
screen. (Note that it doesn't quite centre as the frame makes it asymmetrical. Hence it really needs to
be nudged over a bit in the x position.)
Now I use these values in the Window10 and Window11 definitions:

window_size = 0.189, 0.469

window_pos = 0.406, 0.125

If you have a regular 1080p display (1920 x 1080) or any other screen size you can substitute your
own values for width and height in place of my dimensions (4066 x 1024). For the 1080p display, the
values come out as:

window_size = 0.4, 0.44

window_pos = 0.3, 0.125

Controlling the HUD from Lvars

You can switch the HUD on and off and change various features by poking particular values into
Lvars. Taking the ON/OFF control, for example, this means you can write an FSUIPC macro to poke
the HUDCAONOFF Lvar and then bind that macro to a switch or to a couple of buttons. These are all
the Lvars HUDCA exposes:

HUDCAONOFF [0/1]
HUD_AUTO [0/1]
HUD_PRI [0/1/?]
Bright_ONOFF [0/1]
Colormode [0/1/2/3]

You can switch the HUD on without any clicks like this (Lua code):

ipc.writeLvar("L: HUDCAONOFF", 1)
ipc.control(66507, 1768) -- PANEL_ID_OPEN, HUDCA
ipc.control(66507, 1769) -- PANEL_ID_OPEN, HUDCA_Glass

You can also set the brightness and glass density from code in the same way.
I will not explain how to do this in detail. Lua macros are covered in detail in the FSUIPC
documentation. I use LINDA to manage my buttons and switches, so I have written a set of Lua
functions that let me control the HUD entirely from buttons and switches. I have added functions to my
Almost Aviation library, which you can download from here. Just put this library in your LINDA/libs
folder and you will see the functions. I have also included a listing of these functions in an appendix.

I have made the HUD default to 'Bright' mode when you switch it on. I have found it best to leave it in
bright mode all the time and then call the transparency functions to make it more or less visible. I
have made my functions SHIFT aware, which means if you call one while the SHIFT flag is on it
works faster (twice as fast). The best way is to map this to a rotary control with a centre-push switch.

You can see the effect of the transparency functions using the Twin Otter configuration page of the
checklist (SHIFT+2), where you can change this with the mouse wheel. The downside is you can't (as
far as I can tell) set the transparency individually for each panel so this (and the library functions)
affects all panels, including the GPS.
Acknowledgements
This is my own work, borne of hours of grappling with the simulator and trying to make sense of it
all. However, sometimes that sense needs an outside perspective. In trying to make sense of the Twin
Otter Extended the two resources I have drawn on most heavily are the book ‘Otter & Twin Otter’ by
Sean Rossiter and the blog ‘Cockpit Conversation’, available at http://airplanepilot.blogspot.co.uk/.
The former is an excellent summary of the history of de Havilland Canada, from both an economic
and engineering perspective, while the latter is an entertaining and often intoxicatingly technical
account of real-world Twin Otter operations.

It would be neglectful of me not to thank Finn Jacobsen, one of the Aerosoft developers of the Twin
Otter Extended, who provided me with much support while I was building my cockpit.
Appendix A: Sample HUDCA configuration file

This is a sample config file that will work for your Twin Otter installation. This file is in
\fsx\gauges\HUDCA$\TwinOtterConfig.ini. The filename you choose here is the one that must be
referenced in the ‘gauge40’ line you added to panel.cfg when you installed the gauge. See the
HUDCA manual for a full explanation of this file.

//Values for Aerosoft Twin Otter Extended

[LVars]
Lvar_00=Decision_High
Lvar_01=TO_V1
Lvar_02=TO_Rotate
Lvar_03=TO_V2
Lvar_04=V_Landing
Lvar_05=Disp_Radio_High
Lvar_06=Flaps_Takeoff_set
Lvar_07=aircraft_type

[Floats]
Value_00=300.
Value_01=63.
Value_02=63.
Value_03=73.
Value_04=74.
Value_05=2500.
Value_06=2.
Value_07=1.
Value_08=0.
Value_09=0.
Value_10=0.
Value_11=0.

// Intervening lines omitted

Value_99=0.
Appendix B: HUDCA LINDA functions
These functions are extracted from my Almost Aviation library. For the definitive version, visit the
forums at www.almostaviation.com.

-- HUDCA Control functions for LINDA

-- by Mark Hurst
--
-- Function list:
--
-- HUD_ON()
-- HUD_OFF()
-- HUD_Bright()
-- HUD_Dim()
-- HUD_Glass_Lighter()
-- HUD_Glass_Darker()
-- HUD_Auto_Toggle()
-- HUD_More_Transparent()
-- HUD_Less_Transparent()

-- Helper functions

local M_RotaryShiftActive = 0
local BUG_MULTIPLIER = 10

function Rotary_Shift_ON()
M_RotaryShiftActive = 1
end

function Rotary_Shift_OFF()
M_RotaryShiftActive = 0
end

local function nToggleVal(nCurrVal, nVal1, nVal2)

if nCurrVal == nVal1 then
return nVal2
else
return nVal1
end
end

-- HUD functions

local HUD_PanelId = 1768

local HUD_Glass_PanelId = 1769

function HUD_ON()
ipc.writeLvar("L:HUDCAONOFF", 1)
_PANEL_ID_OPEN(HUD_PanelId)
_PANEL_ID_OPEN(HUD_Glass_PanelId)
HUD_Light()
end

function HUD_OFF()
_PANEL_ID_CLOSE(HUD_Glass_PanelId)
_PANEL_ID_CLOSE(HUD_PanelId)
ipc.writeLvar("L:HUDCAONOFF", 0)
end

function HUD_Light()
ipc.writeLvar("L:Bright_ONOFF", 1)
end

function HUD_Dark()
ipc.writeLvar("L:Bright_ONOFF", 0)
end

function HUD_Dark_Light_Toggle()
if ipc.readLvar("L:Bright_ONOFF") == 1 then
ipc.writeLvar("L:Bright_ONOFF", 0)
else
ipc.writeLvar("L:Bright_ONOFF", 1)
end
end

function HUD_Glass_Lighter()
local NewVal = ipc.readLvar("L:Colormode") + 1
NewVal = math.min(NewVal, 3)
ipc.writeLvar("L:Colormode", NewVal)
end

function HUD_Glass_Darker()
local NewVal = ipc.readLvar("L:Colormode") - 1
NewVal = math.max(NewVal, 0)
ipc.writeLvar("L:Colormode", NewVal)
end

function HUD_Glass_Toggle()
ipc.writeLvar("L:Colormode",
(ipc.readLvar("L:Colormode") - 1 + 4) % 4)
end

function HUD_Auto_Toggle()
ipc.writeLvar("L:HUD_AUTO",
nToggleVal(ipc.readLvar("L:HUD_AUTO"), 0, 1))
end

local M_PanelAlpha = 255

local M_SavedPanelAlpha = M_PanelAlpha

function HUD_More_Transparent()

local Step
if M_PanelAlpha > 155 then
Step = 20
elseif M_PanelAlpha > 115 then
Step = 10
else
Step = 5
end

if M_RotaryShiftActive == 1 then
Step = 1
end

M_PanelAlpha = math.max(M_PanelAlpha - Step, 0)

_VIEW_PANEL_ALPHA_SET(M_PanelAlpha)
end

function HUD_Less_Transparent()

local Step
if M_PanelAlpha > 155 then
Step = 20
elseif M_PanelAlpha > 115 then
Step = 10
else
Step = 5
end

if M_RotaryShiftActive == 1 then
Step = 1
end

if M_RotaryShiftActive == 1 then
Step = 1
end

M_PanelAlpha = math.min(M_PanelAlpha + Step, 255)

_VIEW_PANEL_ALPHA_SET(M_PanelAlpha)

end

function HUD_Toggle_Transparency()
-- Toggles HUD alpha between a saved value and 255 (max).
-- Saves the value if not at max.
M_PanelAlpha, M_SavedPanelAlpha))
if M_PanelAlpha == 255 then
M_PanelAlpha = M_SavedPanelAlpha
_VIEW_PANEL_ALPHA_SET(M_PanelAlpha)
else
M_SavedPanelAlpha = M_PanelAlpha
M_PanelAlpha = 255
_VIEW_PANEL_ALPHA_SET(M_PanelAlpha)
end
end
Appendix C: LINDA functions for enhanced icing
These functions are from the LINDA library for the DHC-6, available for download at the LINDA
download forum. You can get my own personal version of this file at the Almost Aviation forums.
They are from two sections of the original file (the ‘Deice’ and ‘Deicer Boots’ sections). I have not
reproduced all of the ice-related functions here, only the ones that I have modified. My modifications
are commented. (For brevity I have also removed the ‘DspShow()’ and Twotter_Switchsound()’
calls.) You should be able to figure out what I have done by studying this code.

Essentially, the modifications do two things. (1) Where it is relevant I am arranging to invoke the FSX
native de-icing call in parallel with the Aerosoft one to clear ice accumulated by the icev10 gauge.
This is necessary for the icev10 indications and ‘interference’ behaviour to work correctly. (2) I am
switching the FSX native engine anti-ice function on and off when we operate the Aerosoft intake
deflector or Intake de-icer. This gives us a penalty (loss of power) when using these systems. See the
text for full details.

-- ## Deice ###############

-- MH...
local function FSX_IntakeDeice_ON()
_ANTI_ICE_SET_ENG1(1)
ipc.sleep(math.random(0, 1000)) –- This line is just for effect
_ANTI_ICE_SET_ENG2(1)
end

local function FSX_IntakeDeice_OFF()

_ANTI_ICE_SET_ENG1(0)
ipc.sleep(math.random(0, 1000)) –- This line is just for effect
_ANTI_ICE_SET_ENG2(0)
end
-- ...End MH

function IntakeDeice_on ()
ipc.writeLvar("L:IntakeDeice", 1)
FSX_IntakeDeice_ON()
end

function IntakeDeice_off ()
ipc.writeLvar("L:IntakeDeice", 0)
-- MH...
if ipc.readLvar("L:Intake_DeflectorB_pos") == 0 then
FSX_IntakeDeice_OFF()
end
-- ...End MH
end

function Intake_Deflector_Sw_off ()
ipc.writeLvar("L:Intake_Deflector_Sw", 0)
-- MH...
if ipc.readLvar("L:Intake_DeflectorB_pos") == 1 then
FSX_IntakeDeice_ON()
else
if ipc.readLvar("L:IntakeDeice") == 0 then
FSX_IntakeDeice_OFF()
 end
end
-- ...End MH
end

-- ## Deicer Boots ###############

-- MH...
local OFF_STRUCT_DEICE_SWITCH = 0x337D -- 1 byte
local OFF_STRUCT_ICE_AMOUNT = 0x0348 -- 2 bytes
-- ...End MH

function AI_ManAuto_sw_auto ()
ipc.writeLvar("L:AI_ManAuto_sw", 1)
-- MH...
-- Switch on the default FSX anti-ice too, but only
-- if we have bleed air.
-- Technically this will fail if we switch on bleed
-- air after the 'auto' switch, but I think we can
-- live with that.
if (ipc.readLvar("L:BleedairL") == 1
or ipc.readLvar("L:BleedairR") == 1) then
ipc.writeUB(OFF_STRUCT_DEICE_SWITCH, 1)
end
-- ...End MH
end

function AI_ManAuto_sw_off ()
ipc.writeLvar("L:AI_ManAuto_sw", 0)
-- MH...
ipc.writeUB(OFF_STRUCT_DEICE_SWITCH, 0)
-- ...End
end

-- MH
-- For each of the following four manual de-ice actions,
-- switch the default FSX de-icing on too. (We switch it
-- off in the corresponding release function.)

function AI_WingInOut_sw_outer ()
ipc.writeLvar("L:AI_WingInOut_sw", 1)

-- MH...
if (ipc.readLvar("L:BleedairL") == 1 or
ipc.readLvar("L:BleedairR") == 1)
and (ipc.readLvar("L:AI_ManAuto_sw") == -1) then
ipc.writeUB(OFF_STRUCT_DEICE_SWITCH, 1)
end
-- ...End MH
end

function AI_WingInOut_sw_inner ()
ipc.writeLvar("L:AI_WingInOut_sw", -1)
-- MH...
if (ipc.readLvar("L:BleedairL") == 1 or
ipc.readLvar("L:BleedairR") == 1)
and (ipc.readLvar("L:AI_ManAuto_sw") == -1) then
ipc.writeUB(OFF_STRUCT_DEICE_SWITCH, 1)
end
-- ...End MH
end
function AI_WingInOut_sw_release ()
ipc.writeLvar("L:AI_WingInOut_sw", 0)
-- MH...
if (ipc.readLvar("L:AI_ManAuto_sw") ~= 1) then
-- Don't do this if we're on auto!
ipc.writeUB(OFF_STRUCT_DEICE_SWITCH, 0)
end
-- ...End MH
end

function AI_Stab_LR_sw_right ()
ipc.writeLvar("L:AI_Stab_LR_sw", 1)
-- MH...
if (ipc.readLvar("L:BleedairL") == 1 or
ipc.readLvar("L:BleedairR") == 1)
and (ipc.readLvar("L:AI_ManAuto_sw") == -1) then
ipc.writeUB(OFF_STRUCT_DEICE_SWITCH, 1)
end
-- ...End MH
end

function AI_Stab_LR_sw_left ()
ipc.writeLvar("L:AI_Stab_LR_sw", -1)
-- MH...
if (ipc.readLvar("L:BleedairL") == 1 or
ipc.readLvar("L:BleedairR") == 1)
and (ipc.readLvar("L:AI_ManAuto_sw") == -1) then
ipc.writeUB(OFF_STRUCT_DEICE_SWITCH, 1)
end
-- ...End MH
end

function AI_Stab_LR_sw_release ()
ipc.writeLvar("L:AI_Stab_LR_sw", 0)
-- MH...
if (ipc.readLvar("L:AI_ManAuto_sw") ~= 1) then
-- Don't do this if we're on auto!
ipc.writeUB(OFF_STRUCT_DEICE_SWITCH, 0)
end
-- ...End MH
end
Appendix D: Installing the icev10 gauge
You can get the icev10 gauge by searching all the regular places for 'icev10.zip'. Unfortunately the
original has a bunch of problems, which I have fixed by tweaking the XML file. I have reproduced my
rewritten XML file in the next appendix. You can also download it from the Almost Aviation forums.

Save this text somewhere safe in a file named ‘IceWarning.xml’. Now install the gauge from the
original zip file, then copy my XML file over the original one. You can install the gauge as a 2D panel
if you want, but I have managed to pop it into the VC by putting it on top of the transponder. It covers
up the altitude readout but that's no real loss.

To get the gauge here you need to add a line to the [VCockpit01] section of panel.cfg:

gauge16=ICE!IceWarning, 8, 441, 120, 60

You will notice that the position numbers are the same as those of the transponder gauge, so you can
experiment with putting it in other places instead. It works over the clock too. It would be nice to get
this in place of the stall warning but I don't know how to do it.
Appendix E: icev10 gauge updated XML

<Gauge Name="Ice Warning Gauge"

Version="1.1 Tweaked by Mark Hurst, markh@keysound.com">
<Element>
<Select>
<Value>(L:IcingSeverity,enum)</Value>
<Case Value="0">
<Image Name="Ice_Off.bmp" Luminous="Yes"/>
</Case>
<Case Value="1">
<Image Name="Ice_Blue.bmp" Luminous="Yes"/>
</Case>
<Case Value="2">
<Image Name="Ice_Yellow.bmp" Luminous="Yes"/>
</Case>
<Case Value="3">
<Image Name="Ice_Red.bmp" Luminous="Yes"/>
</Case>
</Select>
</Element>

<Element>
<Shift>
<Value>

<!--
*****************************************************************
Ice Warning Gauge (a.k.a. 'icev10')
*****************************************************************

Original gauge by Charles (Dutch) Owen.

This XML code modified and commented by Mark Hurst, June 2015.
markh@keysound.com
www.keysound.com

Changes from the original

*************************

(1) Ice now accumulates at a rate that is in proportion to the

aircraft size (actually the Empty Weight) instead of at a
constant rate for all aircraft.

(2) Freezing rain now accumulates ice even if the regular ice
load is not increasing.

(3) Freezing rain ice now only melts if we are out of the icing
conditions.

(4) Freezing rain ice no longer rises without limit.

(5) Freezing rain ice melts faster than it accumulated. The

rates are tunable by changing the constants defined below.

(6) Interference with the controls in AMBER and RED zones now
also disconnects the autopilot.
(7) Interference with controls in the RED zone is a bit more
variable. (Same as AMBER zone plus a guaranteed tailplane
stall at cruising speed.

(8) Interference with controls leaves the aircraft somewhat

controllable.

Implementation notes
********************

The behaviour is essentially the same as the original gauge but

with a few rough edges smoothed off. The regular ice load is
tracked using FSX's internal percentage rather than pounds as
in the original gauge. This has the advantage that ice
accumulation rate is in proportion to the aircraft size. We
accumulate freezing rain ice using the same percentages and
apply the same thresholds as in the original (1% and 2% of Empty
Weight)to determine severity of icing. Although it looks like we
can now accumulate 200% of the maximum ice load defined by FSX
(i.e. 100% FSX ice plus 100% additional freezing rain ice), FSX
will not know about the additional 100%. In other words, its only
significance is in how we choose to interpret that extra load in
this script.

The simulation of stalls at high ice loads is not very

sophisticated but given that we should never get there it is
convincing enough. For example, we will be able to stay flying
but we will not be able to land or do much of anything until we
have cleared the ice. (We can no longer use the autopilot to fly
the aircraft perfectly in spite of a critical ice load!)

*****************************************************************
-->

<!--
All loads are percentages of maximum ice load. FSX calculates
100% ice loading for any aircraft as 5.5% of its empty weight.

We monitor the ice load maintained by FSX but we keep a separate

accumulation of ice attributed to freezing rain (FRI). We use the
total load for deciding when to change the warning indicator and
when to mess with the controls. In principle this means that the
total ice load can go above 100%, but in practice this doesn't
matter as we'll be in trouble long before then.
-->

<!-- Script is invoked on the 55ms system timer -->

18 (>L:TicksPerSecond, Number)

(L:ClockTick, number) 1 + (>L:ClockTick, number)

(L:ClockTick, number) 18 >= if{

<!-- This block runs every second -->

<!-- CONSTANTS -->

<!-- FSX accumulates regular ice at 0.05% -->

0.05 (>L:FRIceGainPerSecond, Percent)
<!-- Let's assume FRI melts faster than it builds -->
0.10 (>L:FRIceLossPerSecond, Percent)
0 (>L:ICE_CLEAR, enum)
1 (>L:ICE_BLUE, enum)
2 (>L:ICE_AMBER, enum)
3 (>L:ICE_RED, enum)

<!--
The original gauge used the limits 1% of Empty Weight and
2% of Empty Weight to determine the boundaries between
Blue/Amber and Amber/Red conditions. We'll stick with that
but we need to calculate these as percentages.
-->

<!-- 100% icing is 5.5% EW, so 1% EW is 100/5.5 -->

18.2 (>L:OnePercentEW, Percent)
<!-- Likewise, 2% EW is 2*100/5.5 -->
36.4 (>L:TwoPercentEW, Percent)

<!-- END OF CONSTANTS -->

<!-- Get the current ice load from FSX -->

(A:Structural Ice Pct, Percent) (>L:RegularIceLoad, Percent)

(L:RegularIceLoad, Percent)
(L:FreezingRainIceLoad, Percent)
+ (>L:TotalIceLoad, Percent)

<!-- Set the indicator -->

(L:ICE_CLEAR, enum) (>L:IcingSeverity, enum)
(L:TotalIceLoad, Percent)
(L:TwoPercentEW, Percent) &gt; if{
(L:ICE_RED, enum) (>L:IcingSeverity, enum)
}
els{
(L:TotalIceLoad, Percent)
(L:OnePercentEW, Percent)
&gt; if{
(L:ICE_AMBER, enum) (>L:IcingSeverity,enum)
}
els{
(L:TotalIceLoad, Percent) 0.5 &gt; if{
(L:ICE_BLUE, enum) (>L:IcingSeverity,enum)
}
}
}

(L:PrevRegularIceLoad, Percent)
(L:RegularIceLoad, Percent) &gt; if{
<!--
If FSX shows the ice load falling, we may want to melt
some of the freezing rain. However, we only shed freezing
rain ice if it's warm enough. The ice load may be
reducing because we have switched the de-icing boots on!
(The de-icing boots do not shed freezing rain ice.)
-->
(A:AMBIENT TEMPERATURE, celsius)
1 &gt; if{
(L:FreezingRainIceLoad, Percent)
(L:FRIceLossPerSecond, Percent)
- (>L:FreezingRainIceLoad, Percent)
}
}
 els{
<!--
The regular FSX ice load is rising or is static. It can
be static if it has fallen to zero or if the temperature
is now too low to accumulate further ice. It can fall to
zero because the temperature has increased and the ice
has all melted or because we have switched de-icing
measures on.
-->
(A:AMBIENT TEMPERATURE,celsius)
1 >= if{
<!--
It's warmed up, so we melt some freezing rain ice.
-->
(L:FreezingRainIceLoad, Percent)
(L:FRIceLossPerSecond, Percent)
- (>L:FreezingRainIceLoad, Percent)
}
els{
<!--
It's still cold, so we may need to accumulate
freezing rain ice if the other conditions are right.
-->
(A:AMBIENT TEMPERATURE, celsius)
-11 &gt; if{
(A:AMBIENT PRECIP STATE, number)
4 == if{
<!--
Temp is between -11 and +1 and it's raining,
so we add some ice. We arbitrarily limit the
freezing rain ice load to approximately 100%
(i.e. 100% of the maximum ice load, which is
equivalent to 5.5% of the empty weight).
This means that we can reach the maximum FSX
ice load even if we have de-icing measures on
and are flying through freezing rain.
-->
(L:FreezingRainIceLoad, Percent)
100 &lt; if{
(L:FreezingRainIceLoad, Percent)
(L:FRIceGainPerSecond, Percent)
+ (>L:FreezingRainIceLoad, Percent)
}
}
}
}
}

(L:FreezingRainIceLoad, Percent)
0 &lt; if{
0 (>L:FreezingRainIceLoad, Percent)
}

(L:RegularIceLoad, Percent) (>L:PrevRegularIceLoad, Percent)

0 (>L:ClockTick, number)
}

<!--
The rest of the script runs every clock tick, or up to 18 times
per second. Everything below here deals with the interference
code, which simulates wing and tailplane stalls if we are
carrying too much ice.
-->

<!-- We define a speed limit based on the Empty Weight. -->

100 (>L:SlowSpeed, number)

(A:Empty Weight, pounds) 6999 &gt; if{
110 (>L:SlowSpeed, number)
}
(A:Empty Weight, pounds) 9999 &gt; if{
120 (>L:SlowSpeed, number)
}
(A:Empty Weight, pounds) 29999 &gt; if{
130 (>L:SlowSpeed, number)
}
(A:Empty Weight, pounds) 39999 &gt; if{
140 (>L:SlowSpeed, number)
}
(A:Empty Weight, pounds) 49999 &gt; if{
150 (>L:SlowSpeed, number)
}
(A:Empty Weight, pounds) 99999 &gt; if{
160 (>L:SlowSpeed, number)
}

<!--
Now we do various things to knobble the flight controls.
The 'UpsetCounter' is used to introduce delays in our
interference when we're in the RED zone. It gets wound back when
we drop back into the other zones. (This logic isn't great but
it's preserved more or less intact from the original version.)
-->

(L:IcingSeverity, enum)
(L:ICE_AMBER, enum) == if{

<!--
Moderate interference that we should be able to recover from.
-->

<!-- This counter is for the RED zone actions -->

(L:UpsetCounter, number) 1 - (>L:UpsetCounter, number)
(L:UpsetCounter, number)
0 &lt; if{
0 (>L:UpsetCounter, number)
}

(A:AIRSPEED TRUE, knots)

(L:SlowSpeed, number) &lt; if{
<!--
If we're flying slowly, fake a wing stall. Remember
that this happens 18 times per second, not just once,
so it is almost impossible to override it with the
flight controls.
-->
1 (>K:AUTOPILOT_OFF)
-10384 (>K:AILERON_SET)
5000 (>K:ELEVATOR_SET)
}
els{
<!--
 Otherwise fake a tailplane stall. I'm not convinced of
the logic here as in many (most?) cases we should not
have the flaps down if we are flying faster than our
'slowflight' cutoff.
-->
(A:Trailing edge flaps0 left percent,percent)
24 &gt; if{
1 (>K:AUTOPILOT_OFF)
10000 (>K:ELEVATOR_SET)
}
}
}
els{

(L:IcingSeverity, enum)
(L:ICE_RED, enum) == if{

<!--
The same moderate interference as we find in the amber
zone applies.
-->

(A:AIRSPEED TRUE, knots)

(L:SlowSpeed, number) &lt; if{
1 (>K:AUTOPILOT_OFF)
-10384 (>K:AILERON_SET)
5000 (>K:ELEVATOR_SET)
}
els{
(A:Trailing edge flaps0 left percent, percent)
24 &gt; if{
1 (>K:AUTOPILOT_OFF)
10000 (>K:ELEVATOR_SET)
}
els{

<!--
Outside of that we can also fake a tailplane
stall. There is an arbitrary delay in the onset
of this interference. The original version was
persistent but here we apply the stall at half-
second intervals to retain some control!
-->

(L:UpsetCounter, number)
1 + (>L:UpsetCounter, number)
(L:UpsetCounter, number)
<!-- Approx 22 second delay -->
400 &gt; if{
<!--
MOD 9 operation does it twice per second
-->
(L:UpsetCounter, number)
9 % 0 == if{
1 (>K:AUTOPILOT_OFF)
10000 (>K:AILERON_SET)
10000 (>K:ELEVATOR_SET)
}
}
}
}
 }
els{
(L:UpsetCounter,number) 1 - (>L:UpsetCounter,number)
(L:UpsetCounter,number)
0 &lt; if{
0 (>L:UpsetCounter,number)
}
}
}

</Value>
</Shift>
</Element>

</Gauge>