Starting Sequence and Batch File Use for ProSim737 Avionics Suite

Splash screen - Prosim737 main module (startup sequence added)

Introduction

A full cockpit simulator that emulates Boeing 737 avionics is far more complex than a desktop flight simulator. A full cockpit simulator integrates multiple hardware components, a complete avionics suite, and several layers of ancillary software. Each component, whether responsible for flight controls, cockpit displays, or system logic must communicate reliably with the others to maintain a seamless and accurate simulation environment.

Because the system’s components are interdependent, the software must be started and shut down in a logical sequence to maintain stability, performance, and consistent behaviour. This is especially important when multiple applications are part of the same workflow, as each component may depend on specific services, configuration states, or background tasks being completed prior to initialisation.

This guide outlines the recommended startup sequence for the ProSim737 avionics suite. It also describes the key components involved and introduces batch files as a practical method for automating the process, ensuring that the flight simulator and its supporting software start and shut down in a controlled and predictable sequence.

Terminology Note: In this article, the terms run, launch and start are used interchangeably.

ProSim737 - Module Instances and Configuration

The ProSim737 avionics suite is designed to operate in both single and multi-computer environments. To support this flexibility, the platform allows a variety of system configurations, including running multiple instances of the same module simultaneously. The only exception is the ProSim737 main module, which must be installed on the server computer running Flight Simulator.

This capability allows individual modules to be tailored to specific functions, providing flexibility in how displays, audio, and other systems are configured. For example, a single display module can be started multiple times to serve different cockpit functions. Four instances can provide the Captain’s and First Officer’s Primary Flight Displays (PFD) and Navigation Displays (ND).

The same principle applies to the audio module. Multiple instances can run in parallel, enabling specific sounds, such as callouts, system alerts, or environmental audio, to be routed to different speakers throughout the simulator.

Typical ProSim737 Setup

A typical Flight Simulator setup will run one or more instances of the following ProSim software:

  • ProSim737 main module.

  • ProSim IOS (Instructor Operator Station).

  • ProSim Display module.

  • ProSim Audio module.

  • ProSim Hardware Connector.

  • ProSim CDU.

  • ProSim Overhead (main panel).

  • ProSim Chrono module (clock and timer).

More complex setups may involve both server and client computers, with multiple instances of the same components running across the network. To ensure proper communication between these modules, the ProSim737 main module must be running and active, as it manages all interactions within the ProSim737 avionics suite.

ProSim737 Module Startup and Communication Logic

The most important module in the ProSim737 family is the ProSim737 main module, which serves as the central controller and must be running and initialised before other modules can communicate.

When run, the ProSim737 main module will:

  • Scan the network for other ProSim modules;

  • Establish communication channels (typically via TCP/UDP);

  • Begin sending and receiving data packets; and

  • Activate the other modules, which ‘wake up’ once communication is established (if in standby mode).

If any other ProSim module is opened before the main module, it remains idle; it processes no flight data, performs no system initialisation, and generates no errors - until a connection with the main module is established. Therefore, running modules in standby mode does not harm the software or corrupt any files.

Although ProSim737 is robust and capable of connecting to its sister modules, starting modules in standby mode before the main module can sometimes cause issues. These may include the main module failing to connect to the server, or individual modules not receiving data or functioning correctly.

For this reason, it is recommended to start the ProSim737 main module first. Once it is running, the remaining modules can be opened to ensure a clean connection and a smooth startup process.

If the main module fails to connect, or if an individual module is not functioning correctly, simply close all ProSim modules and restart them. Flight Simulator and other supporting programs can remain running.

Important Point

  • ProSim737 modules can be started in any sequence. However, for the most logical, reliable, and consistent operation, it is recommended to start the main module first, allow it time to initialise, and then start the remaining modules.

When to Start Flight Simulator and ProSim737

For the ProSim737 avionics suite to operate correctly, it is important to follow a logical startup sequence. Begin by starting Flight Simulator, loading a flight, and positioning the aircraft on the runway with the wheel brakes applied to prevent unintended movement. Once Flight Simulator is running correctly, start the ProSim737 main module. After the main module has opened and the software has initialised, the remaining modules can be started.

Launching modules in the wrong sequence will not damage the software, but following a controlled startup sequence ensures each application has time to initialise, establishes clean inter‑module communication, reduces the risk of conflicts, and allows background services to stabilise before use.

Flight Simulator should be started first because ProSim737 relies on several layers of software hierarchy that must communicate with Flight Simulator before the main module can initialise successfully.

Ancillary Software

Although real‑world testing has shown no issues, it is good practice to start any additional software only after Flight Simulator and ProSim737 are running, unless the additional software’s own manual specifies a different startup sequence.

Active Sky

Active Sky (ASFS) is widely used by ProSim737 users because it provides realistic rainfall returns on the weather radar. Hi‑Fi recommends starting Active Sky before launching Flight Simulator so that the desired weather can be viewed and selected prior to loading a flight. However, this is not essential, Active Sky can also be started after Flight Simulator is already running.

Since the ProSim737 main module reads weather information during its startup sequence, it is best to have Active Sky running with the weather already selected (or live weather downloaded and displayed) before starting the main module.

Recommended Starting Sequence

After Flight Simulator and the ProSim737 main module have been started, there is no specific sequence that the remaining modules should be opened. The following is a suggestion:

  1. Flight Simulator.

  2. ProSim737 main module (wait until running and initialised).

  3. ProSim Hardware Connector (if required).

  4. ProSim Display module (Captain and First Officer-side PFD, ND and EICAS - any sequence).

  5. ProSim Audio module (s).

  6. ProSim Chrono module.

  7. ProSim Overhead (main panel).

  8. ProSim other components/displays (if required).

  9. ProSim CDU.

  10. Ancillary Programs.

Note: In this startup sequence, Active Sky (if used) may be started either after Flight Simulator but before starting the ProSim737 main module, or prior to starting Flight Simulator.

Closing ProSim737, Flight Simulator and Ancillary Programs

There is no officially defined shutdown protocol, and depending on your setup, it may be necessary to keep the ProSim737 main module running to use the IOS for closing client computers (For IOS to function, it must maintain a connection with the main module). The following shutdown sequence is therefore recommended:

  1. Close ancillary programs.

  2. Close all ProSim components and displays.

  3. Close ProSim IOS.

  4. Close ProSim737 main module.

  5. Close Flight Simulator.

Batch File Use

Batch files provide an efficient way to automate repetitive tasks within a simulator environment. When configured correctly, they streamline the startup and shutdown of multiple applications, reduce operator workload, and ensure programs run in a controlled, predictable sequence.

This section offers an overview of batch file usage, key concepts, and common syntax relevant to ProSim737 and associated Flight Simulator software.

Function of Batch Files

A batch file is a simple script that executes a series of Windows commands automatically. In a simulation environment, batch files are particularly useful for:

  • Launching, closing, or terminating multiple programs in a defined sequence;

  • Managing timing between application launches;

  • Displaying status messages to the operator; and

  • Reducing manual input and the potential for error.

Batch files can range from very simple (one or two commands) to highly complex scripts containing logic, error handling and console display formatting.

For example, a typical startup batch file used for a simulator session may:

  • Display a formatted header;

  • Launch multiple simulator-related applications;

  • Start programs from specific directories;

  • Display confirmation messages after each command;

  • Insert timed pauses between launches (timeouts);

  • Report success or failure of each operation;

  • Display timestamps or proprietary information; and

  • Automatically close the console window after a defined delay (to allow time to read the console display message).

The batch file may also configure the console display (the pop-up window that appears when it runs) by:

  • Disabling command echoing (@echo off): prevents commands from being displayed;

  • Setting UTF‑8 encoding (chcp 65001): enables support for additional special characters; and

  • Applying custom console colors (color 2F): changes the text and background colors for improved readability.

While the advantages of a startup batch file are clear, a shutdown batch file is equally valuable. Both provide significant time savings and offer a convenient, one‑click method for opening or closing a flight simulator session.

Special Note - Shutting Down Active Sky

Active Sky requires a graceful, timed shutdown. Closing the program without allowing sufficient time can prevent it from shutting down correctly, which may cause it to fail to connect to its server the next time it is started.

If the batch file does not close Active Sky properly, it is recommended to close the program manually. This can be done either by clicking the X in the top-right corner of the window or by right-clicking the Active Sky icon in the Taskbar and selecting Close.

System Stability and Timeouts

Launching multiple programs simultaneously using a batch file can sometimes overload system resources or cause applications to initialise incorrectly, particularly when network connections must be established before proper operation. To prevent this, it is recommended to include a short pause between commands to allow for:

  • Completion of background processes;

  • Graceful initialisation of programs; and

  • Establishment of stable connections for network-dependent modules.

Most ProSim737 modules initialise quickly, and a one-second pause between each module is usually sufficient. However, some modules may require slightly longer delays if additional startup time is needed or if the computer is operating under limited resources. The ProSim737 main module typically takes the longest to initialise; however, a slight overlap during the startup of other modules rarely, if ever, causes issues.

When the main module runs on a server machine and the remaining modules run on a client machine, it should be allowed to fully initialise before starting any client-side modules. This ensures that all dependent components can connect cleanly and helps prevent unnecessary connection errors.

Important Point

  • Timeouts are strongly recommended in startup scripts. During shutdown, they are optional but still beneficial, as programs may require time to save data and close gracefully.

Creating a Batch File

  1. Start Notepad.

  2. Enter the file path and desired batch commands.

  3. Save the file: choose Save As - All Files and apply the .bat extension.

  4. Create a desktop shortcut if desired (the shortcut can also be pinned to the Taskbar).

Note: The batch file can be edited at any time by right-clicking the file and selecting Edit.

Because batch syntax is extensive, the most practical way to learn is to adapt an existing working script. Sample batch files are available for download in the file download section (Batch Files ProSim737 Advanced).

If you search the Internet, you will find several methods to create batch files of varying complexity. Often, there are multiple ways to accomplish the same task.

Important Point

  • Long file paths are easy to mistype. To copy a file path accurately:

  1. Hold Shift and right-click the file; and

  2. Select Copy As Path.

The copied path can then be pasted into Notepad along with the appropriate batch command.

Common Batch Commands

There are many batch commands that can be used. Table 1 outlines some of the more common commands used.

TABLE 1: Common batch file commands

My Preferences

I do not use a batch file to start Flight Simulator (MSFS 2020/2024) or Active Sky.

Flight Simulator can take considerable time to load, depending on connection speeds, and it is important that the software starts gracefully without competing processes. I manually start Active Sky from a taskbar shortcut after Flight Simulator is running and the aircraft is stable at the selected airport.

I do use batch files to start the ProSim737 main module and other ProSim components on both server and client computers. A corresponding closure batch file shuts down all programs on the server and client machines.

Sample Batch Files

In the sample closure batch file (see the gallery and download section), several programs are listed; some which may not be running when the batch file is executed. This is intentional, as different programs are often used during testing. In practice, executing a batch file that attempts to close programs not currently running has no effect - Windows simply ignores the command without causing any issues.

Troubleshooting Starting Sequence and Batch File Issues

Startup problems with ProSim737 are most often caused by connection issues between the ProSim737 main module and its associated modules. If errors occur during startup:

  1. Allow sufficient time for the ProSim737 main module to start and initialise. Ensure the module connects to the server and fully initialises before starting any other modules.

  2. If problems persist, especially after installing an update, the recommended approach is to:

  • Uninstall ProSim737 and reinstall the latest full (non-beta) release (including modules).

  • After confirming that version works correctly, you may then update to the latest beta if desired.

Important Point

Many startup problems can also related to batch files, particularly if you are unfamiliar with their syntax or directory paths. If a batch file does not function as expected, check that:

  • All directory paths are correct;

  • Commands are typed accurately; and

  • Appropriate delays (timeouts) are included between module launches (if required).

Additional Information

Final Call

Starting ProSim737 modules in the wrong sequence will not damage the software, but following a logical startup sequence and allowing each application time to initialise helps the system establish clean, reliable communication between modules - particularly the ProSim737 main module. By following this controlled startup approach, the likelihood of conflicts is reduced, background services have time to stabilise, and the environment for running Flight Simulator becomes more stable.

To help maintain this stable environment, batch files automate the sequence: they start and close each program in a consistent, methodical sequence, reinforcing the clean startup conditions the system relies on for stable inter‑module communication.

Gallery

Screenshots of batch file examples, batch file syntax colour table and common batch syntax commands.

Disconnecting the Autothrottle and Autopilot (Normal and Non-Normal Operations)

Mode Control Panel (MCP) showing A/T toggle and speed window

This article will examine the use of the autothrottle during normal operations and explore several non-normal conditions, highlighting both the advantages and potential drawbacks. It will also discuss the relationship between the autopilot and autothrottle, offering insight into why the recommended procedure is to operate them in unison, rather than using one without the other.

Note that single engine operation will not be addressed as this is a separate subject.

A search on aviation forums will uncover a plethora of comments concerning the use of the autothrottle which, combined with the use of the autopilot and non-normal procedures, can easily be misconstrued. An interesting discussion can be read on PPRuNe forum.

What is the Autothrottle

The Autothrottle (A/T) is a part of the Automatic Flight System (AFS) comprising the Autopilot Flight Director System (AFDS) and the flight management computer. The autothrottle provides automatic thrust control through all phases of flight and its functionality is designed to operate in unison with the Autopilot (A/P).

Autothrottle Use

The autothrottle is armed whenever the A/T toggle is set to the UP and latched position and the green-coloured annunciator is illuminated on the Mode Control Panel (MCP). The autothrottle is engaged when either the N1 or SPEED button annunciator is illuminated.

The autothrottle is usually engaged during the takeoff roll by pressing one or both TOGA buttons located under the thrust handles. TOGA, sometimes referenced as TO/GA (note diagonal line) is an abbreviation for Takeoff/Go-Around.

Stabilisation Criteria (during takeoff roll)

Allowing the engines to stabilize during the takeoff roll is important, as stabilisation prevents thrust asymmetry whereby one engine may spool at a slower rate during the commencement of takeoff thrust.

%N1 and %N2

TOGA is selected when %N1 readings stabilise for both engines (both arcs matched) at around 40%N1, and when the EGT numbers decrease slightly, typically after 2-3 seconds. Although %N1 (fan speed) is the primary reference for takeoff thrust monitoring, %N2 (core speed) which stabilises earlier at around 20-25% can also be monitored - but bear in mind %N2 is not the key metric.

The reason the autothrottle is used during takeoff, is to simplify thrust procedures during a busy segment of the flight and to ensure that both engines are generating similar thrust.

FMA Captain-side PFD showing n1 and TOGA annunciation during takeoff roll. A green coloured display indicates that a particular mode is active - green for go or green is live

Once engaged, the TOGA command mode will control the thrust outputs to the engines until the mode is exited, either at the designated altitude set on the MCP, or by activating another automaton mode such as Level Change (LVL CHG).

When TOGA is engaged, the Flight Mode Annunciator (FMA) will display N1 and TOGA. The FMA display indicates to the flight crew what the AFS is doing.

Important Point:

  • Always monitor the FMA to know what mode is selected and whether the mode is armed or engaged. The monitoring of the FMA cannot be understated.

The Autothrottle is Designed to be Coupled with the Autopilot

The autothrottle is a sophisticated automated system that will continually update thrust based on minor pitch and attitude changes and operates exceptionally well when coupled with the autopilot. But when the autopilot is not selected and the autothrottle is selected by itself, its reliability can be questionable.

Some individuals believe that during a landing with the autopilot off and the autothrottle engaged, a drop in airspeed, such as during the flare, will cause the autothrottle to apply thrust. While this is technically true, there is a lag between the initiation of the thrust command and the engines spooling to the commanded %N1. As a result, there is a risk of a tail strike as the aircraft’s pitch increases before the engines have produced the required thrust. Likewise, excessive wind gusts during the approach can lead to pitch coupling (discussed below).

The advantages of using the autothrottle and autopilot together (coupled) are:

  • Speed is stabilised;

  • Speed floor protection is maintained;

  • Task loading is reduced; and,

  • Flight crews can concentrate on visual manoeuvring and not have to be overly concerned with wind additives.

The disadvantages of using the autothrottle with the autopilot not selected are:

  • Additional crew workload and possible loss of situational awareness (due to workload);

  • Potential excessive and unexpected throttle movement caused by pitch and attitude changes;

  • Potential excessive airspeed when landing in windy conditions with gusts;

  • The potential for pitch coupling to occur (discussed below); and,

  • A loss of thrust awareness (out of the loop).

Important Point:

  • The autopilot and autothrottle should not be used independently of each another.

737 Next Generation thrust levers. TOGA and A/T disconnect buttons are just visible

Pitch Coupling

Pitch coupling occurs when the autothrottle system actively attempts to maintain thrust based on the aircraft’s pitch or attitude. It can occur when the autopilot is disconnected while the autothrottle remains engaged. In this situation, the pilot uses manual pitch and roll inputs to control the aircraft, while the autothrottle controls the thrust output.

The design of the 737 airframe is prone to pitch coupling because of its under wing mounted engines. The position of the engines cause the thrust vector to pitch upwards with increasing thrust and pitch down with a reduction in thrust.

When the autopilot is disconnected and the autothrottle is engaged, the pilot controls pitch manually while the autothrottle adjusts thrust to maintain airspeed. Because thrust changes influence pitch and pitch changes affect airspeed, the two systems can interact with each other. This coupling of pitch and thrust can create a roller‑coaster effect as the aircraft alternately increases and decreases pitch in response to pilot inputs and autothrottle driven thrust changes.

This coupling of pitch to thrust can be potentially hazardous; namely:

  1. When flying an approach due to the lower above ground altitude and airspeed (closer to Vref); and,

  2. In windy conditions whereby; the autothrottle will command the engine to spool up and down based on wind speed and gusts.

The autopilot and autothrottle have been designed to operate in unison, and the autopilot’s high level of fidelity can compensate for any variations in pitch and thrust output, as well as the inherent lag between commanded N1 settings and engine spool‑up.

A/T ARM toggle, N1 and speed button.  The N1 and speed button illuminate when either is in active mode.  In the image, the A/T is armed; however, the speed option is not selected (the annunciator is extinguished).  This enables thrust to be controlled manually

Autothrottle Non-Normal Operations (Arm Mode)

The primary function of the A/T ARM mode is to provide minimum speed protection.

The autothrottle system comprises two discrete functions - the A/T ARM toggle and the SPEED button, which operate either in combination or independently of each other. Both functions are accessed from the MCP.

During normal operations, the A/T ARM toggle is positioned in the UP position and the function of the SPEED button is coupled to the toggle. When selected, both functions display green-coloured lights on the MCP and the speed window displays the target speed.

During non-normal operations, the A/T ARM toggle and the SPEED button do not operate as a coupled system. To decouple the two functions, the SPEED button is pressed to disconnect the speed function. When disconnected, the green-coloured light will be extinguished and the speed window will be blank with no target speed displayed. This will place the autothrottle in the ARM mode.

When using the autothrottle in ARM mode, it is important to monitor the FMA to determine whether the autothrottle is armed or engaged. It is not prudent to rely solely on the green lights on the MCP, as these indications confirm only that a mode has been selected, not that it is actively engaged or performing as expected.

When in ARM mode, the FMA displays the word ARM in white letters within an outlined white box. Conversely, when the SPEED button is pressed (to engage speed mode), the colour of ARM changes from white (armed) to green (engaged).

Note that the outlined box on the FMA is initially displayed in white (armed/pre‑selected) to indicate that a mode change has been commanded. The box then changes to green (engaged) after approximately 10 seconds to signify the active mode.

Why Use ARM Mode

The primary purpose of decoupling speed from the autothrottle is to permit manual thrust control while retaining the autothrottle in the armed state. This can be advantageous during non-precision approaches. Recall that the autopilot and autothrottle must not remain engaged during the final stages of the approach and landing, except during an autoland.

The arming of the autothrottle is an expedient way to engage the autothrottle if a Go-Around is required - all that is required is to push the TOGA buttons on the thrust lever and the autothrottle will engage (rather than having to manually engage the autothrottle). This enables a Go-Around to be executed more expediently and with less workload.

If the approach proceeds smoothly and a go‑around is not required, the crew will, prior to landing, disengage the A/T toggle on the MCP by either manually moving the toggle to the OFF position or pressing the A/T buttons on the thrust levers. If the A/T toggle is not placed in the OFF position, the autothrottle system will automatically disconnect when the main wheels touch down, based on WOW logic (Weight‑on‑Wheels logic is triggered by the squat switches on the main landing gear, which activate when the shock strut is compressed by a predefined amount).

Although this procedure is favoured by some flight crews, this practice is not authorised by all airlines, with some company policies expressly forbidding the ARM A/T technique.

FMA display showing the relationship between the A/T toggle and the Speed button

The reason this procedure is prohibited by some airlines is the variety of approach types the 737 can fly. Crews accustomed to precision approaches, where this technique is unnecessary, may become uncertain about the autothrottle’s behaviour, and there have been several incidents in which crews failed to notice significant airspeed changes.

The recommendation by Boeing in the 737 Flight Crew Training Manual (FCTM) states:

‘The A/T ARM mode is not normally recommended because its function can be confusing. The primary feature the A/T ARM mode provides is minimum speed protection in the event the airplane slows to minimum manoeuvring speed. Other features normally associated with the A/T, such as gust protection, are not provided’. (When the A/T is armed and the SPEED button not selected).

Important Points:

  • It is important that, if the autothrottle is disconnected or in ARM mode, the crew maintains vigilant monitoring of the aircraft’s airspeed.

  • The ARM mode is not suitable for all approach types and usually is only used for non-precision approaches.

Speed Protection (Windy, Gusty and Turbulent Conditions)

The autothrottle system provides speed protection through airspeed and acceleration sensing; however, its effectiveness depends on correct use of wind additives and an understanding of how the system behaves in gusty or turbulent environments.

To ensure adequate wind and gust protection when using the autothrottle during an approach in windy conditions, the command speed should be set to the appropriate wind additive. This additive is derived from the prevailing wind speed, direction, and gusts, and typically ranges between Vref +5 and Vref +20. Applying a wind additive provides a safety buffer that accounts for fluctuations in wind velocity and reduces the likelihood of the autothrottle commanding a speed that drops below Vref.

In turbulent conditions, the autothrottle maintains a thrust level that averages higher than the minimum required in order to preserve the commanded approach speed.

When to Apply Additives to Vref

Although the concept is comparatively straightforward, there is often uncertainty about the appropriate speed additives to apply to Vref, particularly regarding whether the autothrottle is in use. To clarify the process:

  • If the autothrottle is to be engaged for landing (for example autoland), set the command speed to Vref+5. There is no need to add wind additives as the autothrottle logic already compensates for gusts through airspeed and acceleration sensing.

  • If the autothrottle will be disconnected (or not selected) for landing, set the command speed to Vref plus the appropriate wind additive to account for steady wind and gusts. This will ensure that speed protection is provided.

Table 1: Summary of A/T conditions, speed settings and reasons


Important Point:

  • Minimum speed protection is lost when the autothrottle is not engaged, or the SPEED function on the MCP is deselected.

Additional Information

A/T disengage button on throttle thrust lever (Captain-side).  This is an OEM throttle from a 737-300 series (classic).  The button is identical to that used in the NG with the exception that the thrust handles are usually white and not grey in colour.  Depressing this button will disconnect the autothrottle

Manual Override - Engaging the Clutch Assembly

Occasionally, for any number of reasons, the flight crew may need to override the autothrottle.

The Boeing autothrottle system incorporates a clutch mechanism that allows the flight crew to manually advance or retard the thrust levers while the autothrottle remains engaged. When the thrust levers are moved, the clutch automatically disengages the servo drive, placing the autothrottle in an overridden state for the duration of the manual input.

This clutch arrangement provides the capability for immediate manual thrust intervention, whether for abnormal situations, rapid thrust changes, or any circumstance requiring direct pilot control.

Correct Sequence for Disconnecting the Autopilot and Autothrottle

A commonly asked question is: “When is the autothrottle disconnected, and under what circumstances?” As with many aspects of operating the 737, the answer varies depending on the source, and different operators may teach slightly different techniques.

Traditionally, and in line with Boeing’s recommended method, the flight crew should disconnect the autothrottle at the same time as the autopilot. Disconnecting both systems allows full manual control of the aircraft. The pilot flying disconnects the autopilot by pressing the deselect button on the yoke (one click), pressing the CMD button, or lowering the disconnect bar on the MCP.

The autothrottle is disconnected simultaneously by pressing the autothrottle disconnect buttons on the thrust levers (one click) or by moving the A/T ARM switch on the MCP to the OFF position.

To silence the autopilot warning horn, the yoke‑mounted disconnect button is pressed a second time, or the flashing AFDS annunciator is pressed once. Similarly, the flashing A/T annunciator on the AFDS is cancelled by pressing the annunciator once.

Timing of Disconnect

Whilst disconnecting both the autopilot and autothrottle simultaneously is perfectly acceptable, it is generally preferable for the flight crew to do so in a controlled sequence. The autothrottle should be disconnected immediately before the autopilot, as the autothrottle’s logic responds more quickly than the autopilot’s.

One click disengages the autothrottle, a second click cancels the warning, a third click disconnects the autopilot, and a fourth click silences the aural alert.

Whether this makes a measurable difference is difficult to quantify, but a calm, deliberate disconnection sequence, with a slight pause between clicks, appears far more controlled and elegant than rapidly clicking multiple times in quick succession.

At What Altitude Should the Autothrottle be Disconnected

A common preference amongst flight crews, when flying a non-precision approach, is to disconnect the autopilot and autothrottle no later than 1500 feet AGL. This is the altitude at which the aircraft should be fully configured for landing, with landing checks completed, the landing gear down, flaps set to 30, and the aircraft established within the required vertical and lateral tolerances.

That said, the altitude is not fixed unless specified by airline policy. A useful maxim is to use the Decision Height (DH) or Minimum Descent Altitude (MDA) as the point at which to disconnect the autothrottle.

Disconnecting the autopilot and autothrottle earlier in the approach provides additional time to transition from automated to manual flight and to establish a feel for the aircraft before landing.

Many flight crews, particularly experienced pilots confident in manual flying, regularly choose to hand‑fly the aircraft. Some will fly from 10,000 feet to landing using the FD, ILS, VNAV, and LNAV cues on the PFD, supported by the ND for situational awareness. Hand‑flying the approach is widely enjoyed, even though it remains one of the most demanding phases of flight.

Important Point:

  • Whenever the aircraft is being hand‑flown with the autothrottle disconnected, it is essential to closely monitor airspeed. This is particularly critical on final approach, where thrust can decay quickly and bring the aircraft close to stall speed.

Hand Flying Without Automation

The benefit of flying with the autopilot and autothrottle disconnected is the ease with which the aircraft can be manoeuvred. The crew sets the appropriate %N1 to produce the thrust required to maintain the desired airspeed; gone are the thrust surges that occur as the autothrottle attempts to maintain speed. This technique is often referred to as ‘flying by the numbers’.

Granted, it takes considerable time and patience to become proficient at manual flying in a variety of conditions, but the overall enjoyment increases significantly.

Company Policies

Airline policies often dictate how a flight crew will operate an aircraft, and while some policies are expedient, they are more often based on economic considerations for the company.

Policies vary with respect to autothrottle use. For example, Ryanair, Air New Zealand, and Kenya Airways require the autopilot and autothrottle to be disconnected simultaneously. QANTAS follows a similar approach; however, they specify an altitude by which disconnection must occur (1500 feet AGL) and stipulate that the autothrottle is to be disconnected before the autopilot, with a distinct pause between each disconnection.

If an airline does not publish a policy, the decision is left to the discretion of the flight crew.

Simulator Nuances

The above information primarily discusses the systems as they operate in the real aircraft. Whether these systems are functional in a simulation depends on the avionics suite in use (Sim‑Avionics, Project Magenta, ProSim737, etc.).

For example, the autothrottle may not maintain the speed selected on the MCP under certain conditions, such as during turns in high winds. In the real aircraft, the crew would manually override the autothrottle. However, if the throttle hardware or avionics suite does not support manual override, the next best option is to either:

  • Disconnect the autothrottle and manually adjust thrust; or

  • Press the SPEED button on the MCP to place the autothrottle in ARM mode, allowing manual control of thrust. Once the manoeuvre is complete, the autothrottle can be re‑engaged by pressing the SPEED button again.

If your throttle does not support manual override, or the avionics suite does not model this functionality, the second option is an effective way to compensate for the limitation.

Final Call

There is little argument that the use of the autothrottle is a major benefit in reducing task loading; however, as with other automated systems, this benefit can come at a cost. This has led several airlines to introduce policies prohibiting the use of the autothrottle without the autopilot. Pitch coupling, excessive vertical speed, and incorrect thrust settings can all contribute to hard landings, possible nose‑wheel collapse, undesirable ground‑effect behaviour, or even controlled flight into terrain.

Ultimately, the decision to use the autopilot and autothrottle as a coupled system rests with the pilot in command and depends on crew experience, environmental conditions, and airline policy. However, Boeing’s recommendation is to avoid using the autothrottle without the autopilot engaged.

Additional Information:

Acronyms and Glossary

  • A/P – Autopilot.

  • A/T – Autothrottle.

  • AFDS – Autopilot Flight Director System
.

  • Command Speed - the target airspeed that the autothrottle (A/T) is trying to maintain.

  • FCTM – Flight Crew Training Manual (Boeing Corporation).

  • FMA – Flight Mode Annunciator.

  • Manual Flight – Hand flying aircraft. A/P and A/T disconnected.

  • MCP – Mode Control Panel.

  • Minimal Speed Protection – Function of the A/T when engaged. The A/T has a reversion mode which will activate according to the condition causing the reversion (placard limit). (For example, flaps, gear, etc).

  • Pitch Coupling – The coupling of A/T thrust to the pitch of the aircraft. A/T thrust increases/decreases as aircraft pitch and attitude changes. Pitch coupling occurs when the A/P is disconnected, but the A/T is engaged.

  • Selected/Designated Speed – The speed that is set in the speed window of the MCP.

  • SPEED button – Located on the MCP the SPEED button (when not illuminated) disconnects the speed from the autothrottle system whilst keeping the autothrottle in the armed mode.

  • Take Off/Go Around (TOGA) – Takeoff Go-around command mode. This mode is selected during takeoff roll by depressing one of two TOGA buttons beneath the throttle levers.

  • Vref – Landing reference speed.