|
|
| (64 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| {{forum|83|ATC-Pie support & development}} | | {{forum|83|ATC-Pie support & development}} |
| | |
| | {{about|the software and its features|help with installation or configuration|ATC-pie installation guide|a manual on how to use it|ATC-pie user guide}} |
|
| |
|
| {{Infobox Software | | {{Infobox Software |
| | title = ATC-pie | | | title = ATC-pie |
| | logo = ATC-pie-logo.png | | | logo = ATC-pie-logo.png |
| | image = ATC-pie-screenshot-KSFOmess.png | | | image = ATC-pie-screenshot-towerViewing.png |
| | alt = ATC-pie at the KSFO mess | | | alt = Tower viewing, following a departing aircraft |
| | developedby = Michael Filhol | | | developedby = Michael Filhol |
| | initialrelease = February 1, 2015 | | | initialrelease = February 1, 2015 |
| | latestrelease = August 22, 2015 (r6c) | | | latestrelease = 1.8.8 (April 1, 2023) |
| | writtenin = Python3 | | | writtenin = Python |
| | | writteninversion = 3 |
| | os = Any | | | os = Any |
| | platform = Qt5 | | | platform = Qt5 |
| Line 15: |
Line 18: |
| | type = ATC client | | | type = ATC client |
| | license = GNU GPL v3 | | | license = GNU GPL v3 |
| | website = https://sourceforge.net/projects/atc-pie | | | website = http://mickybadia.free.fr/atcpie |
| }} | | }} |
|
| |
|
| '''ATC-pie''' is an [[air traffic control]] simulation program featuring solo training and a multi-player game mode to connect to [[FlightGear]] networks. It is essentially designed for realism, and simulates many features of real-life ATC tasks such as transponder identification, strip rack and sequence management, handovers to/from neighbouring controllers, ATIS recording, flight plan editing, routing and conflict solving. | | '''ATC-pie''' is a free (libre) [[air traffic control]] simulation program with strong ties to [[FlightGear]]. It features: |
| | | * solo sessions with AI traffic (incl. voice instruction recognition and pilot read-back); |
| ATC-pie is free and open source, programmed in Python3 for Qt5 hence system-independant, only Python3 and its Qt5 bindings must be installed. That done, it is meant to work straight away, with no make/compile command to run or external resource to install (except for local tower viewing, which requires FlightGear and the appropriate scenery).
| | * "multi-player" network sessions (FlightGear and FSD protocols supported); |
| | | * tutorial sessions for teacher supervision of an ATC student. |
| == Program features ==
| |
| | |
| The features listed below have been tested on various Linux versions, Mac and Windows.
| |
| | |
| === Game and environment ===
| |
| World data:
| |
| * Real world METAR updates from selectable weather stations | |
| * Real world declination lookup and true/magnetic distinction
| |
| * Airport and navigation data retrieved from the latest [http://data.x-plane.com X-Plane] file set
| |
| * Custom additions possible in separate files
| |
| | |
| Multi-player and network environment:
| |
| * Multi-player game mode with configurable [[FGMS]] connection
| |
| * ATC handovers: strip exchange with [[OpenRadar]] and other ATC-pie instances in range
| |
| * Interface with Lenny64's [http://flightgear-atc.alwaysdata.net flight plan data base], including in-game FPL retrieval, filing and editing
| |
| * In-app session announcement facility to post on Lenny64's popular [http://flightgear-atc.alwaysdata.net ATC event page]
| |
| * Ignore contacts
| |
| | |
| Solo game mode:
| |
| * Free combination choice of APP, TWR and DEP control positions for custom training
| |
| * Handovers to/from virtual ATCs
| |
| * Instruction interface and pilot read back
| |
| * Adjustable difficulty (traffic density)
| |
| * Departure–arrival and ILS–visual balance options | |
| * Configurable runways in use, entry and exit points
| |
| | |
| GUI:
| |
| * Floatable, dockable and closable GUI panes: strips, radios, text chat, etc. (window layout saved)
| |
| * Notification system combining selectable sounds, status bar messages and a time-tagged history
| |
| * General and airport-specific settings and notepads saved on close and restored on restart
| |
| * Customisable colours
| |
| | |
| === Radar and visual contacts ===
| |
| Transponders:
| |
| * Full support and mode-dependant behaviour (off, A, C, S)
| |
| * Choice of simulated mode for non-equipped aircraft models
| |
| * Radar identification assistant (unique squawk link between radar pick-up and strip assignment detection)
| |
| * Individual and general cheat modes to override XPDR settings or reveal those turned off
| |
| | |
| Radar scope:
| |
| * Open multiple radar screens
| |
| * Custom radar background drawing and image display (e.g. to display real procedure charts)
| |
| * Variety of show/hide options for navigation points, vectors and route assignments, etc. | |
| * Quick point-to-point heading & distance measuring tool
| |
| * Custom text labels to annotate radar background
| |
| | |
| Tower viewing:
| |
| * Real-time rendering of the airport scene from tower viewpoint, available in all game modes
| |
| * Internally started (requires ''FlightGear'' installed) or through connection to an external instance
| |
| * View controller pane and direct free look/zoom from the view
| |
| * Easy use of custom scenery and aircraft model addition/substitution
| |
| | |
| === ATC management ===
| |
| Strips, racks, flight plans:
| |
| * Strip drag&drop along and across user-defined racks, with configurable colours
| |
| * Strip drop on neighbouring ATCs to hand over
| |
| * Link strips to flight plans and radar contacts to merge editable details and inform radar display
| |
| * Conflicts between linked elements reported
| |
| * Work with local FPL copies and manage sync with online publication
| |
|
| |
|
| Routes, vectors, conflicts:
| | It is designed to support a maximum range of ATC situations (roles, equipment...), at any world location and for every session type above. All control positions are possible, whether airport-based (TWR, APP, GND...) or en-route (CTR). Equipment may include radar screens, data link, etc. or be limited to binoculars and a view of the airfield. |
| * Route parsing and drawing
| |
| * Current leg and next waypoint display with geodesic calculations of headings and distances
| |
| * Assign vectors and change routes with direct mouse gestures
| |
| * Anticipated route conflict warning and separation incident alarm
| |
| * Visible mismatches between assigned vectors and picked up positions
| |
| | |
| === Communications ===
| |
| Radio:
| |
| * [[FGCom]] integration, incl. echo test and possible use of externally running client
| |
| * ATIS recording with information letter and pre-filled preparation notepad
| |
| * Multiple and single frequency transmissions
| |
| * Frequency-specific sound level selection
| |
|
| |
|
| Text chat:
| | Its essential goal is realism. It simulates many tasks of real-life ATC such as: |
| * Custom preset message list and automatic line completion | | * strip racks and sequence management; |
| * Preset and custom text aliases for context-sensitive replacements | | * coordination with neighbouring controllers (handovers, voice phone calls...); |
| * Message history and single-click message recall | | * radar monitoring and identification of traffic; |
| * Hardcore communication sim possible by disabling unknown senders' callsigns | | * vectoring and course/level conflict anticipation; |
| | * flight plan operations; |
| | * CPDLC... |
|
| |
|
| == Screenshots == | | == Screenshots == |
|
| |
|
| {{Gallery
| | <gallery mode="packed"> |
| |ATC-pie-screenshot-soloMode.png|Playing solo mode with three coloured racks
| | ATC-pie-screenshot-sectorView.png|Sector view around Geneva |
| |ATC-pie-screenshot-towerViewing.png|Tower viewing, following a departing aircraft
| | ATC-pie-screenshot-soloMode.png|Solo session with three coloured racks |
| |ATC-pie-screenshot-radarIdentification.png|Radar identification marked in blue
| | ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display |
| |ATC-pie-screenshot-LFPGcloseUp.png|Depiction of airport tarmac and objects
| | ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects |
| |ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
| | ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red |
| |ATC-pie-screenshot-backgroundHandDrawing.png|Hand drawing for LSGG procedures
| | ATC-pie-screenshot-flightPlans.png|Flight plan editor |
| |ATC-pie-screenshot-courseAndAssignmentsGraphics.png|All-in-one display of assignments
| | </gallery> |
| |ATC-pie-screenshot-separationRings.png|Horizontal separation rings
| |
| |ATC-pie-screenshot-routeConflictDetection.png|Route conflict warning
| |
| |ATC-pie-screenshot-stripDetailSheet.png|Strip detail sheet with editable route
| |
| |ATC-pie-screenshot-ATISdialog.png|ATIS recording feature with scrap notebook
| |
| }}
| |
|
| |
|
| == Working principles ==
| | Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more. |
|
| |
|
| === General === | | == Detailed feature list == |
| You are the air traffic controller, and players will connect to the network (or AI traffic be simulated in solo mode) with different types of aircraft and [[transponder]] equipment. As in real life, the radar is [http://en.wikipedia.org/wiki/Secondary_surveillance_radar 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.
| |
|
| |
|
| === Strips === | | === Sessions and environments === |
| 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. Strip details include:
| | Session/connection types: |
| * most importantly, the aircraft's ''callsign'', to be used on the radio; | | * solo simulation (AI traffic) |
| * information like aircraft type, airspeed, route... that can be specified by the pilots themselves when filing ''flight plans''; | | * FlightGear network connection ([[FGMS]] protocol) |
| * transponder code and flight parameter assignments (or vectors: heading, altitude/FL, speed).
| | * FSD connection (as served by https://github.com/kuroneko/fsd commit bc7d43, latest available in Dec. 2022) |
| | * teaching service (spawn and simulate traffic visible to a connected student) |
| | * student session (control traffic simulated by teacher) |
|
| |
|
| === Linking strips ===
| | Location modes (available for all sessions): |
| Strip details can be manually edited, but every 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 one radar contact. Linking to a strip will automatically:
| | * airport (AD): positions such as TWR, GND, APP, DEP at a selected airfield |
| * make the strip display the missing elements made available by the linked aircraft transponder or flight plan; | | * en-route centre (CTR): free positioning of radar, no base airport or runway-related options |
| * 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.
| |
|
| |
|
| === Radar identification === | | {| class="wikitable" style="text-align:center" |
| 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 its transponder has mode S turned on, 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 '''radar identification''' of aircraft–strip pairs such that:
| | |+ Feature support by session type |
| * the strip is assigned a transponder code;
| | ! || Solo || FlightGear || FSD || Tutoring (teacher/student) |
| * no other strip is assigned the same code;
| |
| * the aircraft is the only one 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".
| |
| | |
| == User guide == | |
| This section helps one download and run ATC-pie, and lists a few tips on some of its features. Other sources to learn to use the program are:
| |
| * the '''online video tutorial''' on ''YouTube'' (follow/bookmark the [https://www.youtube.com/playlist?list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb link to the full playlist]);
| |
| * the in-app '''quick reference''' available from the ''Help'' menu (summary of mouse/keyboard gestures, display conventions, etc.).
| |
| | |
| Anyone motivated to write a full user guide is obviously welcome to contact the developer.
| |
| | |
| === Getting it to run ===
| |
| | |
| ==== Downloading ====
| |
| 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 [http://git-scm.com 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 <code>README</code> file.
| |
| | |
| Downloading the '''tarball''':
| |
| # get the latest stable version from [https://sourceforge.net/projects/atc-pie the project page];
| |
| # extract the files to the directory of your choice.
| |
| | |
| To clone the '''repository''':
| |
| : <code>git clone git://git.code.sf.net/p/atc-pie/code ATC-pie</code>
| |
| | |
| When a new release is announced and if you have cloned the repository, you can update your software with a single command from the downloaded directory:
| |
| : <code>git pull</code>
| |
| | |
| ==== 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 <code>ATC-pie.py</code> 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:
| |
| : <code>./ATC-pie.py ICAO</code>
| |
| | |
| If no ICAO code is given, good old KSFO will be chosen as default. After a few seconds, you should see the main window appear with a radar scope and a depiction of your airport in the centre.
| |
| | |
| Additional command line options are available:
| |
| {| class="wikitable"
| |
| ! Option || Effect and argument specification || Default | |
| |- | | |- |
| | --tower-view-external=''host'' || Avoid running an internal FlightGear process for tower viewing, and specify a host on which a viewer is running. This may still be "localhost". || (none, start internal process) | | ! ACFT traffic |
| | | AI aircraft generated according to RWY capacities, ACFT equipment, intentions... |
| | | colspan="2" | connected flight sim pilots |
| | | created and simulated by teacher |
| |- | | |- |
| | --tower-view-ports=''udp'',''telnet'' || Specify the tower view ports to send/connect to. These can be the same (UDP+TCP on same port), and are used whether the view is a child (internal), local or remote process. || 5010,5010 | | ! ATCs and coordination |
| | | virtual ATCs depending on assumed positions |
| | | colspan="2" | connected ATC clients (full ATC-pie interaction, [[#Interoperability with other software|interoperability with other software]]) |
| | | teacher-configured ATCs |
| |- | | |- |
| | --add-view=''host'':''port'' || Register an additional FlightGear instance to forward MP and solo game packets to. This option can be repeated. || (none) | | ! Voice radio |
| | | voice recognition for instructions (mouse-only also available) and synthesis for pilot read-back |
| | | colspan="2" | [[FGCom-mumble]] integration |
| | | teacher simulates pilots |
| |- | | |- |
| | --views-send-from=''port'' || Change the local UDP port number to bind for sending FGMS packets to views. This includes all tower and additional views, but does not affect the multi-player connection ports, chosen on MP connect. || 5009 | | ! ATC phone lines |
| | | N/A |
| | | colspan="2" | integrated Mumble connection |
| | | teacher simulates ATCs |
| |- | | |- |
| | --fgcom-server=''address'' || Set the server used by internal FGCom radio boxes. || fgcom.flightgear.org | | ! Flight plans |
| | | local entries only |
| | | interface with the FlightGear ''de facto'' [http://flightgear-atc.alwaysdata.net data base by Lenny64] |
| | | available from network (NB: protocol does not support open/close and only pilots can file/amend FPLs) |
| | | shared virtual online system |
| |- | | |- |
| | --fgcom-ports=''list-spec'' || Specify a comma-separated list of port numbers for internally started radio boxes. The first one becomes reserved for echo test and ATIS recording while every other port will allow for an additional radio box in the game. Alternatively, enter a string of the form ''reserved''+''nboxes'' as a shortcut for a contiguous range of ''nboxes''+1 ports. || 16665+4 (port 16665 reserved, plus 16666 through 16669 for up to 4 radio boxes) | | ! CPDLC |
| |} | | | interpreted subset of instruction messages |
| | | | integrated (supported by MP IRC) |
| ==== Running for the first time ====
| | | integrated interface with [https://www.hoppie.nl/acars/ Hoppie's ACARS network] |
| A few things you will want to do when running ATC-pie for the first time:
| | | full simulation by teacher (with WILCO assistance to execute instructions) |
| * If you intend to use the radio like you should in multi-player games, check the FGCom version setting in the ''System'' menu, and try an echo test. Read the <code>resources/fgcom/Notice</code> file if you have problems hearing yourself, and check the FAQ section in this article.
| |
| * In the same menu, if you want to use the tower viewing system and not bother making it external (see feature note below), make sure you have the right paths set for your FlightGear installation.
| |
| * Set up the airport runway parameters in the airport settings, especially ILS capability if you will be playing solo often at the same location.
| |
| | |
| === Feature notes ===
| |
| This section describes a few major features. See more exhaustive list at the top of this article.
| |
| | |
| ==== Routing and conflict warnings ====
| |
| ATC-pie analyses routes and assigned vectors to assist traffic management and anticipate path conflicts between controlled aircraft.
| |
| | |
| A '''route''' is parsed for every strip with both recognised departure and destination airports (names shown near respective fields on the strip sheet), as follows:
| |
| * route tokens are whitespace-separated;
| |
| * each recognised navpoint token (world navigation aid, airfield, fix, RNAV point) creates a ''waypoint'' on the path to destination, and a route ''leg'' from the previous point (a final leg connects the last point to the destination airport);
| |
| * other tokens are kept as route leg specifications to the following waypoint;
| |
| * if ambiguous (navpoint names are not all unique around the world), a waypoint is always the nearest homonym to the point beginning the leg.
| |
| | |
| When a route is parsed and a radar contact linked to the strip, the current route leg is detected based on distance to destination, and:
| |
| * the route to go is drawn as a dotted line on the radar scope (according to scope "show" options);
| |
| * the current leg is displayed in the selection info pane, including any contained specification;
| |
| * the strip shows only the remainder of the route for this contact;
| |
| * the info box contains the next waypoint and the heading leading the aircraft to it on a great circle, unless:
| |
| ** the current route leg is the first, and the keyword "SID" appears in its specification: "SID ''wp''" is displayed, where ''wp'' is the first waypoint on the route;
| |
| ** the current route leg is the last, and the keyword "STAR" appears in its specification: "STAR ''wp''" is displayed, where ''wp'' is the last en-route waypoint.
| |
| | |
| If no route can be interpreted (missing or unidentified DEP or ARR), info boxes will show the strip destination detail (ARR) if it is filled, possibly with a heading if it is recognised.
| |
| | |
| ATC-pie also features a '''conflict prediction system''', which can be activated or turned off from the ''Options'' menu. It uses route and vector assignments to anticipate and alert you of ''path conflicts'' so you can take action and prevent separation losses.
| |
| | |
| When looking for conflicts, a horizontal (ground projection) path is considered for every aircraft with a linked strip and a parsed route or an assigned heading vector. An aircraft is assumed to follow its route, unless a heading vector is given in which case it is assumed to be flying the assigned straight course. Path conflicts occur when horizontal paths intersect and the intervals between respective current and assigned altitudes overlap. When no altitude is assigned, the interval is one around the current altitude. When an aircraft's altitude is unknown, any assigned altitude will be considered instead.
| |
| | |
| Another possible alarm is the ''separation incident'', a serious ATC mistake which calls for immediate action. The table below summarises the different levels of conflicts, ranked in decreasing order of emergency.
| |
| | |
| {| class="wikitable"
| |
| |+ Conflict warnings in ATC-pie
| |
| |-
| |
| ! Alarm || Shown on scope (default colours) || Meaning
| |
| |- | | |- |
| | Separation incident || Bright red intersecting circles || Separation loss between aircraft | | ! Weather |
| | | randomised and evolving |
| | | real world METAR retrieval |
| | | fetch from server or retrieve real world METAR |
| | | controlled by teacher |
| |- | | |- |
| | Path conflict || Red circles and paths || Anticipated paths and altitudes are intersecting | | ! Other specific features |
| |- | | | style="text-align:left" | |
| | Possible path conflict || Yellow circles, red paths || Ground projection of paths are conflicting but not all altitudes are known | | * aircraft type and airline choice with custom appearence in tower view |
| | * configurable airspace rules and traffic density, incl. uncontrolled distractors |
| | | style="text-align:left" | |
| | * exact aircraft rendering in views (incl. control surfaces, etc.) |
| | * legacy [[FGCom_3.0|stand-alone FGCom]] alternate possible (although deprecated) |
| | | style="text-align:left" | |
| | * frequency tuning system for radio text chat |
| | * text ATIS repeatedly sent through radio chat on recorded frequency |
| | | style="text-align:left" | |
| | * traffic snapshots and recall to repeat situations with the student |
| | * individual aircraft freeze |
| |} | | |} |
|
| |
|
| ==== Solo training mode ==== | | === ATC surveillance === |
| This mode allows to train on your own in different situations. Three combinable positions are available:
| | Radars and tracking: |
| * tower (TWR), controlling runways and immediate surroundings; | | * SSR mode capability selection (none/A/C/S) |
| * departure (DEP), bringing departing traffic to their exit point; | | * primary radar toggle |
| * approach (APP), vectoring arrivals onto final. | | * traffic identification assistant |
| | * position/track vs. strip assignment mismatch warning system |
| | * route/vector conflict anticipation |
| | * separation incident alarm |
| | * runway occupation/incursion detection |
|
| |
|
| In any case, you will be controlling virtual IFR planes via the software interface, and receiving and handing over strips to virtual ATCs, depending on your position and on the aircraft's intentions (see table below). Approaches can be requested ILS or visual, and the balance between the two is adjustable from the solo mode settings.
| | Tower view in airport mode (rendered by FlightGear): |
| | * view of airport, aircraft, weather, time of day |
| | * start internal process or use externally running instance |
| | * control panel to orient/zoom view or follow aircraft |
| | * additional views can be connected (for multiple camera angles) |
|
| |
|
| Assuming APP, aircraft requesting ILS must be vectored to intercept a runway localiser and cleared for ILS approach, whereas those requesting visual require vectors until they report the expected runway is in sight. Then, approaching aircraft must be handed over to TWR, unless you are in the TWR position as well. If you are, you must clear them to land—or they will climb back up for go-around—and hand them over to ground control (GND) once they have vacated the runway. Tower also manages departures, which appear ready holding short of runways. After take-off, hand over your strips to departure control, unless assuming DEP yourself. When doing DEP, you must hand outbound aircraft over to the en-route centre (CTR) once they are high enough and close enough to their exit point if specified.
| | Other: |
| | * radio direction finding (RDF) and integration to radar |
| | * multiple weather (METAR) station monitor |
|
| |
|
| {| class="wikitable" style="text-align:center"
| | === Traffic management === |
| |+ Handovers with virtual ATCs
| | Strips and racks: |
| |-
| | * user-defined strip racks with configurable colours (for linked radar contacts) and ATCs to receive from |
| | || colspan="2" | Departure strips || colspan="2" | Arrival strips
| | * runway boxes with automatic RWY separation timers |
| |-
| | * loose strip bays with customisable backgrounds |
| ! Assuming positions || Receive from || Hand over to || Receive from || Hand over to
| | |
| |-
| | Flight plans and routes: |
| ! DEP only
| | * flight plan system (file, edit, open, close, publish/retrieve online) |
| | TWR || CTR || colspan="2" | N/A
| | * world route suggestions, presets, analysis, radar drawing and world map view |
| |-
| | * departure clearance assistant |
| ! APP only
| | * automatic strip printing for expected departures or arrivals (from FPLs) |
| | colspan="2" | N/A || CTR || TWR
| |
| |-
| |
| ! TWR only
| |
| | GND || DEP || APP || GND
| |
| |-
| |
| ! APP+DEP
| |
| | TWR || CTR || CTR || TWR
| |
| |-
| |
| ! TWR+DEP
| |
| | GND || CTR || APP || GND
| |
| |-
| |
| ! TWR+APP
| |
| | GND || DEP || CTR || GND
| |
| |-
| |
| ! TWR+APP+DEP
| |
| | GND || CTR || CTR || GND
| |
| |}
| |
|
| |
|
| '''Vectors''' are given by means of the vectoring assignment tool (click&drag on radar contact for heading, with SHIFT for altitude/FL and speed). '''Other instructions''' (''line up and wait'', ''clear to land'', etc.) can be sent from the instruction dock. Pull it up from the ''View'' menu if it is not visible. Non-vectoring instructions are sent to the callsign entered in the top field, which should fill automatically on aircraft or strip selection if a callsign is known.
| | Radar tools: |
| | * convenient mouse input for instructions (vectors, taxi...) and CPDLC integration |
| | * approach spacing hints (estimated touch-down time difference, sequence optimisation suggestions) |
| | * quick point-to-point heading and distance measuring tool |
| | * direct text annotation of radar screen |
| | * flag/unflag (highlight) radar targets |
|
| |
|
| Things you can train for:
| | === Communications === |
| * approach in dense traffic: select APP position only and increase traffic density; | | With aircraft: |
| * towering a single runway, optimising its use: select TWR position and an equal balance of departures and arrivals; | | * voice radio with 8.33 kHz frequency spacing, multiple radio transmissions and monitoring |
| * change of runways (e.g. irl after wind direction change): start with APP+TWR and select a runway for arrivals at least, play for a while and go back to the dialog to change for the opposite runway; | | * [[ATIS]] recording and reminder alarm (see [[:File:ATC-pie-screenshot-ATISdialog.png|dialog]] with pre-filled notepad) |
| * etc.
| | * [[controller-pilot data link communication]] (CPDLC), incl. DEP clearance delivery, multi-element messages... |
| | * text radio chat with preset messages, auto-completion, predefined and custom aliases (context-sensitive replacements), sender blacklist |
|
| |
|
| ==== Tower viewing ====
| | ATC coordination: |
| This feature allows you to overlook your airport and the connected (MP) or simulated (solo) traffic, like a controller from a '''tower viewpoint'''. It uses the tower position specified in the source data if any, otherwise defaults to somewhere over the airport to allow towering all available airports.
| | * strip exchange (handovers) |
| | * CPDLC authority transfers |
| | * telephone lines and switchboard (direct voice communication) |
| | * text messaging (private channels and general ATC chat room) |
| | * "who has?" requests |
|
| |
|
| There are two ways of activating a tower view. You may let ATC-pie start its own suitably configured FlightGear process, or have it connect to an external viewer, manually set up and accepting connections. The latter way takes a little more effort but allows to run FlightGear on a different machine and thereby relieve your session from the CPU load a local instance induces. If you are going for that, start ATC-pie with <code>--tower-view-external</code> and check the <code>--tower-view-ports</code> and <code>--views-send-from</code> command line options in the table above to set it up correctly.
| | === 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 |
|
| |
|
| Running internally only requires FlightGear installed on your computer. A basic installation is enough, but:
| | GUI: |
| * not all aircraft will be drawn properly if you do not have the corresponding [[Aircraft|models]] installed—it is up to you to add models or create substitution links (in your FlightGear [[$FG_ROOT|root directory]] or in <code>resources/fg-aircraft</code> according to the <code>Notice</code> file), or be happy with the default blue and yellow glider that will stand for any missing model; | | * multiple window workspace (radar screens, strip racks and bays) saved by location |
| * more importantly, you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!)—go to [http://www.flightgear.org/download/scenery/ this page] or use [[TerraSync]] to download it to your computer, and add it to your FlightGear root directory or set the right scenery directory in the ''System'' menu (ATC-pie will pass it on to FlightGear and save your setting). | | * floatable/dockable panels and toolbars (see [[:File:ATC-pie-screenshot-toolbars.png|screenshot]]) and layout save/restore |
| | * notification system combining selectable sounds, status bar messages and time-tagged history |
| | * customisable style and colours |
|
| |
|
| In either case, once activated from the ''View'' menu, the tower view controller pane is enabled and you can turn to runway points, follow selected aircraft, etc. Additionally, use right click and drag directly on the view to look around, and you may use the <code>x</code>/<code>X</code> keys to change the zoom level from the view window (this is direct FlightGear input).
| | Data sources: |
| | * airport and navigation data sourced in the [http://developer.x-plane.com/docs/specs 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/[http://www.vatsim.net VATSIM]/IVAO "sector file" conversion tool included) |
| | * ground elevation maps (can be generated automatically with a provided script if FlightGear terrain data available) |
| | * manual magnetic declination input |
|
| |
|
| You can also connect '''additional viewers''' to your session, for example placed around your airport for exciting camera footage of challenging landings. You will not be able to control those viewers from ATC-pie like the tower viewer, but you will be able to activate/stop the connection with a switch in the application ''View'' menu. To do so, start every additional FlightGear viewer with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, and append an option <code>--add-view=XXX:YYY</code> to your ATC-pie command. In these options:
| | == Interoperability with other software == |
| * ''HHH'' is the host on which ATC-pie is running (same value for all viewers);
| |
| * ''PPP'' is the default 5009, or the chosen port number if ATC-pie is started with <code>--views-send-from</code> (same value for all viewers);
| |
| * ''TTT'' is the network polling frequency (100 is common practice; change as desired if you know what you are doing);
| |
| * ''XXX'' is the host where this viewer is started;
| |
| * ''YYY'' is the port to use on ''XXX'' for FGMS packet reception by the viewer.
| |
|
| |
|
| ==== Multi-player strip exchange (handovers) and OpenRadar interoperability ==== | | === OpenRadar === |
| The handover feature in ATC-pie is based on OpenRadar's exchange server to enable ATC coordination between users of both software programs. However, it is to note that their philosophies differ in several ways:
| | [[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 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, write any callsign and link it to a radar contact; | | * 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 the OpenRadar philosophy, a handover must be acknowledged by the receiver for the sender to lose ownership and for all neighbouring OpenRadar users to see the handover complete, whereas ATC-pie considers that a strip sent through the hand-over pipe is gone and should land directly on a receiver's rack at the other end, without anybody else necessarily to know. | | * 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 while still respecting both philosophies as much as possible, the following principles were chosen: | | 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 that are linked to a radar contact (no lone strip can be sent); | | * 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; | | * aircraft under ATC-pie control are not shown as "owned" to OpenRadar users; |
| * handovers from ATC-pie will fail if an OpenRadar user in range is claiming ownership; | | * 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. | | * when sending to ATC-pie controllers, OpenRadar users will see their transfers acknowledged straight away, unconditionally. |
|
| |
|
| Callsign exchange policy: | | Callsign handover policy: |
| * O-R to ATC-pie: FGMS callsign will appear on the strip, as if the sender had filled the detail properly; | | * OpenRadar 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; | | * ATC-pie to OpenRadar: callsign resolved for the receiver, sender's entry will reappear next time ATC-pie handles the strip; |
| * pie-to-pie handovers: strip detail preserved, whether present or absent. | | * pie-to-pie handovers through OpenRadar's service: strip detail preserved, whether present or absent. |
| | |
| In practice, in ATC-pie, a strip can be handed over by dropping it on the chosen ATC in the list of connected controllers in range. Received strips appear unlinked on the reserved rack, with an identification of the sender which disappears as soon as the strip is clicked on.
| |
| | |
| ==== Background drawings ====
| |
| Background drawings allow to decorate radar scopes with all sorts of maps and useful information about the airspace, terrain or procedures.
| |
| | |
| There are two ways of drawing in the radar background. One is to import '''image files with transparency''', the other is to write a '''text drawing specification''' file to draw coloured lines and label points. This allows to import anything from the most complex coloured height map to the the most schematic airspace outline. All images are positioned and drawing points specified using lat/lon coordinates or navpoints in radar range. The <code>resources/bgdrawings/Notice</code> file explains how to import and create background drawings.
| |
| | |
| For example, you can map out SID/STAR routes with one image per published chart, named by procedure and associated runways to make in-game selection easy. If you want more than schematic line plots of the procedures, the best way is certainly to draw the images yourself with good enough resolution, e.g. with Gimp. Superimpose a drawing layer on top of a real map canvas, or over a screenshot of your ATC-pie radar with pinned navaids as landmarks. If you have proper to-scale documentation, it is worth trying the command below (requires ''ImageMagick'') to turn the white background of a ready published chart into transparency, and checking if the rendered images are acceptable and zoom-resistant enough.
| |
| :<code>convert -transparent white input-file.png output-file.png</code>
| |
| | |
| Use the image positioning helper tool in the ''System'' menu if you want to adjust image corners visually rather than programmatically. All visible pixmap drawings will be moved simultaneously, so you can work with several at a time if you need to. On dialog box close, a file is generated in the <code>output</code> folder for you to open and copy/edit, or use as a direct substitution.
| |
| | |
| === Tips ===
| |
| Here are a few tips to help you navigate and use the program.
| |
| | |
| '''FGMS callsigns''' for ATCs typically start with the ICAO code of the controlled airport or sector, and end with a hint on the provided service: twr, gnd... When choosing your callsign on MP connect, make sure it is unique, and note that FGMS restricts callsign length to 7 characters. :-(
| |
| | |
| ==== Interface and information display ====
| |
| The '''''Options'' menu''' is divided in two sections. The top section contains unsaved session options, which go back to their default setting on restart. The bottom section are saved settings, which come in two flavours:
| |
| * airport-specific (all under a unique submenu): saved and restored when started at the same airport again, e.g. runway ILS capabilities;
| |
| * global settings: saved and restored regardless of airports, e.g. preset text chat messages.
| |
| | |
| You can '''customise the radar colours''' by editing the colour codes in the <code>settings/colours.ini</code> file generated on first run.
| |
| | |
| '''Heading displays''' are mostly magnetic so they can be read out to pilots. The only exceptions perhaps are the navigator and handover list tooltips, for easier human identification on the scope. All directions are geodesic.
| |
| | |
| The '''transition level''' displayed in the weather analysis is the lowest flight level that is still above the transition altitude. This does not mean the lowest to be expected in ATC clearances, which may be higher, for more vertical separation on either side of the transition layer or due to coordination with neighbouring zones and fields.
| |
| | |
| The grouped tick marks along the '''localiser line''' (when shown) indicate best altitudes AMSL for final approach along the defined flight path angle: every mark in a group is 1,000 ft.
| |
| | |
| ==== Radio and text communications ====
| |
| Several radios can be opened and tuned in at once, and you can talk on either one by holding the PTT mouse button down for the chosen radio box. The <code>left-Ctrl</code> keyboard key will also let you PTT on selected frequencies. You can transmit on several at once, for example to service GND+TWR frequencies in view of splitting them seemlessly again if a controller is expected soon to fill one of the two positions. Tick the ''Kbd PTT'' option in the radio boxes of the frequencies to merge. Your keyboard PTT key will then transmit on them all simultaneously. Note that while you will be broadcasting on, and hearing incoming transmissions from, all frequencies, pilots will not be hearing each other across frequencies.
| |
| | |
| Say you are TWR coordinating with GND at your airport, and you want to '''monitor both radio frequencies''' while you are only in charge of TWR. To set this up, start your radio box on TWR frequency and turn on a second one to monitor GND. Tick "Kbd PTT" only for TWR so that you only transmit to your frequency and don't interfere with the other, and set the volume to "soft" on the latter so that you can tell the radio you are hearing the messages from, and know if it is for you to answer.
| |
| | |
| The '''''PTT turns off sounds''''' option is recommended for those of you who do not wear headsets, as it will avoid GUI sound notifications being picked up by your microphone while transmitting on frequencies.
| |
| | |
| For more efficient text chat, '''text aliases''' are available and allowed in both instant and preset chat messages, e.g. <code>$wind</code>, <code>$qnh</code>... When the containing message is sent, they automatically expand to the current context-dependant value. Custom aliases can be used, whose replacement will be searched for in the general and airport notes (your notepads) and in the selected strip comments. This allows for variable text by controller, by airport and by radar contact. Have a look at the ''Quick reference'' available from the ''Help'' menu, ''Text aliases'' section. Unsuccessful replacements will trigger an edit box so that you can review your message before sending it.
| |
| | |
| Everything up to the first pipe character (<code>|</code>, if any) in a text chat line will be stripped before the message is processed and sent. For quicker access to preset messages if you use them and the keyboard a lot, you can therefore '''prefix your messages''' with a custom shortcut and a pipe, which will enable autocompletion to pull up the desired message line as you start typing the prefix. Here is a preset message example enabling something like a dot-command for sending a bearing to your airport to the currently selected pilot:
| |
| : <code>.qdm|Heading to airport $qdm</code>
| |
| | |
| ==== Strip and flight plan details ====
| |
| Every '''initial contact by a pilot''' should basically make you hit F2 and enter at least the call sign announced. You should then soon figure out if:
| |
| * a flight plan is filed, in which case you can save the strip relatively quickly and look for the FPL to link to it (middle click on the FPL entry);
| |
| * a flight plan must be filed (e.g. IFR departure not filed by lazy pilot), which only takes a tick in the bottom-line box before saving to open a freshly linked FPL detail sheet to fill;
| |
| * he was asked to contact you by a previous ATC, in which case you may have a strip handed over to you already (check the unassigned strip rack);
| |
| * etc.
| |
| | |
| In '''airport input fields''', typing a single dot will instantly fill the box with your ICAO position. Use this as a shortcut from/to your airport when filling details.
| |
| | |
| Resolving '''strip–FPL conflicts''':
| |
| * to confirm strip details: open the strip detail sheet, tick the "push details to FPL" box and save to propagate the strip details;
| |
| * to confirm FPL details: "pull FPL details" from the button menu to reset the conflicting strip details to the values filled in the linked flight plan;
| |
| * to confirm some details of each source: open the strip sheet, get rid of the bad details before pushing to the flight plan.
| |
| | |
| Resolving '''local–online flight plan 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).
| |
| | |
| == FAQ ==
| |
| | |
| Questions frequently asked (at least twice) about the program:
| |
| | |
| '''Q: How do I start anywhere else than bl*ody KSFO?'''
| |
| | |
| A: Use a command line argument: <code>./ATC-pie.py ICAO</code>
| |
| | |
| '''Q: Why am I not seeing this aircraft on my radar? I know it is there: the pilot is sending chat messages and/or it is visible on the online live map...'''
| |
| | |
| A: You only see an aircraft on your screen if your radar picks up a transponder signal from it. The two following cases will therefore prevent you from seeing a connected aircraft:
| |
| # Its onboard transponder is turned off, i.e. not responding to your radar ping, and you should tell the pilot to switch it on. See the [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. If the aircraft model does not support the transponder feature, it will be simulated by ATC-pie according to the fallback mode you have selected in the settings dialog; any non-zero mode will do. Another, more radical way is to cheat with menu options "reveal OFF/STBY" or "radar cheat mode" ([https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3]).
| |
| # The aircraft is under the radar floor setting. Check in the ''General settings'' dialog; set it to "SFC" to pick up all signals.
| |
| | |
| '''Q: What is the strip exchange server? Which one to use?'''
| |
| | |
| A: The strip exchange feature allows you to hand over strips to ATCs who are connected to the same server and within 180 NM from your position. The public server currently open for general multi-player use is <code>http://h2281805.stratoserver.net/FgFpServer</code>. To hand over a strip, drag it from its rack and drop it on the chosen callsign in the ATC handover list. Publicise your frequency so that ATCs around know what to tell pilots for them to contact you!
| |
| | |
| '''Q: What nickname should I use for the strip exchange server? Where to get my ID?'''
| |
| | |
| A: This feature is not linked to any account or identification process; just choose any name you would like to be recognised by. It will appear in a tooltip over your callsign in the handover list of ATCs who will connect near enough to see you. In a sense, this feature is more social than technical, but makes sense as typical ATC callsigns remain mostly anonymous over MP. Use this field so that other players can identify you.
| |
| | |
| '''Q: Can I draw SID and STAR procedures on the radar?'''
| |
| | |
| A: Yes, and virtually anything else, using background images and hand drawings. To learn how, see the corresponding section above, read the <code>resources/bgdrawings/Notice</code> file and have a look at the packaged example for KSFO.
| |
| | |
| '''Q: How do I assign SIDs and STARs to aircraft?'''
| |
| | |
| A: This question seems asked quite a lot more than it sounds relevant to a real controller's task. Say you could click around the interface and "assign" a STAR to an inbound aircraft; what would the effect be after that? Should this be important to you, you can always freely comment your strips with the information you want to save. But the realistic wishes in relation to this question are already addressed otherwise:
| |
| * Planning routes
| |
| *: Published standard departure and arrival procedures (SIDs and STARs) are very often relied on when planning a route for an aircraft, usually prior to departure. Hopefully copied straight from an existing flight plan, the route is written on the flight strip, modified as the flight progresses and passed along with handovers. Like any piece of route specification, you can specify that a SID or STAR is to be followed in the strip route field, e.g. "SID FUBAR en route stuff DUMMY STAR". This will even be recognised by ATC-pie and accounted for in the second line of the radar contact info box when appropriate (see feature note on routing).
| |
| * Reference for easy text chat communications
| |
| *: When such route is parsed on the selected strip, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively be replaced with the first and last en-route waypoints if the "SID"/"STAR" keywords are present and placed correctly. With the example route above, <code>$wpsid</code> will turn into "FUBAR" and <code>$wpstar</code> into "DUMMY". Now if you specifically want to assign a full published procedure name to a contact, e.g. FUBAR4E, and use it in text chat messages without typing it, include a line "sid=FUBAR4E" in your strip comments. It will pop up with the strip mouse-over tooltip, and create a custom <code>$sid</code> alias that will automatically be filled in your sent messages when that strip is selected.
| |
| | |
| '''Q: FGCom radio is not working. What is going on?'''
| |
| | |
| A: There can be a variety of reasons, all of them to rule out before reporting a bug in the program. Start a single ATC-pie instance and try the echo test (''System'' menu). If it works, you may skip directly to item 3 below.
| |
| # Bad FGCom version setting
| |
| #: Verify the "FGCom version" set in the ''System'' menu, which should point to the right executable file under <code>resources/fgcom</code> and suit your operating system (see <code>Notice</code> file). Four versions are initially packaged with ATC-pie: Linux64, Linux32, Mac, Win32.
| |
| # FGCom server down
| |
| #: This can happen, unfortunately even for up to a few days. Check for responses from the server, e.g. with <code>ping fgcom.flightgear.org</code>.
| |
| # FGCom subprocess error
| |
| #: If the server is up (responding to ping), check for errors in the logged FGCom output files in the <code>output</code> directory.
| |
| # Port mess-up on your side
| |
| #: If you are running multiple instances of ATC-pie, make sure you have no more than one radio box on every port. In any case, verify you only choose available ports that are not already in use by your operating system for example. Typically, default ports (from 16661 counting up) work fine, but you will have to change them for parallel instances, using the <code>--fgcom-ports</code> command line option (see section: ''starting the program''). To check what port a radio box is using, see its "on/off" button tooltip.
| |
| | |
| '''Q: Tower view is not starting. The menu option is ticked but nothing happens.'''
| |
|
| |
|
| A: Ruling out that FlightGear is not installed at all, your system path settings are probably wrong. From a terminal, find the right command to start FlightGear and enter it as ''FlightGear executable'' from the ''System'' menu. Do not add options of any kind; they will be taken care of internally. You may have to enter a ''[[$FG_ROOT|FlightGear root directory]]'' as well, especially if you have the program files installed somewhere unexpected. Your entries will be saved after that.
| | Features not supported by OpenRadar: |
| | * wake turbulance category on strips (but detail preserved for ATC-pie clients later receiving the strip); |
| | * ATC text messaging; |
| | * ATC phone lines; |
| | * CPDLC transfers. |
|
| |
|
| '''Q: Why is my tower in the middle of the sea, and aircraft water landing/floating?'''
| | Who-has requests are fully supported. |
|
| |
|
| A: You are missing the FlightGear scenery data for your location, or ATC-pie does not know where it is. Check out the ''Tower viewing'' feature note in this article.
| | === Euroscope === |
| | Euroscope is a popular program to control on VATSIM, a flight simulation network whose protocol is historically based on FSD. It has been increasingly tailored for VATSIM, although for a long time it allowed also to connect to "plain" (non-VATSIM) FSD servers. Operability outside of VATSIM is now discontinued all together, but 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. |
|
| |
|
| | [[Category:ATC-pie]] |
| [[Category:ATC clients]] | | [[Category:ATC clients]] |
| | [[Category:Air Traffic Control]] |
