From FlightGear wiki
Revision as of 20:29, 11 February 2015 by Mickybadia (talk | contribs)
Jump to navigation Jump to search
ATC-pie logo
ATC-pie at the KSFO mess
ATC-pie at the KSFO mess
Developed by Michael Filhol
Initial release Febuary 1, 2015
Latest release Febuary 11, 2015
Written in Python3
OS Any
Platform Qt5
Development status Active
Type ATC client
License GNU GPL v3

ATC-pie is a radar air traffic control simulation program for the FlightGear multi-player network, initially released Febuary 2015. It is comparable to OpenRadar, but essentially designed for realism.

It is programmed in Python3 for Qt5, hence system-independant, only both must be installed as well as the python3-qt5 bindings. That done, it is meant to work straight away, with no other resource to install or make/compile command to run. No need to install or update FlightGear, download scenery or fetch any external resource before it can run.


Features listed below are already implemented and supposedly stable. Tested on Linux and Windows; still waiting for Mac users to report.


  • Real METAR updates with selectable weather station
  • Real declination lookup and true/magnetic distinction
  • Data retrieved from the latest X-Plane file set
  • In-app announcement of ATC session on Lenny64's popular ATC event page
  • Network text chat system
  • Manage ignored contacts

Transponder support

  • Realistic mode-dependant behaviour (modes 0, A, C, S)
  • Choice for default mode for the many FlightGear aircraft models still not equipped
  • Individual and general cheat modes to "see all" (override XPDR settings)
  • Radar identification assistant (unique squawk link between radar pick-up and strip assignment detection)

Radar scope

  • Variety of show/hide options: navigation points and fixes, aircraft info boxes, vectoring assignments...
  • Directly assign headings, altitudes/FLs and speeds by click&drag on radar contacts
  • All-in-one display of aircraft course, vector assignments and conflict warning
  • Measuring tool for quick point-to-point heading & distance checks
  • In-game custom text labels to annotate radar background (saved across sessions)


  • FGCom 3 integration
  • ATIS recording with information letter and pre-filled preparation notepad
  • Multiple radio management enabling simultaneous transmission on different frequencies
  • Frequency-specific sound level selection enabling efficient monitoring
  • Mouse and keyboard PTT
  • Integrated echo test
  • Use of separate (externally running) FGCom possible

Strip, route and flight plan management

  • Strip drag&drop along and across user-defined strip racks racks
  • Link strips to flight plans and radar contacts to merge editable details and inform radar display
  • Interface with Lenny64's flight plan data base including in-game FPL retrieval, filing and editing
  • FPL, transponder and vectoring assignment conflicts reported
  • Strip route management and next waypoint display
  • Work with local FPL copies and manage sync with online publication


  • Floatable/dockable GUI panes: strips, radios, text chat, etc.
  • General and airport-specific settings saved on close and restored on restart
  • Notification system combining selectable sounds, status bar messages and a time-tagged history
  • Personal notepads (general and airport-specific) saved across sessions


Radar identification marked in blue (unique strip–transponder match)  
Fine airport tarmac depiction  
Strip detail sheet with editable route  
ATIS recording feature with scrap notebook  

Working principles


You are the air traffic controller, and players will connect to the network with different types of aircraft and transponder equipment. As in real-life, the radar is SSR, hence will show you only (unless you cheat) what you pick up from on-board transponders in your range. That means:

  • If a transponder is off or on standby, you will not see the aircraft on your radar screen.
  • If a transponder is on, you will at least be able to see its position and read the transponder code, possibly its altitude and even its type and callsign, depending on the mode set by the pilot.


Your basic traffic flow and sequence working unit is the strip, each representing a controlled (or soon expected) aircraft. Strips are created, filled with details and moved along and across racks until handed over to a different controller or discarded. Details written on strips include:

  • most importantly, the aircraft's callsign, to be used on the radio;
  • details like aircraft type, airspeed, route... that can be specified by the pilots themselves when filing flight plans; and
  • transponder code and flight parameter assignments (or vectors: heading, altitude/FL, speed).

Linking strips

Double-clicking on a strip will open a strip detail sheet where those details can be manually edited, but each strip can also be linked to a flight plan and/or a visible radar contact on the scope screen—a strip can only be linked to one flight plan and to one radar contact. Linking to a strip will automatically:

  • make the strip display the missing elements made available by the linked aircraft transponder or flight plan;
  • label the radar contact dot with the more informed linked details (e.g. assigned altitude).

Any detail mismatch between a strip and its linked flight plan or radar contact will be reported for you to resolve.

To identify an aircraft and link the right radar contact to a strip, an ATC can rely on different things. He can read an aircraft's callsign straight away if it is visible (or cheated), tell from reported positions and altitudes, or use a transponder code. For instance, say a VFR traffic makes an initial radio contact giving his callsign and approximate position. ATC will typically pull out a new blank strip and give the pilot a unique transponder code to squawk, writing it on the strip alongside the announced callsign, then wait for it to appear on the radar. This allows for what ATC-pie calls soft links, in essence radar identification of an aircraft–strip pair such that:

  • the strip is assigned a transponder code;
  • no other strip is assigned the same code;
  • the aircraft is the only one squawking that code in radar range.

Soft links are reported to you so you can properly link the two and consider the aircraft identified, before getting back to the pilot with subsequent instructions.

User guide

This section is very poor standalone documentation. It helps one download and run ATC-pie, and lists a few tips on some of its features. Yet better sources to learn the program are:

  • the in-app quick reference from the help menu (summary of mouse/keyboard gestures, etc.);
  • the tutorial videos (to be announced).

Anyone motivated to write a full user guide is obviously welcome to contact the developer.

Getting it to run


There are essentially two ways of downloading ATC-pie: one is to download a tarball to extract locally; the other is to clone the Git repository. The latter requires Git, but will keep you in sync with updates more easily. Your choice. In either case, you will have no compiling to do (make, etc.), but do make sure you have the few dependencies installed (e.g. Qt5), listed in the README file.

Downloading the tarball requires nothing but the standard tar+gzip combo:

  1. download the compressed archive;
  2. extract the files in the directory of your choice.

To clone the repository, from the directory of your choice:

git clone

Starting the program

Depending on your system and preference, you might be double-clicking, typing stuff or pulling your hair out. In any case what you need to start the program is to run a Python3 interpreter on the file in the top-level directory. To start at a chosen airport location, say with code ICAO, add a system command-line argument, which may look as simple as:


After a few seconds, you should see the main window appear with a radar scope and a depiction of your airport in the centre.


Here are a few tips to help you navigate and use the program.

  • Callsigns typically start with the ICAO code of a controlled airport, and end with a hint on the provided service: twr, gnd... With no callsign given, you will appear as "ICAOobs" on network connect. Note that FGMS restricts callsigns lengths to 7 characters. :-(
  • For more efficient text chat, a growing list of text aliases exist ($wind, $qnh, $icao...) for both instant and preset chat messages. They automatically expand to the current value when message is sent.
  • In airport input fields, a single dot will be replaced by your ICAO position. Use this as a shortcut from/to your airport when filling strip/FPL details.

Any strip with valid departure and arrival airports will contain a parsed route. Recognised navpoints in the route field (whitespace-sparated tokens) create waypoints on the way to arrival. All other tokens are stored as route leg specifications to the following waypoint. The current route leg of the selected aircraft (leg spec + waypoint) is displayed in the info pane.

Information display

  • Heading displays are mostly magnetic so they can be read out to pilots. The only exception perhaps are the navigator tooltips, for easier identification on the scope.
  • The transition level is by definition the lowest flight level that is still above the transition altitude. This does not mean the lowest assignable FL, which may take more vertical separation.
  • The grouped tick marks along the localiser line (when shown) indicate best altitudes AMSL for final approach along the defined slope rate. Every mark in a group is 1,000 ft.
  • "OK" near the route field on the strip detail sheet means that the route could be parsed correctly; otherwise "!!" is displayed. This does not matter, only the info boxes will be showing destination (or nothing if unknown) instead of next waypoint.


Say you are TWR coordinating with GND at an airport and you want to monitor both radio frequencies while you are only in charge of one. You can set this up by starting your own radio box on TWR frequency, and turn on a second one to monitor GND, setting the volume to "soft" on the latter so that you can always tell if a message is for you to answer or not.

The FGCom version setting is the name of a subdirectory in resources/fgcom. See Notice file there.

Resolving conflicts

Strip–FPL conflicts:

  • to confirm all strip details: open the strip detail sheet, tick the "push details to FPL" box and save to propagate the strip details;
  • to confirm all FPL details: reset the strip to overwrite its details with those of the linked flight plan;
  • to confirm some details of each source: open the strip detail sheet, get rid of the bad details and save without pushing to the flight plan to fall back on the first case where all strip details can be confirmed.

Flight plan local–online conflicts:

  • to update the online version with your local modifications, double-click the flight plan and tick the "publish" box before saving (if still decorated red, there was a network problem or the change was rejected by the server);
  • to discard all local modifications of an online FPL, remove the FPL from the list and check for new flight plans again (the deleted entry should be retrieved with online state).