ATC-pie

From FlightGear wiki
Jump to navigation Jump to search
ATC-pie
ATC-pie logo
Tower viewing, following a departing aircraft
Tower viewing, following a departing aircraft
Developed by Michael Filhol
Initial release February 1, 2015
Latest release 1.8.4 (Aug. 14, 2021)
Written in Python (Version 3)
OS Any
Platform Qt5
Development status Active
Type ATC client
License GNU GPL v3
Website

ATC-pie is a free (libre) air traffic control simulation program featuring:

  • solo sessions, incl. voice instruction recognition and pilot speech synthesis;
  • network sessions ("multi-player"), through FGMS and FSD;
  • tutorial sessions for teacher supervision of an ATC student.

It allows en-route centre control (CTR) as well as airport-based services (TWR, APP, GND...), including 3D tower viewing through FlightGear. It is essentially designed for realism and simulates many tasks and situations of real-life ATC such as:

  • strip rack and sequence management;
  • radar monitoring and transponder identification;
  • coordination with neighbouring controllers (strip handovers, voice phone calls...);
  • en-route vectoring and path/level conflict anticipation;
  • flight plan filing and editing...

To download the program and learn more about how to use it, read the ATC-pie installation and user guides. If you have a question, check the FAQ first, or try the forum for help.

Screenshots

Visit the ATC-pie screenshot category for more.

Working principles

You are the air traffic controller, working with equipment depending on your position and local facility. This may include a tower view, radar scopes, data links, etc. Your traffic is the aircraft connected by human pilots (FlightGear, FSD), or simulated with AI (solo) or by a teacher (student). They all contact you with different types of aircraft, transponder equipment and intentions.

Strips

The ATC-pie strip detail sheet

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 across racks and bays until handed over to a different controller or shelved. Strip details can all be manually edited, and include:

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

Radar

As in real life, the main radar technology is SSR, which only shows what is picked up from on-board transponders in its range. This means that:

  • if a transponder is off or out of range, you will not see the aircraft on your radar screen;
  • if a transponder is on and in range, you will at least be able to see its position and read a transponder code, and possibly its altitude, type, callsign... depending on the transponder mode and your radar capabilities.

Linking strips

Every strip can be linked to a flight plan and to a transponder contact on radar. A linked strip will automatically:

  • display its missing elements when available from the linked flight plan or aircraft transponder;
  • populate the information in the radar tag of the linked aircraft with useful details, e.g. assigned altitude.

Radar identification

Radar identification: both matched strip and radar contact marked in blue

When using radar, ATCs use different methods to identify an aircraft and link the right contact to its strip. They can read an aircraft's callsign straight away if its transponder is squawking mode S, tell from reported positions, or use a transponder code.

For instance, say a transponder-equipped VFR traffic makes radio contact giving their 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 radar identification of aircraft–strip pairs such that:

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

ATC-pie identifies such pairs automatically and reports them to you so you can properly link the two and get back to the pilot: "radar identified".

Detailed feature list

Sessions

Available session/connection types:

  • Solo simulation (AI traffic)
  • FlightGear networks (FGMS protocol)
  • FSD networks (as served by https://github.com/kuroneko/fsd commit bc7d43, latest available in April 2020)
  • Teacher–student tutoring (teacher spawns and runs the traffic visible to the student)

Location modes:

  • Airport (for ATC positions such as TWR, GND, APP, DEP at a selected airfield)
  • En-route centre (free positioning of radar, no base airport or runway-related options)

ATC surveillance

Radars and tracking:

  • SSR mode selection (none/A/C/S)
  • Primary radar option
  • Traffic identification assistant
  • Position/track vs. strip assignment mismatch warning system
  • Route/vector conflict anticipation
  • Separation incident alarm
  • Runway occupation/incursion detection

Tower view in airport mode (rendered by FlightGear):

  • View of airport, aircraft, weather, time of day
  • Through internally started process or externally running instance
  • Control panel to orient/zoom view or follow aircraft
  • Additional views can be connected (for multiple camera angles)

Other:

  • Radio direction finding (RDF) and integration to radar
  • Multiple weather (METAR) station monitor

Traffic management

Strips and racks:

  • User-defined strip racks with configurable colours (for linked radar contacts) and ATCs to receive from
  • Runway boxes with automatic RWY separation timers
  • Loose strip bays with customisable backgrounds

Flight plans and routes:

  • Flight plan system (file, edit, open, close, publish/retrieve online)
  • World route suggestions, presets, analysis, radar drawing and world map view
  • Automatic strip printing for expected departures or arrivals (from FPLs)

Radar tools:

  • Convenient mouse input for vectors, taxi instructions and waypoint changes
  • Approach spacing hints for inbound sequencing (estimated touch-down time difference)
  • Quick point-to-point heading and distance measuring tool
  • Direct text annotation of radar screen
  • Flag/unflag (highlight) radar targets

Communications

With aircraft:

  • Multiple 8.33 radio support with simultaneous frequency/channel transmissions and monitoring
  • ATIS recording and reminder alarm (see dialog with pre-filled notepad)
  • Controller-pilot data link communication (CPDLC)
  • Text radio chat with preset messages, auto-completion, predefined and custom aliases for context-sensitive replacements, sender blacklist to filter out trolls

ATC coordination:

  • Strip exchange (handovers)
  • CPDLC authority transfers
  • Telephone lines (direct voice communication)
  • Text messaging (private channels and general ATC chat room)
  • "Who has?" requests

Session environments

Solo sessions (AI traffic):

  • Strip exchange: handovers to/from virtual ATCs
  • Voice radio: instruction recognition (with Sphinx) and pilot read-back synthesis (with pyttsx)
  • Weather: randomised and evolving
  • Aircraft type and airline choice with custom appearence in tower view
  • Configurable airspace rules and traffic density

FlightGear network sessions:

FSD network sessions:

  • Strip exchange: handovers with other clients (lossy if not ATC-pie)
  • Weather: fetch from server or retrieve real world METAR
  • Flight plans: available from the network (although only editable by the pilots, and open/close not supported by FSD)
  • ATIS: recorded as text only (sent through chat system)

Tutoring sessions (teacher with student):

  • Strip exchange: configurable ATC neighbours and handover supervision by teacher
  • Weather: controlled by teacher
  • Traffic snapshots and recall to repeat situations with the student

Other

Misc. tools:

  • World airport, map navpoint and AD parking position browsing/indicating
  • Aeronautical unit conversion calculator
  • Custom alarm clocks with quick keyboard timer start
  • General and location-specific notepads restored between sessions

GUI:

  • Multiple window workspace (radar screens, strip racks and bays) saved by location
  • Floatable/dockable panels and toolbars (see screenshot) and layout save/restore
  • Notification system combining selectable sounds, status bar messages and time-tagged history
  • Customisable style and colours

Data sources:

  • Airport and navigation data sourced in the X-Plane format (old world-wide default file set provided but custom imports recommended)
  • Editable aircraft data base (ICAO designators, cruise speeds, WTC, etc.)
  • Custom radar background images and hand drawings (EuroScope/VATSIM/IVAO "sector file" conversion tool included)
  • Ground elevation maps (can be generated automatically with a provided script if FlightGear terrain data available)
  • Real world magnetic declination lookup

Interoperability with other software

OpenRadar

OpenRadar is another stand-alone program able to connect to FlightGear networks. ATC-pie and OpenRadar's philosophies differ in several ways:

  • OpenRadar's basic processing unit is the FGMS callsign, whereas ATC-pie's is the strip;
  • OpenRadar's concept of handover is based on a shared notion of aircraft ownership, whereas ATC-pie allows any controller to pull out a strip and write a callsign on it;
  • in OpenRadar, a handover must be acknowledged by the receiver for the sender to lose ownership and for all neighbouring users to see it complete, whereas ATC-pie considers that a strip sent is gone and assumed to land on the receiver's rack, without anybody else necessarily to know.

For most interactions to work in FlightGear sessions while respecting both approaches as much as possible, the following principles and restrictions apply to strip exchange between the two programs:

  • ATC-pie users can only hand over strips to OpenRadar that are linked to a radar contact;
  • aircraft under ATC-pie control are not shown as "owned" to OpenRadar users;
  • handovers from ATC-pie will fail if an OpenRadar user is claiming ownership on the linked radar contact;
  • when sending to ATC-pie controllers, OpenRadar users will see their transfers acknowledged straight away, unconditionally.

Callsign handover policy:

  • O-R to ATC-pie: FGMS callsign will appear on the strip, as if the sender had filled the detail herself;
  • ATC-pie to O-R: callsign resolved for the receiver, sender's entry will reappear next time ATC-pie handles the strip;
  • pie-to-pie handovers through OpenRadar's service: strip detail preserved, whether present or absent.

Features not supported by OpenRadar:

  • wake turbulance category on strips (but detail preserved for ATC-pie instances later receiving the strip);
  • ATC text messaging;
  • ATC phone lines;
  • CPDLC.

Note that who-has requests are fully supported.

Euroscope

Euroscope is a popular program to control on VATSIM, a flight simulation network whose protocol is historically based on FSD. For a long time Euroscope allowed to connect to "plain" FSD servers, although being increasingly tailored for VATSIM, until it discontinued operability outside of VATSIM all together.

Older versions of Euroscope are still around and connecting to FSD networks. ATC-pie is able to interact with them in FSD sessions, but only to a limited extent:

  • sending a strip to Euroscope will result in a loss of all strip details but the callsign (which must be connected), the only information left to the recipient being the FPL details for that callsign if any (strip changes made after FPL data retrieval are therefore lost);
  • receiving a strip from Euroscope is supported, but the sender will see the hondover pending (never "assumed");
  • who-has requests will remain unanswered by Euroscope;
  • there are no integrated phone lines to Euroscope clients.