FlightGear wiki - User contributions [en]

ATC-pie FAQ

2026-03-16T00:20:09Z

Mickybadia: Version 1.10.0

{{forum|83|ATC-Pie support & development}}

This page is a collection of questions asked at least twice about [[ATC-pie]]. It is a good idea to search through it before repeating a question on the forum or anywhere.

== Things "not working" ==

=== This aircraft is connected but I am not seeing it on my radar. ===
As in real life, the main radar technology is [http://en.wikipedia.org/wiki/Secondary_surveillance_radar SSR], which only shows what is picked up from on-board transponders in its range. It coexists with primary radar, which detects aircraft regardless of transponders but offers no information other than position (angle and distance), i.e. neither of callsign, altitude, type, IAS, etc.

The following cases will therefore prevent you from seeing a connected aircraft:
* The radars are turned off. Turn on at least a primary radar from the ''Options'' menu, or an SSR capability from the ''Radar'' tab in the location settings dialog. Any SSR setting other than "none" will pick up contacts.
* The aircraft is out of radar range, either too far out or under the radar floor. Check the horizontal range and floor settings ("SFC" will pick up all signals down to the ground). Primary and secondary radars share the same range.
* Its onboard transponder is turned off (and primary radar is off); see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Otherwise if you accept cheating, you can activate the "radar cheat mode" which will simulate a mode S transponder for all aircraft in horizontal range; see [https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3].

=== The aircraft vectoring tool does not come up when I click and drag out of radar contacts. ===
Your radar contact is not linked. Link it to a strip to enable registering the mouse-issued vectors. Radar and strip displays will then be informed according to the current options, e.g. altitude reaching point, unfollowed vector warnings, etc.

=== FGCom is not working. ===
First, note that the historic executable variant of FGCom (FlightGear sessions only) was abandoned in 2025. We now assume the [[FGCom-mumble]] plug-in, which must be run with an external ''Mumble'' client connected to a chosen server. See the project [https://github.com/hbeni/fgcom-mumble/releases release] and wiki pages to download and install it.

To work in sessions, the FGCom-mumble subsystem must be enabled from the session start dialog, with the control port set to the one FGCom-mumble is listening on. To troubleshoot:
* open a single ATC-pie instance;
* check that your sound is on, your volume loud and your system picking up a signal from your microphone;
* start the FGCom-mumble configuration test from the FG/FSD voice settings dialog;
* speak in the microphone while the echo test is running.

=== Tower view is not starting. ===
If the tower viewer process is set to "internal" in the viewer settings, find the right command to start FlightGear and enter it as ''FGFS command''. Do not add options here; they will be taken care of internally. You may have to enter a ''FlightGear root directory'' as well, especially if you have the program files installed somewhere unexpected.

If your tower viewer process is set to "external", the FlightGear viewer must already be running. It is up to you to start it on the specified host. ATC-pie will only be sending data to it, assuming it running.

=== My tower is in the middle of the sea, and aircraft floating/landing on water! ===
You are missing the FlightGear scenery data for your location, or ATC-pie does not know where it is. If you have downloaded scenery and saved it somewhere, have you tried filling the scenery directory with that location in the viewer settings? Also read the [[ATC-pie_installation_guide#Airport scene rendering|related section]] in the installation guide.

=== Simulated aircraft dip underground or levitate over taxiways. ===
Do you have a ground elevation map for the location? Quoting from <code>CONFIG/elev/Notice</code>: "''When no elevation map is found for an airport, the field elevation value is used everywhere on the ground. This should be OK for a rough approximation on flat terrain, but ground traffic will not follow any slopes, thus may appear as floating above the ground, or dipping into it.''" Read the full notice for instructions on how to build your elevation map.

Once you have an elevation map, the next focus is on the FlightGear aircraft models. Because each model has its own coordinate system chosen at developer's discretion, ATC-pie must be given the height difference between each model's origin and the aircraft touch-down point (gear wheels) to position aircraft more accurately. You do this on a per-model basis with ":height" specifications in <code>CONFIG/acft/icao2fgfs</code>. Read the associated <code>Notice</code> section for more information.

=== Phone lines have broken, choppy or dragged out sound ===
You and the other parties must adjust microphone sensitivity. Toggle the phone squelch adjustment box from the system menu and tune the spinbox next to the "call" button in the ATC coordination panel. Lower values will decrease the threshold for sound pick-up and likely break the sound less, but can generate more lag in the communications. The right balance depends on your local configuration, so a few test calls with other connected ATCs will be necessary to decide on the best acceptable value.

=== I cannot connect to my teacher as a student. ===
Using IPv4 addresses, this typically happens when the teacher is in a local area network behind a router. It is a common setup for home internet, in which the teacher's actual host address is not publicly accessible from outside his private network.

If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either:
* for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local host address;
* or to create a virtual network, using a third-party VPN service.

== What is ...? What value/setting for ...? ==

=== What "social name" should I use for FlightGear/FSD sessions? ===
Choose any name you would like to be recognised by on the network. In ATC-pie, it will appear in the tool tip over your callsign for connected ATCs who see you. This feature is only social in the sense that it does not refer to an account or to anything technical, but it makes sense as typical ATC callsigns (e.g. "VHHHtwr") remain mostly anonymous. Use this field to identify yourself on the network.

=== What is the purpose of the flat "strip shelf" button in the strip panes? ===
More than a button, the strip shelf is where you should drop the contacts you release without a handover, e.g. parked traffic shutting down, VFR traffic flying out of your airspace, etc. Clicking on the shelf allows to browse the previously shelved strips, and to recall them, for example if shelved inadvertently.

=== What is "radio direction finding"? ===
RDF is a system that detects the horizontal direction of radio sources when signals are received. Its most common uses are:
* to locate ACFT making radio contact;
* to give bearings to the airport to disoriented VFR pilots.

Setting up your location as equipped with RDF will essentially provide two things:
* a status bar indication of the form "hdg/qdm" in the main window, where "hdg" is the heading from your location to the currently detected radio signal source, or "---" if none, and "qdm" is the bearing (opposite direction, from source to location) for the last received signal, displayed until the next signal is detected;
* the option to draw a line on radar scopes when a signal is detected, making it easy to visualise the transmitting ACFT as the line should hit its target.

=== Are the vector headings true or magnetic? ===
Heading displays in ATC-pie are mostly magnetic so they can be read out to pilots. The exceptions are the navigator and handover list tool tips, which show true radial headings from the radar position, and the teacher's wind section to match the generated ATIS string.

Also note: all directions are geodesic, i.e. initial headings to take on a great circle.

=== How do approach spacing hints work? ===
When the option is turned on, an approach spacing hint will show on every strip verifying the following conditions:
* it is racked in sequence behind another marked with the same (recognised) destination;
* both are linked to an airborne aircraft with a known ground speed;
* the time hint value (see below) does not exceed 30 minutes.

The hint value for a strip is an estimated time difference between the linked aircraft touchdown and that of the traffic ahead, assuming:
* both present ground speeds;
* for the leading aircraft, a straight path to destination;
* for the tailing aircraft, a path straight to the leading one first, then straight to destination.

Caution: some judgement is required when interpreting the hints, as the actual paths to expect can be different from those assumed above, for example when the aicraft are coming from opposite directions.

=== What do the various markings along the approach centre line mean? ===
The regularly spaced groups along a centre line represent altitudes on the approach plane. Each group sums up to an AMSL value in accordance with the set flight path angle (also see ''Display conventions'' in the quick reference):
* straight line = 1,000 ft;
* solid diamond = 5,000 ft.

The other markers drawn with thicker lines are the positions of the ILS marker beacons (OM, MM, IM), the line pattern representing the sound triggered by the beacon in the pilot's headset. They are sourced on program start-up from the navigation data (<code>CONFIG/nav/navaid.dat</code>).

=== Why do I keep getting runway incursion alarms? ===
Because you have the runway occupation monitor turned on (''Options'' menu), while not using your runway boxes. The alarm triggers when the radar detects traffic stepping on a runway in either of the following situations:
* the runway is active (marked in use) and no strip is boxed for it;
* it is reserved but there is already traffic on the runway;
* it is reserved for a different aircraft: the boxed strip is linked to a contact that is not the entering aircraft, or the aircraft is linked to a strip different to the one boxed.

Turning the runway occupation monitor off will deactivate all radar warnings regarding runways. If you are interested in the strip boxing and visual runway highlighting system but bothered by the alarm sound, you can mute the sound notification by unticking it in the general settings.

== Where is ...? How to ...? ==

=== Can I draw SID and STAR procedures on the radar? ===
Yes, and virtually anything else, using background images. To learn about those:
* see the corresponding [[ATC-pie_installation_guide#Background images|installation guide section]];
* read the <code>CONFIG/bg/Notice</code> file.

=== How do I assign SIDs and STARs to aircraft? ===
This question is asked quite a lot more than it is relevant to a real controller's task...

You may be looking to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. The way to handle this is to stack your inbound strips on racks named after your STARs. Every rack represents its own traffic sequence of ordered aircraft, which is perfectly suited to control separate approach paths. Placing a strip on a STAR-named rack basically serves as the "assignment" itself. You can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times.

If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. A route can contain an indication of a standard departure or arrival procedure, but only by their entry or exit navpoints. It should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. Keyword "SID" can be used in the first route leg specification, e.g. "SID FUBAR ..." for a standard departure out to exit point FUBAR, and keyword "STAR" in the last, e.g. "... DUMMY STAR" for a standard approach from entry point DUMMY. They are recognised by ATC-pie and affect the second line of the radar tag when appropriate (see feature note on routes).

One meaningful wish regarding this question is for easy '''reference in text radio''' messages. Firstly, using and naming racks as suggested above, you can use the <code>$rack</code> alias which substitutes the name of the rack on which the current strip selection is stacked. Alternatively, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". If you specifically want to assign a full procedure name like "FUBAR1A" to a contact and refer to it with a generic text message, include a line "sid=FUBAR1A" in your strip comments. It will allow a custom <code>$sid</code> alias that will automatically expand in sent messages when that strip is selected.

=== How to set the transition level? ===
You do not. You can however set the transition altitude in the location settings if your airport specification file does not already include one.

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, e.g. for more vertical separation on either side of the transition layer or due to coordination with neighbouring zones and fields.

=== Can I look up ILS frequencies? ===
Yes, in the ''Location info'' dialog ({{key press|Shift+F1}}).

Besides, you can create aliases with the local notepad for a quick and integrated way of sending them through text, which will be saved when you close ATC-pie. For example, use the following format, one runway per line: <code>ils05=111.11 MHz</code>.

=== The airport/navigation data is outdated. How can I update it? ===

The included '''airport data''' (taxiways, parking positions, frequencies, etc.) is the latest but outdated world-wide <code>apt.dat</code> file compiled by ''X-plane'' ages ago. We keep it there because it allows to run ATC-pie anywhere in the world without requiring external data, but for any serious work at a specific airfield, you should provide the latest source available on the [http://gateway.x-plane.com/airports/page X-plane airport gateway], directly accessible from the ''System'' menu. Extract the <code>apt.dat</code> file from the downloaded package, rename it after the airport's ICAO code keeping the extension (e.g. <code>KJFK.dat</code>), and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> there). Alternatively, for a quick manual touch-up of the old data, you can use the locally extracted file (see <code>OUTPUT/Notice</code>).

The included '''navigation data''' (navaids, fixes, airways, etc.) is the latest GPL version seen for each relevant ''X-plane'' file, also all out of date today. You should provide more recent navigation data, as explained in <code>CONFIG/nav/Notice</code>.

=== How do I customise the GUI and colours? ===
To change the '''radar or strip drawing colours''', edit the <code>CONFIG/colours.conf</code> file. Each line specifies the paint colour for an object type, in a typical hex <code>RRGGBB</code> (red-green-blue) format or as an SVG colour keyword name like "white". To customise the '''main session window''', place a [https://doc.qt.io/archives/qt-5.15/stylesheet.html Qt stylesheet] named <code>main-stylesheet.qss</code> in the <code>CONFIG</code> directory. ATC-pie will apply it to every session window. While you are working on your look and feel, use the reload feature from the "System" menu to avoid restarting after every change.

Send us screenshots and share your files if you find a setup looking really cool! :-)

== Miscellaneous ==

=== What's with the funny name? ===
ATC-pie is written in Python, and I reckoned that the ''pyXXX'' naming habit was becoming a little dull, so I merely switched things around. You can surely do the rest of the math in terms of spelling, and later impact on the logo.

=== Why is the learning curve so steep? People would use your program more if you did/provided [...] ===
Often continued with: '''(you must understand that) this is not VATSIM!'''

We do have a [https://sourceforge.net/p/atc-pie/wiki/Wishlist wish list] and will consider any feature or help request. However, though it has a few cheats, ATC-pie has always choosen realism as a criterion for implementation and design, over the mere incentive of converting otherwise happy users of other programs. It is a good thing that different philosophies and work flows are available out there, and there would be much less interest in having them all copy each other, fighting over users instead of understanding that not all of them wish for the same experience. If serious simulation or learning new skills sound like threats to fun for you, you have a perfectly valid reason not to opt for ATC-pie.

[[Category:ATC-pie]]

ATC-pie user guide

2026-03-16T00:17:00Z

Mickybadia: Version 1.10.0

{{forum|83|ATC-Pie support & development}}

This article is a guide to the air traffic control simulation program [[ATC-pie]], describing some of its major features. A more exhaustive list can be found in the main article. For download and installation help, refer to the [[ATC-pie installation guide]]. For support and troubleshooting, the [[ATC-pie FAQ]] might get you an answer first. Otherwise kindly ask on the dedicated FlightGear sub-forum so that the discussion is public.

Other ways to learn the program:
* watch the online [https://www.youtube.com/playlist?list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb video tutorial];
* read the in-app ''Quick reference'' available from the ''Help'' menu (summary of mouse/keyboard gestures, display conventions...);
* connect to a skilled teacher as a student (personal training);
* [[#Solo_sessions|train solo]]!

== Flight strips ==

Whether electronic (dematerialised) or on paper, printed automatically or filled by hand, the '''flight progress strip''' is the essential piece of air and ground traffic control. Every aircraft in contact is represented by a unique strip on the ATC workbench, and every strip represents a unique contact, present or expected. This ensures that no aircraft is ever forgotten about. Strip positioning and updating then enable to monitor the aircraft's status, sequence number, position, intentions, etc.

=== Strip details and linking ===
[[File:ATC-pie-screenshot-stripDetailSheet.png|thumbnail|The ATC-pie strip detail sheet]]
A click on the "new strip" tool bar button (shortcut {{key press|F2}}) or double-click on an empty strip rack or bay space will open a dialog to fill flight details on a fresh blank strip, e.g. callsign, type of aircraft, destination, etc. Double-clicking on an existing strip allows to edit the filled details.

If providing radar service, strips should be '''linked''' to identified contacts to inform the radar display with the filled details, e.g. assigned altitude, and enable joint selection. To link a strip to a radar contact, select one and middle-click on the other. Conflicts between strip details and the values squawked by the linked transponder will mark the strip with a "!!XPDR" warning.

A strip can also be linked to a filed flight plan (FPL). This will make radar and strip display fall back on filed information for missing details. The strip does not warn of mismatching information between the two because it is normal for the strip information to be updated as the flight progresses.

All together, a selection can therefore involve up to three linked elements: strip, radar contact, flight plan. From the strip menu at the bottom of any strip panel, you can pull details from linked elements (copy them to the selected strip), or push strip details to their linked flight plan if necessary. If you use linking carefully, auto-fill options are available from the general settings, to fill blank strip details with newly-linked information. Unlinking is possible with {{key press|Shift}}+middle-click.

For fast and efficient service, every initial contact by a pilot should basically make you hit {{key press|F2}} and type the spoken callsign. You should then soon figure out if:
* you already have a strip for that contact: a "!!dup" warning appears next to the input field;
* a flight plan is filed whose details can be linked immediately: a list of candidate FPL matches is displayed in the bottom row, which you can select from to link on dialog save;
* a flight plan must be filed, e.g. IFR departure not filed by lazy pilot: save the dialog and use the {{key press|Shift+F3}} shortcut to create a new FPL linked to the selected strip.

=== Strip placeholders ===
ATC-pie provides with three types of placeholders for flight strips: ''racks'', ''loose strip bays'' and ''runway boxes''. According to your ATC position and local facilities, you should choose and arrange your placeholders for optimal control. Strips can then be moved between them using mouse drag and drop.

[[File:ATC-pie-screenshot-stripRacks.png|thumbnail|Strip rack panel]]
A '''strip rack''' is the preferred way of keeping track of a sequence, e.g. a departure queue at a runway threshold. Rack panels can be created from the main window workspace, popped out as separate windows, and a persistent one can be found among the available docks. You can create as many racks as you wish in every panel. Double click on a rack's name to rename it or edit its properties. Use mouse drag to move strips up and down a rack sequence.

A '''loose strip bay''' allows free-hand positioning of strips in its reserved space. Such bays are useful for unsequenced traffic, or to map out relative positions when controlling without a radar. You may also import background images, e.g. a ground chart to keep visual track of taxiing aircraft and vehicles. See <code>CONFIG/bg/Notice</code> to learn how.

[[File:ATC-pie-screenshot-runwayReserved.png|thumbnail|Reserved runway marked in yellow]]
A '''runway box''' is a placeholder for a single strip, named after a physical runway and denoting a clearence to use it (enter, cross, land...). Runway boxes are contained in their own dock, with one made visible for each runway marked as in use in either direction. Thorough use of runway boxes will help you avoid bad mistakes like clear an aircraft to land over lined up traffic. When freed, runway boxes start and display a timer together with the wake turbulance category of the last contained strip to help with TKOF/LDG separation. What is more, if you use radar, a filled runway box marks the runway as ''reserved'' on the scope.

Besides, there are two other places a strip can be dropped on, usually when releasing a contact:
* an ATC callsign in the ATC panel to initiate a handover (or CPDLC transfer/instruction if {{key press|Alt}} is pressed);
* a '''strip shelf''' (flat button at the bottom of strip panels), which clears the strip from your workbench and stores it as shelved.

== Vectors, routes and separation ==

ATC-pie can register and analyse issued vectors and routes to:
* inform strip and radar display;
* help monitor traffic, checking tracked positions against route/vector assignments;
* help manage traffic, anticipating route and FL conflicts between controlled aircraft.

=== Vectors ===
[[File:ATC-pie-screenshot-courseAndAssignmentsGraphics.png|thumbnail|Course/vector drawing for linked radar contact]]
Registering vectors on strips enhances the drawing of linked radar contacts, enables easy monitoring of tracks and detection of aircraft flying off course. To register vectors automatically when a radar contact is linked to a strip, use the following mouse gestures:
* click and drag out of a radar contact to issue a heading vector;
* holding {{key press|Shift}}, click and drag vertically for altitude/FL vectors;
* holding {{key press|Shift}}, click and drag horizontally for speed instructions;
* holding {{key press|Shift}}, double-click on the radar target to clear registered vecors from the linked strip.

See [https://www.youtube.com/watch?v=BvA3MRlGJjU video 5] of the tutorial for more on vectoring, and check the quick reference ''display conventions'' to interpret the lines and colours of the course and vector graphics around radar contacts.

NB: In network sessions, an appropriate text radio instruction is suggested for every mouse vectoring action. This allows you to send it easily to pilots whose communications are limited to text.

=== Routes ===
[[File:ATC-pie-screenshot-routeDetailsView.png|thumbnail|Route details dialog with world path drawn, available when both end airfields are recognised]]
A route is analysed for every strip with recognised departure and destination airports (entry fields both turned green), as follows:
* route tokens are whitespace-separated;
* each recognised navpoint token (radio navigation beacon, 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);
* if ambiguous (navpoint names are not all unique around the world), a waypoint is the nearest homonym to the point beginning the leg;
* other tokens are kept as route leg specifications to the following waypoint, e.g. airways between fixes.

[[File:ATC-pie-screenshot-routeDrawing.png|thumbnail|Assigned routes are drawn as dashed lines on the radar scope when linked to contacts]]
Routes on flight plans and strips are viewable in a route dialog, showing geodesic paths, headings and leg distances on a world map. When a specified route is linked to a radar contact, ATC-pie works out its current leg based on distance to destination, and:
* details of the current leg are displayed in the selection info pane, and the route viewing button enabled;
* the strip shows only the remainder of the route for this contact;
* the route to go is drawn as a dashed line on the radar (unless aircraft is inbound and near enough);
* the radar tag 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.

NB: If DEP and ARR airports are not both recognised, radar tags show the strip destination detail if it is filled, possibly with a heading if it is recognised.

See tutorial [https://www.youtube.com/watch?v=LfdukpBc90w video 7] for a demonstration of routes.

=== Conflicts and anticipation ===
[[File:ATC-pie-screenshot-routeConflictDetection.png|thumbnail|Route conflict depiction]]
ATC-pie 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 aircraft with a linked strip and an assigned route or heading. 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. When the projections of two aircraft intersect, a conflict is anticipated if the respective intervals between the current and assigned altitudes overlap. When an aircraft's altitude is unknown, the assigned altitude will be assumed. If an altitude assignment is missing, a ''possible'' conflict is reported.

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 || Thick bright red intersecting circles || Separation loss between aircraft
|-
| Path conflict || Red circles and paths || Anticipated paths and altitudes are intersecting
|-
| Possible path conflict || Yellow circles and paths || Paths intersecting but some altitudes unknown
|}

== Communications with aircraft ==

=== Voice radio ===
In solo and tutoring sessions, radio transmissions are simulated over a virtual frequency tuned to by all ATC and ACFT parties. Solo radio happens through speech recognition of instructions and read-back synthesis. In tutoring sessions, ACFT transmissions are simulated by the teacher. In all cases, use the {{key press|Ctrl}} key to PTT.

In FlightGear and FSD network sessions, enabling FGCom supports proper frequency-based radio interaction. Multiple radios can then be opened and tuned separately. You can transmit on either one by holding down the PTT button of the chosen radio, or on a selected set (''Kbd PTT'' boxes ticked) using the {{key press|Ctrl}} key. This lets you PTT on multiple frequencies at once, for example to service GND+TWR frequencies at the same time. To monitor frequencies without attending them, a trick is to set their volume to "soft" to tell them apart.

=== CPDLC ===
When [[CPDLC]] is serviced (location setting), aircraft can establish a data link from their cockpit for a direct text communication channel supplementing the radio frequency. You can monitor connections from the CPDLC dock and open a window for each active or terminated connection in the CPDLC history. Combining the {{key press|Alt}} key with a double-click on a strip or radar contact opens the current or latest dialogue for the selected callsign.

Each active CPDLC dialogue window allows to manually compose formatted or free text message elements. But the most frequent and convenient way of creating message elements is to combine the {{key press|Alt}} key with (also see ''Mouse gestures'' in the quick reference):
* a click-and-drag vectoring gesture to send a heading, altitude/FL or speed instruction (see [[#Vectors|section on vectors]]);
* a strip drop on an ATC to initiate a CPDLC authority transfer or to send the aircraft a "contact" instruction;
* an instruction panel "OK" button click to send the corresponding formatted instruction if applicable.

Created message elements are appended to the message buffer in the connection dialogue window until you send the message manually. The other party must then acknowledge it before it times out.

=== Text radio ===
Although voice communications should be encouraged for realism whenever possible, ATC-pie has a powerful text messaging system for keyboard interaction with pilots in network sessions. In FlightGear sessions, all messages from within at least 100 NM and up to the radar range are displayed. In FSD sessions, whose protocol simulates text frequencies, ATC-pie tunes the text radio to the "publicised frequency" in the radio panel.

'''Text aliases''' are dollar-prefixed words that ATC-pie can replace with context-dependant values when sent. For example, <code>$metar</code> expands to the current primary station weather, which allows to send formatted messages like "Current weather is $metar" instead of copy-pasting a weather look-up for every such message. There is a list of predefined aliases, whose replacements depend on the environment, local configuration or current selection. All other aliases are expected to find their replacement in one of the following sources, checked in order (see ''Text aliases'' tab in quick reference for more information):
* general notepad (editable in any session, regardless of location);
* location notepad (saved for this airport or centre);
* strip comments (value applies to single aircraft contact).

Moreover, ATC-pie strips everything up to the first '''pipe character''' (<code>|</code>) in the message if any, before it is processed and sent. You may test this by sending "stripped part|sent part" and observe that only the "sent part" makes it to the message contents. You can therefore make your life easier with piped shortcuts in your preset message list. They will pop up like any other message in the filtered menu as you type. For example, the following preset message enables something like a dot-command for sending a bearing to your base airport in a few key strokes:
: <code>.qdm|Heading to airport $qdm</code>

Lastly, if a troll or angry user is polluting your session with undesired messages, add their callsign to the '''senders blacklist'''. All messages from the user will then be filtered out from the message pane. You can view and clear this list at any time.

== ATC coordination ==

"ATC coordination" refers to the following, in all sessions except playback:
* strip exchange, i.e. sending and receiving strips (handovers);
* ATC phone lines, for private voice calls (unavailable in solo sessions);
* CPDLC authority transfers;
* ''who-has'' requests, to query ATCs about who is claiming control of callsigns;
* ATC text messaging, to exchange text messages with other ATCs (unavailable in solo sessions).

=== Strip exchange ===
[[File:ATC-pie-screenshot-receivedStrip.png|thumbnail|Example of a strip received from "GND"]]
To hand a strip over, drag it and drop it on the recipient in the list of controllers in the ''ATC coordination'' dock. A received strip appears with an identification of the sender which disappears as soon as the strip is clicked on.

A received strip lands on the collecting rack set for the sender if any (double-click on a rack name to add an ATC callsign from which to collect strips), or on the "Default" rack otherwise. It may link automatically to an identified radar contact according to the selected auto-link options (general settings).

See [https://www.youtube.com/watch?v=oQIud-cAlT4 tutorial video 6] for a presentation of the feature.

=== ATC phone lines ===
Phone lines allow to call and talk to other ATCs directly from the ''ATC coordination'' dock. Each line has an outgoing state that you control, toggling between open and closed with a double-click on its phone icon. Opening a line places a call to the connected ATC, showing as incoming on their side. When two parties have their line open to one another, they are in direct communication (no push-to-talk). In other words, opening an incoming call puts you on the phone with the caller, and closing an active call hangs up the active line, but you can pick it back up as long as the other party holds it open.

You can only talk to one ATC at a time but may place multiple outgoing calls. If a call you placed is answered while you are already in a call, the answered call switches to show as incoming without interrupting the one in progress. On your side, an incoming call you answer which turns to "placed" (outgoing only) instead of "in progress" means that the other party is already on the phone and is now seeing an incoming call from you. Opening (answering) an incoming call while already in a call yourself drops the current line.

=== ATC text messaging ===
The ATC text messaging system allows to talk with other ATCs in channels outside of the "text radio" visible to pilots. It offers private channels for one-to-one conversations, and a public ATC chat room in network sessions, readable by all connected ATCs. Text alias substitution works here too.

'''Note on interoperability in FG sessions''': While only ATC-pie integrates ATC text messaging in its interface, other users can interact with a regular IRC client connected to <code>mpirc.flightgear.org</code>, with their FlightGear network callsign as IRC nickname, and joining the set IRC channel. They will be able to send and receive public and private messages and talk with everybody, at the only cost of ignoring the system messages that will sometimes appear on their side.

== Solo sessions ==

In solo sessions, you control virtual IFR planes, receiving and handing over strips to virtual ATCs depending on your position and the aircraft's intentions. You can train as an en-route controller in CTR mode, or as an airport controller in AD mode, where four combinable positions are available:
* ground (GND), to taxi aircraft between parking positions and runways;
* tower (TWR), to control runways and immediate surroundings;
* departure (DEP), to bring departing traffic to their exit point;
* approach (APP), to vector arrivals onto final.

=== Objectives ===
In '''CTR mode''', your task is to transit the aircraft across your airspace, always ensuring separation, and to hand each of them over to the most appropriate neighbouring centre North, South, East or West of your sector. You can specify local navpoints in the location settings so that the system includes them as turning points in the randomised aircraft routes.

In '''airport mode''', traffic is either inbound or outbound. Assuming APP, inbound aircraft must be sequenced and vectored into tower range for handover, unless you are in the TWR position as well. Each inbound aircraft either requests ILS or visual. Assuming TWR, you must clear them to land when appropriate, i.e. cleared for ILS approach or expected runway reported in sight. If landing cannot take place (too high, not cleared...), aircraft will go around. Controlling GND, you must move inbound traffic near their parking position once they have vacated the runway, and hand them over to the ramp. Outbound traffic must be brought to hold short of a runway threshold and report ready for departure with TWR. If you assume DEP, you must hand outbound aircraft over to the en-route centre (CTR) once they are high enough and close to their exit point if specified in their route. Entry and exit points are configurable in <code>CONFIG/nav/AD-entry-exit</code> (see <code>Notice</code> in the directory).

[[File:ATC-pie-screenshot-handoverPane-solo.png|thumbnail|Handover pane in an AD solo session, assuming all three available positions]]
{| class="wikitable" style="text-align:center"
|+ Handovers with virtual ATCs in airport mode
|-
| || colspan="2" | Departure strips || colspan="2" | Arrival strips
|-
! Assuming positions || Receive from || Hand over to || Receive from || Hand over to
|-
! GND only
| DEL || TWR || TWR || Ramp
|-
! TWR only
| GND || DEP || APP || GND
|-
! DEP only
| TWR || CTR || colspan="2" | N/A
|-
! APP only
| colspan="2" | N/A || CTR || TWR
|-
! TWR+GND
| DEL || DEP || APP || Ramp
|-
! TWR+DEP
| GND || CTR || APP || GND
|-
! TWR+APP
| GND || DEP || CTR || GND
|-
! APP+DEP
| TWR || CTR || CTR || TWR
|-
! TWR+GND+DEP
| DEL || CTR || APP || Ramp
|-
! TWR+GND+APP
| DEL || DEP || APP || Ramp
|-
! TWR+APP+DEP
| GND || CTR || CTR || GND
|-
! All 4
| DEL || CTR || CTR || Ramp
|}

=== Instructing aircraft ===
[[File:ATC-pie-screenshot-taxiInstructionTool.png|thumbnail|Click&drag taxi instruction tool at OMDB ground]]
Instructions are given through different means:
* provided the speech recognition modules are installed, you can turn on voice instructions from the solo simulation options dialog and instruct aircraft through your microphone, using the {{key press|Ctrl}} key as push-to-talk and standard phraseology (see the quick reference tab about it);
* if voice instructions are turned off:
** mouse vector assignments issue the corresponding instructions (see section on vectors above);
** handoffs are issued when dropping strips on an ATC receiver;
* instruct taxi routes by dragging out of radar contacts when they are considered on the ground (low enough or squawking GND);
* the dockable instruction panel works regardless of voice vs. mouse selection;
* alternatively, if the aircraft is connected to CPDLC, you can send instructions through the [[#CPDLC|data link]].

Instructions from the panel are always issued to the callsign entered in the top field, which should fill automatically on aircraft or strip selection when a callsign is known. Therefore, make sure you do not mess up your strip links or your instructions will realistically be acknowledged and followed by the wrong aircraft.

=== Need a scenario? ===
Things you can train for:
* towering a single runway with mixed traffic: select TWR position and an equal balance of departures and arrivals;
* optimising approach spacing in dense traffic: select APP position only, increase traffic density, turn on spacing hints and try to stabilise them all at "3:00" for example;
* change of runways (e.g. irl after wind direction change): start with APP+TWR and select a runway for arrivals at least, run the simulation for a while and change for opposite runway use;
* CTR mode with a low ceiling to increase the number of conflicts to resolve;
* etc.

== Teacher & student connections (ATC tutoring) ==

This session type is made to bring an ATC student and a teacher together for tutorial sessions. To '''set up a session''', the student must connect to the teacher, so make sure the teacher's session is running first. Only one student can connect to a teacher at a time. The teacher creates and manipulates traffic for the student to work with, controls the weather and decides on the ATC neighbours. The student can exchange strips and text messages with virtual ATCs (monitored/simulated by the teacher). The teacher can also snapshot traffic position situations to recall them later.

In '''teacher sessions''':
* The teaching console is enabled, which allows you to control the aircraft's XPDR status, send strips to the student, configure the weather environment, and more.
* You create new traffic holding {{key press|Shift}} down with a right click-and-drag on the radar specifying the position and face heading. A dialog pops up and allows you to choose a callsign (one is initially generated), altitude and other details. If near a ground route node, a parking position or runway, you can create it on the ground, ready to taxi or for departure (NB: parking overrides position/heading input).
* Traffic is initially created in an "unspawned" state (radar contact marked "+"), in other words visible to you but not to the student. This allows you to set its transponder or get it into a certain state before spawning it into the student's world.
* Controlling the traffic is done in the same way as in solo sessions without voice, i.e. using the click&drag vector and taxi tools and the instruction dock. The only difference is that you control the selected aircraft directly, regardless of your strip links and details. You therefore do not need a strip and a correctly filled callsign to instruct a pilot, though it is a good idea to have one if you want your vectors registered and drawn on the radar. The traffic creation dialog offers to create a linked strip with every new aircraft.
* You may pause the whole simulation, or freeze each aircraft individually.
* The ATC text messaging system allows to simulate ATC conversations with the student (select callsign to interact as), or interact with the student directly as the teacher.
* For your convenience in further control of the traffic, teacher strips do not disappear after you send them to the student (but the "+" indication on the strip disappears).
* When the teacher keys in PTT, a radio signal is detectable by the student coming from the teacher's selected aircraft.
* CPDLC is supported, the dialogue windows reflecting the change of perspective (ACFT instead of ATC). The {{key press|Alt}} key combinations generate requests rather than instructions.

[[Category:ATC-pie]]

ATC-pie installation guide

2026-03-16T00:16:22Z

Mickybadia: Version 1.10.0

{{forum|83|ATC-Pie support & development}}

{{about|installing and configuring ATC-pie|a manual on how to use it|ATC-pie user guide}}

== Installing ==

[[ATC-pie]] is free and open source, and programmed in Python for Qt5. It is therefore system-independant, but requires Python and its PyQt5 library to run. Otherwise, ATC-pie runs straight after download without any compiling (make, etc.) to do.

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.

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 Git '''repository''':
: <code>git clone git://git.code.sf.net/p/atc-pie/code ATC-pie</code>

I say again: the download/clone alone is not enough; both Python and PyQt5 must be installed too. The exact dependencies and required versions are listed in the <code>README</code> file packed in the download.

At this point you have a working program. But further software pieces can be installed to enable more of its features, as listed in the table below. Depending on your use of ATC-pie, they can be recommended for more realism but they are not required, and can be installed later. Also read the <code>README</code> file for extra notes on installation.

To enhance:
* all airport sessions with '''3D views''' (incl. tower view), ''[[FlightGear]]'' must be available with the sufficient ACFT and scenery data (it can run on a separate machine, as explained [[#Airport scene rendering|down this article]]);
* solo sessions with '''voice instruction recognition''' by the AI aircraft, install ''PyAudio'' and ''PocketSphinx'';
* solo sessions with '''speech synthesis''' of AI pilots' radio messages, install ''pyttsx'';
* FlightGear network sessions with '''full ATC coordination''' (incl. unlimited strip exchange, phone lines...) and '''[[CPDLC]]''', install the Python ''irc'' library;
* FlightGear and FSD sessions with realistic '''voice radio simulation''', set-up the ''[[FGCom-mumble]]'' plugin (requires a ''Mumble''>=1.4 client);
* all sessions (except solo and playback) with integrated '''ATC phone lines''', install ''PyAudio'' (FlightGear sessions also require ''irc'').

== Running ==

Depending on your system and preference, you might be double-clicking, typing stuff or pulling your hair out. In any case what you must do is run a Python interpreter on the <code>ATC-pie.py</code> file from the downloaded directory.

Tip for Windows users: create a shortcut whose "target" is <code>cmd /k Z:\path-to-pie\ATC-pie.py</code>, making sure "start in" is set to the same <code>Z:\path-to-pie</code> and that <code>.py</code> files are associated with Python.

=== Two program modes ===
[[File:ATC-pie-screenshot-launcherDialog.png|thumbnail|Initial graphical launcher, with AD vs. CTR mode choice]]
On program start, a welcome launcher window should open, from which you may start a session in either airport (AD) or centre (CTR) mode, i.e. respectively with or without a base airfield.

The '''airport mode''' is for ATC positions like approach or tower control, or any combination of those. In this mode, ATC-pie centres the radar at the chosen base airfield, depicts its tarmac and runways, and enables features like a tower view and active runway selection.

The '''centre mode''' is designed for en-route control centre simulation. It disables all airport-specific features, and allows to place the radar anywhere on Earth. When selecting this mode:
* The location code is a designator of your choice (excluding airport codes), under which to save your location-specific settings. A good idea is to use ICAO airspace designations, e.g. <code>SBBS</code> for the Brasilia FIR in central Brazil or <code>LFFF</code> for the Paris region in France.
* The radar position field specifies the point on which to centre the radar. For example, <code>LFPO>090,15</code> will centre the radar on a point 15 NM to the East of Orly airport. Click on the help button for a summary of valid point specification formats, or read the ''Point specification'' section in the quick reference for more detail.

=== Command line arguments ===
You may bypass the launcher and start directly at a given location with the following command, using an ICAO code for an airport or a previously defined CTR location code:
: <code>./ATC-pie.py location_code</code>

Besides, the following command line options are available:
{| class="wikitable"
! Option || Effect and argument specification || Default
|-
| --map-range=''range'' || Only valid with a location code argument. Defines the distance in NM from the radar centre up to which the map will be drawn and navpoints listed in the navigator (accepted values are 20..500). This does not affect radar range, which can still be greater or lower, and be changed within sessions.' || 100 in AD mode; 300 in CTR mode
|-
| --views-send-from=''port'' || Sets the local UDP port number to bind for sending FGMS packets to FlightGear viewers. This includes tower and additional viewers, but does not affect the FGMS connection port, chosen on session start. || 5009
|}

=== Starting sessions ===
All session types are started from the ''System'' menu.

Solo simulation:
* wind will be randomised at start, but will be forced to blow in a favourable direction if at least one active runway is selected before start;
* traffic is spawned with intentions according to the ''solo simulation options'' ({{key press|Shift|F11}}), so it is preferable to configure them before starting the session to avoid undesired traffic at start.

FlightGear network session:
* callsigns for ATCs in FlightGear are expected to start with the ICAO code of the controlled airport or sector, and end with a hint on the provided service (twr, gnd, ctr...), e.g. "KORDgnd" (note that FGMS restricts callsign length to 7 characters);
* before choosing your callsign, make sure it is not already in use;
* you can connect multiple ATC-pie instances from the same computer, but you must use a different local port for each one;
* the four "sub-systems" that can be activated support different features and differ in terms of interoperability with other clients, but all can be enabled together:
** '''native ATC-pie coordination''' enables full interaction with other ATC-pie clients (except phone lines), plus CPDLC with aircraft;
** '''FGCom-mumble''' is the recommended (realistic) FlightGear radio system—leave unticked if using an external software for radio;
** '''ATC phone lines''' enables direct voice communications (telephone calls) with other connected ATC-pie clients;
** '''OpenRadar handover compatibility''' implements [[OpenRadar]]'s protocol to enable coordination with its users ([[ATC-pie#OpenRadar|some limitations]] apply)—also works as a fallback between ATC-pie clients if native sub-system not available.

== Configuring ==

Here are things you will soon need or want to set up for a regular use of ATC-pie:
* set up a [[#Airport scene rendering|tower view]] to enable visual contact with your traffic in AD sessions;
* for a realistic radio experience in FlightGear and FSD sessions, set up FGCom-mumble.

If you intend to operate often at a given location, it is sensible to:
* if it is an airfield location, download the latest airport data file from the [https://gateway.x-plane.com/airports/page# X-plane gateway] and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> file there);
* review and fill the various fields in the location set-up dialog (runway capabilities deserve special focus for more realisitc aircraft intentions in AD solo sessions);
* configure the workspace racks, bays and radar screens to suit the environment and service provided (they will be saved for future runs at the same location);
* if using the radar, pin your preferred navpoints (they are restored on every run at the same location) and consider creating/importing background pictures to map terrain obstacles, procedure charts, etc. (see [[#Background images|section below]]);
* for solo and teacher sessions at airports especially, build an elevation map (see <code>CONFIG/elev/Notice</code>).

For more advanced editable options, read the <code>CONFIG/Notice</code> file.

=== Airport scene rendering ===
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
A '''tower view''' allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any (X-plane seems only to allow one, but feel free to declare more for ATC-pie), otherwise defaults to somewhere over the airport to allow towering everywhere. It is disabled in CTR mode.
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 to listen for traffic and accept telnet connections.

Running internally only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the viewer settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].

Connecting to an external viewer allows to run your own FlightGear instance separately, for example on a more powerful machine. If you want to do so, get a hint of the required positioning options you should start it with from the viewer settings dialog. Of course, scenery, models and liveries must also be available to the running process.

In either case, once activated from the ''System'' menu, the tower view '''control panel''' is enabled, from which you can turn to runway points, follow selected aircraft... Direct FlightGear input in the view window is also possible: right click and drag allows to look around, {{key press|x}} and {{key press|Shift|x}} change the zoom level, etc.

You can hook up '''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 the connections individually from the ''System'' menu. Additional viewers are registered by their host+port address.

Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
* ''HHH'' is the host on which ATC-pie is running;
* ''PPP'' is the default 5009, or the chosen port number if ATC-pie was started with <code>--views-send-from</code>;
* ''TTT'' is the network polling frequency (100 is common practice; change as desired if you know what you are doing).

=== Background images ===
[[File:ATC-pie-screenshot-backgroundPixmapDrawing.png|thumbnail|Pixmap image example with a terrain map around LIMW (Aosta, Italy)]]
[[File:ATC-pie-screenshot-backgroundHandDrawing.png|thumbnail|Text-specified drawing example with procedures for LSGG (Geneva, Switzerland)]]
Background images allow to decorate:
* radar scopes, e.g. to display procedure routes or airspace boundaries;
* loose strip bays, to work the strips over custom backgrounds, e.g. an airport ground chart.

There are two ways to create a background. One is to '''import a picture''' (pixmap file like JPEG or PNG, including transparency); the other consists in writing a '''drawing specification''' file to paint coloured lines, points and text labels (for radar backgrounds only). See <code>CONFIG/bg/Notice</code> to learn how to import and draw background images.

For example, you can map out procedures (SID, STAR, IAD...), grouping them by associated runways so they toggle together on the radar. Drawings are generally appropriate for that because they avoid manual positioning by directly referring to the points named in the published procedures. But if you want more than schematic line plots and text labels, you should create the picture yourself, for example using an image processing tool like ''GIMP'' and a transparent layer over a real map canvas or a screenshot of your ATC-pie radar with pinned navaids as landmarks.

'''If you have a sector file''' of the format used in VATSIM/IVAO (.sct) for your area, you should try to import it with the provided extraction tool. It will retrieve most of the contents around the open location up to the current map range, and translate it to ATC-pie's native drawing format, although the generated files always require some filtering and post-editing. If you know they are included, it is generally the best option for things like SID/STAR procedures. The way to proceed is as follows:
# Run the "extract drawings from sector file" option (''System'' menu) and select the file to extract from. This generates the following files in the <code>OUTPUT</code> directory:
#* <code>ICAO.lst.extract</code>, a menu file for the generated drawings;
#* <code>bg-ICAO-*</code>, the extracted drawings in the ATC-pie format;
#* <code>bg-extract.err</code>, a log of the errors detected in your sector file (do not be alarmed as they often contain many).
# Import the results:
#* move or copy-paste lines from <code>ICAO.lst.extract</code> to <code>CONFIG/bg/ICAO.lst</code>;
#* move the desired drawing files under <code>CONFIG/bg</code>, adjusting the paths in the <code>.lst</code> menu as you organise subdirectories.
# Post-editing (cleaning)
#: ATC-pie does its best to understand the objects in the sector file and to group things together depending on their type. But not everything can be guessed automatically. This last step is where you filter, merge and split objects, rename points, change colours, etc. to your liking.
#: Each generated drawing section (point list under a colour) is automatically labelled with the line number where it was sourced from in the sector file so you can easily trace it (<code>@nnn</code>). A tool like ''sed'' will help you get rid of all these unwanted suffixes once you have sorted and renamed your objects:
#:: <code>sed -ri 's/ +@[0-9]+$//' file_to_clean</code>

NB: ATC-pie does not package or source from sector files directly because their data is not free. Besides, a lot of it is usually redundant with the airport sources.

Tips:
* You can check your image configuration without restarting the program, by reloading the files in their current state from the ''System'' menu ({{key press|Alt|F12}}).
* The "image positioning helper" allows to move and resize imported pictures, adjusting the corners visually rather than programmatically if you have no specification for them. All visible pixmap images will be moved simultaneously, so you can work with several at a time if you want to. On dialog box close, a file is generated in the <code>OUTPUT</code> directory for you to copy from.
* An [[OpenStreetMap]] option will take you to the free online map server, centred on your radar centre position. For a quick and dirty start (e.g. for access to coastlines, borders and rivers) you can screenshot the map and use it as a background.

[[Category:ATC-pie]]

ATC-pie

2026-03-16T00:15:20Z

Mickybadia: Version 1.10.0

{{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
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.10.0 (March 15, 2026)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''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);
* "multi-player" network sessions (FlightGear and FSD protocols supported);
* tutorial sessions for teacher supervision of an ATC student.

It is designed to support a maximum range of ATC situations, and will allow any world location for every session type. All control positions are possible, whether airport-based (TWR, APP, GND...) or en-route (CTR). Equipment can be set up to include radar screens, data link, etc. or be limited to binoculars and a view of the airfield.

Its essential goal is realism. It simulates many tasks of real-life ATC such as:
* strip racks and sequence management;
* coordination with neighbouring controllers (phone calls, handovers...);
* radar monitoring for traffic identification and sequencing;
* vectoring and course/level conflict anticipation;
* flight plan operations;
* CPDLC...

== Screenshots ==

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Solo session with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

== Sessions and environments ==

ATC-pie features six session/connection types:
* solo simulation (AI traffic);
* FlightGear network connection ([[FGMS]] protocol);
* 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 a teacher);
* playback of recorded sessions (manual timeline control).

Every session is open at a chosen location, in either mode below:
* airport (AD): positions such as TWR, GND, APP, DEP at a selected airfield;
* en-route centre (CTR): free positioning of radar, no base airport or TKOF/LDG-related options.

{| class="wikitable" style="text-align:center"
|+ Feature support by session type
! || Solo || FlightGear || FSD || Tutoring (teacher/student) || Playback
|-
! ACFT traffic
| AI aircraft generated according to RWY capacities, ACFT equipment, intentions...
| colspan="2" | connected flight sim pilots
| created and simulated by teacher
| interpolated from recorded radar blips
|-
! ATCs
| 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
| recorded interactions
|-
! Voice radio
| voice recognition for instructions (mouse-only also available) and synthesis for pilot read-back
| colspan="2" | integrated [[FGCom-mumble]]
| teacher simulates pilots
| N/A
|-
! ATC phone lines
| N/A
| colspan="2" | integrated VoIP support
| teacher simulates ATCs
| recorded line status changes
|-
! 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
| N/A 
|-
! CPDLC
| interpreted subset of instruction messages
| integrated (supported by MP IRC)
| integrated interface with [https://www.hoppie.nl/acars/ Hoppie's ACARS network]
| full simulation by teacher (with WILCO assistance to execute instructions)
| recorded connections, messages, transfers...
|-
! Weather
| randomised and evolving
| real world METAR retrieval
| fetch from server or retrieve real world METAR
| controlled by teacher
| display of recorded information
|-
! Other specific features
| style="text-align:left" |
* 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.)
* RDF supported even without FGCom enabled
| style="text-align:left" |
* frequency tuning system for text radio
* text ATIS repeatedly sent through text radio on recorded frequency
| style="text-align:left" |
* traffic snapshots and recall to repeat situations with the student
* individual aircraft freeze
| style="text-align:left" |
* manual time control or continuous playback with controlable speed
* more recorded events reported using text message history as timeline
|}

== Detailed feature list ==

=== ATC surveillance ===
Radars and tracking:
* SSR mode capability selection (none/A/C/S)
* primary radar toggle
* 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
* 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)

Other:
* radio direction finding (RDF) and integration to radar
* multiple weather (METAR) station monitor
* [[ATIS]] recording and reminder alarm (see [[:File:ATC-pie-screenshot-ATISdialog.png|dialog]] with pre-filled notepad)

=== 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
* departure clearance assistant
* automatic strip printing for expected departures or arrivals (from FPLs)

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

=== Communications ===
With aircraft:
* voice radio with 8.33 kHz frequency spacing, multiple radio transmissions and monitoring
* [[controller-pilot data link communication]] (CPDLC), incl. DEP clearance delivery, multi-element messages...
* text radio with preset messages, auto-completion, predefined and custom aliases (context-sensitive replacements), sender blacklist

ATC coordination:
* strip exchange (handovers)
* CPDLC authority transfers
* telephone lines and switchboard (direct voice communication)
* text messaging (private channels and public ATC chat room, with alias substitution)
* "who has?" requests

=== Other ===
Misc. tools:
* world airport, map navpoint and AD parking position browsing/indicating
* aeronautical unit conversion calculator
* custom timers with quick keyboard start
* general and location-specific notepads restored between sessions
* list of known ACFT types by callsign
* session recording for later playback (incl. traffic, communications, weather)

GUI:
* multiple window workspace (radar screens, strip racks and bays) saved by location
* 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

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

== Interoperability with other software ==

=== OpenRadar ===
[[OpenRadar]] is another stand-alone program for 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:
* OpenRadar to ATC-pie: FGMS callsign will appear on the strip, as if the sender had filled the detail herself;
* 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 through OpenRadar's service: strip detail preserved, whether present or absent.

Features not supported by OpenRadar:
* ATC phone lines;
* ATC text messaging;
* CPDLC transfers;
* wake turbulance category and departure clearances on strips (but details preserved for ATC-pie clients later receiving the strip).

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. 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:Air Traffic Control]]

ATC-pie

2025-11-29T15:34:34Z

Mickybadia: Version 1.9.2

{{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
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.9.2 (Nov. 29, 2025)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''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);
* "multi-player" network sessions (FlightGear and FSD protocols supported);
* tutorial sessions for teacher supervision of an ATC student.

It is designed to support a maximum range of ATC situations, and will allow any world location for every session type above. All control positions are possible, whether airport-based (TWR, APP, GND...) or en-route (CTR). Equipment can be set up to include radar screens, data link, etc. or be limited to binoculars and a view of the airfield.

Its essential goal is realism. It simulates many tasks of real-life ATC such as:
* strip racks and sequence management;
* coordination with neighbouring controllers (phone calls, handovers...);
* radar monitoring for traffic identification and sequencing;
* vectoring and course/level conflict anticipation;
* flight plan operations;
* CPDLC...

== Screenshots ==

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Solo session with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

== Sessions and environments ==

ATC-pie features five session/connection types, all of which support both ''airport'' and ''centre'' location modes.

Session types:
* solo simulation (AI traffic)
* FlightGear network connection ([[FGMS]] protocol)
* 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 a teacher)

Location modes:
* airport (AD): positions such as TWR, GND, APP, DEP at a selected airfield
* en-route centre (CTR): free positioning of radar, no base airport or TKOF/LDG-related options

{| class="wikitable" style="text-align:center"
|+ Feature support by session type
! || Solo || FlightGear || FSD || Tutoring (teacher/student)
|-
! ACFT traffic
| AI aircraft generated according to RWY capacities, ACFT equipment, intentions...
| colspan="2" | connected flight sim pilots
| created and simulated by teacher
|-
! 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
|-
! Voice radio
| voice recognition for instructions (mouse-only also available) and synthesis for pilot read-back
| colspan="2" | integrated [[FGCom-mumble]]
| teacher simulates pilots
|-
! ATC phone lines
| N/A
| colspan="2" | integrated VoIP support
| teacher simulates ATCs
|-
! 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
|-
! CPDLC
| interpreted subset of instruction messages
| integrated (supported by MP IRC)
| integrated interface with [https://www.hoppie.nl/acars/ Hoppie's ACARS network]
| full simulation by teacher (with WILCO assistance to execute instructions)
|-
! Weather
| randomised and evolving
| real world METAR retrieval
| fetch from server or retrieve real world METAR
| controlled by teacher
|-
! Other specific features
| style="text-align:left" |
* 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.)
* RDF supported even without FGCom enabled
| style="text-align:left" |
* frequency tuning system for text radio
* text ATIS repeatedly sent through text radio on recorded frequency
| style="text-align:left" |
* traffic snapshots and recall to repeat situations with the student
* individual aircraft freeze
|}

== Detailed feature list ==

=== ATC surveillance ===
Radars and tracking:
* SSR mode capability selection (none/A/C/S)
* primary radar toggle
* 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
* 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)

Other:
* radio direction finding (RDF) and integration to radar
* multiple weather (METAR) station monitor
* [[ATIS]] recording and reminder alarm (see [[:File:ATC-pie-screenshot-ATISdialog.png|dialog]] with pre-filled notepad)

=== 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
* departure clearance assistant
* automatic strip printing for expected departures or arrivals (from FPLs)

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

=== Communications ===
With aircraft:
* voice radio with 8.33 kHz frequency spacing, multiple radio transmissions and monitoring
* [[controller-pilot data link communication]] (CPDLC), incl. DEP clearance delivery, multi-element messages...
* text radio with preset messages, auto-completion, predefined and custom aliases (context-sensitive replacements), sender blacklist

ATC coordination:
* strip exchange (handovers)
* CPDLC authority transfers
* telephone lines and switchboard (direct voice communication)
* text messaging (private channels and public ATC chat room, with alias substitution)
* "who has?" requests

=== 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
* list of known ACFT types by callsign

GUI:
* multiple window workspace (radar screens, strip racks and bays) saved by location
* 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

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

== Interoperability with other software ==

=== OpenRadar ===
[[OpenRadar]] is another stand-alone program for 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:
* OpenRadar to ATC-pie: FGMS callsign will appear on the strip, as if the sender had filled the detail herself;
* 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 through OpenRadar's service: strip detail preserved, whether present or absent.

Features not supported by OpenRadar:
* ATC phone lines;
* ATC text messaging;
* CPDLC transfers;
* wake turbulance category and departure clearances on strips (but details preserved for ATC-pie clients later receiving the strip).

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. 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:Air Traffic Control]]

ATC-pie installation guide

2025-11-29T15:34:30Z

Mickybadia: Version 1.9.2

{{forum|83|ATC-Pie support & development}}

{{about|installing and configuring ATC-pie|a manual on how to use it|ATC-pie user guide}}

== Installing ==

[[ATC-pie]] is free and open source, and programmed in Python for Qt5. It is therefore system-independant, but requires Python and its PyQt5 library to run. Otherwise, ATC-pie runs straight after download without any compiling (make, etc.) to do.

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.

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 Git '''repository''':
: <code>git clone git://git.code.sf.net/p/atc-pie/code ATC-pie</code>

I say again: the download/clone alone is not enough; both Python and PyQt5 must be installed too. The exact dependencies and required versions are listed in the <code>README</code> file packed in the download.

At this point you have a working program. But further software pieces can be installed to enable more of its features, as listed in the table below. Depending on your use of ATC-pie, they can be recommended for more realism but they are not required, and can be installed later. Also read the <code>README</code> file for extra notes on installation.

To enhance:
* all airport sessions with '''3D views''' (incl. tower view), ''[[FlightGear]]'' must be available with the sufficient ACFT and scenery data (it can run on a separate machine, as explained [[#Airport scene rendering|down this article]]);
* solo sessions with '''voice instruction recognition''' by the AI aircraft, install ''PyAudio'' and ''PocketSphinx'';
* solo sessions with '''speech synthesis''' of AI pilots' radio messages, install ''pyttsx'';
* FlightGear network sessions with '''full ATC coordination''' (incl. unlimited strip exchange, phone lines...) and '''[[CPDLC]]''', install the Python ''irc'' library;
* FlightGear and FSD sessions with realistic '''voice radio simulation''', set-up the ''[[FGCom-mumble]]'' plugin (requires a ''Mumble''>=1.4 client);
* all sessions (except solo) with integrated '''ATC phone lines''', install ''PyAudio'' (FlightGear sessions also require ''irc'').

== Running ==

Depending on your system and preference, you might be double-clicking, typing stuff or pulling your hair out. In any case what you must do is run a Python interpreter on the <code>ATC-pie.py</code> file from the downloaded directory.

Tip for Windows users: create a shortcut whose "target" is <code>cmd /k Z:\path-to-pie\ATC-pie.py</code>, making sure "start in" is set to the same <code>Z:\path-to-pie</code> and that <code>.py</code> files are associated with Python.

=== Two program modes ===
[[File:ATC-pie-screenshot-launcherDialog.png|thumbnail|Initial graphical launcher, with AD vs. CTR mode choice]]
On program start, a welcome launcher window should open, from which you may start a session in either airport (AD) or centre (CTR) mode, i.e. respectively with or without a base airfield.

The '''airport mode''' is for ATC positions like approach or tower control, or any combination of those. In this mode, ATC-pie centres the radar at the chosen base airfield, depicts its tarmac and runways, and enables features like a tower view and active runway selection.

The '''centre mode''' is designed for en-route control centre simulation. It disables all airport-specific features, and allows to place the radar anywhere on Earth. When selecting this mode:
* The location code is a designator of your choice (excluding airport codes), under which to save your location-specific settings. A good idea is to use ICAO airspace designations, e.g. <code>SBBS</code> for the Brasilia FIR in central Brazil or <code>LFFF</code> for the Paris region in France.
* The radar position field specifies the point on which to centre the radar. For example, <code>LFPO>090,15</code> will centre the radar on a point 15 NM to the East of Orly airport. Click on the help button for a summary of valid point specification formats, or read the ''Point specification'' section in the quick reference for more detail.

=== Command line arguments ===
You may bypass the launcher and start directly at a given location with the following command, using an ICAO code for an airport or a previously defined CTR location code:
: <code>./ATC-pie.py location_code</code>

Besides, the following command line options are available:
{| class="wikitable"
! Option || Effect and argument specification || Default
|-
| --map-range=''range'' || Only valid with a location code argument. Defines the distance in NM from the radar centre up to which the map will be drawn and navpoints listed in the navigator (accepted values are 20..500). This does not affect radar range, which can still be greater or lower, and be changed within sessions.' || 100 in AD mode; 300 in CTR mode
|-
| --views-send-from=''port'' || Sets the local UDP port number to bind for sending FGMS packets to FlightGear viewers. This includes tower and additional viewers, but does not affect the FGMS connection port, chosen on session start. || 5009
|}

=== Starting sessions ===
All session types are started from the ''System'' menu.

Solo simulation:
* wind will be randomised at start, but will be forced to blow in a favourable direction if at least one active runway is selected before start;
* traffic is spawned with intentions according to the ''solo simulation options'' ({{key press|Shift|F11}}), so it is preferable to configure them before starting the session to avoid undesired traffic at start.

FlightGear network session:
* callsigns for ATCs in FlightGear are expected to start with the ICAO code of the controlled airport or sector, and end with a hint on the provided service (twr, gnd, ctr...), e.g. "KORDgnd" (note that FGMS restricts callsign length to 7 characters);
* before choosing your callsign, make sure it is not already in use;
* you can connect multiple ATC-pie instances from the same computer, but you must use a different local port for each one;
* the four "sub-systems" that can be activated support different features and differ in terms of interoperability with other clients, but all can be enabled together:
** '''native ATC-pie coordination''' enables full interaction with other ATC-pie clients (except phone lines), plus CPDLC with aircraft;
** '''FGCom-mumble''' is the recommended (realistic) FlightGear radio system—leave unticked if using an external software for radio;
** '''ATC phone lines''' enables direct voice communications (telephone calls) with other connected ATC-pie clients;
** '''OpenRadar handover compatibility''' implements [[OpenRadar]]'s protocol to enable coordination with its users ([[ATC-pie#OpenRadar|some limitations]] apply)—also works as a fallback between ATC-pie clients if native sub-system not available.

== Configuring ==

Here are things you will soon need or want to set up for a regular use of ATC-pie:
* set up a [[#Airport scene rendering|tower view]] to enable visual contact with your traffic in AD sessions;
* for a realistic radio experience in FlightGear and FSD sessions, set up FGCom-mumble.

If you intend to operate often at a given location, it is sensible to:
* if it is an airfield location, download the latest airport data file from the [https://gateway.x-plane.com/airports/page# X-plane gateway] and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> file there);
* review and fill the various fields in the location set-up dialog (runway capabilities deserve special focus for more realisitc aircraft intentions in AD solo sessions);
* configure the workspace racks, bays and radar screens to suit the environment and service provided (they will be saved for future runs at the same location);
* if using the radar, pin your preferred navpoints (they are restored on every run at the same location) and consider creating/importing background pictures to map terrain obstacles, procedure charts, etc. (see [[#Background images|section below]]);
* for solo and teacher sessions at airports especially, build an elevation map (see <code>CONFIG/elev/Notice</code>).

For more advanced editable options, read the <code>CONFIG/Notice</code> file.

=== Airport scene rendering ===
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
A '''tower view''' allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any (X-plane seems only to allow one, but feel free to declare more for ATC-pie), otherwise defaults to somewhere over the airport to allow towering everywhere. It is disabled in CTR mode.
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 to listen for traffic and accept telnet connections.

Running internally only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the viewer settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].

Connecting to an external viewer allows to run your own FlightGear instance separately, for example on a more powerful machine. If you want to do so, get a hint of the required positioning options you should start it with from the viewer settings dialog. Of course, scenery, models and liveries must also be available to the running process.

In either case, once activated from the ''System'' menu, the tower view '''control pane''' is enabled, from which you can turn to runway points, follow selected aircraft... Direct FlightGear input in the view window is also possible: right click and drag allows to look around, {{key press|x}} and {{key press|Shift|x}} change the zoom level, etc.

You can hook up '''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 the connections individually from the ''System'' menu. Additional viewers are registered by their host+port address, from the same dialog.

Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
* ''HHH'' is the host on which ATC-pie is running;
* ''PPP'' is the default 5009, or the chosen port number if ATC-pie was started with <code>--views-send-from</code>;
* ''TTT'' is the network polling frequency (100 is common practice; change as desired if you know what you are doing).

=== Background images ===
[[File:ATC-pie-screenshot-backgroundPixmapDrawing.png|thumbnail|Pixmap image example with a terrain map around LIMW (Aosta, Italy)]]
[[File:ATC-pie-screenshot-backgroundHandDrawing.png|thumbnail|Text-specified drawing example with procedures for LSGG (Geneva, Switzerland)]]
Background images allow to decorate:
* radar scopes, e.g. to display procedure routes or airspace boundaries;
* loose strip bays, to work the strips over custom backgrounds, e.g. an airport ground chart.

There are two ways to create a background. One is to '''import a picture''' (pixmap file like JPEG or PNG, including transparency); the other consists in writing a '''drawing specification''' file to paint coloured lines, points and text labels (for radar backgrounds only). See <code>CONFIG/bg/Notice</code> to learn how to import and draw background images.

For example, you can map out procedures (SID, STAR, IAD...), grouping them by associated runways so they toggle together on the radar. Drawings are generally appropriate for that because they avoid manual positioning by directly referring to the points named in the published procedures. But if you want more than schematic line plots and text labels, you should create the picture yourself, for example using an image processing tool like ''GIMP'' and a transparent layer over a real map canvas or a screenshot of your ATC-pie radar with pinned navaids as landmarks.

'''If you have a sector file''' of the format used in VATSIM/IVAO (.sct) for your area, you should try to import it with the provided extraction tool. It will retrieve most of the contents around the open location up to the current map range, and translate it to ATC-pie's native drawing format, although the generated files always require some filtering and post-editing. If you know they are included, it is generally the best option for things like SID/STAR procedures. The way to proceed is as follows:
# Run the "extract drawings from sector file" option (''System'' menu) and select the file to extract from. This generates the following files in the <code>OUTPUT</code> directory:
#* <code>ICAO.lst.extract</code>, a menu file for the generated drawings;
#* <code>bg-ICAO-*</code>, the extracted drawings in the native ATC-pie format;
#* <code>bg-extract.err</code>, a log of the errors detected in your sector file (do not be alarmed as they often contain many).
# Import the results:
#* move or copy-paste lines from <code>ICAO.lst.extract</code> to <code>CONFIG/bg/ICAO.lst</code>;
#* move the desired drawing files under <code>CONFIG/bg</code>, adjusting the paths in the <code>.lst</code> menu as you organise subdirectories.
# Post-editing (cleaning)
#: ATC-pie does its best to understand the objects in the sector file and to group things together depending on their type. But not everything can be guessed automatically. This last step is where you filter, merge and split objects, rename points, change colours, etc. to your liking.
#: Each generated drawing section (point list under a colour) is automatically labelled with the line number where it was sourced from in the sector file so you can easily trace it (<code>@nnn</code>). A tool like ''sed'' will help you get rid of all these unwanted suffixes once you have sorted and renamed your objects:
#:: <code>sed -ri 's/ +@[0-9]+$//' file_to_clean</code>

NB: ATC-pie does not package or source from sector files directly because their data is not free. Besides, a lot of it is usually redundant with the airport sources.

Tips:
* You can check your image configuration without restarting the program, by reloading the files in their current state from the ''System'' menu ({{key press|Alt|F12}}).
* The "image positioning helper" allows to move and resize imported pictures, adjusting the corners visually rather than programmatically if you have no specification for them. All visible pixmap images will be moved simultaneously, so you can work with several at a time if you want to. On dialog box close, a file is generated in the <code>OUTPUT</code> directory for you to copy from.
* An [[OpenStreetMap]] option will take you to the free online map server, centred on your radar centre position. For a quick and dirty start (e.g. for access to coastlines, borders and rivers) you can screenshot the map and use it as a background.

[[Category:ATC-pie]]

ATC-pie user guide

2025-11-29T15:34:27Z

Mickybadia: Version 1.9.2

{{forum|83|ATC-Pie support & development}}

This article is a guide to the air traffic control simulation program [[ATC-pie]], describing some of its major features. A more exhaustive list can be found in the main article. For download and installation help, refer to the [[ATC-pie installation guide]]. For support and troubleshooting, the [[ATC-pie FAQ]] might get you an answer first. Otherwise kindly ask on the dedicated FlightGear sub-forum so that the discussion is public.

Other ways to learn the program:
* watch the online [https://www.youtube.com/playlist?list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb video tutorial];
* read the in-app ''Quick reference'' available from the ''Help'' menu (summary of mouse/keyboard gestures, display conventions...);
* connect to a skilled teacher as a student (personal training);
* [[#Solo_sessions|train solo]]!

== Flight strips ==

Whether electronic (dematerialised) or on paper, printed automatically or filled by hand, the '''flight progress strip''' is the essential piece of air and ground traffic control. Every aircraft in contact is represented by a unique strip on the ATC workbench, and every strip represents a unique contact, present or expected. This ensures that no aircraft is ever forgotten about. Strip positioning and updating then enable to monitor the aircraft's status, sequence number, position, intentions, etc.

=== Strip details and linking ===
[[File:ATC-pie-screenshot-stripDetailSheet.png|thumbnail|The ATC-pie strip detail sheet]]
A click on the "new strip" tool bar button (shortcut {{key press|F2}}) or double-click on an empty strip rack or bay space will open a dialog to fill flight details on a fresh blank strip, e.g. callsign, type of aircraft, destination, etc. Double-clicking on an existing strip allows to edit the filled details.

If providing radar service, strips should be '''linked''' to identified contacts to inform the radar display with the filled details, e.g. assigned altitude, and enable joint selection. To link a strip to a radar contact, select one and middle-click on the other. Conflicts between strip details and the values squawked by the linked transponder will mark the strip with a "!!XPDR" warning.

A strip can also be linked to a filed flight plan (FPL). This will make radar and strip display fall back on filed information for missing details. The strip does not warn of mismatching information between the two because it is normal for the strip information to be updated as the flight progresses.

All together, a selection can therefore involve up to three linked elements: strip, radar contact, flight plan. From the strip menu at the bottom of any strip panel, you can pull details from linked elements (copy them to the selected strip), or push strip details to their linked flight plan if necessary. If you use linking carefully, auto-fill options are available from the general settings, to fill blank strip details with newly-linked information. Unlinking is possible with {{key press|Shift}}+middle-click.

For fast and efficient service, every initial contact by a pilot should basically make you hit {{key press|F2}} and type the spoken callsign. You should then soon figure out if:
* you already have a strip for that contact: a "!!dup" warning appears next to the input field;
* a flight plan is filed whose details can be linked immediately: a list of candidate FPL matches is displayed in the bottom row, which you can select from to link on dialog save;
* a flight plan must be filed, e.g. IFR departure not filed by lazy pilot: save the dialog and use the {{key press|Shift+F3}} shortcut to create a new FPL linked to the selected strip.

=== Strip placeholders ===
ATC-pie provides with three types of placeholders for flight strips: ''racks'', ''loose strip bays'' and ''runway boxes''. According to your ATC position and local facilities, you should choose and arrange your placeholders for optimal control. Strips can then be moved between them using mouse drag and drop.

[[File:ATC-pie-screenshot-stripRacks.png|thumbnail|Strip rack panel]]
A '''strip rack''' is the preferred way of keeping track of a sequence, e.g. a departure queue at a runway threshold. Rack panels can be created from the main window workspace, popped out as separate windows, and a persistent one can be found among the available docks. You can create as many racks as you wish in every panel. Double click on a rack's name to rename it or edit its properties. Use mouse drag to move strips up and down a rack sequence.

A '''loose strip bay''' allows free-hand positioning of strips in its reserved space. Such bays are useful for unsequenced traffic, or to map out relative positions when controlling without a radar. You may also import background images, e.g. a ground chart to keep visual track of taxiing aircraft and vehicles. See <code>CONFIG/bg/Notice</code> to learn how.

[[File:ATC-pie-screenshot-runwayReserved.png|thumbnail|Reserved runway marked in yellow]]
A '''runway box''' is a placeholder for a single strip, named after a physical runway and denoting a clearence to use it (enter, cross, land...). Runway boxes are contained in their own dock, with one made visible for each runway marked as in use in either direction. Thorough use of runway boxes will help you avoid bad mistakes like clear an aircraft to land over lined up traffic. When freed, runway boxes start and display a timer together with the wake turbulance category of the last contained strip to help with TKOF/LDG separation. What is more, if you use radar, a filled runway box marks the runway as ''reserved'' on the scope.

Besides, there are two other places a strip can be dropped on, usually when releasing a contact:
* an ATC callsign in the ATC panel to initiate a handover (or CPDLC transfer/instruction if {{key press|Alt}} is pressed);
* a '''strip shelf''' (flat button at the bottom of strip panels), which clears the strip from your workbench and stores it as shelved.

== Vectors, routes and separation ==

ATC-pie can register and analyse issued vectors and routes to:
* inform strip and radar display;
* help monitor traffic, checking tracked positions against route/vector assignments;
* help manage traffic, anticipating route and FL conflicts between controlled aircraft.

=== Vectors ===
[[File:ATC-pie-screenshot-courseAndAssignmentsGraphics.png|thumbnail|Course/vector drawing for linked radar contact]]
Registering vectors on strips enhances the drawing of linked radar contacts, enables easy monitoring of tracks and detection of aircraft flying off course. To register vectors automatically when a radar contact is linked to a strip, use the following mouse gestures:
* click and drag out of a radar contact to issue a heading vector;
* holding {{key press|Shift}}, click and drag vertically for altitude/FL vectors;
* holding {{key press|Shift}}, click and drag horizontally for speed instructions;
* holding {{key press|Shift}}, double-click on the radar target to clear registered vecors from the linked strip.

See [https://www.youtube.com/watch?v=BvA3MRlGJjU video 5] of the tutorial for more on vectoring, and check the quick reference ''display conventions'' to interpret the lines and colours of the course and vector graphics around radar contacts.

NB: In network sessions, an appropriate text radio instruction is suggested for every mouse vectoring action. This allows you to send it easily to pilots whose communications are limited to text.

=== Routes ===
[[File:ATC-pie-screenshot-routeDetailsView.png|thumbnail|Route details dialog with world path drawn, available when both end airfields are recognised]]
A route is analysed for every strip with recognised departure and destination airports (entry fields both turned green), as follows:
* route tokens are whitespace-separated;
* each recognised navpoint token (radio navigation beacon, 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);
* if ambiguous (navpoint names are not all unique around the world), a waypoint is the nearest homonym to the point beginning the leg;
* other tokens are kept as route leg specifications to the following waypoint, e.g. airways between fixes.

[[File:ATC-pie-screenshot-routeDrawing.png|thumbnail|Assigned routes are drawn as dashed lines on the radar scope when linked to contacts]]
Routes on flight plans and strips are viewable in a route dialog, showing geodesic paths, headings and leg distances on a world map. When a specified route is linked to a radar contact, ATC-pie works out its current leg based on distance to destination, and:
* details of the current leg are displayed in the selection info pane, and the route viewing button enabled;
* the strip shows only the remainder of the route for this contact;
* the route to go is drawn as a dashed line on the radar (unless aircraft is inbound and near enough);
* the radar tag 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.

NB: If DEP and ARR airports are not both recognised, radar tags show the strip destination detail if it is filled, possibly with a heading if it is recognised.

See tutorial [https://www.youtube.com/watch?v=LfdukpBc90w video 7] for a demonstration of routes.

=== Conflicts and anticipation ===
[[File:ATC-pie-screenshot-routeConflictDetection.png|thumbnail|Route conflict depiction]]
ATC-pie 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 aircraft with a linked strip and an assigned route or heading. 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. When the projections of two aircraft intersect, a conflict is anticipated if the respective intervals between the current and assigned altitudes overlap. When an aircraft's altitude is unknown, the assigned altitude will be assumed. If an altitude assignment is missing, a ''possible'' conflict is reported.

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 || Thick bright red intersecting circles || Separation loss between aircraft
|-
| Path conflict || Red circles and paths || Anticipated paths and altitudes are intersecting
|-
| Possible path conflict || Yellow circles and paths || Paths intersecting but some altitudes unknown
|}

== Communications with aircraft ==

=== Voice radio ===
In solo sessions, radio interaction is simulated through speech recognition of instructions and read-back synthesis. Use the {{key press|Ctrl}} key to PTT.

In FlightGear and FSD network sessions, multiple radios can be opened and tuned in simultaneously. You can transmit on either one by holding down the PTT button of the chosen radio, or on a selected set (''Kbd PTT'' boxes ticked) using the {{key press|Ctrl}} key. This lets you PTT on multiple frequencies at once (merged frequencies), for example to service GND+TWR frequencies in view of splitting them seemlessly again later. To monitor frequencies without attending them, a trick is to set their volume to "soft" to tell them apart.

Note: Except for solo sessions, you may always use a separate voice communication program for radio. In this case, try making the same {{key press|Ctrl}} key the PTT to preserve other features such as RDF for receiving stations, or the ''PTT turns off notification sounds'' option recommended if not wearing a headset.

=== CPDLC ===
When [[CPDLC]] is serviced (location setting), aircraft can establish a data link from their cockpit for a direct text communication channel supplementing the radio frequency. You can monitor connections from the CPDLC dock and open a window for each active or terminated connection in the CPDLC history. Combining the {{key press|Alt}} key with a double-click on a strip or radar contact opens the current or latest dialogue for the selected callsign.

Each active CPDLC dialogue window allows to manually compose formatted or free text message elements. But the most frequent and convenient way of creating message elements is to combine the {{key press|Alt}} key with (also see ''Mouse gestures'' in the quick reference):
* a click-and-drag vectoring gesture to send a heading, altitude/FL or speed instruction (see [[#Vectors|section on vectors]]);
* a strip drop on an ATC to initiate a CPDLC authority transfer or to send the aircraft a "contact" instruction;
* an instruction panel "OK" button click to send the corresponding formatted instruction if applicable.

Created message elements are appended to the message buffer in the connection dialogue window until you send the message manually. The other party must then acknowledge it before it times out.

=== Text radio ===
Although voice communications should be encouraged for realism whenever possible, ATC-pie has a powerful text messaging system for keyboard interaction with pilots in network sessions. In FlightGear sessions, all messages from within at least 100 NM and up to the radar range are displayed. In FSD sessions, whose protocol simulates text frequencies, ATC-pie tunes the text radio to the "publicised frequency" in the radio panel.

'''Text aliases''' are dollar-prefixed words that ATC-pie can replace with context-dependant values when sent. For example, <code>$metar</code> expands to the current primary station weather, which allows to send formatted messages like "Current weather is $metar" instead of copy-pasting a weather look-up for every such message. There is a list of predefined aliases, whose replacements depend on the environment, local configuration or current selection. All other aliases are expected to find their replacement in one of the following sources, checked in order (see ''Text aliases'' tab in quick reference for more information):
* general notepad (editable in any session, regardless of location);
* location notepad (saved for this airport or centre);
* strip comments (value applies to single aircraft contact).

Moreover, ATC-pie strips everything up to the first '''pipe character''' (<code>|</code>) in the message if any, before it is processed and sent. You may test this by sending "stripped part|sent part" and observe that only the "sent part" makes it to the message contents. You can therefore make your life easier with piped shortcuts in your preset message list. They will pop up like any other message in the filtered menu as you type. For example, the following preset message enables something like a dot-command for sending a bearing to your base airport in a few key strokes:
: <code>.qdm|Heading to airport $qdm</code>

Lastly, if a troll or angry user is polluting your session with undesired messages, add their callsign to the '''senders blacklist'''. All messages from the user will then be filtered out from the message pane. You can view and clear this list at any time.

== ATC coordination ==

"ATC coordination" refers to the following:
* strip exchange, i.e. sending and receiving strips (handovers);
* ATC phone lines, for private voice calls (except in solo sessions);
* CPDLC authority transfers;
* ''who-has'' requests, to query ATCs about who is claiming control of callsigns;
* ATC text messaging, to exchange text messages with other ATCs (except in solo sessions).

=== Strip exchange ===
[[File:ATC-pie-screenshot-receivedStrip.png|thumbnail|Example of a strip received from "GND"]]
To hand a strip over, drag it and drop it on the recipient in the list of controllers in the ''ATC coordination'' dock. A received strip appears with an identification of the sender which disappears as soon as the strip is clicked on.

A received strip lands on the collecting rack set for the sender if any (double-click on a rack name to add an ATC callsign from which to collect strips), or on the "Default" rack otherwise. It may link automatically to an identified radar contact according to the selected auto-link options (general settings).

See [https://www.youtube.com/watch?v=oQIud-cAlT4 tutorial video 6] for a presentation of the feature.

=== ATC phone lines ===
Phone lines allow to call and talk to other ATCs directly from the ''ATC coordination'' dock. Each line has an outgoing state that you control, toggling between open and closed with a double-click on its phone icon. Opening a line places a call to the connected ATC, showing as incoming on their side. When two parties have their line open to one another, they are in direct communication (no push-to-talk). In other words, opening an incoming call puts you on the phone with the caller, and closing an active call hangs up the active line, but you can pick it back up as long as the other party holds it open.

You can only talk to one ATC at a time but may place multiple outgoing calls. If a call you placed is answered while you are already in a call, the answered call switches to show as incoming without interrupting the one in progress. On your side, an incoming call you answer which turns to "placed" (outgoing only) instead of "in progress" means that the other party is already on the phone and is now seeing an incoming call from you. Opening (answering) an incoming call while already in a call yourself drops the current line.

=== ATC text messaging ===
The ATC text messaging system allows to talk with other ATCs in channels outside of the "text radio" visible to pilots. It offers private channels for one-to-one conversations, and a public ATC chat room in network sessions, readable by all connected ATCs. Text alias substitution works here too.

'''Note on interoperability in FG sessions''': While only ATC-pie integrates ATC text messaging in its interface, other users can interact with a regular IRC client connected to <code>mpirc.flightgear.org</code>, with their FlightGear network callsign as IRC nickname, and joining the set IRC channel. They will be able to send and receive public and private messages and talk with everybody, at the only cost of ignoring the system messages that will sometimes appear on their side.

== Solo sessions ==

In solo sessions, you control virtual IFR planes, receiving and handing over strips to virtual ATCs depending on your position and the aircraft's intentions. You can train as an en-route controller in CTR mode, or as an airport controller in AD mode, where four combinable positions are available:
* ground (GND), to taxi aircraft between parking positions and runways;
* tower (TWR), to control runways and immediate surroundings;
* departure (DEP), to bring departing traffic to their exit point;
* approach (APP), to vector arrivals onto final.

=== Objectives ===
In '''CTR mode''', your task is to transit the aircraft across your airspace, always ensuring separation, and to hand each of them over to the most appropriate neighbouring centre North, South, East or West of your sector. You can specify local navpoints in the location settings so that the system includes them as turning points in the randomised aircraft routes.

In '''airport mode''', traffic is either inbound or outbound. Assuming APP, inbound aircraft must be sequenced and vectored into tower range for handover, unless you are in the TWR position as well. Each inbound aircraft either requests ILS or visual. Assuming TWR, you must clear them to land when appropriate, i.e. cleared for ILS approach or expected runway reported in sight. If landing cannot take place (too high, not cleared...), aircraft will go around. Controlling GND, you must move inbound traffic near their parking position once they have vacated the runway, and hand them over to the ramp. Outbound traffic must be brought to hold short of a runway threshold and report ready for departure with TWR. If you assume DEP, you must hand outbound aircraft over to the en-route centre (CTR) once they are high enough and close to their exit point if specified in their route. Entry and exit points are configurable in <code>CONFIG/nav/AD-entry-exit</code> (see <code>Notice</code> in the directory).

[[File:ATC-pie-screenshot-handoverPane-solo.png|thumbnail|Handover pane in an AD solo session, assuming all three available positions]]
{| class="wikitable" style="text-align:center"
|+ Handovers with virtual ATCs in airport mode
|-
| || colspan="2" | Departure strips || colspan="2" | Arrival strips
|-
! Assuming positions || Receive from || Hand over to || Receive from || Hand over to
|-
! GND only
| DEL || TWR || TWR || Ramp
|-
! TWR only
| GND || DEP || APP || GND
|-
! DEP only
| TWR || CTR || colspan="2" | N/A
|-
! APP only
| colspan="2" | N/A || CTR || TWR
|-
! TWR+GND
| DEL || DEP || APP || Ramp
|-
! TWR+DEP
| GND || CTR || APP || GND
|-
! TWR+APP
| GND || DEP || CTR || GND
|-
! APP+DEP
| TWR || CTR || CTR || TWR
|-
! TWR+GND+DEP
| DEL || CTR || APP || Ramp
|-
! TWR+GND+APP
| DEL || DEP || APP || Ramp
|-
! TWR+APP+DEP
| GND || CTR || CTR || GND
|-
! All 4
| DEL || CTR || CTR || Ramp
|}

=== Instructing aircraft ===
[[File:ATC-pie-screenshot-taxiInstructionTool.png|thumbnail|Click&drag taxi instruction tool at OMDB ground]]
Instructions are given through different means:
* provided the speech recognition modules are installed, you can turn on voice instructions from the solo simulation options dialog and instruct aircraft through your microphone, using the {{key press|Ctrl}} key as push-to-talk and standard phraseology (see the quick reference tab about it);
* if voice instructions are turned off:
** mouse vector assignments issue the corresponding instructions (see section on vectors above);
** handoffs are issued when dropping strips on an ATC receiver;
* instruct taxi routes by dragging out of radar contacts when they are considered on the ground (low enough or squawking GND);
* the dockable instruction panel works regardless of voice vs. mouse selection;
* alternatively, if the aircraft is connected to CPDLC, you can send instructions through the [[#CPDLC|data link]].

Instructions from the panel are always issued to the callsign entered in the top field, which should fill automatically on aircraft or strip selection when a callsign is known. Therefore, make sure you do not mess up your strip links or your instructions will realistically be acknowledged and followed by the wrong aircraft.

=== Need a scenario? ===
Things you can train for:
* towering a single runway with mixed traffic: select TWR position and an equal balance of departures and arrivals;
* optimising approach spacing in dense traffic: select APP position only, increase traffic density, turn on spacing hints and try to stabilise them all at "3:00" for example;
* change of runways (e.g. irl after wind direction change): start with APP+TWR and select a runway for arrivals at least, run the simulation for a while and change for opposite runway use;
* CTR mode with a low ceiling to increase the number of conflicts to resolve;
* etc.

== Teacher & student connections (ATC tutoring) ==

This session type is made to bring an ATC student and a teacher together for tutorial sessions. To '''set up a session''', the student must connect to the teacher, so make sure the teacher's session is running first. Only one student can connect to a teacher at a time. The teacher creates and manipulates traffic for the student to work with, controls the weather and decides on the ATC neighbours. The student can exchange strips and text messages with virtual ATCs (monitored/simulated by the teacher). The teacher can also snapshot traffic position situations to recall them later.

In '''teacher sessions''':
* The teaching console is enabled, which allows you to control most aspects of the environment visible to the student.
* You create new traffic holding {{key press|Shift}} down with a right click-and-drag on the radar specifying the position and face heading. A dialog pops up and allows you to choose a callsign (one is initially generated), altitude and other details. If near a ground route node, a parking position or runway, you can create it on the ground, ready to taxi or for departure (NB: parking overrides position/heading input).
* Traffic is initially created in an "unspawned" state (radar contact marked "+"), in other words visible to you but not to the student. This allows you to set its transponder or get it into a certain state before spawning it into the student's world.
* Controlling the traffic is done in the same way as in solo sessions without voice, i.e. using the click&drag vector and taxi tools and the instruction dock. The only difference is that you control the selected aircraft directly, regardless of your strip links and details. You therefore do not need a strip and a correctly filled callsign to instruct a pilot, though it is a good idea to have one if you want your vectors registered and drawn on the radar. The traffic creation dialog offers to create a linked strip with every new aircraft.
* You may pause the whole simulation, or freeze each aircraft individually.
* The ATC text messaging system allows to simulate ATC conversations with the student (select callsign to interact as), or interact with the student directly as the teacher.
* To send a strip to the student, drop it on the callsign of the ATC whom it should appear sent from on the student's side. Note that for your convenience in further control of the traffic, teacher strips do not disappear on handovers;
* CPDLC is supported, the dialogue windows reflecting the change of perspective (ACFT instead of ATC) and the {{key press|Alt}} key combinations generating requests rather than instructions.

[[Category:ATC-pie]]

ATC-pie FAQ

2025-11-29T15:34:25Z

Mickybadia: Version 1.9.2

{{forum|83|ATC-Pie support & development}}

This page is a collection of questions asked at least twice about [[ATC-pie]]. It is a good idea to search through it before repeating a question on the forum or anywhere.

== Things "not working" ==

=== This aircraft is connected but I am not seeing it on my radar. ===
As in real life, the main radar technology is [http://en.wikipedia.org/wiki/Secondary_surveillance_radar SSR], which only shows what is picked up from on-board transponders in its range. It coexists with primary radar, which detects aircraft regardless of transponders but offers no information other than position (angle and distance), i.e. neither of callsign, altitude, type, IAS, etc.

The following cases will therefore prevent you from seeing a connected aircraft:
* The radars are turned off. Turn on at least a primary radar from the ''Options'' menu, or an SSR capability from the ''Radar'' tab in the location settings dialog. Any SSR setting other than "none" will pick up contacts.
* The aircraft is out of radar range, either too far out or under the radar floor. Check the horizontal range and floor settings ("SFC" will pick up all signals down to the ground). Primary and secondary radars share the same range.
* Its onboard transponder is turned off (and primary radar is off); see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Otherwise if you accept cheating, you can activate the "radar cheat mode" which will simulate a mode S transponder for all aircraft in horizontal range; see [https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3].

=== The aircraft vectoring tool does not come up when I click and drag out of radar contacts. ===
Your radar contact is not linked. Link it to a strip to enable registering the mouse-issued vectors. Radar and strip displays will then be informed according to the current options, e.g. altitude reaching point, unfollowed vector warnings, etc.

=== FGCom is not working. ===
First, note that the historic executable variant of FGCom (FlightGear sessions only) was abandoned in 2025. We now assume the [[FGCom-mumble]] plug-in, which must be run with an external ''Mumble'' client connected to a chosen server. See the project [https://github.com/hbeni/fgcom-mumble/releases release] and wiki pages to download and install it.

The control port in the ATC-pie settings must be set to the one FGCom-mumble is listening on. In sessions (FG and FSD), FGCom-mumble must be enabled in the session start dialog.

To troubleshoot:
* open a single ATC-pie instance;
* check that your sound is on, your volume loud and your system picking up a signal from your microphone;
* start the FGCom-mumble configuration test from the FG/FSD voice settings dialog;
* speak in the microphone while the echo test is running.

=== Tower view is not starting. ===
If the tower viewer process is set to "internal" in the viewer settings, find the right command to start FlightGear and enter it as ''FGFS command''. Do not add options here; they will be taken care of internally. You may have to enter a ''FlightGear root directory'' as well, especially if you have the program files installed somewhere unexpected.

If your tower viewer process is set to "external", the FlightGear viewer must already be running. It is up to you to start it on the specified host. ATC-pie will only be sending data to it, assuming it running.

=== My tower is in the middle of the sea, and aircraft floating/landing on water! ===
You are missing the FlightGear scenery data for your location, or ATC-pie does not know where it is. If you have downloaded scenery and saved it somewhere, have you tried filling the scenery directory with that location in the viewer settings? Also read the [[ATC-pie_installation_guide#Airport scene rendering|related section]] in the installation guide.

=== Simulated aircraft dip underground or levitate over taxiways. ===
Do you have a ground elevation map for the location? Quoting from <code>CONFIG/elev/Notice</code>: "''When no elevation map is found for an airport, the field elevation value is used everywhere on the ground. This should be OK for a rough approximation on flat terrain, but ground traffic will not follow any slopes, thus may appear as floating above the ground, or dipping into it.''" Read the full notice for instructions on how to build your elevation map.

Once you have an elevation map, the next focus is on the FlightGear aircraft models. Because each model has its own coordinate system chosen at developer's discretion, ATC-pie must be given the height difference between each model's origin and the aircraft touch-down point (gear wheels) to position aircraft more accurately. You do this on a per-model basis with ":height" specifications in <code>CONFIG/acft/icao2fgfs</code>. Read the associated <code>Notice</code> section for more information.

=== Phone lines have broken, choppy or dragged out sound ===
You and the other parties must adjust microphone sensitivity. Toggle the phone squelch adjustment box from the system menu and tune the spinbox next to the "call" button in the ATC coordination panel. Lower values will decrease the threshold for sound pick-up and likely break the sound less, but can generate more lag in the communications. The right balance depends on your local configuration, so a few test calls with other connected ATCs will be necessary to decide on the best acceptable value.

=== I cannot connect to my teacher as a student. ===
Using IPv4 addresses, this typically happens when the teacher is in a local area network behind a router. It is a common setup for home internet, in which the teacher's actual host address is not publicly accessible from outside his private network.

If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either:
* for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local host address;
* or to create a virtual network, using a third-party VPN service.

== What is ...? What value/setting for ...? ==

=== What "social name" should I use for FlightGear/FSD sessions? ===
Choose any name you would like to be recognised by on the network. In ATC-pie, it will appear in the tool tip over your callsign for connected ATCs who see you. This feature is only social in the sense that it does not refer to an account or to anything technical, but it makes sense as typical ATC callsigns (e.g. "VHHHtwr") remain mostly anonymous. Use this field to identify yourself on the network.

=== What is the purpose of the flat "strip shelf" button in the strip panes? ===
More than a button, the strip shelf is where you should drop the contacts you release without a handover, e.g. parked traffic shutting down, VFR traffic flying out of your airspace, etc. Clicking on the shelf allows to browse the previously shelved strips, and to recall them, for example if shelved inadvertently.

=== What is "radio direction finding"? ===
RDF is a system that detects the horizontal direction of radio sources when signals are received. Its most common uses are:
* to locate ACFT making radio contact;
* to give bearings to the airport to disoriented VFR pilots.

Setting up your location as equipped with RDF will essentially provide two things:
* a status bar indication of the form "hdg/qdm" in the main window, where "hdg" is the heading from your location to the currently detected radio signal source, or "---" if none, and "qdm" is the bearing (opposite direction, from source to location) for the last received signal, displayed until the next signal is detected;
* the option to draw a line on radar scopes when a signal is detected, making it easy to visualise the transmitting ACFT as the line should hit its target.

=== Are the vector headings true or magnetic? ===
Heading displays in ATC-pie are mostly magnetic so they can be read out to pilots. The exceptions are the navigator and handover list tool tips, which show true radial headings from the radar position, and the teacher's wind section to match the generated ATIS string.

Also note: all directions are geodesic, i.e. initial headings to take on a great circle.

=== How do approach spacing hints work? ===
When the option is turned on, an approach spacing hint will show on every strip verifying the following conditions:
* it is racked in sequence behind another marked with the same (recognised) destination;
* both are linked to an airborne aircraft with a known ground speed;
* the time hint value (see below) does not exceed 30 minutes.

The hint value for a strip is an estimated time difference between the linked aircraft touchdown and that of the traffic ahead, assuming:
* both present ground speeds;
* for the leading aircraft, a straight path to destination;
* for the tailing aircraft, a path straight to the leading one first, then straight to destination.

Caution, some judgement is required depending on the aircraft positions, because the actual paths to expect can vary from those above. For example, the interpretation of the hint should be different whether both aircraft are aligned with the runway or coming from opposite directions. But with some practice, the rate of the changes still help to optimise spacing when the displayed values don't.

=== What do the various markings along the approach centre line mean? ===
The regularly spaced groups along a centre line represent altitudes on the approach plane. Each group sums up to an AMSL value in accordance with the set flight path angle (also see ''Display conventions'' in the quick reference):
* straight line = 1,000 ft;
* solid diamond = 5,000 ft.

The other markers drawn with thicker lines are the positions of the ILS marker beacons (OM, MM, IM), the line pattern representing the sound triggered by the beacon in the pilot's headset. They are sourced on program start-up from the navigation data (<code>CONFIG/nav/navaid.dat</code>).

=== Why do I keep getting runway incursion alarms? ===
Because you have the runway occupation monitor turned on (''Options'' menu), while not using your runway boxes. The alarm triggers when the radar detects traffic stepping on a runway in either of the following situations:
* the runway is active (marked in use) and no strip is boxed for it;
* it is reserved but there is already traffic on the runway;
* it is reserved for a different aircraft: the boxed strip is linked to a contact that is not the entering aircraft, or the aircraft is linked to a strip different to the one boxed.

Turning the runway occupation monitor off will deactivate all radar warnings regarding runways. If you are interested in the strip boxing and visual runway highlighting system but bothered by the alarm sound, you can mute the sound notification by unticking it in the general settings.

== Where is ...? How to ...? ==

=== Can I draw SID and STAR procedures on the radar? ===
Yes, and virtually anything else, using background images. To learn about those:
* see the corresponding [[ATC-pie_installation_guide#Background images|installation guide section]];
* read the <code>CONFIG/bg/Notice</code> file.

=== How do I assign SIDs and STARs to aircraft? ===
This question is asked quite a lot more than it is relevant to a real controller's task...

You may be looking to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. The way to handle this is to stack your inbound strips on racks named after your STARs. Every rack represents its own traffic sequence of ordered aircraft, which is perfectly suited to control separate approach paths. Placing a strip on a STAR-named rack basically serves as the "assignment" itself. You can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times.

If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. A route can contain an indication of a standard departure or arrival procedure, but only by their entry or exit navpoints. It should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. Keyword "SID" can be used in the first route leg specification, e.g. "SID FUBAR ..." for a standard departure out to exit point FUBAR, and keyword "STAR" in the last, e.g. "... DUMMY STAR" for a standard approach from entry point DUMMY. They are recognised by ATC-pie and affect the second line of the radar tag when appropriate (see feature note on routes).

One meaningful wish regarding this question is for easy '''reference in text radio''' messages. Firstly, using and naming racks as suggested above, you can use the <code>$rack</code> alias which substitutes the name of the rack on which the current strip selection is stacked. Alternatively, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". If you specifically want to assign a full procedure name like "FUBAR1A" to a contact and refer to it with a generic text message, include a line "sid=FUBAR1A" in your strip comments. It will allow a custom <code>$sid</code> alias that will automatically expand in sent messages when that strip is selected.

=== How to set the transition level? ===
You do not. You can however set the transition altitude in the location settings if your airport specification file does not already include one.

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, e.g. for more vertical separation on either side of the transition layer or due to coordination with neighbouring zones and fields.

=== Can I look up ILS frequencies? ===
Yes, in the ''Location info'' dialog ({{key press|Shift+F1}}).

Besides, you can create aliases with the local notepad for a quick and integrated way of sending them through text, which will be saved when you close ATC-pie. For example, use the following format, one runway per line: <code>ils05=111.11 MHz</code>.

=== The airport/navigation data is outdated. How can I update it? ===

The included '''airport data''' (taxiways, parking positions, frequencies, etc.) is the latest but outdated world-wide <code>apt.dat</code> file compiled by ''X-plane'' ages ago. We keep it there because it allows to run ATC-pie anywhere in the world without requiring external data, but for any serious work at a specific airfield, you should provide the latest source available on the [http://gateway.x-plane.com/airports/page X-plane airport gateway], directly accessible from the ''System'' menu. Extract the <code>apt.dat</code> file from the downloaded package, rename it after the airport's ICAO code keeping the extension (e.g. <code>KJFK.dat</code>), and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> there). Alternatively, for a quick manual touch-up of the old data, you can use the locally extracted file (see <code>OUTPUT/Notice</code>).

The included '''navigation data''' (navaids, fixes, airways, etc.) is the latest GPL version seen for each relevant ''X-plane'' file, also all out of date today. You should provide more recent navigation data, as explained in <code>CONFIG/nav/Notice</code>.

=== How do I customise the GUI and colours? ===
To change the '''radar or strip drawing colours''', edit the <code>CONFIG/colours.conf</code> file. Each line specifies the paint colour for an object type, in a typical hex <code>RRGGBB</code> (red-green-blue) format or as an SVG colour keyword name like "white". To customise the '''main session window''', place a ''Qt stylesheet'' named <code>main-stylesheet.qss</code> in the <code>CONFIG</code> directory. ATC-pie will apply it to every session window. While you are working on your look and feel, use the reload feature from the "System" menu to avoid restarting after every change.

Send us screenshots and share your files if you find a setup looking really cool! :-)

== Miscellaneous ==

=== What's with the funny name? ===
ATC-pie is written in Python, and I reckoned that the ''pyXXX'' naming habit was becoming a little dull, so I merely switched things around. You can surely do the rest of the math in terms of spelling, and later impact on the logo.

=== Why is the learning curve so steep? People would use your program more if you did/provided [...] ===
Often continued with: '''(you must understand that) this is not VATSIM!'''

We do have a [https://sourceforge.net/p/atc-pie/wiki/Wishlist wish list] and will consider any feature or help request. However, though it has a few cheats, ATC-pie has always choosen realism as a criterion for implementation and design, over the mere incentive of converting otherwise happy users of other programs. It is a good thing that different philosophies and work flows are available out there, and there would be much less interest in having them all copy each other, fighting over users instead of understanding that not all of them wish for the same experience. If serious simulation or learning new skills sound like threats to fun for you, you have a perfectly valid reason not to opt for ATC-pie.

[[Category:ATC-pie]]

ATC-pie

2025-03-26T13:14:56Z

Mickybadia: v1.9.1

{{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
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.9.1 (March 25, 2025)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''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);
* "multi-player" network sessions (FlightGear and FSD protocols supported);
* tutorial sessions for teacher supervision of an ATC student.

It is designed to support a maximum range of ATC situations, and will allow any world location for every session type above. All control positions are possible, whether airport-based (TWR, APP, GND...) or en-route (CTR). Equipment can be set up to include radar screens, data link, etc. or be limited to binoculars and a view of the airfield.

Its essential goal is realism. It simulates many tasks of real-life ATC such as:
* strip racks and sequence management;
* coordination with neighbouring controllers (phone calls, handovers...);
* radar monitoring for traffic identification and sequencing;
* vectoring and course/level conflict anticipation;
* flight plan operations;
* CPDLC...

== Screenshots ==

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Solo session with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

== Sessions and environments ==

ATC-pie features five session/connection types, all of which support both ''airport'' and ''centre'' location modes.

Session types:
* solo simulation (AI traffic)
* FlightGear network connection ([[FGMS]] protocol)
* 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)

Location modes:
* airport (AD): positions such as TWR, GND, APP, DEP at a selected airfield
* en-route centre (CTR): free positioning of radar, no base airport or TKOF/LDG-related options

{| class="wikitable" style="text-align:center"
|+ Feature support by session type
! || Solo || FlightGear || FSD || Tutoring (teacher/student)
|-
! ACFT traffic
| AI aircraft generated according to RWY capacities, ACFT equipment, intentions...
| colspan="2" | connected flight sim pilots
| created and simulated by teacher
|-
! 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
|-
! Voice radio
| voice recognition for instructions (mouse-only also available) and synthesis for pilot read-back
| colspan="2" | [[FGCom-mumble]] integration
| teacher simulates pilots
|-
! ATC phone lines
| N/A
| colspan="2" | integrated Mumble connection
| teacher simulates ATCs
|-
! 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
|-
! CPDLC
| interpreted subset of instruction messages
| integrated (supported by MP IRC)
| integrated interface with [https://www.hoppie.nl/acars/ Hoppie's ACARS network]
| full simulation by teacher (with WILCO assistance to execute instructions)
|-
! Weather
| randomised and evolving
| real world METAR retrieval
| fetch from server or retrieve real world METAR
| controlled by teacher
|-
! Other specific features
| style="text-align:left" |
* 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.)
* historic [[FGCom_3.0|FGCom executable]] alternative supported
| 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
|}

== Detailed feature list ==

=== ATC surveillance ===
Radars and tracking:
* SSR mode capability selection (none/A/C/S)
* primary radar toggle
* 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
* 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)

Other:
* radio direction finding (RDF) and integration to radar
* multiple weather (METAR) station monitor
* [[ATIS]] recording and reminder alarm (see [[:File:ATC-pie-screenshot-ATISdialog.png|dialog]] with pre-filled notepad)

=== 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
* departure clearance assistant
* automatic strip printing for expected departures or arrivals (from FPLs)

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

=== Communications ===
With aircraft:
* voice radio with 8.33 kHz frequency spacing, multiple radio transmissions and monitoring
* [[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

ATC coordination:
* 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

=== 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
* list of known ACFT types by callsign

GUI:
* multiple window workspace (radar screens, strip racks and bays) saved by location
* 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

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

== 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:
* OpenRadar to ATC-pie: FGMS callsign will appear on the strip, as if the sender had filled the detail herself;
* 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 through OpenRadar's service: strip detail preserved, whether present or absent.

Features not supported by OpenRadar:
* ATC phone lines;
* ATC text messaging;
* CPDLC transfers;
* wake turbulance category and departure clearances on strips (but details preserved for ATC-pie clients later receiving the strip).

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. 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:Air Traffic Control]]

ATC-pie FAQ

2025-03-16T20:15:24Z

Mickybadia: v1.9.0

{{forum|83|ATC-Pie support & development}}

This page is a collection of questions asked at least twice about [[ATC-pie]]. It is a good idea to search through it before repeating a question on the forum or anywhere.

== Things "not working" ==

=== This aircraft is connected but I am not seeing it on my radar. ===
As in real life, the main radar technology is [http://en.wikipedia.org/wiki/Secondary_surveillance_radar SSR], which only shows what is picked up from on-board transponders in its range. It coexists with primary radar, which detects aircraft regardless of transponders but offers no information other than position (angle and distance), i.e. neither of callsign, altitude, type, IAS, etc.

The following cases will therefore prevent you from seeing a connected aircraft:
* The radars are turned off. Turn on at least a primary radar from the ''Options'' menu, or an SSR capability from the ''Radar'' tab in the ''Local settings'' dialog. Any SSR setting other than "none" will pick up contacts.
* The aircraft is out of radar range, either too far out or under the radar floor. Check the horizontal range and floor settings ("SFC" will pick up all signals down to the ground). Primary and secondary radars share the same range.
* Its onboard transponder is turned off (and primary radar is off); see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Otherwise if you accept cheating, you can activate the "radar cheat mode" which will simulate a mode S transponder for all aircraft in horizontal range; see [https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3].

=== The aircraft vectoring tool does not come up when I click and drag out of radar contacts. ===
Your radar contact is not linked. Link it to a strip to enable registering the mouse-issued vectors. Radar and strip displays will then be informed according to the current options, e.g. altitude reaching point, unfollowed vector warnings, etc.

=== FGCom is not working. ===
First, note that there are two variants of FGCom: the ''FGCom-mumble'' plug-in (works in FlightGear and FSD sessions) and the historic ''executable'' (FlightGear sessions only). They are not interoperable: users can only hear and interact with others using the same variant and server.

'''FGCom-mumble''' is a plug-in that must be run with an external ''Mumble'' client connected to a chosen server. See the project [https://github.com/hbeni/fgcom-mumble/releases release] and wiki pages to download and install it. The control port in ATC-pie must be set to the one FGCom-mumble is listening on. To troubleshoot:
* open a single ATC-pie instance;
* check that your sound is on, your volume loud and your system picking up a signal from your microphone;
* start the FGCom-mumble configuration test from the system settings dialog;
* speak in the microphone while the echo test is running.

For the '''executable''' variant (selectable in the FlightGear ''system settings''), the FGCom command should be a valid command or path to an FGCom executable file. If you have FlightGear installed on your machine, you can point to the FGCom executable already available with it. On Linux, the plain "fgcom" command usually does the job in that case. Otherwise, get one from ATC-pie's [https://sourceforge.net/projects/atc-pie/files/fgcom-standalone/ SourceForge file list]. Try the entry from a terminal in the ATC-pie directory to manually check that it runs correctly, and try the echo test available from the settings box. Other things you might check if you do not want to switch to FGCom-mumble:
* server status: check for responses from the chosen server, e.g. with <code>ping</code>;
* subprocess error: after turning a first radio on, check the FGCom error logs in the <code>OUTPUT</code> directory;
* port mess-up: make sure you choose an unused port number for each created radio at run time.

=== Tower view is not starting. ===
Ruling out that FlightGear is not installed at all, your system path settings are probably wrong. From a terminal or a file system navigator, find the right command to start FlightGear and enter it as ''FlightGear executable'' from the system settings. Do not add options here; they will be taken care of internally. You may have to enter a ''FlightGear root directory'' as well, especially if you have the program files installed somewhere unexpected.

=== My tower is in the middle of the sea, and aircraft floating/landing on water! ===
You are missing the FlightGear scenery data for your location, or ATC-pie does not know where it is. If you have downloaded scenery and saved it somewhere, have you tried filling the scenery directory with that location in the system settings? Also read the [[ATC-pie_installation_guide#Airport scene rendering|related section]] in the installation guide.

=== Simulated aircraft dip underground or levitate over taxiways. ===
Do you have a ground elevation map for the location? Quoting from <code>CONFIG/elev/Notice</code>: "''When no elevation map is found for an airport, the field elevation value is used everywhere on the ground. This should be OK for a rough approximation on flat terrain, but ground traffic will not follow any slopes, thus may appear as floating above the ground, or dipping into it.''" Read the full notice for instructions on how to build your elevation map.

Once you have an elevation map, the next focus is on the FlightGear aircraft models. Because each model has its own coordinate system chosen at developer's discretion, ATC-pie must be given the height difference between each model's origin and the aircraft touch-down point (gear wheels) to position aircraft more accurately. You do this on a per-model basis with ":height" specifications in <code>CONFIG/acft/icao2fgfs</code>. Read the associated <code>Notice</code> section for more information.

=== Phone lines have broken, choppy or dragged out sound ===
You and the other parties must adjust microphone sensitivity. Toggle the phone squelch adjustment box from the system menu and tune the spinbox next to the "call" button in the ATC coordination panel. Lower values will decrease the threshold for sound pick-up and likely break the sound less, but can generate more lag in the communications. The right balance depends on your local configuration, so a few test calls with other connected ATCs will be necessary to decide on the best acceptable value.

=== I cannot connect to my teacher as a student. ===
Using IPv4 addresses, this typically happens when the teacher is in a local area network behind a router. It is a common setup for home internet, in which the teacher's actual host address is not publicly accessible from outside his private network.

If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either:
* for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local host address;
* or to create a virtual network, using a third-party VPN service.

== What is ...? Why is ...? What value/setting for ...? ==

=== What "social name" should I use for FlightGear/FSD sessions? ===
Choose any name you would like to be recognised by on the network. In ATC-pie, it will appear in the tool tip over your callsign for connected ATCs who see you. This feature is only social in the sense that it does not refer to an account or to anything technical, but it makes sense as typical ATC callsigns (e.g. "VHHHtwr") remain mostly anonymous. Use this field to identify yourself on the network.

=== What is the purpose of the flat "strip shelf" button in the strip panes? ===
More than a button, the strip shelf is where you should drop the contacts you release without a handover, e.g. parked traffic shutting down, VFR traffic flying out of your airspace, etc. Clicking on the shelf allows to browse the previously shelved strips, and to recall them, for example if shelved inadvertently.

=== What is "radio direction finding"? ===
RDF is a system that detects the horizontal direction of radio sources when signals are received. Its most common uses are:
* to locate ACFT making radio contact;
* to give bearings to the airport to disoriented VFR pilots.

Setting up your location as equipped with RDF will essentially provide two things:
* a status bar indication of the form "hdg/qdm" in the main window, where "hdg" is the heading from your location to the currently detected radio signal source, or "---" if none, and "qdm" is the bearing (opposite direction, from source to location) for the last received signal, displayed until the next signal is detected;
* the option to draw a line on radar scopes when a signal is detected, making it easy to visualise the transmitting ACFT as the line should hit its target.

=== Are the vector headings true or magnetic? ===
Heading displays in ATC-pie are mostly magnetic so they can be read out to pilots. The exceptions are the navigator and handover list tool tips, which show true radial headings from the radar position, and the teacher's wind section to match the generated ATIS string.

Also note: all directions are geodesic, i.e. initial headings to take on a great circle.

=== How do approach spacing hints work? ===
When the option is turned on, an approach spacing hint will show on every strip verifying the following conditions:
* it is racked in sequence behind another marked with the same (recognised) destination;
* both are linked to an airborne aircraft with a known ground speed;
* the time hint value (see below) does not exceed 30 minutes.

The hint value for a strip is an estimated time difference between the linked aircraft touchdown and that of the traffic ahead, assuming:
* both present ground speeds;
* for the leading aircraft, a straight path to destination;
* for the tailing aircraft, a path straight to the leading one first, then straight to destination.

Caution, some judgement is required depending on the aircraft positions, because the actual paths to expect can vary from those above. For example, the interpretation of the hint should be different whether both aircraft are aligned with the runway or coming from opposite directions. But with some practice, the rate of the changes still help to optimise spacing when the displayed values don't.

=== What do the various markings along the approach centre line mean? ===
The regularly spaced groups along a centre line represent altitudes on the approach plane. Each group sums up to an AMSL value in accordance with the set flight path angle (also see ''Display conventions'' in the quick reference):
* straight line = 1,000 ft;
* solid diamond = 5,000 ft.

The other markers drawn with thicker lines are the positions of the ILS marker beacons (OM, MM, IM), the line pattern representing the sound triggered by the beacon in the pilot's headset. They are sourced on program start-up from the navigation data (<code>CONFIG/nav/navaid.dat</code>).

=== Why do I keep getting runway incursion alarms? ===
Because you have the runway occupation monitor turned on (''Options'' menu), while not using your runway boxes. The alarm triggers when the radar detects traffic stepping on a runway in either of the following situations:
* the runway is active (marked in use) and no strip is boxed for it;
* it is reserved but there is already traffic on the runway;
* it is reserved for a different aircraft: the boxed strip is linked to a contact that is not the entering aircraft, or the aircraft is linked to a strip different to the one boxed.

Turning the runway occupation monitor off will deactivate all radar warnings regarding runways. If you are interested in the strip boxing and visual runway highlighting system but bothered by the alarm sound, you can mute the sound notification by unticking it in the general settings.

== Where is ...? How to ...? ==

=== Can I draw SID and STAR procedures on the radar? ===
Yes, and virtually anything else, using background images. To learn about those:
* see the corresponding [[ATC-pie_installation_guide#Background images|installation guide section]];
* read the <code>CONFIG/bg/Notice</code> file.

=== How do I assign SIDs and STARs to aircraft? ===
This question is asked quite a lot more than it is relevant to a real controller's task...

You may be looking to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. The way to handle this is to stack your inbound strips on racks named after your STARs. Every rack represents its own traffic sequence of ordered aircraft, which is perfectly suited to control separate approach paths. Placing a strip on a STAR-named rack basically serves as the "assignment" itself. You can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times.

If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. A route can contain an indication of a standard departure or arrival procedure, but only by their entry or exit navpoints. It should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. Keyword "SID" can be used in the first route leg specification, e.g. "SID FUBAR ..." for a standard departure out to exit point FUBAR, and keyword "STAR" in the last, e.g. "... DUMMY STAR" for a standard approach from entry point DUMMY. They are recognised by ATC-pie and affect the second line of the radar tag when appropriate (see feature note on routes).

One meaningful wish regarding this question is for easy '''reference in text chat''' messages. Firstly, using and naming racks as suggested above, you can use the <code>$rack</code> alias which substitutes the name of the rack on which the current strip selection is stacked. Alternatively, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". If you specifically want to assign a full procedure name like "FUBAR1A" to a contact and refer to it with a generic text chat message, include a line "sid=FUBAR1A" in your strip comments. It will allow a custom <code>$sid</code> alias that will automatically expand in sent messages when that strip is selected.

=== How to set the transition level? ===
You do not. You can however set the transition altitude in the location settings if your airport specification file does not already include one.

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, e.g. for more vertical separation on either side of the transition layer or due to coordination with neighbouring zones and fields.

=== Can I look up ILS frequencies? ===
Yes, in the ''environment info'' dialog.

Besides, you can create aliases with the local notepad for a quick and integrated way of sending them through text chat, which will be saved when you close ATC-pie. For example, use the following format, one runway per line: <code>ils05=111.11 MHz</code>. See [[ATC-pie_user_guide#Public text chat|custom text aliases]] for more.

=== The airport/navigation data is outdated. How can I update it? ===

The included '''airport data''' (taxiways, parking positions, frequencies, etc.) is the latest but outdated world-wide <code>apt.dat</code> file compiled by ''X-plane'' ages ago. We keep it there because it allows to run ATC-pie anywhere in the world without requiring external data, but for any serious work at a specific airfield, you should provide the latest source available on the [http://gateway.x-plane.com/airports/page X-plane airport gateway], directly accessible from the ''System'' menu. Extract the <code>apt.dat</code> file from the downloaded package, rename it after the airport's ICAO code keeping the extension (e.g. <code>KJFK.dat</code>), and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> there). Alternatively, for a quick manual touch-up of the old data, you can use the locally extracted file (see <code>OUTPUT/Notice</code>).

The included '''navigation data''' (navaids, fixes, airways, etc.) is the latest GPL version seen for each relevant ''X-plane'' file, also all out of date today. You should provide more recent navigation data, as explained in <code>CONFIG/nav/Notice</code>.

=== How do I customise the GUI and colours? ===
To change the '''radar or strip drawing colours''', edit the <code>CONFIG/colours.conf</code> file. Each line specifies the paint colour for an object type, in a typical hex <code>RRGGBB</code> (red-green-blue) format or as an SVG colour keyword name like "white". To customise the '''main session window''', place a ''Qt stylesheet'' named <code>main-stylesheet.qss</code> in the <code>CONFIG</code> directory. ATC-pie will apply it to every session window. While you are working on your look and feel, use the reload feature from the "System" menu to avoid restarting after every change.

Send us screenshots and share your files if you find a setup looking really cool! :-)

== Miscellaneous ==

=== What's with the funny name? ===
ATC-pie is written in Python, and I reckoned that the ''pyXXX'' naming habit was becoming a little dull, so I merely switched things around. You can surely do the rest of the math in terms of spelling, and later impact on the logo.

=== Why is the learning curve so steep? People would use your program more if you did/provided [...] ===
Often continued with: '''(you must understand that) this is not VATSIM!'''

We do have a [https://sourceforge.net/p/atc-pie/wiki/Wishlist wish list] and will consider any feature or help request. However, though it has a few cheats, ATC-pie has always choosen realism as a criterion for implementation and design, over the mere incentive of converting otherwise happy users of other programs. It is a good thing that different philosophies and work flows are available out there, and there would be much less interest in having them all copy each other, fighting over users instead of understanding that not all of them wish for the same experience. If serious simulation or learning new skills sound like threats to fun for you, you have a perfectly valid reason not to opt for ATC-pie.

[[Category:ATC-pie]]

ATC-pie user guide

2025-03-16T20:14:30Z

Mickybadia: v1.9.0

{{forum|83|ATC-Pie support & development}}

This article is a guide to the air traffic control simulation program [[ATC-pie]], describing some of its major features. A more exhaustive list can be found in the main article. For download and installation help, refer to the [[ATC-pie installation guide]]. For support and troubleshooting, the [[ATC-pie FAQ]] might get you an answer first. Otherwise kindly ask on the dedicated FlightGear sub-forum so that the discussion is public.

Other ways to learn the program are:
* to watch the online [https://www.youtube.com/playlist?list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb video tutorial];
* to read the in-app ''Quick reference'' available from the ''Help'' menu (summary of mouse/keyboard gestures, display conventions...);
* to connect with a skilled teacher as a student (personal training);
* to [[#Solo_sessions|train solo]]!

== Flight strips ==

Whether electronic (dematerialised) or on paper, printed automatically or filled by hand, the '''flight progress strip''' is the essential piece of air and ground traffic control. Every aircraft in contact is represented by a unique strip on the ATC workbench, and every strip represents a unique contact, present or expected. This ensures that no aircraft is ever forgotten about. Strip positioning and updating then enable to monitor the aircraft's status, sequence number, position, intentions, etc.

=== Strip details and linking ===
[[File:ATC-pie-screenshot-stripDetailSheet.png|thumbnail|The ATC-pie strip detail sheet]]
A click on the "new strip" tool bar button (shortcut {{key press|F2}}) or double-click on an empty strip rack or bay space will open a dialog to fill flight details on a fresh blank strip, e.g. callsign, type of aircraft, destination, etc. Double-clicking on an existing strip allows to edit the filled details.

If providing radar service, strips should be '''linked''' to identified contacts to inform the radar display with the filled details, e.g. assigned altitude, and enable joint selection. To link a strip to a radar contact, select one and middle-click on the other. Conflicts between strip details and the values squawked by the linked transponder will mark the strip with a "!!XPDR" warning.

A strip can also be linked to a filed flight plan (FPL). This will make radar and strip display fall back on filed information for missing details. The strip does not warn of mismatching information between the two because it is normal for the strip information to be updated as the flight progresses.

All together, a selection can therefore involve up to three linked elements: strip, radar contact, flight plan. From the strip menu at the bottom of any strip panel, you can pull details from linked elements (copy them to the selected strip), or push strip details to their linked flight plan if necessary. If you use linking carefully, auto-fill options are available from the general settings, to fill blank strip details with newly-linked information. Unlinking is possible with {{key press|Shift}}+middle-click.

For fast and efficient service, every initial contact by a pilot should basically make you hit {{key press|F2}} and type the spoken callsign. You should then soon figure out if:
* you already have a strip for that contact: a "!!dup" warning appears next to the input field;
* a flight plan is filed whose details can be linked immediately: a list of candidate FPL matches is displayed in the bottom row, which you can select from to link on dialog save;
* a flight plan must be filed, e.g. IFR departure not filed by lazy pilot: save the dialog and use the {{key press|Shift+F3}} shortcut to create a new FPL linked to the selected strip.

=== Strip placeholders ===
ATC-pie provides with three types of placeholders for flight strips: ''racks'', ''loose strip bays'' and ''runway boxes''. According to your ATC position and local facilities, you should choose and arrange your placeholders for optimal control. Strips can then be moved between them using mouse drag and drop.

[[File:ATC-pie-screenshot-stripRacks.png|thumbnail|Strip rack panel]]
A '''strip rack''' is the preferred way of keeping track of a sequence, e.g. a departure queue at a runway threshold. Rack panels can be created from the main window workspace, popped out as separate windows, and a persistent one can be found among the available docks. You can create as many racks as you wish in every panel. Double click on a rack's name to rename it or edit its properties. Use mouse drag to move strips up and down a rack sequence.

A '''loose strip bay''' allows free-hand positioning of strips in its reserved space. Such bays are useful for unsequenced traffic, or to map out relative positions when controlling without a radar. You may also import background images, e.g. a ground chart to keep visual track of taxiing aircraft and vehicles. See <code>CONFIG/bg/Notice</code> to learn how.

[[File:ATC-pie-screenshot-runwayReserved.png|thumbnail|Reserved runway marked in yellow]]
A '''runway box''' is a placeholder for a single strip, named after a physical runway and denoting a clearence to use it (enter, cross, land...). Runway boxes are contained in their own dock, with one made visible for each runway marked as in use in either direction. Thorough use of runway boxes will help you avoid bad mistakes like clear an aircraft to land over lined up traffic. When freed, runway boxes start and display a timer together with the wake turbulance category of the last contained strip to help with TKOF/LDG separation. What is more, if you use radar, a filled runway box marks the runway as ''reserved'' on the scope.

Besides, there are two other places a strip can be dropped on, usually when releasing a contact:
* an ATC callsign in the ATC panel to initiate a handover (or CPDLC transfer/instruction if {{key press|Alt}} is pressed);
* a '''strip shelf''' (flat button at the bottom of strip panels), which clears the strip from your workbench and stores it as shelved.

== Vectors, routes and separation ==

ATC-pie can register and analyse issued vectors and routes to:
* inform strip and radar display;
* help monitor traffic, checking tracked positions against route/vector assignments;
* help manage traffic, anticipating route and FL conflicts between controlled aircraft.

=== Vectors ===
[[File:ATC-pie-screenshot-courseAndAssignmentsGraphics.png|thumbnail|Course/vector drawing for linked radar contact]]
Registering vectors on strips enhances the drawing of linked radar contacts, enables easy monitoring of tracks and detection of aircraft flying off course. To register vectors automatically when a radar contact is linked to a strip, use the following mouse gestures:
* click and drag out of a radar contact to issue a heading vector;
* holding {{key press|Shift}}, click and drag vertically for altitude/FL vectors;
* holding {{key press|Shift}}, click and drag horizontally for speed instructions;
* holding {{key press|Shift}}, double-click on the radar target to clear registered vecors from the linked strip.

See [https://www.youtube.com/watch?v=BvA3MRlGJjU video 5] of the tutorial for more on vectoring, and check the quick reference ''display conventions'' to interpret the lines and colours of the course and vector graphics around radar contacts.

NB: In network sessions, an appropriate text chat instruction is suggested for every mouse vectoring action. This allows you to send it easily, for example to pilots whose communications are limited to text chat.

=== Routes ===
[[File:ATC-pie-screenshot-routeDetailsView.png|thumbnail|Route details dialog with world path drawn, available when both end airfields are recognised]]
A route is analysed for every strip with recognised departure and destination airports (entry fields both turned green), as follows:
* route tokens are whitespace-separated;
* each recognised navpoint token (radio navigation beacon, 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);
* if ambiguous (navpoint names are not all unique around the world), a waypoint is the nearest homonym to the point beginning the leg;
* other tokens are kept as route leg specifications to the following waypoint, e.g. airways between fixes.

[[File:ATC-pie-screenshot-routeDrawing.png|thumbnail|Assigned routes are drawn as dashed lines on the radar scope when linked to contacts]]
Routes on flight plans and strips are viewable in a route dialog, showing geodesic paths, headings and leg distances on a world map. When a specified route is linked to a radar contact, ATC-pie works out its current leg based on distance to destination, and:
* details of the current leg are displayed in the selection info pane, and the route viewing button enabled;
* the strip shows only the remainder of the route for this contact;
* the route to go is drawn as a dashed line on the radar (unless aircraft is inbound and near enough);
* the radar tag 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.

NB: If DEP and ARR airports are not both recognised, radar tags show the strip destination detail if it is filled, possibly with a heading if it is recognised.

See tutorial [https://www.youtube.com/watch?v=LfdukpBc90w video 7] for a demonstration of routes.

=== Conflicts and anticipation ===
[[File:ATC-pie-screenshot-routeConflictDetection.png|thumbnail|Route conflict depiction]]
ATC-pie 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 aircraft with a linked strip and an assigned route or heading. 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. When the projections of two aircraft intersect, a conflict is anticipated if the respective intervals between the current and assigned altitudes overlap. When an aircraft's altitude is unknown, the assigned altitude will be assumed. If an altitude assignment is missing, a ''possible'' conflict is reported.

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 || Thick bright red intersecting circles || Separation loss between aircraft
|-
| Path conflict || Red circles and paths || Anticipated paths and altitudes are intersecting
|-
| Possible path conflict || Yellow circles and paths || Paths intersecting but some altitudes unknown
|}

== Communications with aircraft ==

=== Voice radio ===
In solo sessions, radio interaction is simulated through speech recognition of instructions and read-back synthesis. Use the {{key press|Ctrl}} key to PTT.

In FlightGear and FSD network sessions, multiple radios can be opened and tuned in simultaneously. You can transmit on either one by holding down the PTT button of the chosen radio, or on a selected set (''Kbd PTT'' boxes ticked) using the {{key press|Ctrl}} key. This lets you PTT on multiple frequencies at once (merged frequencies), for example to service GND+TWR frequencies in view of splitting them seemlessly again later. To monitor frequencies without attending them, a trick is to set their volume to "soft" to tell them apart.

Note: Except for solo sessions, you may always use a separate voice communication program for radio. In this case, try making the same {{key press|Ctrl}} key the PTT to preserve other features such as RDF for receiving stations, or the ''PTT turns off notification sounds'' option recommended if not wearing a headset.

=== CPDLC ===
When [[CPDLC]] is serviced (location setting), aircraft can establish a data link from their cockpit for a direct text communication channel supplementing the radio frequency. You can monitor connections from the CPDLC dock and open a window for each active or terminated connection in the CPDLC history. Combining the {{key press|Alt}} key with a double-click on a strip or radar contact opens the current or latest dialogue for the selected callsign.

Each active CPDLC dialogue window allows to manually compose formatted or free text message elements. But the most frequent and convenient way of creating message elements is to combine the {{key press|Alt}} key with (also see ''Mouse gestures'' in the quick reference):
* a click-and-drag vectoring gesture to send a heading, altitude/FL or speed instruction (see [[#Vectors|section on vectors]]);
* a strip drop on an ATC to initiate a CPDLC authority transfer or to send the aircraft a "contact" instruction;
* an instruction panel "OK" button click to send the corresponding formatted instruction if applicable.

Created message elements are appended to the message buffer in the connection dialogue window until you send the message manually. The other party must then acknowledge it before it times out.

=== Radio text chat ===
Although voice communications should be encouraged for realism whenever possible, ATC-pie has a powerful text chat system for keyboard interaction with pilots in network sessions. In FlightGear sessions, all messages from within at least 100 NM and up to the radar range are visible in the chat. In FSD sessions, whose protocol simulates text frequencies, ATC-pie tunes the chat to the "publicised frequency" in the radio panel.

'''Text aliases''' are dollar-prefixed words that ATC-pie can replace with context-dependant values when sent. For example, <code>$metar</code> expands to the current primary station weather, which allows to send formatted messages like "Current weather is $metar" instead of copy-pasting a weather look-up for every such message. There is a list of predefined aliases, whose replacements depend on the environment, local configuration or current selection. All other aliases are expected to find their replacement in one of the following sources, checked in order (see ''Text aliases'' tab in quick reference for more information):
* general notepad (editable in any session, regardless of location);
* location notepad (saved for this airport or centre);
* strip comments (value applies to single aircraft contact).

Moreover, ATC-pie strips everything up to the first '''pipe character''' (<code>|</code>) in the message if any, before it is processed and sent. You may test this by sending "stripped part|sent part" and observe that only the "sent part" makes it to the message contents. You can therefore make your life easier with piped shortcuts in your preset message list. They will pop up like any other message in the filtered menu as you type. For example, the following preset message enables something like a dot-command for sending a bearing to your base airport in a few key strokes:
: <code>.qdm|Heading to airport $qdm</code>

Lastly, if a troll or angry user is polluting your session with undesired messages, add their callsign to the '''senders blacklist'''. All messages from the user will then be filtered out from the message pane. You can view and clear this list at any time.

== ATC coordination ==

"ATC coordination" refers to the following:
* strip exchange, i.e. sending and receiving strips (handovers);
* ATC phone lines, for private voice calls (except in solo sessions);
* CPDLC authority transfers;
* ''who-has'' requests, to query ATCs about who is claiming control of callsigns;
* ATC text chat, to exchange text messages with other ATCs (except in solo sessions).

=== Strip exchange ===
[[File:ATC-pie-screenshot-receivedStrip.png|thumbnail|Example of a strip received from "GND"]]
To hand a strip over, drag it and drop it on the recipient in the list of controllers in the ''ATC coordination'' dock. A received strip appears with an identification of the sender which disappears as soon as the strip is clicked on.

A received strip lands on the collecting rack set for the sender if any (double-click on a rack name to add an ATC callsign from which to collect strips), or on the "Default" rack otherwise. It may link automatically to an identified radar contact according to the selected auto-link options (general settings).

See [https://www.youtube.com/watch?v=oQIud-cAlT4 tutorial video 6] for a presentation of the feature.

=== ATC phone lines ===
Phone lines allow to call and talk to other ATCs directly from the ''ATC coordination'' dock. Each line has an outgoing state that you control, toggling between open and closed with a double-click on its phone icon. Opening a line places a call to the connected ATC, showing as "incoming" on their side. When two parties have their line open to one another, they are in direct communication (no push-to-talk). In other words, opening an incoming call puts you on the phone with the caller. Closing a call hangs up the active line, but you can pick it back up as long as the other party holds it open ("still incoming" for you).

You can only talk to one ATC at a time but may place multiple outgoing calls. If a call you placed is answered while you are in another call, the answered call switches to show as incoming without interrupting the one in progress. Conversely, opening (answering) an incoming call while already in another call drops the current line. An incoming call you answer which turns to "placed" (outgoing only) instead of "in progress" means that the other party is already on the phone and is now seeing an incoming call from you.

=== ATC text chat ===
The ATC text messaging system allows to chat with other ATCs in channels that are separate from the "radio text chat" read by pilots. It offers private channels for one-to-one conversations, and a general ATC chat room in network sessions, readable by all connected ATCs.

'''Note on interoperability in FG sessions''': While only ATC-pie integrates ATC text chat in its interface, other users can interact with a regular IRC client connected to <code>mpirc.flightgear.org</code>, with their FlightGear network callsign as IRC nickname, and joining the set IRC channel. They will be able to send and receive public and private messages and chat with everybody, at the only cost of ignoring the system messages that will sometimes appear on their side.

== Solo sessions ==

In solo sessions, you control virtual IFR planes, receiving and handing over strips to virtual ATCs depending on your position and the aircraft's intentions. You can train as an en-route controller in CTR mode, or as an airport controller in AD mode, where four combinable positions are available:
* ground (GND), to taxi aircraft between parking positions and runways;
* tower (TWR), to control runways and immediate surroundings;
* departure (DEP), to bring departing traffic to their exit point;
* approach (APP), to vector arrivals onto final.

=== Objectives ===
In '''CTR mode''', your task is to transit the aircraft across your airspace, always ensuring separation, and to hand each of them over to the most appropriate neighbouring centre North, South, East or West of your sector. You can specify local navpoints in the location settings so that the system includes them as turning points in the randomised aircraft routes.

In '''airport mode''', traffic is either inbound or outbound. Assuming APP, inbound aircraft must be sequenced and vectored into tower range for handover, unless you are in the TWR position as well. Each inbound aircraft either requests ILS or visual. Assuming TWR, you must clear them to land when appropriate, i.e. cleared for ILS approach or expected runway reported in sight. If landing cannot take place (too high, not cleared...), aircraft will go around. Controlling GND, you must move inbound traffic near their parking position once they have vacated the runway, and hand them over to the ramp. Outbound traffic must be brought to hold short of a runway threshold and report ready for departure with TWR. If you assume DEP, you must hand outbound aircraft over to the en-route centre (CTR) once they are high enough and close to their exit point if specified in their route. Entry and exit points are configurable in <code>CONFIG/nav/AD-entry-exit</code> (see <code>Notice</code> in the directory).

[[File:ATC-pie-screenshot-handoverPane-solo.png|thumbnail|Handover pane in an AD solo session, assuming all three available positions]]
{| class="wikitable" style="text-align:center"
|+ Handovers with virtual ATCs in airport mode
|-
| || colspan="2" | Departure strips || colspan="2" | Arrival strips
|-
! Assuming positions || Receive from || Hand over to || Receive from || Hand over to
|-
! GND only
| DEL || TWR || TWR || Ramp
|-
! TWR only
| GND || DEP || APP || GND
|-
! DEP only
| TWR || CTR || colspan="2" | N/A
|-
! APP only
| colspan="2" | N/A || CTR || TWR
|-
! TWR+GND
| DEL || DEP || APP || Ramp
|-
! TWR+DEP
| GND || CTR || APP || GND
|-
! TWR+APP
| GND || DEP || CTR || GND
|-
! APP+DEP
| TWR || CTR || CTR || TWR
|-
! TWR+GND+DEP
| DEL || CTR || APP || Ramp
|-
! TWR+GND+APP
| DEL || DEP || APP || Ramp
|-
! TWR+APP+DEP
| GND || CTR || CTR || GND
|-
! All 4
| DEL || CTR || CTR || Ramp
|}

=== Instructing aircraft ===
[[File:ATC-pie-screenshot-taxiInstructionTool.png|thumbnail|Click&drag taxi instruction tool at OMDB ground]]
Instructions are given through different means:
* provided the speech recognition modules are installed, you can turn on voice instructions from the solo simulation settings dialog and instruct aircraft through your microphone, using the {{key press|Ctrl}} key as push-to-talk and standard phraseology (see the quick reference tab about it);
* if voice instructions are turned off:
** mouse vector assignments issue the corresponding instructions (see section on vectors above);
** handoffs are issued when dropping strips on an ATC receiver;
* instruct taxi routes by dragging out of radar contacts when they are considered on the ground (low enough or squawking GND);
* the dockable instruction panel works regardless of voice vs. mouse selection;
* alternatively, if the aircraft is connected to CPDLC, you can send instructions through the [[#CPDLC|data link]].

Instructions from the panel are always issued to the callsign entered in the top field, which should fill automatically on aircraft or strip selection when a callsign is known. Therefore, make sure you do not mess up your strip links or your instructions will realistically be acknowledged and followed by the wrong aircraft.

=== Need a scenario? ===
Things you can train for:
* towering a single runway with mixed traffic: select TWR position and an equal balance of departures and arrivals;
* optimising approach spacing in dense traffic: select APP position only, increase traffic density, turn on spacing hints and try to stabilise them all at "3:00" for example;
* change of runways (e.g. irl after wind direction change): start with APP+TWR and select a runway for arrivals at least, run the simulation for a while and change for opposite runway use;
* CTR mode with a low ceiling to increase the number of conflicts to resolve;
* etc.

== Teacher & student connections (ATC tutoring) ==

This session type is made to bring an ATC student and a teacher together for tutorial sessions. To '''set up a session''', the student must connect to the teacher, so make sure the teacher's session is running first. Only one student can connect to a teacher at a time. The teacher creates and manipulates traffic for the student to work with, controls the weather and decides on the ATC neighbours. Strip exchange and ATC text chat is possible, either between both parties ("offline" exchanges) or between the student and the virtual ATCs (in-sim coordination). All exchanges are monitored by the teacher, and transparent to the student. The teacher can also snapshot traffic position situations to recall them later.

In '''teacher sessions''':
* The teaching console is enabled, which allows you to control most aspects of the environment visible to the student.
* You create new traffic holding {{key press|Shift}} down with a right click-and-drag on the radar specifying the position and face heading. A dialog pops up and allows you to choose a callsign (one is initially generated), altitude and other details. If near a ground route node, a parking position or runway, you can create it on the ground, ready to taxi or for departure (NB: parking overrides position/heading input).
* Traffic is initially created in an "unspawned" state (radar contact marked "+"), in other words visible to you but not to the student. This allows you to set its transponder or get it into a certain state before spawning it into the student's world.
* Controlling the traffic is done in the same way as in solo sessions without voice, i.e. using the click&drag vector and taxi tools and the instruction dock. The only difference is that you control the selected aircraft directly, regardless of your strip links and details. You therefore do not need a strip and a correctly filled callsign to instruct a pilot, though it is a good idea to have one if you want your vectors registered and drawn on the radar. The traffic creation dialog offers to create a linked strip with every new aircraft.
* You may pause the whole simulation, or freeze each aircraft individually. Frozen aircraft will result in stationary flights on the student's radar.
* The ATC text messaging system allows to simulate ATC conversations with the student (select callsign to interact as), or interact with the student directly as the teacher.
* To exchange strips, drop them on "Student" and select whom the strip should appear from on the student's side. Note that for your convenience in further control of the traffic, teacher strips do not disappear on handovers;
* CPDLC is supported, the dialogue windows reflecting the change of perspective (ACFT instead of ATC) and the {{key press|Alt}} key combinations generating requests rather than instructions.

[[Category:ATC-pie]]

ATC-pie installation guide

2025-03-16T20:13:27Z

Mickybadia: v1.9.0

{{forum|83|ATC-Pie support & development}}

{{about|installing and configuring ATC-pie|a manual on how to use it|ATC-pie user guide}}

== Installing ==

[[ATC-pie]] is free and open source, and programmed in Python for Qt5. It is therefore system-independant, but requires Python and its PyQt5 library to run. Otherwise, ATC-pie runs straight after download without any compiling (make, etc.) to do.

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.

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 Git '''repository''':
: <code>git clone git://git.code.sf.net/p/atc-pie/code ATC-pie</code>

I say again: the download/clone alone is not enough; both Python and PyQt5 must be installed too. The exact dependencies and required versions are listed in the <code>README</code> file packed in the download.

At this point you have a working program. But further software pieces can be installed to enable more of its features, as listed below. Depending on your use of ATC-pie, they can be recommended for more realism but they are not required, and can be installed later. Also read the <code>README</code> file for extra notes on installation.

To enhance:
* all airport sessions with a 3D '''tower view''', ''[[FlightGear]]'' must be available, with the appropriate aircraft models and scenery data—note that it can run on a separate machine, as explained [[#Airport scene rendering|down this article]];
* solo sessions with '''voice instruction recognition''' by the AI aircraft, install ''PocketSphinx'' (requires ''PyAudio'');
* solo sessions with '''speech synthesis''' of AI pilots' radio messages, install ''pyttsx'';
* FlightGear sessions with '''full ATC coordination''', including unlimited strip exchange (recommended!) and '''[[CPDLC]]''', install the ''Python IRC library'';
* FlightGear and FSD sessions with realistic '''voice radio simulation''', install the ''FGCom-Mumble'' plugin (requires a ''Mumble''>=1.4 client)—alternatively for FlightGear sessions, the historic executable FGCom variant is supported;
* all sessions (except solo) with an '''ATC phone line switchboard''', install ''PyAudio'' (for FlightGear and FSD, ''PyMumble'' is also required).

== Running ==

Depending on your system and preference, you might be double-clicking, typing stuff or pulling your hair out. In any case what you must do is run a Python interpreter on the <code>ATC-pie.py</code> file from the downloaded directory.

Tip for Windows users: create a shortcut whose "target" is <code>cmd /k Z:\path-to-pie\ATC-pie.py</code>, making sure "start in" is set to the same <code>Z:\path-to-pie</code> and that <code>.py</code> files are associated with Python.

=== Two program modes ===
[[File:ATC-pie-screenshot-launcherDialog.png|thumbnail|Initial graphical launcher, with AD vs. CTR mode choice]]
On program start, a welcome launcher window should open, from which you may start a session in either airport (AD) or centre (CTR) mode, i.e. respectively with or without a base airfield.

The '''airport mode''' is for ATC positions like approach or tower control, or any combination of those. In this mode, ATC-pie centres the radar at the chosen base airfield, depicts its tarmac and runways, and enables features like a tower view and active runway selection.

The '''centre mode''' is designed for en-route control centre simulation. It disables all airport-specific features, and allows to place the radar anywhere on Earth. When selecting this mode:
* The location code is a designator of your choice (excluding airport codes), under which to save your location-specific settings. A good idea is to use ICAO airspace designations, e.g. <code>SBBS</code> for the Brasilia FIR in central Brazil or <code>LFFF</code> for the Paris region in France.
* The radar position field specifies the point on which to centre the radar. For example, <code>LFPO>090,15</code> will centre the radar on a point 15 NM to the East of Orly airport. Click on the help button for a summary of valid point specification formats, or read the ''Point specification'' section in the quick reference for more detail.

=== Command line arguments ===
You may bypass the launcher and start directly at a given location with the following command, using an ICAO code for an airport or a previously defined CTR location code:
: <code>./ATC-pie.py location_code</code>

Besides, the following command line options are available:
{| class="wikitable"
! Option || Effect and argument specification || Default
|-
| --map-range=''range'' || Only valid with a location code argument. Defines the distance in NM from the radar centre up to which the map will be drawn and navpoints listed in the navigator (accepted values are 20..500). This does not affect radar range, which can still be greater or lower, and be changed within sessions.' || 100 in AD mode; 300 in CTR mode
|-
| --views-send-from=''port'' || Sets the local UDP port number to bind for sending FGMS packets to FlightGear viewers. This includes tower and additional viewers, but does not affect the FGMS connection port, chosen on session start. || 5009
|}

=== Starting sessions ===
All session types are started from the ''System'' menu.

Solo simulation:
* wind will be randomised at start, but will be forced to blow in a favourable direction if at least one active runway is selected before start;
* traffic is spawned with intentions according to the ''solo simulation configuration options'' ({{key press|Shift|F11}}), so it is preferable to configure them before starting the session to avoid undesired traffic at start.

FlightGear network session:
* callsigns for ATCs in FlightGear are expected to start with the ICAO code of the controlled airport or sector, and end with a hint on the provided service (twr, gnd, ctr...), e.g. "KORDgnd" (note that FGMS restricts callsign length to 7 characters);
* before choosing your callsign, make sure it is not already in use;
* you can connect multiple ATC-pie instances from the same computer, but you must use a different local port for each one;
* the three "sub-systems" that can be activated support different coordination features and differ in terms of interoperability with other clients, but all can be enabled together:
** '''native ATC-pie coordination''' enables full interaction with other ATC-pie clients (except phone lines), plus CPDLC with FG aircraft;
** '''ATC phone lines''' enables direct voice communications (telephone calls) with other connected ATC-pie clients;
** '''OpenRadar handover compatibility''' implements [[OpenRadar]]'s protocol to enable coordination with its users (will work with ATC-pie clients as a fallback if native sub-system not available), although some limitations apply (see [[ATC-pie#OpenRadar|interoperability note]] in the main article).

== Configuring ==

Here are things you will soon need or want to set up for a regular use of ATC-pie:
* set up a [[#Airport scene rendering|tower view]] to enable visual contact with your traffic in AD sessions;
* for FlightGear and FSD sessions, give yourself a "social name" so that others recognise you when using any of the ATC coordination/exchange features;
* for a realistic radio experience in FlightGear and FSD sessions, set up FGCom-mumble.

If you intend to operate often at a given location, it is sensible to:
* if it is an airfield location, download the latest airport data file from the [https://gateway.x-plane.com/airports/page# X-plane gateway] and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> file there);
* review and fill the various fields in the location set-up dialog (runway capabilities deserve special focus for more realisitc aircraft intentions in AD solo sessions);
* configure the workspace racks, bays and radar screens to suit the environment and service provided (they will be saved for future runs at the same location);
* if using the radar, pin your preferred navpoints (they are restored on every run at the same location) and consider creating/importing background pictures to map terrain obstacles, procedure charts, etc. (see [[#Background images|section below]]);
* for solo and teacher sessions at airports especially, build an elevation map (see <code>CONFIG/elev/Notice</code>).

For more advanced editable options, read the <code>CONFIG/Notice</code> file.

=== Airport scene rendering ===
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
A '''tower view''' allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any (X-plane seems only to allow one, but feel free to declare more for ATC-pie), otherwise defaults to somewhere over the airport to allow towering everywhere. It is disabled in CTR mode.
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 to listen for traffic and accept telnet connections.

Running internally only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the ''System'' settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].

Connecting to an external viewer allows to run FlightGear on a different machine and thereby relieve your session from the CPU load a local instance induces. If you want to do so, get a hint of the required positioning options you should start your viewer with, from the tower view tab in the system settings dialog. Of course, scenery, models and liveries must also be available to the running process.

In either case, once activated from the ''System'' menu, the tower view '''control pane''' is enabled, from which you can turn to runway points, follow selected aircraft... Direct FlightGear input in the view window is also possible: right click and drag allows to look around, {{key press|x}} and {{key press|Shift|x}} change the zoom level, etc.

You can hook up '''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 the connections individually from the ''System'' menu. Additional viewers are registered by their host+port address, from the same dialog.

Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
* ''HHH'' is the host on which ATC-pie is running;
* ''PPP'' is the default 5009, or the chosen port number if ATC-pie was started with <code>--views-send-from</code>;
* ''TTT'' is the network polling frequency (100 is common practice; change as desired if you know what you are doing).

=== Background images ===
[[File:ATC-pie-screenshot-backgroundPixmapDrawing.png|thumbnail|Pixmap image example with a terrain map around LIMW (Aosta, Italy)]]
[[File:ATC-pie-screenshot-backgroundHandDrawing.png|thumbnail|Text-specified drawing example with procedures for LSGG (Geneva, Switzerland)]]
Background images allow to decorate:
* radar scopes, e.g. to display procedure routes or airspace boundaries;
* loose strip bays, to work the strips over custom backgrounds, e.g. an airport ground chart.

There are two ways to create a background. One is to '''import a picture''' (pixmap file like JPEG or PNG, including transparency); the other consists in writing a '''drawing specification''' file to paint coloured lines, points and text labels (for radar backgrounds only). See <code>CONFIG/bg/Notice</code> to learn how to import and draw background images.

For example, you can map out procedures (SID, STAR, IAD...), grouping them by associated runways so they toggle together on the radar. Drawings are generally appropriate for that because they avoid manual positioning by directly referring to the points named in the published procedures. But if you want more than schematic line plots and text labels, you should create the picture yourself, for example using an image processing tool like ''GIMP'' and a transparent layer over a real map canvas or a screenshot of your ATC-pie radar with pinned navaids as landmarks.

'''If you have a sector file''' of the format used in VATSIM/IVAO (.sct) for your area, you should try to import it with the provided extraction tool. It will retrieve most of the contents around the open location up to the current map range, and translate it to ATC-pie's native drawing format, although the generated files always require some filtering and post-editing. If you know they are included, it is generally the best option for things like SID/STAR procedures. The way to proceed is as follows:
# Run the "extract drawings from sector file" option (''System'' menu) and select the file to extract from. This generates the following files in the <code>OUTPUT</code> directory:
#* <code>ICAO.lst.extract</code>, a menu file for the generated drawings;
#* <code>bg-ICAO-*</code>, the extracted drawings in the native ATC-pie format;
#* <code>bg-extract.err</code>, a log of the errors detected in your sector file (do not be alarmed as they often contain many).
# Import the results:
#* move or copy-paste lines from <code>ICAO.lst.extract</code> to <code>CONFIG/bg/ICAO.lst</code>;
#* move the desired drawing files under <code>CONFIG/bg</code>, adjusting the paths in the <code>.lst</code> menu as you organise subdirectories.
# Post-editing (cleaning)
#: ATC-pie does its best to understand the objects in the sector file and to group things together depending on their type. But not everything can be guessed automatically. This last step is where you filter, merge and split objects, rename points, change colours, etc. to your liking.
#: Each generated drawing section (point list under a colour) is automatically labelled with the line number where it was sourced from in the sector file so you can easily trace it (<code>@nnn</code>). A tool like ''sed'' will help you get rid of all these unwanted suffixes once you have sorted and renamed your objects:
#:: <code>sed -ri 's/ +@[0-9]+$//' file_to_clean</code>

NB: ATC-pie does not package or source from sector files directly because their data is not free. Besides, a lot of it is usually redundant with the airport sources.

Tips:
* You can check your image configuration without restarting the program, by reloading the files in their current state from the ''System'' menu ({{key press|Alt|F12}}).
* The "image positioning helper" allows to move and resize imported pictures, adjusting the corners visually rather than programmatically if you have no specification for them. All visible pixmap images will be moved simultaneously, so you can work with several at a time if you want to. On dialog box close, a file is generated in the <code>OUTPUT</code> directory for you to copy from.
* An [[OpenStreetMap]] option will take you to the free online map server, centred on your radar centre position. For a quick and dirty start (e.g. for access to coastlines, borders and rivers) you can screenshot the map and use it as a background.

[[Category:ATC-pie]]

ATC-pie

2025-03-16T20:08:30Z

Mickybadia: v1.9.0

{{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
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.9.0 (March 16, 2025)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''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);
* "multi-player" network sessions (FlightGear and FSD protocols supported);
* tutorial sessions for teacher supervision of an ATC student.

It is designed to support a maximum range of ATC situations, and will allow any world location for every session type above. All control positions are possible, whether airport-based (TWR, APP, GND...) or en-route (CTR). Equipment can be set up to include radar screens, data link, etc. or be limited to binoculars and a view of the airfield.

Its essential goal is realism. It simulates many tasks of real-life ATC such as:
* strip racks and sequence management;
* coordination with neighbouring controllers (phone calls, handovers...);
* radar monitoring for traffic identification and sequencing;
* vectoring and course/level conflict anticipation;
* flight plan operations;
* CPDLC...

== Screenshots ==

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Solo session with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

== Sessions and environments ==

ATC-pie features five session/connection types, all of which support both ''airport'' and ''centre'' location modes.

Session types:
* solo simulation (AI traffic)
* FlightGear network connection ([[FGMS]] protocol)
* 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)

Location modes:
* airport (AD): positions such as TWR, GND, APP, DEP at a selected airfield
* en-route centre (CTR): free positioning of radar, no base airport or TKOF/LDG-related options

{| class="wikitable" style="text-align:center"
|+ Feature support by session type
! || Solo || FlightGear || FSD || Tutoring (teacher/student)
|-
! ACFT traffic
| AI aircraft generated according to RWY capacities, ACFT equipment, intentions...
| colspan="2" | connected flight sim pilots
| created and simulated by teacher
|-
! 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
|-
! Voice radio
| voice recognition for instructions (mouse-only also available) and synthesis for pilot read-back
| colspan="2" | [[FGCom-mumble]] integration
| teacher simulates pilots
|-
! ATC phone lines
| N/A
| colspan="2" | integrated Mumble connection
| teacher simulates ATCs
|-
! 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
|-
! CPDLC
| interpreted subset of instruction messages
| integrated (supported by MP IRC)
| integrated interface with [https://www.hoppie.nl/acars/ Hoppie's ACARS network]
| full simulation by teacher (with WILCO assistance to execute instructions)
|-
! Weather
| randomised and evolving
| real world METAR retrieval
| fetch from server or retrieve real world METAR
| controlled by teacher
|-
! Other specific features
| style="text-align:left" |
* 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.)
* historic [[FGCom_3.0|FGCom executable]] alternative supported
| 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
|}

== Detailed feature list ==

=== ATC surveillance ===
Radars and tracking:
* SSR mode capability selection (none/A/C/S)
* primary radar toggle
* 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
* 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)

Other:
* radio direction finding (RDF) and integration to radar
* multiple weather (METAR) station monitor
* [[ATIS]] recording and reminder alarm (see [[:File:ATC-pie-screenshot-ATISdialog.png|dialog]] with pre-filled notepad)

=== 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
* departure clearance assistant
* automatic strip printing for expected departures or arrivals (from FPLs)

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

=== Communications ===
With aircraft:
* voice radio with 8.33 kHz frequency spacing, multiple radio transmissions and monitoring
* [[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

ATC coordination:
* 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

=== 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
* list of known ACFT types by callsign

GUI:
* multiple window workspace (radar screens, strip racks and bays) saved by location
* 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

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

== 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:
* OpenRadar to ATC-pie: FGMS callsign will appear on the strip, as if the sender had filled the detail herself;
* 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 through OpenRadar's service: strip detail preserved, whether present or absent.

Features not supported by OpenRadar:
* ATC phone lines;
* ATC text messaging;
* CPDLC transfers;
* wake turbulance category and departure clearances on strips (but details preserved for ATC-pie clients later receiving the strip).

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. 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:Air Traffic Control]]

ATC-pie

2023-04-02T08:27:19Z

Mickybadia: v1.8.8

{{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
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.8.8 (April 1, 2023)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''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);
* "multi-player" network sessions (FlightGear and FSD protocols supported);
* tutorial sessions for teacher supervision of an ATC student.

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.

Its essential goal is realism. It simulates many tasks of real-life ATC such as:
* strip racks and sequence management;
* coordination with neighbouring controllers (handovers, voice phone calls...);
* radar monitoring and identification of traffic;
* vectoring and course/level conflict anticipation;
* flight plan operations;
* CPDLC...

== Screenshots ==

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Solo session with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

== Detailed feature list ==

=== Sessions and environments ===
Session/connection types:
* solo simulation (AI traffic)
* FlightGear network connection ([[FGMS]] protocol)
* 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)

Location modes (available for all sessions):
* airport (AD): positions such as TWR, GND, APP, DEP at a selected airfield
* en-route centre (CTR): free positioning of radar, no base airport or runway-related options

{| class="wikitable" style="text-align:center"
|+ Feature support by session type
! || Solo || FlightGear || FSD || Tutoring (teacher/student)
|-
! ACFT traffic
| AI aircraft generated according to RWY capacities, ACFT equipment, intentions...
| colspan="2" | connected flight sim pilots
| created and simulated by teacher
|-
! 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
|-
! Voice radio
| voice recognition for instructions (mouse-only also available) and synthesis for pilot read-back
| colspan="2" | [[FGCom-mumble]] integration
| teacher simulates pilots
|-
! ATC phone lines
| N/A
| colspan="2" | integrated Mumble connection
| teacher simulates ATCs
|-
! 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
|-
! CPDLC
| interpreted subset of instruction messages
| integrated (supported by MP IRC)
| integrated interface with [https://www.hoppie.nl/acars/ Hoppie's ACARS network]
| full simulation by teacher (with WILCO assistance to execute instructions)
|-
! Weather
| randomised and evolving
| real world METAR retrieval
| fetch from server or retrieve real world METAR
| controlled by teacher
|-
! Other specific features
| style="text-align:left" |
* 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
|}

=== ATC surveillance ===
Radars and tracking:
* SSR mode capability selection (none/A/C/S)
* primary radar toggle
* 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
* 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)

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
* departure clearance assistant
* automatic strip printing for expected departures or arrivals (from FPLs)

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

=== Communications ===
With aircraft:
* voice radio with 8.33 kHz frequency spacing, multiple radio transmissions and monitoring
* [[ATIS]] recording and reminder alarm (see [[:File:ATC-pie-screenshot-ATISdialog.png|dialog]] with pre-filled notepad)
* [[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

ATC coordination:
* 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

=== 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 [[: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

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

== 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:
* OpenRadar to ATC-pie: FGMS callsign will appear on the strip, as if the sender had filled the detail herself;
* 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 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 clients later receiving the strip);
* ATC text messaging;
* ATC phone lines;
* CPDLC transfers.

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. 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:Air Traffic Control]]

ATC-pie FAQ

2023-01-31T15:46:08Z

Mickybadia: v1.8.7

{{forum|83|ATC-Pie support & development}}

This page is a collection of questions asked at least twice about [[ATC-pie]]. It is a good idea to search through it before repeating a question on the forum or anywhere.

== Things "not working" ==

=== This aircraft is connected but I am not seeing it on my radar. ===
As in real life, the main radar technology is [http://en.wikipedia.org/wiki/Secondary_surveillance_radar SSR], which only shows what is picked up from on-board transponders in its range. It coexists with primary radar, which detects aircraft regardless of transponders but offers no information other than position (angle and distance), i.e. neither of callsign, altitude, type, IAS, etc.

The following cases will therefore prevent you from seeing a connected aircraft:
* The radars are turned off. Turn on at least a primary radar from the ''Options'' menu, or an SSR capability from the ''Radar'' tab in the ''Local settings'' dialog. Any SSR setting other than "none" will pick up contacts.
* The aircraft is out of radar range, either too far out or under the radar floor. Check the horizontal range and floor settings ("SFC" will pick up all signals down to the ground). Primary and secondary radars share the same range.
* Its onboard transponder is turned off (and primary radar is off); see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Otherwise if you accept cheating, you can activate the "radar cheat mode" which will simulate a mode S transponder for all aircraft in horizontal range; see [https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3].

=== The aircraft vectoring tool does not come up when I click and drag out of radar contacts. ===
Your radar contact is not linked. Link it to a strip to enable registering the mouse-issued vectors. Radar and strip displays will then be informed according to the current options, e.g. altitude reaching point, unfollowed vector warnings, etc.

=== FGCom is not working. ===
First, note that there are two variants of FGCom: the standard FGCom-mumble plug-in available in FlightGear and FSD sessions, and the legacy (deprecated) alternate available in FlightGear sessions only. They are ''not'' interoperable: users can only hear and interact with others using the same variant and server.

'''FGCom-mumble''' is a plug-in that must be run with an external ''Mumble'' client (minimum version 1.4.0 to support plugins) connected to a chosen server. See the project [https://github.com/hbeni/fgcom-mumble/releases release] and wiki pages to download and install it. The control port in ATC-pie must be set to the one FGCom-mumble is listening on. To troubleshoot:
* open a single ATC-pie instance;
* check that your sound is on, your volume loud and your system picking up a signal from your microphone;
* start an FGCom-mumble configuration test from the system tools menu;
* speak in the microphone while the echo test is running.

For the FlightGear '''standalone''' variant (selectable in the ''system settings''), the FGCom command in the system settings should be a valid command or path to an FGCom executable file. If you have FlightGear installed on your machine, you can point to the FGCom executable already available with it. On Linux, the default "fgcom" command usually does the job. Otherwise, get one from ATC-pie's [https://sourceforge.net/projects/atc-pie/files/fgcom-standalone/ SourceForge file list]. Try the entry from a terminal in the ATC-pie directory to manually check that it runs correctly, and try the echo test available from the settings box. Other things you might check if you really do not want to switch to FGCom-mumble:
* server status: check for responses from the chosen server, e.g. with <code>ping</code>;
* subprocess error: after turning a first radio on, check the FGCom error logs in the <code>OUTPUT</code> directory;
* port mess-up: make sure you choose an unused port number for each created radio at run time.

=== Tower view is not starting. ===
Ruling out that FlightGear is not installed at all, your system path settings are probably wrong. From a terminal or a file system navigator, find the right command to start FlightGear and enter it as ''FlightGear executable'' from the system settings. Do not add options here; they will be taken care of internally. You may have to enter a ''FlightGear root directory'' as well, especially if you have the program files installed somewhere unexpected.

=== My tower is in the middle of the sea, and aircraft floating/landing on water! ===
You are missing the FlightGear scenery data for your location, or ATC-pie does not know where it is. If you have downloaded scenery and saved it somewhere, have you tried filling the scenery directory with that location in the system settings? Also read the [[ATC-pie_installation_guide#Airport scene rendering|related section]] in the installation guide.

=== Simulated aircraft dip underground or levitate over taxiways. ===
Do you have a ground elevation map for the location? Quoting from <code>CONFIG/elev/Notice</code>: "''When no elevation map is found for an airport, the field elevation value is used everywhere on the ground. This should be OK for a rough approximation on flat terrain, but ground traffic will not follow any slopes, thus may appear as floating above the ground, or dipping into it.''" Read the full notice for instructions on how to build your elevation map.

Once you have an elevation map, the next focus is on the FlightGear aircraft models. Because each model has its own coordinate system chosen at developer's discretion, ATC-pie must be given the height difference between each model's origin and the aircraft touch-down point (gear wheels) to position aircraft more accurately. You do this on a per-model basis with ":height" specifications in <code>CONFIG/acft/icao2fgfs</code>. Read the associated <code>Notice</code> section for more information.

=== Phone lines have broken, choppy or dragged out sound ===
You and the other parties must adjust microphone sensitivity. Toggle the phone squelch adjustment box from the system menu and tune the spinbox next to the "call" button in the ATC coordination panel. Lower values will decrease the threshold for sound pick-up and likely break the sound less, but can generate more lag in the communications. The right balance depends on your local configuration, so a few test calls with other connected ATCs will be necessary to decide on the best acceptable value.

=== I cannot connect to my teacher as a student. ===
Using IPv4 addresses, this typically happens when the teacher is in a local area network behind a router. It is a common setup for home internet, in which the teacher's actual host address is not publicly accessible from outside his private network.

If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either:
* for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local host address;
* or to create a virtual network, using a third-party VPN service.

== What is ...? Why is ...? What value/setting for ...? ==

=== What "social name" should I use for FlightGear/FSD sessions? ===
Choose any name you would like to be recognised by on the network. In ATC-pie, it will appear in the tool tip over your callsign for connected ATCs who see you. This feature is only social in the sense that it does not refer to an account or to anything technical, but it makes sense as typical ATC callsigns (e.g. "VHHHtwr") remain mostly anonymous. Use this field to identify yourself on the network.

=== What is the purpose of the flat "strip shelf" button in the strip panes? ===
More than a button, the strip shelf is where you should drop the contacts you release without a handover, e.g. parked traffic shutting down, VFR traffic flying out of your airspace, etc. Clicking on the shelf allows to browse the previously shelved strips, and to recall them, for example if shelved inadvertently.

=== What is "radio direction finding"? ===
RDF is a system that detects the horizontal direction of radio sources when signals are received. Its most common uses are:
* to locate ACFT making new radio contacts on their first transmissions;
* to give bearings to the airport to disoriented VFR pilots.

Setting up your location as equipped with RDF will essentially provide two things:
* a status bar indication of the form "hdg/qdm" in the main window, where "hdg" is the heading of the currently detected radio signal (direction to source, or "---" if none), and "qdm" the opposite heading of the last received signal (bearing from source, displayed until the next signal is received);
* the option to draw a line on radar scopes when a signal is received, making it easy to visualise the transmitting ACFT as the line should hit its target.

=== Are the vector headings true or magnetic? ===
Heading displays in ATC-pie are mostly magnetic so they can be read out to pilots. The exceptions are the navigator and handover list tool tips, which show true radial headings from the radar position, and the teacher's wind section to match the generated ATIS string.

Also note: all directions are geodesic, i.e. initial headings to take on a great circle.

=== How do approach spacing hints work? ===
When the option is turned on, an approach spacing hint will show on every strip verifying the following conditions:
* it is racked in sequence behind another marked with the same (recognised) destination;
* both are linked to an airborne aircraft with a known ground speed;
* the time hint value (see below) does not exceed 30 minutes.

The hint value for a strip is an estimated time difference between the linked aircraft touchdown and that of the traffic ahead, assuming:
* both present ground speeds;
* for the leading aircraft, a straight path to destination;
* for the tailing aircraft, a path straight to the leading one first, then straight to destination.

Caution, some judgement is required depending on the aircraft positions, because the actual paths to expect can vary from those above. For example, the interpretation of the hint should be different whether both aircraft are aligned with the runway or coming from opposite directions. But with some practice, the rate of the changes still help to optimise spacing when the displayed values don't.

=== What do the various markings along the approach centre line mean? ===
The regularly spaced groups along a centre line represent altitudes on the approach plane. Each group sums up to an AMSL value in accordance with the set flight path angle (also see ''Display conventions'' in the quick reference):
* straight line = 1,000 ft;
* solid diamond = 5,000 ft.

The other markers drawn with thicker lines are the positions of the ILS marker beacons (OM, MM, IM), the line pattern representing the sound triggered by the beacon in the pilot's headset. They are sourced on program start-up from the navigation data (<code>CONFIG/nav/navaid.dat</code>).

=== Why do I keep getting runway incursion alarms? ===
Because you have the runway occupation monitor turned on (''Options'' menu), while not using your runway boxes. The alarm triggers when the radar detects traffic stepping on a runway in either of the following situations:
* the runway is active (marked in use) and no strip is boxed for it;
* it is reserved but there is already traffic on the runway;
* it is reserved for a different aircraft: the boxed strip is linked to a contact that is not the entering aircraft, or the aircraft is linked to a strip different to the one boxed.

Turning the runway occupation monitor off will deactivate all radar warnings regarding runways. If you are interested in the strip boxing and visual runway highlighting system but bothered by the alarm sound, you can mute the sound notification by unticking it in the general settings.

== Where is ...? How to ...? ==

=== Can I draw SID and STAR procedures on the radar? ===
Yes, and virtually anything else, using background images. To learn about those:
* see the corresponding [[ATC-pie_installation_guide#Background images|installation guide section]];
* read the <code>CONFIG/bg/Notice</code> file.

=== How do I assign SIDs and STARs to aircraft? ===
This question is asked quite a lot more than it is relevant to a real controller's task...

What people seem to be after when asking this question is a way to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. The way to handle this is to stack your inbound strips on racks named after your STARs. Racks are indeed above all meant for efficient traffic sequencing. Every rack represents its own sequence of ordered aircraft, which is perfectly suited to control separate approach paths in parallel. With this technique, placing a strip on a STAR-named rack basically serves as the "assignment" itself. Similarly, runway-specific racks can keep track of separate landing sequences at large airports. Then you can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times in the sequence all the way to touchdown.

If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. Routes are lists of waypoints and instructions to follow between the two end airfields. Normally pulled straight from properly filed flight plans, routes are printed on strips prior to departure, then modified as the flights progress and passed along with handovers. Standard departure and arrival procedures (SIDs and STARs) can be referred to in those routes, but only by their entry or exit navpoints. They should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. For example, routes ending with a STAR should end with "FUBAR STAR", which means that waypoint FUBAR is an entry point from which a published STAR must be followed. The keyword "STAR" is in fact a mere specification for the last route leg. Similarly, routes of the form "SID DUMMY ..." specify their first leg as a standard departure to the first waypoint DUMMY. "SID" and "STAR" keywords are recognised by ATC-pie and accounted for in the second line of the radar tag when appropriate (see feature note on routes).

One meaningful wish regarding this question is for easy '''reference in text chat''' messages. Firstly, using racks in the way suggested above, you can use the <code>$rack</code> alias which is substituted by the name of the rack on which the current strip selection is stacked. Otherwise, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". Now if you specifically want to assign a full procedure name like FUBAR1A to a contact and refer to it in a generic text chat message, include a line "sid=FUBAR1A" 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 expanded in your sent messages when that strip is selected.

=== How to set the transition level? ===
You do not. You can however set the transition altitude in the location settings if your airport specification file does not already include one.

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, e.g. for more vertical separation on either side of the transition layer or due to coordination with neighbouring zones and fields.

=== Can I look up ILS frequencies? ===
Yes, in the ''environment info'' dialog.

Besides, you can create aliases with the local notepad for a quick and integrated way of sending them through text chat, which will be saved when you close ATC-pie. For example, use the following format, one runway per line: <code>ils05=111.11 MHz</code>. See [[ATC-pie_user_guide#Public text chat|custom text aliases]] for more.

=== The airport/navigation data is outdated. How can I update it? ===

The included '''airport data''' (taxiways, parking positions, frequencies, etc.) is the latest but outdated world-wide <code>apt.dat</code> file compiled by ''X-plane'' ages ago. We keep it there because it allows to run ATC-pie anywhere in the world without requiring external data, but for any serious work at a specific airfield, you should provide the latest source available on the [http://gateway.x-plane.com/airports/page X-plane airport gateway], directly accessible from the ''System'' menu. Extract the <code>apt.dat</code> file from the downloaded package, rename it after the airport's ICAO code keeping the extension (e.g. <code>KJFK.dat</code>), and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> there). Alternatively, for a quick manual touch-up of the old data, you can use the locally extracted file (see <code>OUTPUT/Notice</code>).

The included '''navigation data''' (navaids, fixes, airways, etc.) is the latest GPL version seen for each relevant ''X-plane'' file, also all out of date today. You should provide more recent navigation data, as explained in <code>CONFIG/nav/Notice</code>.

=== How do I customise the GUI and colours? ===
To change the '''radar or strip drawing colours''', edit the <code>CONFIG/colours.conf</code> file. Each line specifies the paint colour for an object type, in a typical hex <code>RRGGBB</code> (red-green-blue) format or as an SVG colour keyword name like "white". To customise the '''main session window''', place a ''Qt stylesheet'' named <code>main-stylesheet.qss</code> in the <code>CONFIG</code> directory. ATC-pie will apply it to every session window. While you are working on your look and feel, use the reload feature from the "System" menu to avoid restarting after every change.

Send us screenshots and share your files if you find a setup looking really cool! :-)

== Miscellaneous ==

=== What's with the funny name? ===
ATC-pie is written in Python, and I reckoned that the ''pyXXX'' naming habit was becoming a little dull, so I merely switched things around. You can surely do the rest of the math in terms of spelling, and later impact on the logo.

=== Why is the learning curve so steep? People would use your program more if you did/provided [...] ===
Often continued with: '''(you must understand that) this is not VATSIM!'''

We do have a [https://sourceforge.net/p/atc-pie/wiki/Wishlist wish list] and will consider any feature or help request. However, though it has a few cheats, ATC-pie has always choosen realism as a criterion for implementation and design, over the mere incentive of converting otherwise happy users of other programs. It is a good thing that different philosophies and work flows are available out there, and there would be much less interest in having them all copy each other, fighting over users instead of understanding that not all of them wish for the same experience. If serious simulation or learning new skills sound like threats to fun for you, you have a perfectly valid reason not to opt for ATC-pie.

[[Category:ATC-pie]]

ATC-pie user guide

2023-01-31T15:44:34Z

Mickybadia: v1.8.7

{{forum|83|ATC-Pie support & development}}

This article is a guide to the air traffic control simulation program [[ATC-pie]], describing some of its major features. A more exhaustive list can be found in the main article. For download and installation help, refer to the [[ATC-pie installation guide]]. For support and troubleshooting, the [[ATC-pie FAQ]] might get you an answer first. Otherwise kindly ask on the dedicated FlightGear sub-forum so that the discussion is public.

Other ways to learn the program are:
* to watch the online [https://www.youtube.com/playlist?list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb video tutorial];
* to read the in-app ''Quick reference'' available from the ''Help'' menu (summary of mouse/keyboard gestures, display conventions...);
* to connect with a skilled teacher as a student (personal training);
* to [[#Solo_sessions|train solo]]!

== Flight strips ==

Whether electronic (dematerialised) or on paper, printed automatically or filled by hand, the '''flight progress strip''' is the essential piece of air and ground traffic control. Every aircraft in contact is represented by a unique strip on the ATC workbench, and every strip represents a unique contact, present or expected. This ensures that no aircraft is ever forgotten about. Strip positioning and updating then enable to monitor the aircraft's status, sequence number, position, intentions, etc.

=== Strip details and linking ===
[[File:ATC-pie-screenshot-stripDetailSheet.png|thumbnail|The ATC-pie strip detail sheet]]
A click on the "new strip" tool bar button (shortcut {{key press|F2}}) or double-click on an empty strip rack or bay space will open a dialog to fill flight details on a fresh blank strip, e.g. callsign, type of aircraft, destination, etc. Double-clicking on an existing strip allows to edit the filled details.

If providing radar service, strips should be '''linked''' to identified contacts to inform the radar display with the filled details, e.g. assigned altitude, and enable joint selection. To link a strip to a radar contact, select one and middle-click on the other. Conflicts between strip details and the values squawked by the linked transponder will mark the strip with a "!!XPDR" warning.

A strip can also be linked to a filed flight plan (FPL). This will make radar and strip display fall back on filed information for missing details. The strip does not warn of mismatching information between the two because it is normal for the strip information to be updated as the flight progresses.

All together, a selection can therefore involve up to three linked elements: strip, radar contact, flight plan. From the strip menu at the bottom of any strip panel, you can pull details from linked elements (copy them to the selected strip), or push strip details to their linked flight plan if necessary. If you use linking carefully, auto-fill options are available from the general settings, to fill blank strip details with newly-linked information. Unlinking is possible with {{key press|Shift}}+middle-click.

For fast and efficient service, every initial contact by a pilot should basically make you hit {{key press|F2}} and type the spoken callsign. You should then soon figure out if:
* you already have a strip for that contact: a "!!dup" warning appears next to the input field;
* a flight plan is filed whose details can be linked immediately: a list of candidate FPL matches is displayed in the bottom row, which you can select from to link on dialog save;
* a flight plan must be filed, e.g. IFR departure not filed by lazy pilot: save the dialog and use the {{key press|Shift+F3}} shortcut to create a new FPL linked to the selected strip.

=== Strip placeholders ===
ATC-pie provides with three types of placeholders for flight strips: ''racks'', ''loose strip bays'' and ''runway boxes''. According to your ATC position and local facilities, you should choose and arrange your placeholders for optimal control. Strips can then be moved between them using mouse drag and drop.

[[File:ATC-pie-screenshot-stripRacks.png|thumbnail|Strip rack panel]]
A '''strip rack''' is the preferred way of keeping track of a sequence, e.g. a departure queue at a runway threshold. Rack panels can be created from the main window workspace, popped out as separate windows, and a persistent one can be found among the available docks. You can create as many racks as you wish in every panel. Double click on a rack's name to rename it or edit its properties. Use mouse drag to move strips up and down a rack sequence.

A '''loose strip bay''' allows free-hand positioning of strips in its reserved space. Such bays are useful for unsequenced traffic, or to map out relative positions when controlling without a radar. You may also import background images, e.g. a ground chart to keep visual track of taxiing aircraft and vehicles. See <code>CONFIG/bg/Notice</code> to learn how.

[[File:ATC-pie-screenshot-runwayReserved.png|thumbnail|Reserved runway marked in yellow]]
A '''runway box''' is a placeholder for a single strip, named after a physical runway and denoting a clearence to use it (enter, cross, land...). Runway boxes are contained in their own dock, with one made visible for each runway marked as in use in either direction. Thorough use of runway boxes will help you avoid bad mistakes like clear an aircraft to land over lined up traffic. When freed, runway boxes start and display a timer together with the wake turbulance category of the last contained strip to help with TKOF/LDG separation. What is more, if you use radar, a filled runway box marks the runway as ''reserved'' on the scope.

Besides, there are two other places a strip can be dropped on, usually when releasing a contact:
* an ATC callsign in the ATC panel to initiate a handover (or CPDLC transfer/instruction if {{key press|Alt}} is pressed);
* a '''strip shelf''' (flat button at the bottom of strip panels), which clears the strip from your workbench and stores it as shelved.

== Vectors, routes and separation ==

ATC-pie can register and analyse issued vectors and routes to:
* inform strip and radar display;
* help monitor traffic, checking tracked positions against route/vector assignments;
* help manage traffic, anticipating route and FL conflicts between controlled aircraft.

=== Vectors ===
[[File:ATC-pie-screenshot-courseAndAssignmentsGraphics.png|thumbnail|Course/vector drawing for linked radar contact]]
Registering vectors on strips enhances the drawing of linked radar contacts, enables easy monitoring of tracks and detection of aircraft flying off course. To register vectors automatically when a radar contact is linked to a strip, use the following mouse gestures:
* click and drag out of a radar contact to issue a heading vector;
* holding {{key press|Shift}}, click and drag vertically for altitude/FL vectors;
* holding {{key press|Shift}}, click and drag horizontally for speed instructions;
* holding {{key press|Shift}}, double-click on the radar target to clear registered vecors from the linked strip.

See [https://www.youtube.com/watch?v=BvA3MRlGJjU video 5] of the tutorial for more on vectoring, and check the quick reference ''display conventions'' to interpret the lines and colours of the course and vector graphics around radar contacts.

NB: In network sessions, an appropriate text chat instruction is suggested for every mouse vectoring action. This allows you to send it easily, for example to pilots whose communications are limited to text chat.

=== Routes ===
[[File:ATC-pie-screenshot-routeDetailsView.png|thumbnail|Route details dialog with world path drawn, available when both end airfields are recognised]]
A route is analysed for every strip with recognised departure and destination airports (entry fields both turned green), as follows:
* route tokens are whitespace-separated;
* each recognised navpoint token (radio navigation beacon, 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);
* if ambiguous (navpoint names are not all unique around the world), a waypoint is the nearest homonym to the point beginning the leg;
* other tokens are kept as route leg specifications to the following waypoint, e.g. airways between fixes.

[[File:ATC-pie-screenshot-routeDrawing.png|thumbnail|Assigned routes are drawn as dashed lines on the radar scope when linked to contacts]]
Routes on flight plans and strips are viewable in a route dialog, showing geodesic paths, headings and leg distances on a world map. When a specified route is linked to a radar contact, ATC-pie works out its current leg based on distance to destination, and:
* details of the current leg are displayed in the selection info pane, and the route viewing button enabled;
* the strip shows only the remainder of the route for this contact;
* the route to go is drawn as a dashed line on the radar (unless aircraft is inbound and near enough);
* the radar tag 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.

NB: If DEP and ARR airports are not both recognised, radar tags show the strip destination detail if it is filled, possibly with a heading if it is recognised.

See tutorial [https://www.youtube.com/watch?v=LfdukpBc90w video 7] for a demonstration of routes.

=== Conflicts and anticipation ===
[[File:ATC-pie-screenshot-routeConflictDetection.png|thumbnail|Route conflict depiction]]
ATC-pie 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 aircraft with a linked strip and an assigned route or heading. 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. When the projections of two aircraft intersect, a conflict is anticipated if the respective intervals between the current and assigned altitudes overlap. When an aircraft's altitude is unknown, the assigned altitude will be assumed. If an altitude assignment is missing, a ''possible'' conflict is reported.

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 || Thick bright red intersecting circles || Separation loss between aircraft
|-
| Path conflict || Red circles and paths || Anticipated paths and altitudes are intersecting
|-
| Possible path conflict || Yellow circles and paths || Paths intersecting but some altitudes unknown
|}

== Communications with aircraft ==

=== Voice radio ===
In solo sessions, voice radio interaction is simulated through speech recognition of instructions and read-back synthesis. Use the {{key press|Ctrl}} key to PTT.

In FlightGear and FSD network sessions, multiple radios can be opened and tuned in simultaneously. You can transmit on either one by holding down the PTT button of the chosen radio, or on a selected set (''Kbd PTT'' boxes ticked) using the {{key press|Ctrl}} key. This lets you PTT on multiple frequencies at once (merged frequencies), for example to service GND+TWR frequencies in view of splitting them seemlessly again later. To monitor frequencies without attending them, a trick is to set their volume to "soft" to tell them apart.

Note: Except for solo sessions, you may always use a separate voice communication program for radio. In this case, try making the same {{key press|Ctrl}} key the PTT to preserve other features such as RDF for receiving stations in FG sessions, or the ''PTT turns off notification sounds'' option recommended if not wearing a headset.

=== CPDLC ===
When [[CPDLC]] is serviced (location setting), aircraft can establish a data link from their cockpit for a direct text communication channel supplementing the radio frequency. You can monitor connections from the CPDLC dock and open a window for each active or terminated connection in the CPDLC history. Combining the {{key press|Alt}} key with a double-click on a strip or radar contact opens the current or latest dialogue for the selected callsign.

Each active CPDLC dialogue window allows to manually compose preformatted or free text message elements. But the most frequent and convenient way of creating message elements is to combine the {{key press|Alt}} key with a mouse gesture (also see ''Mouse gestures'' in the quick reference):
* click-and-drag vectoring gesture to send a heading, altitude/FL or speed instruction (see [[#Vectors|section on vectors]]);
* strip drop on an ATC to initiate a CPDLC authority transfer or to send the aircraft a "contact" instruction;
* "OK" button click in the instruction panel to send the corresponding formatted instruction.

Created message elements are appended to the message buffer in the connection dialogue window until you send the message manually. The other party must then acknowledge it before it times out.

=== Radio text chat ===
Although voice communications should be encouraged for realism whenever possible, ATC-pie has a powerful text chat system for keyboard interaction with pilots in network sessions. In FlightGear sessions, all messages from within at least 100 NM and up to the radar range are visible in the chat. In FSD sessions, whose protocol simulates text frequencies, ATC-pie tunes the chat to the "publicised frequency" in the radio panel.

'''Text aliases''' are dollar-prefixed words that ATC-pie tries to replace with context-dependant values when sent. For example, <code>$metar</code> expands to the current primary station weather. This allows to send/save formatted messages like "Current weather is $metar" instead of copy-pasting a weather look-up for every such message.

Predefined aliases such as <code>$metar</code> take values that are specified by the program and may depend on the local environment (weather, declination, airport elevation...), on your configuration (transition altitude, runways in use...) or on the current selection (QDM to airport, assigned route...). They are all listed with their meaning in the "quick reference", ''Text aliases'' section.

All other aliases will be considered custom, in other words expected to take a value specified by you, on either of the following levels:
* world (value saved for replacement anywhere that the program will be opened), in the general notes (notepad dock);
* location (saved for this airport or centre), in the local notes;
* single aircraft contact (by selected strip), in the strip comments.

Here is how ATC-pie decides what to do with a text alias of the form <code>$foo</code> in a sent message:
# If it is one of the predefined list, the specified substitution is performed. If not, it is a custom alias and we carry on to the next step.
# Look for a line beginning with <code>foo=</code> in the general notes. If one is found, the alias is replaced with what follows the '<code>=</code>' character.
# Look for a line beginning with <code>foo=</code> in the local notes. If one is found, the alias is replaced with what follows the '<code>=</code>' character.
# If a strip is part of the current selection, search likewise in its comment field and substitute if the search succeeds.
# Substitution is unsuccessful. ATC-pie will open an edit box so that you can review your message before sending it.

Moreover, ATC-pie strips everything up to the first '''pipe character''' (<code>|</code>) in the message if any, before it is processed and sent. You may test this by sending "stripped part|sent part" and observe that only the "sent part" makes it to the message contents. You can therefore make your life easier with piped shortcuts in your preset message list. They will pop up like any other message in the filtered menu as you type. For example, the following preset message enables something like a dot-command for sending a bearing to your base airport in a few key strokes:
: <code>.qdm|Heading to airport $qdm</code>

Lastly, if a troll or angry user is polluting your session with undesired messages, add their callsign to the '''senders blacklist'''. All messages from the user will then be filtered out from the message pane. You can view and clear this list at any time.

== ATC coordination ==

"ATC coordination" refers to the following:
* strip exchange, i.e. sending and receiving strips (handovers);
* ATC phone lines, for private voice calls (except in solo sessions);
* CPDLC authority transfers;
* ''who-has'' requests, to query ATCs about who is claiming control of callsigns;
* ATC text chat, to exchange text messages with other ATCs (except in solo sessions).

=== Strip exchange ===
[[File:ATC-pie-screenshot-receivedStrip.png|thumbnail|Example of a strip received from "GND"]]
To hand a strip over, drag it and drop it on the recipient in the list of controllers in the ''ATC coordination'' dock. A received strip appears with an identification of the sender which disappears as soon as the strip is clicked on.

A received strip lands on the collecting rack set for the sender if any (double-click on a rack name to add an ATC callsign from which to collect strips), or on the "Default" rack otherwise. It may link automatically to an identified radar contact according to the selected auto-link options (general settings).

See [https://www.youtube.com/watch?v=oQIud-cAlT4 tutorial video 6] for a presentation of the feature.

=== ATC phone lines ===
Phone lines allow to call and talk to other ATCs directly from the ''ATC coordination'' dock. Each line has an outgoing state that you control, toggling between open and closed with a double-click on its phone icon. Opening a line places a call to the connected ATC, showing as "incoming" on their side. When two parties have their line open to one another, they are in direct communication (no push-to-talk). In other words, opening an incoming call puts you on the phone with the caller. Closing a call hangs up the active line, but you can pick it back up as long as the other party holds it open ("still incoming" for you).

You can only talk to one ATC at a time but may place multiple outgoing calls. If a call you placed is answered while you are in another call, the answered call switches to show as incoming without interrupting the one in progress. Conversely, opening (answering) an incoming call while already in another call drops the current line. An incoming call you answer which turns to "placed" (outgoing only) instead of "in progress" means that the other party is already on the phone and is now seeing an incoming call from you.

=== ATC text chat ===
The ATC text messaging system allows to chat with other ATCs in channels that are separate from the "radio text chat" read by pilots. It offers private channels for one-to-one conversations, and a general ATC chat room in network sessions, readable by all connected ATCs.

'''Note on interoperability in FG sessions''': While only ATC-pie integrates ATC text chat in its interface, other users can interact with a regular IRC client connected to <code>mpirc.flightgear.org</code>, with their FlightGear network callsign as IRC nickname, and joining the set IRC channel. They will be able to send and receive public and private messages and chat with everybody, at the only cost of ignoring the system messages that will sometimes appear on their side.

== Solo sessions ==

In solo sessions, you control virtual IFR planes, receiving and handing over strips to virtual ATCs depending on your position and the aircraft's intentions. You can train as an en-route controller in CTR mode, or as an airport controller in AD mode, where four combinable positions are available:
* ground (GND), to taxi aircraft between parking positions and runways;
* tower (TWR), to control runways and immediate surroundings;
* departure (DEP), to bring departing traffic to their exit point;
* approach (APP), to vector arrivals onto final.

=== Objectives ===
In '''CTR mode''', your task is to transit the aircraft across your airspace, always ensuring separation, and to hand each of them over to the most appropriate neighbouring centre North, South, East or West of your sector. You can specify local navpoints in the location settings so that the system includes them as turning points in the randomised aircraft routes.

In '''airport mode''', traffic is either inbound or outbound. Assuming APP, inbound aircraft must be sequenced and vectored into tower range for handover, unless you are in the TWR position as well. Each inbound aircraft either requests ILS or visual. Assuming TWR, you must clear them to land when appropriate, i.e. cleared for ILS approach or expected runway reported in sight. If landing cannot take place (too high, not cleared...), aircraft will go around. Controlling GND, you must move inbound traffic near their parking position once they have vacated the runway, and hand them over to the ramp. Outbound traffic must be brought to hold short of a runway threshold and report ready for departure with TWR. If you assume DEP, you must hand outbound aircraft over to the en-route centre (CTR) once they are high enough and close to their exit point if specified in their route. Entry and exit points are configurable in <code>CONFIG/nav/AD-entry-exit</code> (see <code>Notice</code> in the directory).

[[File:ATC-pie-screenshot-handoverPane-solo.png|thumbnail|Handover pane in an AD solo session, assuming all three available positions]]
{| class="wikitable" style="text-align:center"
|+ Handovers with virtual ATCs in airport mode
|-
| || colspan="2" | Departure strips || colspan="2" | Arrival strips
|-
! Assuming positions || Receive from || Hand over to || Receive from || Hand over to
|-
! GND only
| DEL || TWR || TWR || Ramp
|-
! TWR only
| GND || DEP || APP || GND
|-
! DEP only
| TWR || CTR || colspan="2" | N/A
|-
! APP only
| colspan="2" | N/A || CTR || TWR
|-
! TWR+GND
| DEL || DEP || APP || Ramp
|-
! TWR+DEP
| GND || CTR || APP || GND
|-
! TWR+APP
| GND || DEP || CTR || GND
|-
! APP+DEP
| TWR || CTR || CTR || TWR
|-
! TWR+GND+DEP
| DEL || CTR || APP || Ramp
|-
! TWR+GND+APP
| DEL || DEP || APP || Ramp
|-
! TWR+APP+DEP
| GND || CTR || CTR || GND
|-
! All 4
| DEL || CTR || CTR || Ramp
|}

=== Instructing aircraft ===
[[File:ATC-pie-screenshot-taxiInstructionTool.png|thumbnail|Click&drag taxi instruction tool at OMDB ground]]
Instructions are given through different means:
* provided the speech recognition modules are installed, you can turn on voice instructions from the solo simulation settings dialog and instruct aircraft through your microphone, using the {{key press|Ctrl}} key as push-to-talk and standard phraseology (see the quick reference tab about it);
* if voice instructions are turned off:
** mouse vector assignments issue the corresponding instructions (see section on vectors above);
** handoffs are issued when dropping strips on an ATC receiver;
* instruct taxi routes by dragging out of radar contacts when they are considered on the ground (low enough or squawking GND);
* the dockable instruction panel works regardless of voice vs. mouse selection;
* alternatively, if the aircraft is connected to CPDLC, you can send instructions through the [[#CPDLC|data link]].

Instructions from the panel are always issued to the callsign entered in the top field, which should fill automatically on aircraft or strip selection when a callsign is known. Therefore, make sure you do not mess up your strip links or your instructions will realistically be acknowledged and followed by the wrong aircraft.

=== Need a scenario? ===
Things you can train for:
* towering a single runway with mixed traffic: select TWR position and an equal balance of departures and arrivals;
* optimising approach spacing in dense traffic: select APP position only, increase traffic density, turn on spacing hints and try to stabilise them all at "3:00" for example;
* change of runways (e.g. irl after wind direction change): start with APP+TWR and select a runway for arrivals at least, run the simulation for a while and change for opposite runway use;
* CTR mode with a low ceiling to increase the number of conflicts to resolve;
* etc.

== Teacher & student connections (ATC tutoring) ==

This session type is made to bring an ATC student and a teacher together for tutorial sessions. To '''set up a session''', the student must connect to the teacher, so make sure the teacher's session is running first. Only one student can connect to a teacher at a time. The teacher creates and manipulates traffic for the student to work with, controls the weather and decides on the ATC neighbours. Strip exchange and ATC text chat is possible, either between both parties ("offline" exchanges) or between the student and the virtual ATCs (in-sim coordination). All exchanges are monitored by the teacher, and transparent to the student. The teacher can also snapshot traffic position situations to recall them later.

In '''teacher sessions''':
* The teaching console is enabled, which allows you to control most aspects of the environment visible to the student.
* You create new traffic holding {{key press|Shift}} down with a right click-and-drag on the radar specifying the position and face heading. A dialog pops up and allows you to choose a callsign (one is initially generated), altitude and other details. If near a ground route node, a parking position or runway, you can create it on the ground, ready to taxi or for departure (NB: parking overrides position/heading input).
* Traffic is initially created in an "unspawned" state (radar contact marked "+"), in other words visible to you but not to the student. This allows you to set its transponder or get it into a certain state before spawning it into the student's world.
* Controlling the traffic is done in the same way as in solo sessions without voice, i.e. using the click&drag vector and taxi tools and the instruction dock. The only difference is that you control the selected aircraft directly, regardless of your strip links and details. You therefore do not need a strip and a correctly filled callsign to instruct a pilot, though it is a good idea to have one if you want your vectors registered and drawn on the radar. The traffic creation dialog offers to create a linked strip with every new aircraft.
* You may pause the whole simulation, or freeze each aircraft individually. Frozen aircraft will result in stationary flights on the student's radar.
* The ATC text chat system allows to chat to the student directly as the teacher, and to simulate private ATC conversations with the student (select callsign to interact as).
* To exchange strips, drop them on "Student" and select whom the strip should appear from on the student's side. Note that for your convenience in further control of the traffic, teacher strips do not disappear on handovers;
* CPDLC is supported, the dialogue windows reflecting the change of perspective (ACFT instead of ATC) and the {{key press|Alt}} key combinations generating requests rather than instructions.

[[Category:ATC-pie]]

ATC-pie installation guide

2023-01-31T15:40:08Z

Mickybadia: v1.8.7

{{forum|83|ATC-Pie support & development}}

{{about|installing and configuring ATC-pie|a manual on how to use it|ATC-pie user guide}}

== Installing ==

[[ATC-pie]] is free and open source, and programmed in Python3 for Qt5. It is therefore system-independant, but requires Python3 and its PyQt5 library to run. Otherwise, ATC-pie runs straight after download without any compiling (make, etc.) to do.

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.

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 Git '''repository''':
: <code>git clone git://git.code.sf.net/p/atc-pie/code ATC-pie</code>

I say again: the download/clone alone is not enough; both Python3 and PyQt5 must be installed too. The exact dependencies and required versions are listed in the <code>README</code> file packed in the download.

At this point you have a working program. But further software pieces can be installed to enable more of its features, as listed below. Depending on your use of ATC-pie, they can be recommended for more realism but they are not required, and can be installed later. Also read the <code>README</code> file for extra notes on installation.

To enhance:
* all airport sessions with a 3D '''tower view''', ''[[FlightGear]]'' must be available, with the appropriate aircraft models and scenery data—note that it can run on a separate machine, as explained [[#Airport scene rendering|down this article]];
* solo sessions with '''voice instruction recognition''' by the AI aircraft, install ''PocketSphinx'' (requires ''PyAudio'');
* solo sessions with '''speech synthesis''' of AI pilots' radio messages, install ''pyttsx'';
* FlightGear sessions with '''full ATC coordination''', including unlimited strip exchange (recommended!) and '''[[CPDLC]]''', install the ''Python IRC library'';
* FlightGear and FSD sessions with realistic '''voice radio simulation''', install the ''FGCom-Mumble'' plugin (requires a ''Mumble''>=1.4 client);
* all sessions (except solo) with an '''ATC phone line switchboard''', install ''PyAudio'', plus ''PyMumble'' for FlightGear and FSD.

== Running ==

Depending on your system and preference, you might be double-clicking, typing stuff or pulling your hair out. In any case what you must do is run a Python3 interpreter on the <code>ATC-pie.py</code> file from the downloaded directory.

Tip for Windows users: create a shortcut whose "target" is <code>cmd /k Z:\path-to-pie\ATC-pie.py</code>, making sure "start in" is set to the same <code>Z:\path-to-pie</code> and that Python source files are associated with Python3.

=== Two program modes ===
[[File:ATC-pie-screenshot-launcherDialog.png|thumbnail|Initial graphical launcher, with AD vs. CTR mode choice]]
On program start, a welcome launcher window should open, from which you may start a session in either airport (AD) or centre (CTR) mode, i.e. respectively with or without a base airfield.

The '''airport mode''' is for ATC positions like approach or tower control, or any combination of those. In this mode, ATC-pie centres the radar at the chosen base airfield, depicts its tarmac and runways, and enables features like a tower view and active runway selection.

The '''centre mode''' is designed for en-route control centre simulation. It disables all airport-specific features, and allows to place the radar anywhere on Earth. When selecting this mode:
* The location code is a designator of your choice (excluding airport codes), under which to save your location-specific settings. A good idea is to use ICAO airspace designations, e.g. <code>SBBS</code> for the Brasilia FIR in central Brazil or <code>LFFF</code> for the Paris region in France.
* The radar position field specifies the point on which to centre the radar. For example, <code>LFPO>090,15</code> will centre the radar on a point 15 NM to the East of Orly airport. Click on the help button for a summary of valid point specification formats, or read the ''Point specification'' section in the quick reference for more detail.

=== Command line arguments ===
You may bypass the launcher and start directly at a given location with the following command, using an ICAO code for an airport or a previously defined CTR location code:
: <code>./ATC-pie.py location_code</code>

Besides, the following command line options are available:
{| class="wikitable"
! Option || Effect and argument specification || Default
|-
| --map-range=''range'' || Only valid with a location code argument. Defines the distance in NM from the radar centre up to which the map will be drawn and navpoints listed in the navigator (accepted values are 20..500). This does not affect radar range, which can still be greater or lower, and be changed within sessions.' || 100 in AD mode; 300 in CTR mode
|-
| --views-send-from=''port'' || Sets 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 FGMS connection port, chosen on session start. || 5009
|}

=== Starting sessions ===
All session types are started from the ''System'' menu.

Solo simulation:
* wind will be randomised at start, but will be forced to blow in a favourable direction if at least one active runway is selected before start;
* traffic is spawned with intentions according to the ''solo simulation configuration options'' ({{key press|Shift|F11}}), so it is preferable to configure them before starting the session to avoid undesired traffic at start.

FlightGear network session:
* callsigns for ATCs in FlightGear are expected to start with the ICAO code of the controlled airport or sector, and end with a hint on the provided service (twr, gnd, ctr...), e.g. "KORDgnd" (note that FGMS restricts callsign length to 7 characters);
* before choosing your callsign, make sure it is not already in use;
* you can connect multiple ATC-pie instances from the same computer, but you must use a different local port for each one;
* the three "sub-systems" that can be activated support different coordination features and differ in terms of interoperability with other clients, but all can be enabled together:
** '''native ATC-pie coordination''' enables full interaction with other ATC-pie clients (except phone lines), plus CPDLC with FG aircraft;
** '''ATC phone lines''' enables direct voice communications (telephone calls) with other connected ATC-pie clients;
** '''OpenRadar handover compatibility''' implements [[OpenRadar]]'s protocol to enable coordination with its users (will work with ATC-pie clients as a fallback if native sub-system not available), although some limitations apply (see [[ATC-pie#OpenRadar|interoperability note]] in the main article).

== Configuring ==

Here are things you will soon want or have to set up for a regular use of ATC-pie:
* set up a [[#Airport scene rendering|tower view]] to enable visual contact with your traffic in AD sessions;
* for FlightGear and FSD sessions, give yourself a "social name" so that others recognise you when using any of the ATC coordination/exchange features;
* for a realistic radio experience in FlightGear and FSD sessions, set up FGCom-mumble, and test the configuration from the ''System'' menu.

If you intend to operate often at a given location, it is sensible to:
* if it is an airfield location, download the latest airport data file from the [https://gateway.x-plane.com/airports/page# X-plane gateway] and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> file there);
* review and fill the various fields in the location set-up dialog (runway capabilities deserve special focus for more realisitc aircraft intentions in AD solo sessions);
* configure the workspace racks, bays and radar screens to suit the environment and service provided, they will be saved for future runs;
* if using the radar, pin your preferred navpoints (they are restored on every run) and consider creating/importing background pictures to map terrain obstacles, procedure charts, etc. (see [[#Background images|section below]]);
* for solo and teacher sessions at airports especially, build an elevation map (see <code>CONFIG/elev/Notice</code>).

For more advanced editable options, read the <code>CONFIG/Notice</code> file.

=== Airport scene rendering ===
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
A '''tower view''' allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any (X-plane seems only to allow for one, but feel free to declare more for ATC-pie), otherwise defaults to somewhere over the airport to allow towering everywhere. It is disabled in CTR mode.
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 to listen for traffic and accept telnet connections.

Running internally only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the ''System'' settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].

Connecting to an external viewer allows to run FlightGear on a different machine and thereby relieve your session from the CPU load a local instance induces. If you want to do so, get a hint of the required positioning options you should start your viewer with, from the tower view tab in the system settings dialog. Of course, scenery, models and liveries must also be available to the running process.

In either case, once activated from the ''View'' menu, the tower view '''control pane''' is enabled, from which you can turn to runway points, follow selected aircraft... Direct FlightGear input in the view window is also possible: right click and drag allows to look around, {{key press|x}} and {{key press|Shift|x}} change the zoom level, etc.

You can hook up '''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 from the ''View'' menu. Additional viewers are registered by their host+port address, from the ''View'' menu at run-time or from a custom settings file (see <code>CONFIG/Notice</code>) read at start-up and on explicit reload (''System'' menu).

Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
* ''HHH'' is the host on which ATC-pie is running;
* ''PPP'' is the default 5009, or the chosen port number if ATC-pie was started with <code>--views-send-from</code>;
* ''TTT'' is the network polling frequency (100 is common practice; change as desired if you know what you are doing).

=== Background images ===
[[File:ATC-pie-screenshot-backgroundPixmapDrawing.png|thumbnail|Pixmap image example with a terrain map around LIMW (Aosta, Italy)]]
[[File:ATC-pie-screenshot-backgroundHandDrawing.png|thumbnail|Text-specified drawing example with procedures for LSGG (Geneva, Switzerland)]]
Background images allow to decorate:
* radar scopes, e.g. to display procedure routes or airspace boundaries;
* loose strip bays, to work the strips over custom backgrounds, e.g. an airport ground chart.

There are two ways to create a background. One is to '''import a picture''' (pixmap file like JPEG or PNG, including transparency); the other consists in writing a '''drawing specification''' file to paint coloured lines, points and text labels (for radar backgrounds only). See <code>CONFIG/bg/Notice</code> to learn how to import and draw background images.

For example, you can map out procedures (SID, STAR, IAD...), grouping them by associated runways so they toggle together on the radar. Drawings are generally appropriate for that because they avoid manual positioning by directly referring to the points named in the published procedures. But if you want more than schematic line plots and text labels, you should create the picture yourself, for example using an image processing tool like ''GIMP'' and a transparent layer over a real map canvas or a screenshot of your ATC-pie radar with pinned navaids as landmarks.

'''If you have a sector file''' of the format used in VATSIM/IVAO (.sct) for your area, you should try to import it with the provided extraction tool. It will retrieve most of the contents around the open location up to the current map range, and translate it to ATC-pie's native drawing format, although the generated files always require some filtering and post-editing. If you know they are included, it is generally the best option for things like SID/STAR procedures. The way to proceed is as follows:
# Run the "extract drawings from sector file" option (''System'' menu) and select the file to extract from. This generates the following files in the <code>OUTPUT</code> directory:
#* <code>ICAO.lst.extract</code>, a menu file for the generated drawings;
#* <code>bg-ICAO-*</code>, the extracted drawings in the native ATC-pie format;
#* <code>bg-extract.err</code>, a log of the errors detected in your sector file (do not be alarmed as they often contain many).
# Import the results:
#* move or copy-paste lines from <code>ICAO.lst.extract</code> to <code>CONFIG/bg/ICAO.lst</code>;
#* move the desired drawing files under <code>CONFIG/bg</code>, adjusting the paths in the <code>.lst</code> menu as you organise subdirectories.
# Post-editing (cleaning)
#: ATC-pie does its best to understand the objects in the sector file and to group things together depending on their type. But not everything can be guessed automatically. This last step is where you filter, merge and split objects, rename points, change colours, etc. to your liking.
#: Each generated drawing section (point list under a colour) is automatically labelled with the line number where it was sourced from in the sector file so you can easily trace it (<code>@nnn</code>). A tool like ''sed'' will help you get rid of all these unwanted suffixes once you have sorted and renamed your objects:
#:: <code>sed -ri 's/ +@[0-9]+$//' file_to_clean</code>

NB: ATC-pie does not package or source from sector files directly because their data is not free. Besides, a lot of it is usually redundant with the airport sources.

Tips:
* You can check your image configuration without restarting the program, by reloading the files in their current state from the ''System'' menu ({{key press|Alt|F12}}).
* The "image positioning helper" allows to move and resize imported pictures, adjusting the corners visually rather than programmatically if you have no specification for them. All visible pixmap images will be moved simultaneously, so you can work with several at a time if you want to. On dialog box close, a file is generated in the <code>OUTPUT</code> directory for you to copy from.
* An [[OpenStreetMap]] option will take you to the free online map server, centred on your radar centre position. For a quick and dirty start (e.g. for access to coastlines, borders and rivers) you can screenshot the map and use it as a background.

[[Category:ATC-pie]]

ATC-pie

2023-01-31T15:39:05Z

Mickybadia: v1.8.7

{{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
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.8.7 (Jan. 31, 2023)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''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);
* "multi-player" network sessions (FlightGear and FSD protocols supported);
* tutorial sessions for teacher supervision of an ATC student.

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.

Its essential goal is realism. It simulates many tasks of real-life ATC such as:
* strip racks and sequence management;
* coordination with neighbouring controllers (handovers, voice phone calls...);
* radar monitoring and identification of traffic;
* vectoring and course/level conflict anticipation;
* flight plan operations;
* CPDLC...

== Screenshots ==

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Solo session with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

== Detailed feature list ==

=== Sessions and environments ===
Session/connection types:
* solo simulation (AI traffic)
* FlightGear network connection ([[FGMS]] protocol)
* 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)

{| class="wikitable" style="text-align:center"
! || Solo || FlightGear || FSD || Tutoring (teacher/student)
|-
! ACFT traffic
| AI aircraft generated according to RWY capacities, ACFT equipment, intentions...
| colspan="2" | connected flight sim pilots
| created and simulated by teacher
|-
! 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
|-
! Voice radio
| voice recognition for instructions (mouse-only also available) and synthesis for pilot read-back
| colspan="2" | [[FGCom-mumble]] integration
| teacher simulates pilots
|-
! ATC phone lines
| rowspan="2" | N/A
| colspan="2" | integrated Mumble connection
| teacher simulates ATCs
|-
! Flight plans
| 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)
| virtual online system
|-
! CPDLC
| interpreted subset of instruction messages
| supported by MP IRC
| supported by [https://www.hoppie.nl/acars/ Hoppie's ACARS network]
| full simulation by teacher (with WILCO assistance to execute instructions)
|-
! Weather
| randomised and evolving
| real world METAR retrieval
| fetch from server or retrieve real world METAR
| controlled by teacher
|-
! Other specific features
| style="text-align:left" |
* 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
|}

Location modes (available for all sessions):
* airport (AD): positions such as TWR, GND, APP, DEP at a selected airfield
* en-route centre (CTR): free positioning of radar, no base airport or runway-related options

=== ATC surveillance ===
Radars and tracking:
* SSR mode capability selection (none/A/C/S)
* primary radar toggle
* 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
* 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)

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
* departure clearance assistant
* automatic strip printing for expected departures or arrivals (from FPLs)

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

=== Communications ===
With aircraft:
* voice radio with 8.33 kHz frequency spacing, multiple radio transmissions and monitoring
* [[ATIS]] recording and reminder alarm (see [[:File:ATC-pie-screenshot-ATISdialog.png|dialog]] with pre-filled notepad)
* [[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

ATC coordination:
* 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

=== 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 [[: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

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

== 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:
* OpenRadar to ATC-pie: FGMS callsign will appear on the strip, as if the sender had filled the detail herself;
* 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 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 clients later receiving the strip);
* ATC text messaging;
* ATC phone lines;
* CPDLC transfers.

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. 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:Air Traffic Control]]

ATC-pie FAQ

2022-09-04T19:17:01Z

Mickybadia: v1.8.6

{{forum|83|ATC-Pie support & development}}

This page is a collection of questions asked at least twice about [[ATC-pie]]. It is a good idea to search through it before repeating a question on the forum or anywhere.

== Things "not working" ==

=== This aircraft is connected but I am not seeing it on my radar. ===
As in real life, the main radar technology is [http://en.wikipedia.org/wiki/Secondary_surveillance_radar SSR], which only shows what is picked up from on-board transponders in its range. It coexists with primary radar, which detects aircraft regardless of transponders but offers no information other than position (angle and distance), i.e. neither of callsign, altitude, type, IAS, etc.

The following cases will therefore prevent you from seeing a connected aircraft:
* The radars are turned off. Turn on at least a primary radar from the ''Options'' menu, or an SSR capability from the ''Radar'' tab in the ''Local settings'' dialog. Any SSR setting other than "none" will pick up contacts.
* The aircraft is out of radar range, either too far out or under the radar floor. Check the horizontal range and floor settings ("SFC" will pick up all signals down to the ground). Primary and secondary radars share the same range.
* Its onboard transponder is turned off (and primary radar is off); see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Otherwise if you accept cheating, you can activate the "radar cheat mode" which will simulate a mode S transponder for all aircraft in horizontal range; see [https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3].

=== Connected pilots do not receive my text messages. ===
This happens with pre-2017.2 FlightGear clients. Tell those pilots to upgrade! Until they do, you can tick the "legacy protocol" option from the FG system settings. Everybody should then be able to read you, but at the expense of network load.

=== The aircraft vectoring tool does not come up when I click and drag out of radar contacts. ===
Your radar contact is not linked. Link it to a strip to enable the vectoring feature. Vectors issued with it will be registered on the strip, and inform the displays according to the current options, e.g. altitude reaching point, unfollowed vector warnings, etc.

=== FGCom is not working. ===
First, there are two variants for FGCom and you should note that they are ''not'' interoperable: users can only hear and interact with others using the same variant and server. Also note that the standalone variant is deprecated. So before troubleshooting it, you should consider switching to the newer [[FGCom-mumble]] variant.

In either case, to troubleshoot:
* close all open sessions, open a single ATC-pie instance and check the FGCom variant selected in the ''system settings'';
* check that your sound is on, your volume loud and your system picking up a signal from your microphone;
* start an FGCom configuration test from the system tools menu;
* speak in the microphone while the echo test is running, and read below if you cannot hear yourself back.

'''FGCom-mumble''' is a plug-in that must be run with an external ''Mumble'' client (minimum version 1.4.0) connected to a chosen server. See the project [https://github.com/hbeni/fgcom-mumble/releases release] and wiki pages to download and install it. The control port in ATC-pie must be set to the one FGCom-mumble is listening on.

For the '''standalone''' variant (deprecated), the FGCom command in the system settings should be a valid command or path to an FGCom executable. If you have FlightGear installed on your machine, you can point to the FGCom executable already available with it. On Linux, the default "fgcom" command usually does the job. Otherwise, get one from ATC-pie's [https://sourceforge.net/projects/atc-pie/files/fgcom-standalone/ SourceForge file list]. Try the entry from a terminal in the ATC-pie directory to manually check that it runs correctly. Other things you might check:
* server status: check for responses from the chosen server, e.g. with <code>ping</code>;
* subprocess error: after turning a first radio on, check the FGCom error logs in the <code>OUTPUT</code> directory;
* port mess-up: make sure you choose an available port number for each created radio at run time, e.g. do not use a port more than once when running multiple ATC-pie instances!

=== Tower view is not starting. ===
Ruling out that FlightGear is not installed at all, your system path settings are probably wrong. From a terminal or a file system navigator, find the right command to start FlightGear and enter it as ''FlightGear executable'' from the system settings. Do not add options here; they will be taken care of internally. You may have to enter a ''FlightGear root directory'' as well, especially if you have the program files installed somewhere unexpected.

=== My tower is in the middle of the sea, and aircraft floating/landing on water! ===
You are missing the FlightGear scenery data for your location, or ATC-pie does not know where it is. If you have downloaded scenery and saved it somewhere, have you tried filling the scenery directory with that location in the system settings? Also read the [[ATC-pie_installation_guide#Airport scene rendering|related section]] in the installation guide.

=== Simulated aircraft dip underground or levitate over taxiways. ===
Do you have a ground elevation map for the location? Quoting from <code>CONFIG/elev/Notice</code>: "''When no elevation map is found for an airport, the field elevation value is used everywhere on the ground. This should be OK for a rough approximation on flat terrain, but ground traffic will not follow any slopes, thus may appear as floating above the ground, or dipping into it.''" Read the full notice for instructions on how to build your elevation map.

Once you have an elevation map, the next focus is on the FlightGear aircraft models. Because each model has its own coordinate system chosen at developer's discretion, ATC-pie must be given the height difference between each model's origin and the aircraft touch-down point (gear wheels) to position aircraft more accurately. You do this on a per-model basis with ":height" specifications in <code>CONFIG/acft/icao2fgfs</code>. Read the associated <code>Notice</code> section for more information.

=== Phone lines have broken, choppy or dragged out sound ===
You and the other parties must adjust microphone sensitivity. Toggle the phone squelch adjustment box from the system menu and tune the spinbox next to the "call" button in the ATC coordination panel. Lower values will decrease the threshold for sound pick-up and likely break the sound less, but can generate more lag in the communications. The right balance depends on your local configuration, so a few test calls with other connected ATCs will be necessary to decide on the best acceptable value.

=== I cannot connect to my teacher as a student. ===
Using IPv4 addresses, this typically happens when the teacher is in a local area network behind a router. It is a common setup for home internet, in which the teacher's actual host address is not publicly accessible from outside his private network.

If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either:
* for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local host address;
* or to create a virtual network, using a third-party VPN service.

== What is ...? Why is ...? What value/setting for ...? ==

=== What "social name" should I use for FlightGear/FSD sessions? ===
Choose any name you would like to be recognised by on the network. In ATC-pie, it will appear in the tool tip over your callsign for connected ATCs who see you. This feature is only social in the sense that it does not refer to an account or to anything technical, but it makes sense as typical ATC callsigns (e.g. "VHHHtwr") remain mostly anonymous. Use this field to identify yourself on the network.

=== What is the purpose of the flat "strip shelf" button in the strip panes? ===
More than a button, the strip shelf is where you should drop the contacts you release without a handover, e.g. parked traffic shutting down, VFR traffic flying out of your airspace, etc. Clicking on the shelf allows to browse the previously shelved strips, and to recall them, for example if shelved inadvertently.

=== What is "radio direction finding"? ===
RDF is a system that detects the horizontal direction of radio sources when signals are received. Its most common uses are:
* to locate ACFT making new radio contacts on their first transmissions;
* to give bearings to the airport to disoriented VFR pilots.

Setting up your location as equipped with RDF will essentially provide two things:
* a status bar indication of the form "hdg/qdm" in the main window, where "hdg" is the heading of the currently detected radio signal (direction to source, or "---" if none), and "qdm" the opposite heading of the last received signal (bearing from source, displayed until the next signal is received);
* the option to draw a line on radar scopes when a signal is received, making it easy to visualise the transmitting ACFT as the line should hit its target.

=== Are the vector headings true or magnetic? ===
Heading displays in ATC-pie are mostly magnetic so they can be read out to pilots. The exceptions are the navigator and handover list tool tips, which show true radial headings from the radar position, and the teacher's wind section to match the generated ATIS string.

Also note: all directions are geodesic, i.e. initial headings to take on a great circle.

=== How do approach spacing hints work? ===
When the option is turned on, an approach spacing hint will show on every strip verifying the following conditions:
* it is racked in sequence behind another marked with the same (recognised) destination;
* both are linked to an airborne aircraft with a known ground speed;
* the time hint value (see below) does not exceed 30 minutes.

The first hint shown on a strip is an estimated time difference between the linked aircraft touchdown and that of the traffic ahead (see the quick reference for more details: ''Display conventions'' for strips). To work it out, ATC-pie assumes:
* both present ground speeds;
* for the aircraft ahead, a straight path to destination;
* for the linked aircraft, a path straight to the one ahead first, then straight to destination.

Caution: some judgement is required depending on the aircraft positions, because the actual paths to expect can vary from those above. For example, the interpretation of the hint should be different whether both aircraft are aligned with the runway or coming from opposite directions.

=== What do the various markings along the approach centre line mean? ===
The regularly spaced groups along a centre line represent altitudes on the approach plane. Each group sums up to an AMSL value in accordance with the set flight path angle (also see ''Display conventions'' in the quick reference):
* straight line = 1,000 ft;
* solid diamond = 5,000 ft.

The other markers drawn with thicker lines are the positions of the ILS marker beacons (OM, MM, IM), the line pattern representing the sound triggered by the beacon in the pilot's headset. They are sourced on program start-up from the navigation data (<code>CONFIG/nav/navaid.dat</code>).

=== Why do I keep getting runway incursion alarms? ===
Because you have the runway occupation monitor turned on (''Options'' menu), while not using your runway boxes. The alarm triggers when the radar detects traffic stepping on a runway in either of the following situations:
* the runway is active (marked in use) and no strip is boxed for it;
* it is reserved but there is already traffic on the runway;
* it is reserved for a different aircraft: the boxed strip is linked to a contact that is not the entering aircraft, or the aircraft is linked to a strip different to the one boxed.

Turning the runway occupation monitor off will deactivate all radar warnings regarding runways. If you are interested in the strip boxing and visual runway highlighting system but bothered by the alarm sound, you can mute the sound notification by unticking it in the general settings.

== Where is ...? How to ...? ==

=== Can I draw SID and STAR procedures on the radar? ===
Yes, and virtually anything else, using background images. To learn about those:
* see the corresponding [[ATC-pie_installation_guide#Background images|installation guide section]];
* read the <code>CONFIG/bg/Notice</code> file.

=== How do I assign SIDs and STARs to aircraft? ===
This question is asked quite a lot more than it is relevant to a real controller's task...

What people seem to be after when asking this question is a way to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. The way to handle this is to stack your inbound strips on racks named after your STARs. Racks are indeed above all meant for efficient traffic sequencing. Every rack represents its own sequence of ordered aircraft, which is perfectly suited to control separate approach paths in parallel. With this technique, placing a strip on a STAR-named rack basically serves as the "assignment" itself. Similarly, runway-specific racks can keep track of separate landing sequences at large airports. Then you can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times in the sequence all the way to touchdown.

If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. Routes are lists of waypoints and instructions to follow between the two end airfields. Normally pulled straight from properly filed flight plans, routes are printed on strips prior to departure, then modified as the flights progress and passed along with handovers. Standard departure and arrival procedures (SIDs and STARs) can be referred to in those routes, but only by their entry or exit navpoints. They should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. For example, routes ending with a STAR should end with "FUBAR STAR", which means that waypoint FUBAR is an entry point from which a published STAR must be followed. The keyword "STAR" is in fact a mere specification for the last route leg. Similarly, routes of the form "SID DUMMY ..." specify their first leg as a standard departure to the first waypoint DUMMY. "SID" and "STAR" keywords are recognised by ATC-pie and accounted for in the second line of the radar tag when appropriate (see feature note on routes).

One meaningful wish regarding this question is for easy '''reference in text chat''' messages. Firstly, using racks in the way suggested above, you can use the <code>$rack</code> alias which is substituted by the name of the rack on which the current strip selection is stacked. Otherwise, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". Now if you specifically want to assign a full procedure name like FUBAR1A to a contact and refer to it in a generic text chat message, include a line "sid=FUBAR1A" 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 expanded in your sent messages when that strip is selected.

=== How to set the transition level? ===
You do not. You can however set the transition altitude in the location settings if your airport specification file does not already include one.

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, e.g. for more vertical separation on either side of the transition layer or due to coordination with neighbouring zones and fields.

=== Can I look up ILS frequencies? ===
Yes, in the ''environment info'' dialog.

Besides, you can create aliases with the local notepad for a quick and integrated way of sending them through text chat, which will be saved when you close ATC-pie. For example, use the following format, one runway per line: <code>ils05=111.11 MHz</code>. See [[ATC-pie_user_guide#Public text chat|custom text aliases]] for more.

=== The airport/navigation data is outdated. How can I update it? ===

The included '''airport data''' (taxiways, parking positions, frequencies, etc.) is the latest but outdated world-wide <code>apt.dat</code> file compiled by ''X-plane'' ages ago. We keep it there because it allows to run ATC-pie anywhere in the world without requiring external data, but for any serious work at a specific airfield, you should provide the latest source available on the [http://gateway.x-plane.com/airports/page X-plane airport gateway], directly accessible from the ''System'' menu. Extract the <code>apt.dat</code> file from the downloaded package, rename it after the airport's ICAO code keeping the extension (e.g. <code>KJFK.dat</code>), and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> there). Alternatively, for a quick manual touch-up of the old data, you can use the locally extracted file (see <code>OUTPUT/Notice</code>).

The included '''navigation data''' (navaids, fixes, airways, etc.) is the latest GPL version seen for each relevant ''X-plane'' file, also all out of date today. You should provide more recent navigation data, as explained in <code>CONFIG/nav/Notice</code>.

=== How do I customise the GUI and colours? ===
To change the '''radar or strip drawing colours''', edit the <code>CONFIG/colours.conf</code> file. Each line specifies the paint colour for an object type, in a typical hex <code>RRGGBB</code> (red-green-blue) format or as an SVG colour keyword name like "white". To customise the '''main session window''', place a ''Qt stylesheet'' named <code>main-stylesheet.qss</code> in the <code>CONFIG</code> directory. ATC-pie will apply it to every session window. While you are working on your look and feel, use the reload feature from the "System" menu to avoid restarting after every change.

Send us screenshots and share your files if you find a setup looking really cool! :-)

== Miscellaneous ==

=== What's with the funny name? ===
ATC-pie is written in Python, and I reckoned that the ''pyXXX'' naming habit was becoming a little dull, so I merely switched things around. You can surely do the rest of the math in terms of spelling, and later impact on the logo.

=== Why is the learning curve so steep? People would use your program more if you did/provided [...] ===
Often continued with: '''(you must understand that) this is not VATSIM!'''

We do have a [https://sourceforge.net/p/atc-pie/wiki/Wishlist wish list] and will consider any feature or help request. However, though it has a few cheats, ATC-pie has always choosen realism as a criterion for implementation and design, over the mere incentive of converting otherwise happy users of other programs. It is a good thing that different philosophies and work flows are available out there, and there would be much less interest in having them all copy each other, fighting over users instead of understanding that not all of them wish for the same experience. If serious simulation or learning new skills sound like threats to fun for you, you have a perfectly valid reason not to opt for ATC-pie.

[[Category:ATC-pie]]

ATC-pie user guide

2022-09-04T18:44:41Z

Mickybadia: v1.8.6

{{forum|83|ATC-Pie support & development}}

This article is a guide to the air traffic control simulation program [[ATC-pie]], describing some of its major features. A more exhaustive list can be found in the main article. For download and installation help, refer to the [[ATC-pie installation guide]]. For support and troubleshooting, the [[ATC-pie FAQ]] might get you an answer first. Otherwise kindly ask on the dedicated FlightGear sub-forum so that the discussion is public.

Other ways to learn the program are:
* to watch the online [https://www.youtube.com/playlist?list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb video tutorial];
* to read the in-app ''Quick reference'' available from the ''Help'' menu (summary of mouse/keyboard gestures, display conventions...);
* to connect with a skilled teacher as a student (personal training);
* to [[#Solo_sessions|train solo]]!

== Flight strips ==

Whether electronic (dematerialised) or on paper, printed automatically or filled by hand, the '''flight progress strip''' is the essential piece of air and ground traffic control. Every aircraft in contact is represented by a unique strip on the ATC workbench, and every strip represents a unique contact, present or expected. This ensures that no aircraft is ever forgotten about. Strip positioning and updating then enable to monitor the aircraft's status, sequence number, position, intentions, etc.

=== Strip details and linking ===
[[File:ATC-pie-screenshot-stripDetailSheet.png|thumbnail|The ATC-pie strip detail sheet]]
A click on the "new strip" tool bar button (shortcut {{key press|F2}}) or double-click on an empty strip rack or bay space will open a dialog to fill flight details on a fresh blank strip, e.g. callsign, type of aircraft, destination, etc. Double-clicking on an existing strip allows to edit the filled details.

If providing radar service, strips should be '''linked''' to identified contacts to inform the radar display with the filled details, e.g. assigned altitude, and enable joint selection. To link a strip to a radar contact, select one and middle-click on the other. Conflicts between the strip details and the values squawked by the linked transponder contact are reported: the strip displays a "!!XPDR" warning and the strip dialog labels the conflicting details.

A strip can also be linked to a filed flight plan (FPL). This will make radar and strip display fall back on filed information for missing details. The strip dialog also shows the mismatching information between the two, though this is rather common because the strip typically gets updated as the flight progresses.

All together, a selection can involve up to three linked elements: strip, radar contact, flight plan. You can pull details from linked elements to strips (strip panel bottom menu), and push strip details to their linked flight plan if necessary (strip dialog bottom tick box). Unlinking is possible with {{key press|Shift}}+middle-click. If you use linking carefully, auto-fill options are available from the general settings, to fill blank strip details with newly-linked information.

For fast and efficient service, every initial contact by a pilot should basically make you hit {{key press|F2}} and type the spoken callsign. You should then soon figure out if:
* you already have a strip for that contact, e.g. it was automatically printed earlier, or handed over by a colleague: a "!!dup" warning appears next to the input field;
* a flight plan is filed whose details can be linked immediately: a number of candidate FPLs is displayed on a button in the bottom row, which you can click on to select the matching FPL;
* a FPL must be filed, e.g. IFR departure not filed by lazy pilot: click on the "new FPL" button in the bottom row to open a fresh FPL detail sheet on save (FPL will be created and linked if saved).

=== Strip placeholders ===
ATC-pie provides with three types of placeholders for flight strips: ''racks'', ''loose strip bays'' and ''runway boxes''. According to your ATC position and local facilities, you should choose and arrange your placeholders for optimal control. Strips can then be moved between them using mouse drag and drop.

[[File:ATC-pie-screenshot-stripRacks.png|thumbnail|Strip rack panel]]
A '''strip rack''' is the preferred way of keeping track of a sequence, e.g. a departure queue at a runway threshold. Rack panels can be created from the main window workspace, popped out as separate windows, and a persistent one can be found among the available docks. You can create as many racks as you wish in every panel. Double click on a rack's name to rename it or edit its properties. Use mouse drag to move strips up and down a rack sequence.

A '''loose strip bay''' allows free-hand positioning of strips in its reserved space. Such bays are useful for unsequenced traffic, or to map out relative positions when controlling without a radar. You may also import background images, e.g. a ground chart to keep visual track of taxiing aircraft and vehicles. See <code>CONFIG/bg/Notice</code> to learn how.

[[File:ATC-pie-screenshot-runwayReserved.png|thumbnail|Reserved runway marked in yellow]]
A '''runway box''' is a placeholder for a single strip, named after a physical runway and denoting a clearence to use it (enter, cross, land...). Runway boxes are contained in their own dock, with one made visible for each runway marked as in use in either direction. Thorough use of runway boxes will help you avoid bad mistakes like clear an aircraft to land over lined up traffic. When freed, runway boxes start and display a timer together with the wake turbulance category of the last contained strip to help with TKOF/LDG separation. What is more, if you use radar, a filled runway box marks the runway as ''reserved'' on the scope.

Besides, there are two other places a strip can be dropped on, usually when releasing a contact:
* an ATC callsign in the ATC panel to initiate a handover;
* a '''strip shelf''' (flat button at the bottom of loose and racked strip panels), which clears the strip from your workbench and stores it as shelved.

== Vectors, routes and separation ==

ATC-pie can register and analyse issued vectors and routes to:
* inform strip and radar display;
* help monitor traffic, checking tracked positions against route/vector assignments;
* help manage traffic, anticipating route and FL conflicts between controlled aircraft.

=== Vectors ===
[[File:ATC-pie-screenshot-courseAndAssignmentsGraphics.png|thumbnail|Course/vector drawing for linked radar contact]]
Registering vectors on strips enhances the drawing of linked radar contacts, enables easy monitoring of tracks and detection of aircraft flying off course. To register vectors automatically when a radar contact is linked to a strip, use the following mouse gestures:
* click and drag out of a radar contact to issue a heading vector;
* holding {{key press|Shift}}, click and drag vertically for altitude/FL vectors;
* holding {{key press|Shift}}, click and drag horizontally for speed instructions;
* holding {{key press|Shift}}, double-click on the radar target to clear registered vecors from the linked strip.

See [https://www.youtube.com/watch?v=BvA3MRlGJjU video 5] of the tutorial for more on vectoring, and check the quick reference ''display conventions'' to interpret the lines and colours of the course and vector graphics around radar contacts.

NB: In network sessions, an appropriate text chat instruction is suggested for every mouse vectoring action. This allows you to send it easily, for example to pilots whose communications are limited to text chat.

=== Routes ===
[[File:ATC-pie-screenshot-routeDetailsView.png|thumbnail|Route details dialog with world path drawn, available when both end airfields are recognised]]
A route is analysed for every strip with recognised departure and destination airports (entry fields both turned green), as follows:
* route tokens are whitespace-separated;
* each recognised navpoint token (radio navigation beacon, 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);
* if ambiguous (navpoint names are not all unique around the world), a waypoint is the nearest homonym to the point beginning the leg;
* other tokens are kept as route leg specifications to the following waypoint, e.g. airways between fixes.

[[File:ATC-pie-screenshot-routeDrawing.png|thumbnail|Assigned routes are drawn as dashed lines on the radar scope when linked to contacts]]
Routes on flight plans and strips are viewable in a route dialog, showing geodesic paths, headings and leg distances on a world map. When a specified route is linked to a radar contact, ATC-pie works out its current leg based on distance to destination, and:
* details of the current leg are displayed in the selection info pane, and the route viewing button enabled;
* the strip shows only the remainder of the route for this contact;
* the route to go is drawn as a dashed line on the radar (unless aircraft is inbound and near enough);
* the radar tag 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.

NB: If DEP and ARR airports are not both recognised, radar tags show the strip destination detail if it is filled, possibly with a heading if it is recognised.

See tutorial [https://www.youtube.com/watch?v=LfdukpBc90w video 7] for a demonstration of routes.

=== Conflicts and anticipation ===
[[File:ATC-pie-screenshot-routeConflictDetection.png|thumbnail|Route conflict depiction]]
ATC-pie 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 aircraft with a linked strip and an assigned route or heading. 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. When the projections of two aircraft intersect, a conflict is anticipated if the respective intervals between the current and assigned altitudes overlap. When an aircraft's altitude is unknown, the assigned altitude will be assumed. If an altitude assignment is missing, a ''possible'' conflict is reported.

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 || Thick bright red intersecting circles || Separation loss between aircraft
|-
| Path conflict || Red circles and paths || Anticipated paths and altitudes are intersecting
|-
| Possible path conflict || Yellow circles and paths || Paths intersecting but some altitudes unknown
|}

== Communications with aircraft ==

=== Voice radio ===
In solo sessions, voice radio interaction is simulated through speech recognition of instructions and read-back synthesis. Use the {{key press|Ctrl}} key to PTT.

In FlightGear network sessions, multiple radios can be opened and tuned in simultaneously. You can transmit on either one by holding down the PTT button of the chosen radio, or on a selected set (''Kbd PTT'' boxes ticked) using the {{key press|Ctrl}} key. This lets you PTT on multiple frequencies at once (merged frequencies), for example to service GND+TWR frequencies in view of splitting them seemlessly again later. Note that while you will be broadcasting on, and hearing incoming transmissions from, all frequencies, pilots will not be hearing each other across frequencies. To monitor frequencies without attending them, a trick is to set their volume to "soft" to tell them apart.

Note: Except for solo sessions, you may always use an external voice communication program like [[Mumble]] for radio. It is even necessary in FSD sessions, which do not integrate radio natively. In this case, try making the same {{key press|Ctrl}} key the PTT to preserve other features such as RDF for receiving stations, or the ''PTT turns off notification sounds'' option recommended if not wearing a headset.

=== CPDLC ===
When [[CPDLC]] is serviced (location setting), aircraft can establish a data link from their cockpit for a direct text communication channel supplementing the radio frequency. You can monitor connections from the CPDLC dock and open a window for each active or terminated connection in the CPDLC history. Combining the {{key press|Alt}} key with a double-click on a strip or radar contact opens the current or latest dialogue for the selected callsign.

Each active CPDLC dialogue window allows to manually compose preformatted or free text message elements. But the most frequent and convenient way of creating message elements is to combine the {{key press|Alt}} key with a mouse gesture (also see ''Mouse gestures'' in the quick reference):
* click-and-drag vectoring gesture to send a heading, altitude/FL or speed instruction (see [[#Vectors|section on vectors]]);
* strip drop on an ATC to initiate a CPDLC authority transfer or to send the aircraft a "contact" instruction;
* "OK" button click in the instruction panel to send the corresponding formatted instruction.

Created message elements are appended to the message buffer in the connection dialogue window until you send the message manually. The other party must then acknowledge it before it times out.

=== Radio text chat ===
Although voice communications should be encouraged for realism whenever possible, ATC-pie has a powerful text chat system for keyboard interaction with pilots in network sessions. In FlightGear sessions, all messages from within at least 100 NM and up to the radar range are visible in the chat. In FSD sessions, whose protocol simulates text frequencies, ATC-pie tunes the chat to the "publicised frequency" in the radio panel.

'''Text aliases''' are dollar-prefixed words that ATC-pie tries to replace with context-dependant values when sent. For example, <code>$metar</code> expands to the current primary station weather. This allows to send/save formatted messages like "Current weather is $metar" instead of copy-pasting a weather look-up for every such message.

Predefined aliases such as <code>$metar</code> take values that are specified by the program and may depend on the local environment (weather, declination, airport elevation...), on your configuration (transition altitude, runways in use...) or on the current selection (QDM to airport, assigned route...). They are all listed with their meaning in the "quick reference", ''Text aliases'' section.

All other aliases will be considered custom, in other words expected to take a value specified by you, on either of the following levels:
* world (value saved for replacement anywhere that the program will be opened), in the general notes (notepad dock);
* location (saved for this airport or centre), in the local notes;
* single aircraft contact (by selected strip), in the strip comments.

Here is how ATC-pie decides what to do with a text alias of the form <code>$foo</code> in a sent message:
# If it is one of the predefined list, the specified substitution is performed. If not, it is a custom alias and we carry on to the next step.
# Look for a line beginning with <code>foo=</code> in the general notes. If one is found, the alias is replaced with what follows the '<code>=</code>' character.
# Look for a line beginning with <code>foo=</code> in the local notes. If one is found, the alias is replaced with what follows the '<code>=</code>' character.
# If a strip is part of the current selection, search likewise in its comment field and substitute if the search succeeds.
# Substitution is unsuccessful. ATC-pie will open an edit box so that you can review your message before sending it.

Moreover, ATC-pie strips everything up to the first '''pipe character''' (<code>|</code>) in the message if any, before it is processed and sent. You may test this by sending "stripped part|sent part" and observe that only the "sent part" makes it to the message contents. You can therefore make your life easier with piped shortcuts in your preset message list. They will pop up like any other message in the filtered menu as you type. For example, the following preset message enables something like a dot-command for sending a bearing to your base airport in a few key strokes:
: <code>.qdm|Heading to airport $qdm</code>

Lastly, if a troll or angry user is polluting your session with undesired messages, add their callsign to the '''senders blacklist'''. All messages from the user will then be filtered out from the message pane. You can view and clear this list at any time.

== ATC coordination ==

"ATC coordination" refers to the following:
* strip exchange, i.e. sending and receiving strips (handovers);
* ATC phone lines, for private voice calls (except in solo sessions);
* CPDLC authority transfers (except in FSD sessions);
* ''who-has'' requests, to query ATCs about who is claiming control of callsigns;
* ATC text chat, to exchange text messages between ATCs (except in solo sessions).

=== Strip exchange ===
[[File:ATC-pie-screenshot-receivedStrip.png|thumbnail|Example of a strip received from "GND"]]
To hand a strip over, drag it and drop it on the recipient in the list of controllers in the ''ATC coordination'' dock. A received strip appears with an identification of the sender which disappears as soon as the strip is clicked on.

A received strip lands on the collecting rack set for the sender if any (double-click on a rack name to add an ATC callsign from which to collect strips), or on the "Default" rack otherwise. It may link automatically to an identified radar contact according to the selected auto-link options (general settings).

See [https://www.youtube.com/watch?v=oQIud-cAlT4 tutorial video 6] for a presentation of the feature.

=== ATC phone lines ===
Phone lines allow to call and talk to other ATCs directly from the ''ATC coordination'' dock. Each line has an outgoing state that you control, toggling between open and closed with a double-click on its phone icon. Opening a line places a call to the connected ATC, showing as "incoming" on their side. When two parties have their line open to one another, they are in direct communication (no push-to-talk). In other words, opening an incoming call puts you on the phone with the caller. Closing a call hangs up the active line, but you can pick it back up as long as the other party holds it open ("still incoming" for you).

You can only talk to one ATC at a time but may place multiple outgoing calls. If a call you placed is answered while you are in another call, the answered call switches to show as incoming without interrupting the one in progress. Conversely, opening (answering) an incoming call while already in another call drops the current line. An incoming call you answer which turns to "placed" (outgoing only) instead of "in progress" means that the other party is already on the phone and is now seeing an incoming call from you.

=== ATC text chat ===
The ATC text messaging system allows to chat with other ATCs in channels that are separate from the "radio text chat" read by pilots. It offers private channels for one-to-one conversations, and a general ATC chat room in network sessions, readable by all connected ATCs.

'''Note on interoperability in FG sessions''': While only ATC-pie integrates ATC text chat in its interface, other users can join the same channel with a regular IRC client. They will be able to send and receive public and private messages and chat with everybody, at the only cost of ignoring the system messages that will sometimes appear on their side. For best results, they should use their FlightGear network callsign as their IRC nickname.

== Solo sessions ==

In solo sessions, you control virtual IFR planes, receiving and handing over strips to virtual ATCs depending on your position and the aircraft's intentions. You can train as an en-route controller in CTR mode, or as an airport controller in AD mode, where four combinable positions are available:
* ground (GND), to taxi aircraft between parking positions and runways;
* tower (TWR), to control runways and immediate surroundings;
* departure (DEP), to bring departing traffic to their exit point;
* approach (APP), to vector arrivals onto final.

=== Objectives ===
In '''CTR mode''', your task is to transit the aircraft across your airspace, always ensuring separation, and to hand each of them over to the most appropriate neighbouring centre North, South, East or West of your sector. You can specify local navpoints in the location settings so that the system includes them as turning points in the randomised aircraft routes.

In '''airport mode''', traffic is either inbound or outbound. Assuming APP, inbound aircraft must be sequenced and vectored into tower range for handover, unless you are in the TWR position as well. Each inbound aircraft either requests ILS or visual. Assuming TWR, you must clear them to land when appropriate, i.e. cleared for ILS approach or expected runway reported in sight. If landing cannot take place (too high, not cleared...), aircraft will go around. Controlling GND, you must move inbound traffic near their parking position once they have vacated the runway, and hand them over to the ramp. Outbound traffic must be brought to hold short of a runway threshold and report ready for departure with TWR. If you assume DEP, you must hand outbound aircraft over to the en-route centre (CTR) once they are high enough and close to their exit point if specified in their route. Entry and exit points are configurable in <code>CONFIG/nav/AD-entry-exit</code> (see <code>Notice</code> in the directory).

[[File:ATC-pie-screenshot-handoverPane-solo.png|thumbnail|Handover pane in an AD solo session, assuming all three available positions]]
{| class="wikitable" style="text-align:center"
|+ Handovers with virtual ATCs in airport mode
|-
| || colspan="2" | Departure strips || colspan="2" | Arrival strips
|-
! Assuming positions || Receive from || Hand over to || Receive from || Hand over to
|-
! GND only
| DEL || TWR || TWR || Ramp
|-
! TWR only
| GND || DEP || APP || GND
|-
! DEP only
| TWR || CTR || colspan="2" | N/A
|-
! APP only
| colspan="2" | N/A || CTR || TWR
|-
! TWR+GND
| DEL || DEP || APP || Ramp
|-
! TWR+DEP
| GND || CTR || APP || GND
|-
! TWR+APP
| GND || DEP || CTR || GND
|-
! APP+DEP
| TWR || CTR || CTR || TWR
|-
! TWR+GND+DEP
| DEL || CTR || APP || Ramp
|-
! TWR+GND+APP
| DEL || DEP || APP || Ramp
|-
! TWR+APP+DEP
| GND || CTR || CTR || GND
|-
! All 4
| DEL || CTR || CTR || Ramp
|}

=== Instructing aircraft ===
[[File:ATC-pie-screenshot-taxiInstructionTool.png|thumbnail|Click&drag taxi instruction tool at OMDB ground]]
Instructions are given through different means:
* provided the speech recognition modules are installed, you can turn on voice instructions from the solo simulation settings dialog and instruct aircraft through your microphone, using the {{key press|Ctrl}} key as push-to-talk and standard phraseology (see the quick reference tab about it);
* if voice instructions are turned off:
** mouse vector assignments issue the corresponding instructions (see section on vectors above);
** handoffs are issued when dropping strips on an ATC receiver;
* instruct taxi routes by dragging out of radar contacts when they are considered on the ground (low enough or squawking GND);
* the dockable instruction panel works regardless of voice vs. mouse selection;
* alternatively, if the aircraft is connected to CPDLC, you can send instructions through the [[#CPDLC|data link]].

Instructions from the panel are always issued to the callsign entered in the top field, which should fill automatically on aircraft or strip selection when a callsign is known. Therefore, make sure you do not mess up your strip links or your instructions will realistically be acknowledged and followed by the wrong aircraft.

=== Need a scenario? ===
Things you can train for:
* towering a single runway with mixed traffic: select TWR position and an equal balance of departures and arrivals;
* optimising approach spacing in dense traffic: select APP position only, increase traffic density, turn on spacing hints and try to stabilise them all at "3:00" for example;
* change of runways (e.g. irl after wind direction change): start with APP+TWR and select a runway for arrivals at least, run the simulation for a while and change for opposite runway use;
* CTR mode with a low ceiling to increase the number of conflicts to resolve;
* etc.

== Teacher & student connections (ATC tutoring) ==

This session type is made to bring an ATC student and a teacher together for tutorial sessions. To '''set up a session''', the student must connect to the teacher, so make sure the teacher's session is running first. Only one student can connect to a teacher at a time. The teacher creates and manipulates traffic for the student to work with, controls the weather and decides on the ATC neighbours. Strip exchange and ATC text chat is possible, either between both parties ("offline" exchanges) or between the student and the virtual ATCs (in-sim coordination). All exchanges are monitored by the teacher, and transparent to the student. The teacher can also snapshot traffic position situations to recall them later.

In '''teacher sessions''':
* The teaching console is enabled, which allows you to control most aspects of the environment visible to the student.
* You create new traffic holding {{key press|Shift}} down with a right click-and-drag on the radar specifying the position and face heading. A dialog pops up and allows you to choose a callsign (one is initially generated), altitude and other details. If near a ground route node, a parking position or runway, you can create it on the ground, ready to taxi or for departure (NB: parking overrides position/heading input).
* Traffic is initially created in an "unspawned" state (radar contact marked "+"), in other words visible to you but not to the student. This allows you to set its transponder or get it into a certain state before spawning it into the student's world.
* Controlling the traffic is done in the same way as in solo sessions without voice, i.e. using the click&drag vector and taxi tools and the instruction dock. The only difference is that you control the selected aircraft directly, regardless of your strip links and details. You therefore do not need a strip and a correctly filled callsign to instruct a pilot, though it is a good idea to have one if you want your vectors registered and drawn on the radar. The traffic creation dialog offers to create a linked strip with every new aircraft.
* You may pause the whole simulation, or freeze each aircraft individually. Frozen aircraft will result in stationary flights on the student's radar.
* The ATC text chat system allows to chat to the student directly as the teacher, and to simulate private ATC conversations with the student (select callsign to interact as).
* To exchange strips, drop them on "Student" and select whom the strip should appear from on the student's side. Note that for your convenience in further control of the traffic, teacher strips do not disappear on handovers;
* CPDLC is supported, the dialogue windows reflecting the change of perspective (ACFT instead of ATC) and the {{key press|Alt}} key combinations generating requests rather than instructions.

[[Category:ATC-pie]]

ATC-pie installation guide

2022-09-04T18:43:42Z

Mickybadia: v1.8.6

{{forum|83|ATC-Pie support & development}}

{{about|installing and configuring ATC-pie|a manual on how to use it|ATC-pie user guide}}

== Installing ==

[[ATC-pie]] is free and open source, and programmed in Python3 for Qt5. It is therefore system-independant, but requires Python3 and its PyQt5 library to run. Otherwise, ATC-pie runs straight after download without any compiling (make, etc.) to do.

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.

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 Git '''repository''':
: <code>git clone git://git.code.sf.net/p/atc-pie/code ATC-pie</code>

I say again: the download/clone alone is not enough; both Python3 and PyQt5 must be installed too. The exact dependencies and required versions are listed in the <code>README</code> file packed in the download.

At this point you have a working program. But further software pieces can be installed to enable more of its features, as listed below. Depending on your use of ATC-pie, they can be recommended for more realism but they are not required, and can be installed later. Also read the <code>README</code> file for extra notes on installation.

For a 3D '''tower view''' (all airport sessions), ''[[FlightGear]]'' must be available, with the appropriate aircraft models and scenery data. Note that it can run on a separate machine, as explained [[#Airport scene rendering|down this article]].

For an integrated '''ATC phone line switchboard''' (all sessions except solo), install ''PyAudio'', plus ''PyMumble'' for FlightGear and FSD sessions.

To enhance solo sessions:
* with '''voice instruction recognition''' by the AI aircraft, install ''PocketSphinx'' (requires ''PyAudio'');
* with '''speech synthesis''' of AI pilots' radio messages, install ''pyttsx''.

To enhance FlightGear sessions:
* with '''[[CPDLC]]''' and '''full ATC coordination''', including unlimited strip exchange and text messaging, install the ''Python IRC library'' (recommended!);
* with '''voice radio simulation''', install the ''FGCom-Mumble'' plugin (requires a ''Mumble''>=1.4 client).

== Running ==

Depending on your system and preference, you might be double-clicking, typing stuff or pulling your hair out. In any case what you must do is run a Python3 interpreter on the <code>ATC-pie.py</code> file from the downloaded directory.

Tip for Windows users: create a shortcut whose "target" is <code>cmd /k Z:\path-to-pie\ATC-pie.py</code>, making sure "start in" is set to the same <code>Z:\path-to-pie</code> and that Python source files are associated with Python3.

=== Two program modes ===
[[File:ATC-pie-screenshot-launcherDialog.png|thumbnail|Initial graphical launcher, with AD vs. CTR mode choice]]
On program start, a welcome launcher window should open, from which you may start a session in either airport (AD) or centre (CTR) mode, i.e. respectively with or without a base airfield.

The '''airport mode''' is for ATC positions like approach or tower control, or any combination of those. In this mode, ATC-pie centres the radar at the chosen base airfield, depicts its tarmac and runways, and enables features like a tower view and active runway selection.

The '''centre mode''' is designed for en-route control centre simulation. It disables all airport-specific features, and allows to place the radar anywhere on Earth. When selecting this mode:
* The location code is a designator of your choice (excluding airport codes), under which to save your location-specific settings. A good idea is to use ICAO airspace designations, e.g. <code>SBBS</code> for the Brasilia FIR in central Brazil or <code>LFFF</code> for the Paris region in France.
* The radar position field specifies the point on which to centre the radar. For example, <code>LFPO>090,15</code> will centre the radar on a point 15 NM to the East of Orly airport. Click on the help button for a summary of valid point specification formats, or read the ''Point specification'' section in the quick reference for more detail.

=== Command line arguments ===
You may bypass the launcher and start directly at a given location with the following command, using an ICAO code for an airport or a previously defined CTR location code:
: <code>./ATC-pie.py location_code</code>

Besides, the following command line options are available:
{| class="wikitable"
! Option || Effect and argument specification || Default
|-
| --map-range=''range'' || Only valid with a location code argument. Defines the distance in NM from the radar centre up to which the map will be drawn and navpoints listed in the navigator (accepted values are 20..500). This does not affect radar range, which can still be greater or lower, and be changed within sessions.' || 100 in AD mode; 300 in CTR mode
|-
| --views-send-from=''port'' || Sets 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 FGMS connection port, chosen on session start. || 5009
|}

=== Starting sessions ===
All session types are started from the ''System'' menu.

Solo simulation:
* wind will be randomised at start, but will be forced to blow in a favourable direction if at least one active runway is selected before start;
* traffic is spawned with intentions according to the ''solo simulation configuration options'' ({{key press|Shift|F11}}), so it is preferable to configure them before starting the session to avoid undesired traffic at start.

FlightGear network session:
* callsigns for ATCs in FlightGear are expected to start with the ICAO code of the controlled airport or sector, and end with a hint on the provided service (twr, gnd, ctr...), e.g. "KORDgnd" (note that FGMS restricts callsign length to 7 characters);
* before choosing your callsign, make sure it is not already in use;
* you can connect multiple ATC-pie instances from the same computer, but you must use a different local port for each one;
* the three "sub-systems" that can be activated support different coordination features and differ in terms of interoperability with other clients, but all can be enabled together:
** '''native ATC-pie coordination''' enables full interaction with other ATC-pie clients (except phone lines), plus CPDLC with FG aircraft;
** '''ATC phone lines''' enables direct voice communications (telephone calls) with other connected ATC-pie clients;
** '''OpenRadar handover compatibility''' implements [[OpenRadar]]'s protocol to enable coordination with its users (will work with ATC-pie clients as a fallback if native sub-system not available), although some limitations apply (see [[ATC-pie#OpenRadar|interoperability note]] in the main article).

== Configuring ==

Here are things you will soon want or have to set up for a regular use of ATC-pie:
* set up a [[#Airport scene rendering|tower view]] to enable visual contact with your traffic in AD sessions;
* for FlightGear and FSD sessions, give yourself a "social name" so that others recognise you when using any of the ATC coordination/exchange features;
* for FlightGear sessions and realistic radio experience, set up an [[FGCom]] system, and test the configuration from the ''System'' menu.

If you intend to operate often at a given location, it is sensible to:
* if it is an airfield location, download the latest airport data file from the [https://gateway.x-plane.com/airports/page# X-plane gateway] and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> file there);
* review and fill the various fields in the location set-up dialog (runway capabilities deserve special focus for more realisitc aircraft intentions in AD solo sessions);
* configure the workspace racks, bays and radar screens to suit the environment and service provided, they will be saved for future runs;
* if using the radar, pin your preferred navpoints (they are restored on every run) and consider creating/importing background pictures to map terrain obstacles, procedure charts, etc. (see [[#Background images|section below]]);
* for solo and teacher sessions at airports especially, build an elevation map (see <code>CONFIG/elev/Notice</code>).

For more advanced editable options, read the <code>CONFIG/Notice</code> file.

=== Airport scene rendering ===
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
A '''tower view''' allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any (X-plane seems only to allow for one, but feel free to declare more for ATC-pie), otherwise defaults to somewhere over the airport to allow towering everywhere. It is disabled in CTR mode.
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 to listen for traffic and accept telnet connections.

Running internally only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the ''System'' settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].

Connecting to an external viewer allows to run FlightGear on a different machine and thereby relieve your session from the CPU load a local instance induces. If you want to do so, get a hint of the required positioning options you should start your viewer with, from the tower view tab in the system settings dialog. Of course, scenery, models and liveries must also be available to the running process.

In either case, once activated from the ''View'' menu, the tower view '''control pane''' is enabled, from which you can turn to runway points, follow selected aircraft... Direct FlightGear input in the view window is also possible: right click and drag allows to look around, {{key press|x}} and {{key press|Shift|x}} change the zoom level, etc.

You can hook up '''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 from the ''View'' menu. Additional viewers are registered by their host+port address, from the ''View'' menu at run-time or from a custom settings file (see <code>CONFIG/Notice</code>) read at start-up and on explicit reload (''System'' menu).

Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
* ''HHH'' is the host on which ATC-pie is running;
* ''PPP'' is the default 5009, or the chosen port number if ATC-pie was started with <code>--views-send-from</code>;
* ''TTT'' is the network polling frequency (100 is common practice; change as desired if you know what you are doing).

=== Background images ===
[[File:ATC-pie-screenshot-backgroundPixmapDrawing.png|thumbnail|Pixmap image example with a terrain map around LIMW (Aosta, Italy)]]
[[File:ATC-pie-screenshot-backgroundHandDrawing.png|thumbnail|Text-specified drawing example with procedures for LSGG (Geneva, Switzerland)]]
Background images allow to decorate:
* radar scopes, e.g. to display procedure routes or airspace boundaries;
* loose strip bays, to work the strips over custom backgrounds, e.g. an airport ground chart.

There are two ways to create a background. One is to '''import a picture''' (pixmap file like JPEG or PNG, including transparency); the other consists in writing a '''drawing specification''' file to paint coloured lines, points and text labels (for radar backgrounds only). See <code>CONFIG/bg/Notice</code> to learn how to import and draw background images.

For example, you can map out procedures (SID, STAR, IAD...), grouping them by associated runways so they toggle together on the radar. Drawings are generally appropriate for that because they avoid manual positioning by directly referring to the points named in the published procedures. But if you want more than schematic line plots and text labels, you should create the picture yourself, for example using an image processing tool like ''GIMP'' and a transparent layer over a real map canvas or a screenshot of your ATC-pie radar with pinned navaids as landmarks.

'''If you have a sector file''' of the format used in VATSIM/IVAO (.sct) for your area, you should try to import it with the provided extraction tool. It will retrieve most of the contents around the open location up to the current map range, and translate it to ATC-pie's native drawing format, although the generated files always require some filtering and post-editing. If you know they are included, it is generally the best option for things like SID/STAR procedures. The way to proceed is as follows:
# Run the "extract drawings from sector file" option (''System'' menu) and select the file to extract from. This generates the following files in the <code>OUTPUT</code> directory:
#* <code>ICAO.lst.extract</code>, a menu file for the generated drawings;
#* <code>bg-ICAO-*</code>, the extracted drawings in the native ATC-pie format;
#* <code>bg-extract.err</code>, a log of the errors detected in your sector file (do not be alarmed as they often contain many).
# Import the results:
#* move or copy-paste lines from <code>ICAO.lst.extract</code> to <code>CONFIG/bg/ICAO.lst</code>;
#* move the desired drawing files under <code>CONFIG/bg</code>, adjusting the paths in the <code>.lst</code> menu as you organise subdirectories.
# Post-editing (cleaning)
#: ATC-pie does its best to understand the objects in the sector file and to group things together depending on their type. But not everything can be guessed automatically. This last step is where you filter, merge and split objects, rename points, change colours, etc. to your liking.
#: Each generated drawing section (point list under a colour) is automatically labelled with the line number where it was sourced from in the sector file so you can easily trace it (<code>@nnn</code>). A tool like ''sed'' will help you get rid of all these unwanted suffixes once you have sorted and renamed your objects:
#:: <code>sed -ri 's/ +@[0-9]+$//' file_to_clean</code>

NB: ATC-pie does not package or source from sector files directly because their data is not free. Besides, a lot of it is usually redundant with the airport sources.

Tips:
* You can check your image configuration without restarting the program, by reloading the files in their current state from the ''System'' menu ({{key press|Alt|F12}}).
* The "image positioning helper" allows to move and resize imported pictures, adjusting the corners visually rather than programmatically if you have no specification for them. All visible pixmap images will be moved simultaneously, so you can work with several at a time if you want to. On dialog box close, a file is generated in the <code>OUTPUT</code> directory for you to copy from.
* An [[OpenStreetMap]] option will take you to the free online map server, centred on your radar centre position. For a quick and dirty start (e.g. for access to coastlines, borders and rivers) you can screenshot the map and use it as a background.

[[Category:ATC-pie]]

ATC-pie

2022-09-04T18:42:36Z

Mickybadia: v1.8.6

{{forum|83|ATC-Pie support & development}}

{{about|the software and its features|a manual on how to use it|ATC-pie user guide}}

{{Infobox Software
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.8.6 (Sept. 4, 2022)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''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);
* "multi-player" network sessions (FlightGear and FSD protocols supported);
* tutorial sessions for teacher supervision of an ATC student.

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.

Its essential goal is realism. It simulates many tasks of real-life ATC such as:
* strip racks and sequence management;
* coordination with neighbouring controllers (handovers, voice phone calls...);
* radar monitoring and identification of traffic;
* vectoring and course/level conflict anticipation;
* flight plan operations;
* CPDLC...

To install/configure the program, refer to the [[ATC-pie installation guide]].

== Screenshots ==

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Solo session with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

== Detailed feature list ==

=== Sessions and environments ===
Session/connection types:
* solo simulation (AI traffic)
* FlightGear network connection ([[FGMS]] protocol)
* FSD connection (as served by https://github.com/kuroneko/fsd commit bc7d43, latest available in April 2020)
* teaching service (spawn and simulate traffic visible to a connected student)
* student session (control traffic simulated by teacher)

{| class="wikitable" style="text-align:center"
! || Solo || FlightGear || FSD || Tutoring (teacher/student)
|-
! ACFT traffic
| AI aircraft generated according to RWY capacities, ACFT equipment, intentions...
| colspan="2" | connected flight sim pilots
| created and simulated by teacher
|-
! ATCs for coordination
| virtual ATCs depending on assumed positions
| colspan="2" | connected ATC clients (full ATC-pie support, [[#Interoperability with other software|interoperability with other software]])
| teacher-configured ATCs
|-
! Voice radio
| voice recognition for instructions (mouse-only also available) and synthesis for pilot read-back
| FGCom integration: [[FGCom-mumble]] plug-in or legacy [[FGCom_3.0|stand-alone]] variant
| working PTT but third-party audio system expected
| teacher simulates pilots
|-
! ATC phone lines
| rowspan="2" | N/A
| colspan="2" | integrated Mumble connection
| teacher simulates ATCs
|-
! Flight plans
| 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)
| virtual online system
|-
! Weather
| randomised and evolving
| real world METAR retrieval
| fetch from server or retrieve real world METAR
| controlled by teacher
|-
! Other specific features
| style="text-align:left" |
* aircraft type and airline choice with custom appearence in tower view
* configurable airspace rules and traffic density, incl. uncontrolled distractors
| style="text-align:left" |
* multiple radio support with simultaneous transmissions and monitoring
* voice ATIS recording
| 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
|}

Location modes (available for all sessions):
* airport (AD): positions such as TWR, GND, APP, DEP at a selected airfield
* en-route centre (CTR): free positioning of radar, no base airport or runway-related options

=== ATC surveillance ===
Radars and tracking:
* SSR mode capability selection (none/A/C/S)
* primary radar toggle
* 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
* 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)

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 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

=== Communications ===
With aircraft:
* voice radio with 8.33 kHz frequency spacing
* [[ATIS]] recording and reminder alarm (see [[:File:ATC-pie-screenshot-ATISdialog.png|dialog]] with pre-filled notepad)
* [[controller-pilot data link communication]] (CPDLC), incl. multi-element messages
* text radio chat with preset messages, auto-completion, predefined and custom aliases (context-sensitive replacements), sender blacklist

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

=== 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 [[: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

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)
* 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:
* OpenRadar to ATC-pie: FGMS callsign will appear on the strip, as if the sender had filled the detail herself;
* 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 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.

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. 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:Air Traffic Control]]

ATC-pie FAQ

2021-12-19T18:12:21Z

Mickybadia: v1.8.5

{{forum|83|ATC-Pie support & development}}

This page is a collection of questions asked at least twice about [[ATC-pie]]. It is a good idea to search through it before repeating a question on the forum or anywhere.

== Things "not working" ==

=== This aircraft is connected but I am not seeing it on my radar. ===
You only see an aircraft on your scopes if a radar contact is established, i.e. if it is visible to the primary radar or if the secondary radar (SSR) picks up a transponder signal from it.

The following cases will therefore prevent you from seeing a connected aircraft:
* The radars are turned off. Turn on at least a primary radar from the ''Options'' menu, or an SSR capability from the ''Radar'' tab in the ''Local settings'' dialog (any setting other than "none" will pick up contacts).
* The aircraft is out of radar range. It can be under the radar floor (minimum signal pick-up alt.) or too far out. In the radar settings, check the floor ("SFC" will pick up all signals down to the ground) and horizontal range. Primary and secondary radars share the same range.
* Its onboard transponder is turned off (and primary is off); see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Otherwise if you accept cheating, you can activate the "radar cheat mode" which will simulate a mode S transponder for all aircraft in horizontal range; see [https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3].

=== Connected pilots do not receive my text messages. ===
This happens with pre-2017.2 clients if you are using the latest protocol to encode properties. Tick the FGMS system option to "use the legacy protocol" for property encoding. Everybody should be able to read you, but it will come at the expense of network throughput. Tell those pilots to upgrade their client.

=== FGCom is not working. ===
First, verify that the FGCom variant selected in the ''system settings'' is the one you want to use. Check that your sound is on, your volume loud and your microphone working (system sound monitor picking up a signal). Close all open sessions and open a single ATC-pie instance.

If you have chosen the '''standalone''' FGCom variant, take the steps below in order:
# Echo test
#: Start a standalone FGCom configuration test from the system tools menu. While the test is running, speak in the microphone and check if you can hear yourself back. If so, you may skip directly to step 4.
# Path to executable
#: Verify the FGCom command entered in the system settings. It should contain an executable system command or a relative or absolute path to an FGCom executable file. If you have FlightGear installed on your machine, you can point to the FGCom executable already available with it. On Linux, the default "fgcom" command usually does the job. Otherwise, [https://sourceforge.net/projects/atc-pie/files/fgcom-standalone/ download an FGCom standalone program] from ATC-pie's SourceForge file list. In any case, try the entry from a terminal in the ATC-pie directory to manually check that it runs correctly.
# FGCom server status
#: The server may temporarily be down, unfortunately even for up to a few days. Check for responses from the server, e.g. with <code>ping fgcom.flightgear.org</code> (adjusting the server name to match the one entered in the settings). FGCom will not work without a responding server.
# FGCom subprocess error
#: After turning your radio on, check for errors in the logged FGCom output files in the <code>OUTPUT</code> directory.
# Port mess-up in your session?
#: When creating a new radio box at run time, make sure you choose an available port number for each. Caution when running multiple ATC-pie instances: do not use a port more than once across the system at the same time.

If you have chosen the '''FGCom-Mumble plug-in''':
# Plug-in status
#: Check that your Mumble client is connected and properly running the FGCom plug-in.
# Port setting
#: Check that the control port in ATC-pie is set to the one FGCom-Mumble is listening on.
# Echo test
#: Start an FGCom-Mumble configuration test from the system tools menu.

Note that the two variants are ''not'' interoperable. Users will only be able to hear and interact with others using the same variant (and server) as their own.

=== Recording ATIS with standalone FGCom: no beep is heard after pressing "record". ===
Assuming FGCom standalone is working (confirm this with an echo test before reading on)...

Due to the design of this legacy FGCom variant, you may only record an ATIS if the requested frequency is enlisted as recordable on the distant server's "phone book" for the airport. The one for <code>fgcom.flightgear.org</code> was compiled a while ago, based on the latest <code>apt.dat</code> at the time. It filtered the frequencies through the two following conditions:
# it is of the "recorded" type (row code 50);
# its name contains the uppercase string "ATIS".

If you are relying on the old data provided by ATC-pie, in other words you have not downloaded new data or edited the frequencies yourself, check against the <code>.dat</code> file extracted in the <code>OUTPUT</code> directory on your side, as it should still be similar to the one on the server's side. One of the two conditions is probably not met, or the frequency missing. NB: The frequencies in the ATIS drop-down list of ATC-pie are matched against the condition (1), but not against the somewhat restrictive condition (2).

In any case, consider switching to the newer FGCom-Mumble plug-in variant. It simulates radio waves, frequencies and ranges, which avoids the phone book problem all together.

=== Tower view is not starting. ===
Ruling out that FlightGear is not installed at all, your system path settings are probably wrong. From a terminal or a file system navigator, find the right command to start FlightGear and enter it as ''FlightGear executable'' from the system settings. Do not add options of any kind; they will be taken care of internally. You may have to enter a ''FlightGear root directory'' as well, especially if you have the program files installed somewhere unexpected.

=== My tower is in the middle of the sea, and aircraft floating/landing on water! ===
You are missing the FlightGear scenery data for your location, or ATC-pie does not know where it is. If you have downloaded scenery and saved it somewhere, have you tried filling the scenery directory with that location in the system settings? Also check out the ''Tower viewing'' [[ATC-pie_user_guide#Tower_view_window|feature note]] in the user guide.

=== Simulated aircraft appear to dip underground or levitate over taxiways. ===
Do you have a ground elevation map for the location? Quoting from <code>CONFIG/elev/Notice</code>: "''When no elevation map is found for an airport, the field elevation value is used everywhere on the ground. This should be OK for a rough approximation on flat terrain, but ground traffic will not follow any slopes, thus may appear as floating above the ground, or dipping into it.''" Read the full notice for instructions on how to build your elevation map.

Once you have one or decide that your field is flat enough, the next focus is on the FlightGear aircraft models. Each model has its own coordinate system chosen at developer's discretion. ATC-pie must be given the height difference between each model's origin and the aircraft touch-down point (gear wheels) to position aircraft more accurately. You can do this on a per-model basis with ":height" specifications in <code>CONFIG/acft/icao2fgfs</code>. Read the associated <code>Notice</code> section for more information.

=== Phone lines have broken, choppy or dragged out sound ===
You and the other parties must adjust microphone sensitivity. Toggle the phone squelch adjustment box from the system menu and tune the spinbox next to the "call" button in the ATC coordination panel. Lower values will decrease the threshold for sound pick-up and likely break the sound less, but can generate more lag in the communications. The right balance depends on your local configuration, so a few test calls with other connected ATCs will be necessary to decide on the best acceptable value.

=== I cannot connect to my teacher as a student. ===
Using IPv4 addresses, this typically happens when the teacher is in a local area network behind a router. It is a common setup for home internet, in which the teacher's actual host address is not publicly accessible from outside his private network.

If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either:
* for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local host address;
* or to create a virtual network, using a third-party VPN service.

== What is ...? Why is ...? What value/setting for ...? ==

=== What "social name" should I use for FlightGear/FSD sessions? ===
Choose any name you would like to be recognised by on the network. In ATC-pie, it will appear in the tool tip over your callsign for connected ATCs who see you. This feature is only social in the sense that it does not refer to an account or to anything technical, but it makes sense as typical ATC callsigns (e.g. "VHHHtwr") remain mostly anonymous. Use this field to identify yourself on the network.

=== Are the vector headings true or magnetic? ===
Heading displays in ATC-pie are mostly magnetic so they can be read out to pilots. The exceptions are the navigator and handover list tool tips, which show true radial headings from the radar position, and the teacher's wind section to match the generated ATIS string.

Also note: all directions are geodesic, i.e. initial headings to take on a great circle.

=== What is the purpose of the flat "strip shelf" button in the strip panes? ===
More than a button, the strip shelf is where you should drop the contacts you release without a handover, e.g. parked traffic shutting down, VFR traffic flying out of your airspace, etc. Clicking on the shelf allows to browse the previously shelved strips, and to recall them, for example if shelved inadvertently.

=== What do the various markings along the approach centre line mean? ===
The regularly spaced groups along a centre line represent altitudes on the approach plane. Each group sums up to an AMSL value in accordance with the set flight path angle (also see ''Display conventions'' in the quick reference):
* straight line = 1,000 ft;
* solid diamond = 5,000 ft.

The other markers drawn with thicker lines are the positions of the ILS marker beacons (OM, MM, IM), the line pattern representing the sound triggered by the beacon in the pilot's headset. They are sourced on program start-up from the navigation data (<code>CONFIG/nav/navaid.dat</code>).

=== Why do I keep getting runway incursion alarms? ===
Because you have the runway occupation monitor turned on (''Options'' menu), while not using your runway boxes. The alarm triggers when the radar detects traffic stepping on a runway in either of the following situations:
* the runway is active (marked in use) and no strip is boxed for it;
* it is reserved but there is already traffic on the runway;
* it is reserved for a different aircraft: the boxed strip is linked to a contact that is not the entering aircraft, or the aircraft is linked to a strip different to the one boxed.

Turning the runway occupation monitor off will deactivate all radar warnings regarding runways. If you are interested in the strip boxing and visual runway highlighting system but bothered by the alarm sound, you can mute the sound notification by unticking it in the general settings.

== Where is ...? How to ...? ==

=== Can I draw SID and STAR procedures on the radar? ===
Yes, and virtually anything else, using background images. To learn about those:
* see the corresponding [[ATC-pie_installation_guide#Background images|installation guide section]];
* read the <code>CONFIG/bg/Notice</code> file.

=== How do I assign SIDs and STARs to aircraft? ===
This question is asked quite a lot more than it is relevant to a real controller's task...

What people seem to be after when asking this question is a way to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. The way to handle this is to stack your inbound strips on racks named after your STARs. Racks are indeed above all meant for efficient traffic sequencing. Every rack represents its own sequence of ordered aircraft, which is perfectly suited to control separate approach paths in parallel. With this technique, placing a strip on a STAR-named rack basically serves as the "assignment" itself. Similarly, runway-specific racks can keep track of separate landing sequences at large airports. Then you can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times in the sequence all the way to touchdown.

If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. Routes are lists of waypoints and instructions to follow between the two end airfields. Normally pulled straight from properly filed flight plans, routes are printed on strips prior to departure, then modified as the flights progress and passed along with handovers. Standard departure and arrival procedures (SIDs and STARs) can be referred to in those routes, but only by their entry or exit navpoints. They should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. For example, routes ending with a STAR should end with "FUBAR STAR", which means that waypoint FUBAR is an entry point from which a published STAR must be followed. The keyword "STAR" is in fact a mere specification for the last route leg. Similarly, routes of the form "SID DUMMY ..." specify their first leg as a standard departure to the first waypoint DUMMY. "SID" and "STAR" keywords are recognised by ATC-pie and accounted for in the second line of the radar tag when appropriate (see feature note on routes).

One meaningful wish regarding this question is for easy '''reference in text chat''' messages. Firstly, using racks in the way suggested above, you can use the <code>$rack</code> alias which is substituted by the name of the rack on which the current strip selection is stacked. Otherwise, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". Now if you specifically want to assign a full procedure name like FUBAR1A to a contact and refer to it in a generic text chat message, include a line "sid=FUBAR1A" 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 expanded in your sent messages when that strip is selected.

=== How to set the transition level? ===
You do not. You can however set the transition altitude in the location settings if your airport specification file does not already include one.

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, e.g. for more vertical separation on either side of the transition layer or due to coordination with neighbouring zones and fields.

=== Can I look up ILS frequencies? ===
Yes, in the ''environment info'' dialog.

Besides, you can create aliases with the local notepad for a quick and integrated way of sending them through text chat, which will be saved when you close ATC-pie. For example, use the following format, one runway per line: <code>ils05=111.11 MHz</code>. See [[ATC-pie_user_guide#Public text chat|custom text aliases]] for more.

=== The navigation/airport data is outdated. How can I update it? ===

For '''airport data''' (taxiways, parking positions, frequencies, etc.), the included source is the last world-wide <code>apt.dat</code> compiled before it became too large to maintain as one huge file. We keep it there because it allows to run ATC-pie anywhere in the world without requiring external data, but its contents grows out of date with time. You should check for more recent sources on the [http://gateway.x-plane.com/airports/page X-plane airport gateway], directly accessible from the ''System'' menu, on a per-airport basis. Extract the <code>apt.dat</code> file from the download, rename it after the airport's ICAO code (keeping the extension, e.g. <code>KJFK.dat</code>), and place it in <code>CONFIG/ad</code> (also see the <code>Notice</code> there). Alternatively, for a quick manual touch-up of the included data, you can move and edit extracted files (see <code>OUTPUT/Notice</code>).

For '''navigation data''' (navaids, fixes, airways, etc.), the included data is the latest version of each file that was seen released as GPL, which makes some of it date back to 2013! You should provide more recent navigation data, as explained in <code>CONFIG/nav/Notice</code>.

=== How do I customise the GUI and colours? ===
To change the '''radar or strip drawing colours''', edit the <code>CONFIG/colours.conf</code> file. Each line specifies the paint colour for an object type, in a typical hex <code>RRGGBB</code> (red-green-blue) format or as an SVG colour keyword name like "white". To customise the '''main session window''', place a ''Qt stylesheet'' named <code>main-stylesheet.qss</code> in the <code>CONFIG</code> directory. ATC-pie will apply it to every session window. While you are working on your look and feel, use the reload feature from the "System" menu to avoid restarting after every change.

Send us screenshots and share your files if you find a setup looking really cool! :-)

== Miscellaneous ==

=== What's with the funny name? ===
ATC-pie is written in Python, and I reckoned that the ''pyXXX'' naming habit was becoming a little dull, so I merely switched things around. You can surely do the rest of the math in terms of spelling, and later impact on the logo.

=== Why is the learning curve so steep? People would use your program more if you did/provided [...] ===
Often continued with: '''(you must understand that) this is not VATSIM!'''

We do have a [https://sourceforge.net/p/atc-pie/wiki/Wishlist wish list] and will consider any feature or help request. However, though it has a few cheats, ATC-pie has always choosen realism as a criterion for implementation and design, over the mere incentive of converting otherwise happy users of other programs. It is a good thing that different philosophies and work flows are available out there, and there would be much less interest in having them all copy each other, fighting over users instead of understanding that not all of them wish for the same experience. If serious simulation or learning new skills sound like threats to fun for you, you have a perfectly valid reason not to opt for ATC-pie.

[[Category:ATC-pie]]

ATC-pie user guide

2021-12-19T18:11:38Z

Mickybadia: v1.8.5

{{forum|83|ATC-Pie support & development}}

This article is a guide to the air traffic control simulation program [[ATC-pie]], describing some of its major features. A more exhaustive list can be found in the main article. For download and installation help, refer to the [[ATC-pie installation guide]]. For support and troubleshooting, the [[ATC-pie FAQ]] might get you an answer first. Otherwise kindly ask on the dedicated FlightGear sub-forum so that the discussion is public.

Other sources to learn the program are:
* the online [https://www.youtube.com/playlist?list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb video tutorial];
* the in-app ''Quick reference'' available from the ''Help'' menu (summary of mouse/keyboard gestures, display conventions...);
* a skilled teacher to connect to as a student (personal training);
* to [[#Solo_sessions|train solo]]!

== Flight strips ==

Whether dematerialised or on physical paper, printed out or filled by hand, the '''flight progress strip''' is the essential piece of air and ground traffic control. Every aircraft in contact is represented by a unique strip, and every strip represents a contact. This helps to ensure that no aircraft is ever forgotten about. Strip positioning and updating then enable to monitor the aircraft's status, sequence number, position, intentions, etc.

=== Strip details and linking ===
A click on the "new strip" tool bar button (shortcut {{key press|F2}}) or double-click on an empty strip rack or bay space will open a dialog to fill flight details on a fresh blank strip, e.g. destination, type of aircraft, etc. Double-clicking on an existing strip allows to edit the filled details.

If providing radar service, strips should be '''linked''' to identified contacts to inform the radar display with the filled details and enable joint selection. To link a strip to a radar contact, select one and middle-click on the other. Conflicts between the strip details and the values squawked by the linked transponder contact are reported: the strip displays a "!!XPDR" warning and the strip dialog labels the conflicting details.

A strip can also be linked to a filed flight plan (FPL). This will make radar and strip display fall back on filed information for missing details. The strip dialog also shows the mismatching information between the two, though this is rather common because the strip typically gets updated as the flight progresses.

All together, a selection can involve up to three linked elements: strip, radar contact, flight plan. You can pull details from linked elements to strips (strip panel bottom menu), and push strip details to their linked flight plan if necessary (strip dialog bottom tick box). Unlinking is possible with {{key press|Shift}}+middle-click. If you use linking carefully, auto-fill options are available from the general settings, to fill blank strip details with newly-linked information.

For fast and efficient service, every initial contact by a pilot should basically make you hit {{key press|F2}} and type the spoken callsign. You should then soon figure out if, for example:
* a flight plan is already filed: a matching FPL count is displayed near the callsign field as you type, if any (click on the button to view them);
* a flight plan must be filed (e.g. IFR departure not filed by lazy pilot): select "new FPL" from the bottom line to open a fresh FPL detail sheet to link to the strip;
* he was asked to contact you by a previous ATC, in which case you may have a strip handed over to you already;
* it is a new contact: keep filling the strip with details the pilot gives you.

=== Strip placeholders ===
ATC-pie provides with three types of placeholders for flight strips: ''racks'', ''loose strip bays'' and ''runway boxes''. According to your ATC position and local facilities, you should choose and arrange your placeholders for optimal control. Strips can then be moved between them using mouse drag and drop.

[[File:ATC-pie-screenshot-stripRacks.png|thumbnail|Strip rack panel]]
A '''strip rack''' is the preferred way of keeping track of a sequence, e.g. a departure queue at a runway threshold. Rack panels can be created from the main window workspace, popped out as separate windows, and a persistent one can be found among the available docks. You can create as many racks as you wish in every panel. Double click on a rack's name to rename it or edit its properties. Use mouse drag to move strips up and down a rack sequence.

A '''loose strip bay''' allows free-hand positioning of strips in its reserved space. Such bays are useful for unsequenced traffic, or to map out relative positions when controlling without a radar. You may also import background images, e.g. a ground chart to keep visual track of taxiing aircraft and vehicles. See <code>CONFIG/bg/Notice</code> to learn how.

[[File:ATC-pie-screenshot-runwayReserved.png|thumbnail|Reserved runway marked in yellow]]
A '''runway box''' is a placeholder for a single strip, named after a physical runway and denoting a clearence to use it (enter, cross, land...). Runway boxes are contained in their own dock, with one made visible for each runway marked as in use in either direction. Thorough use of runway boxes will help you avoid bad mistakes like clear an aircraft to land over lined up traffic. When freed, runway boxes start and display a timer together with the wake turbulance category of the last contained strip to help with TKOF/LDG separation. What is more, if you use radar, a filled runway box marks the runway as ''reserved'' on the scope.

Besides, there are two other places a strip can be dropped on, usually when releasing a contact:
* an ATC callsign in the ATC panel to initiate a handover;
* a '''strip shelf''' (flat button at the bottom of loose and racked strip panels), which clears the strip from your workbench and stores it as shelved.

== Vectors, routes and separation warnings ==

ATC-pie can register and analyse issued vectors and routes to:
* inform strip and radar display;
* help monitor traffic, checking tracked positions against route/vector assignments;
* help manage traffic, anticipating route and FL conflicts between controlled aircraft.

=== Vectors ===
[[File:ATC-pie-screenshot-courseAndAssignmentsGraphics.png|thumbnail|Course/vector drawing for linked radar contact]]
Registering vectors on strips enhances the drawing of linked radar contacts, enables easy monitoring of tracks and detection of aircraft flying off course. To register vectors automatically when a radar contact is linked to a strip, use the following mouse gestures:
* click and drag out of a radar contact to issue a heading vector;
* holding {{key press|Shift}}, click and drag vertically for altitude/FL vectors;
* holding {{key press|Shift}}, click and drag horizontally for speed instructions;
* holding {{key press|Shift}}, double-click on the radar target to clear registered vecors from the linked strip.

See [https://www.youtube.com/watch?v=BvA3MRlGJjU video 5] of the tutorial for more on vectoring, and check the quick reference ''display conventions'' to interpret the lines and colours of the course and vector graphics around radar contacts.

NB: In network sessions, an appropriate text chat instruction is suggested for every mouse vectoring action. This allows you to send it easily, for example to pilots whose communications are limited to text chat.

=== Routes ===
[[File:ATC-pie-screenshot-routeDetailsView.png|thumbnail|Route details dialog with world path drawn, available when both end airfields are recognised]]
A route is analysed for every strip with recognised departure and destination airports (entry fields both turned green), 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);
* if ambiguous (navpoint names are not all unique around the world), a waypoint is always the nearest homonym to the point beginning the leg;
* other tokens are kept as route leg specifications to the following waypoint (e.g. airways between fixes).

[[File:ATC-pie-screenshot-routeDrawing.png|thumbnail|Assigned routes are drawn as dashed lines on the radar scope when linked to contacts]]
Routes on flight plans and strips are viewable in a route dialog, showing geodesic paths, headings and leg distances on a world map. When a specified route is linked to a radar contact, ATC-pie works out its current leg based on distance to destination, and:
* details of the current leg are displayed in the selection info pane, and the route viewing button enabled;
* the strip shows only the remainder of the route for this contact;
* the route to go is drawn as a dashed line on the radar (unless aircraft is inbound and near enough);
* the radar tag 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.

NB: If DEP and ARR airports are not both recognised, radar tags show the strip destination detail if it is filled, possibly with a heading if it is recognised.

See tutorial [https://www.youtube.com/watch?v=LfdukpBc90w video 7] for a demonstration of routes.

=== Conflicts and anticipation ===
[[File:ATC-pie-screenshot-routeConflictDetection.png|thumbnail|Route conflict depiction]]
ATC-pie 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 aircraft with a linked strip and an assigned route or heading. 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. When the projections of two aircraft intersect, a conflict is anticipated if the respective intervals between the current and assigned altitudes overlap. When an aircraft's altitude is unknown, the assigned altitude will be assumed. If an altitude assignment is missing, a ''possible'' conflict is reported.

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 || Thick bright red intersecting circles || Separation loss between aircraft
|-
| Path conflict || Red circles and paths || Anticipated paths and altitudes are intersecting
|-
| Possible path conflict || Yellow circles and paths || Paths intersecting but some altitudes unknown
|}

== Communications with aircraft ==

=== Voice radio ===
In solo sessions, voice radio interaction is simulated through speech recognition of instructions and read-back synthesis. Use the {{key press|Ctrl}} key to PTT.

In FlightGear network sessions, multiple radios can be opened and tuned in simultaneously. You can transmit on either one by holding down the PTT button of the chosen radio, or on a selected set (''Kbd PTT'' boxes ticked) using the {{key press|Ctrl}} key. This lets you PTT on multiple frequencies at once (merged frequencies), for example to service GND+TWR frequencies in view of splitting them seemlessly again later. Note that while you will be broadcasting on, and hearing incoming transmissions from, all frequencies, pilots will not be hearing each other across frequencies. To monitor frequencies without attending them, a trick is to set their volume to "soft" to tell them apart.

Note: Except for solo sessions, you may always use an external voice communication program like [[Mumble]] for radio. It is even necessary in FSD sessions, which do not integrate radio natively. In this case, try making the same {{key press|Ctrl}} key the PTT to preserve other features such as RDF for receiving stations, or the ''PTT turns off notification sounds'' option recommended if not wearing a headset.

=== CPDLC ===
When [[CPDLC]] is serviced (location setting), aircraft can establish a data link from their cockpit for a direct text communication channel supplementing the radio frequency. You can monitor connections from the CPDLC dock and open a window for each active or terminated connection in the CPDLC history. Combining the {{key press|Alt}} key with a double-click on a strip or radar contact opens the current or latest dialogue for the selected callsign.

Each active CPDLC dialogue window allows to manually compose preformatted or free text message elements. But the most frequent and convenient way of creating message elements is to combine the {{key press|Alt}} key with a mouse gesture (also see ''Mouse gestures'' in the quick reference):
* click-and-drag vectoring gesture to send a heading, altitude/FL or speed instruction (see [[#Vectors|section on vectors]]);
* strip drop on an ATC to initiate a CPDLC authority transfer or to send the aircraft a "contact" instruction;
* "OK" button click in the instruction panel to send the corresponding formatted instruction.

Created message elements are appended to the message buffer in the connection dialogue window until you send the message manually. The other party must then acknowledge it before it times out.

=== Radio text chat ===
Although voice communications should be encouraged for realism whenever possible, ATC-pie has a powerful text chat system for keyboard interaction with pilots in network sessions. In FlightGear sessions, all messages from within at least 100 NM and up to the radar range are visible in the chat. In FSD sessions, whose protocol simulates text frequencies, ATC-pie tunes the chat to the "publicised frequency" in the radio panel.

'''Text aliases''' are dollar-prefixed words that ATC-pie tries to replace with context-dependant values when sent. For example, <code>$metar</code> expands to the current primary station weather. This allows to write and save formatted messages instead of repeating chunks of a recurrent format. For instance, anybody will enjoy the comfort of sending "Current weather is $metar" instead of copy-pasting a weather look-up for every such message.

Aliases can be predefined or custom. Predefined aliases take values that are specified by the program, e.g. <code>$metar</code>, and may depend on the local environment (declination, airport elevation...), on your configuration (transition altitude, runways in use...) or on the current selection (QDM to airport, assigned route...). They are all listed with their meaning in the "quick reference", ''Text aliases'' section. Make sure to take a look.

All other aliases will be considered custom, in other words to take values specified by you. You can define text aliases on three different levels:
* world (saved for replacement anywhere that the program will be opened), in the general notes (notepad dock);
* location (saved for this airport or centre), in the local notes;
* single aircraft contact (by selected strip), in the strip comments.

Here is how ATC-pie decides what to do with a text alias of the form <code>$foo</code> in a sent message:
# If it is one of the predefined list, the specified substitution is performed. If not, it is a custom alias and we carry on to the next step.
# Look for a line beginning with <code>foo=</code> in the general notes. If one is found, the alias is replaced with what follows the '<code>=</code>' character.
# Look for a line beginning with <code>foo=</code> in the local notes. If one is found, the alias is replaced with what follows the '<code>=</code>' character.
# If a strip is part of the current selection, search likewise in its comment field and substitute if the search succeeds.
# Substitution is unsuccessful. ATC-pie will open an edit box so that you can review your message before sending it.

Moreover, ATC-pie strips everything up to the first '''pipe character''' (<code>|</code>) in the message if any, before it is processed and sent. You may test this by sending "stripped part|sent part" and observe that only the "sent part" makes it to the message contents. You can therefore make your life easier with piped shortcuts in your preset message list. They will pop up like any other message in the filtered menu as you type. For example, the following preset message enables something like a dot-command for sending a bearing to your base airport in a few key strokes:
: <code>.qdm|Heading to airport $qdm</code>

Lastly, if a troll or angry user is polluting your session with undesired messages, add their callsign to the '''senders blacklist'''. All messages from the user will then be filtered out from the message pane. You can view and clear this list at any time.

== ATC coordination ==

"ATC coordination" refers to the following:
* strip exchange, i.e. sending and receiving strips (handovers);
* ATC phone lines, for private voice calls (except in solo sessions);
* CPDLC authority transfers (except in FSD sessions);
* ''who-has'' requests, to query ATCs about who is claiming control of callsigns;
* ATC text chat, to exchange text messages between ATCs (except in solo sessions).

=== Strip exchange ===
[[File:ATC-pie-screenshot-receivedStrip.png|thumbnail|Example of a strip received from "GND"]]
To hand a strip over, drag it and drop it on the recipient in the list of controllers in the ''ATC coordination'' dock. A received strip appears with an identification of the sender which disappears as soon as the strip is clicked on.

A received strip lands on the collecting rack set for the sender if any (double-click on a rack name to add an ATC callsign from which to collect strips), or on the "Default" rack otherwise. It may link automatically to an identified radar contact according to the selected auto-link options (general settings).

See [https://www.youtube.com/watch?v=oQIud-cAlT4 tutorial video 6] for a presentation of the feature.

=== ATC phone lines ===
Phone lines allow to call and talk to other ATCs directly from the ''ATC coordination'' dock. Each line has an outgoing state that you control, toggling between open and closed with a double-click on its phone icon. Opening a line places a call to the connected ATC, showing as "incoming" on their side. When two parties have their line open to one another, they are in direct communication (no push-to-talk). In other words, opening an incoming call puts you on the phone with the caller. Closing a call hangs up the active line, but you can pick it back up as long as the other party holds it open ("still incoming" for you).

You can only talk to one ATC at a time but may place multiple outgoing calls. If a call you placed is answered while you are in another call, the answered call switches to show as incoming without interrupting the one in progress. Conversely, opening (answering) an incoming call while already in another call drops the current line. If an incoming call you answer turns to "placed" (outgoing only) instead of "in progress", the other party was already on the phone and is now seeing an incoming call from you.

=== ATC text chat ===
The ATC text messaging system allows to chat with other ATCs in channels that are separate from the "radio text chat" read by pilots. It offers private channels for one-to-one conversations, and a general ATC chat room in network sessions, readable by all connected ATCs.

'''Note on interoperability in FG sessions''': While only ATC-pie integrates ATC text chat in its interface, other users can join the same channel with a regular IRC client. They will be able to send and receive public and private messages and chat with everybody, at the only cost of ignoring the system messages that will sometimes appear on their side. For best results, they should use their FlightGear network callsign as their IRC nickname.

== Solo sessions ==

In solo sessions, you control virtual IFR planes, receiving and handing over strips to virtual ATCs depending on your position and the aircraft's intentions. You can train as an en-route controller in CTR mode, or as an airport controller in AD mode, where four combinable positions are available:
* ground (GND), to taxi aircraft between parking positions and runways;
* tower (TWR), to control runways and immediate surroundings;
* departure (DEP), to bring departing traffic to their exit point;
* approach (APP), to vector arrivals onto final.

=== Objectives ===
In '''CTR mode''', your task is to transit the aircraft across your airspace, always ensuring separation, and to hand each of them over to the most appropriate neighbouring centre North, South, East or West of your sector. You can specify local navpoints in the location settings so that the system includes them as turning points in the randomised aircraft routes.

In '''airport mode''', traffic is either inbound or outbound. Assuming APP, inbound aircraft must be sequenced and vectored into tower range for handover, unless you are in the TWR position as well. Each inbound aircraft either requests ILS or visual. Assuming TWR, you must clear them to land when appropriate, i.e. cleared for ILS approach or expected runway reported in sight. If landing cannot take place (too high, not cleared...), aircraft will go around. Controlling GND, you must move inbound traffic near their parking position once they have vacated the runway, and hand them over to the ramp. Outbound traffic must be brought to hold short of a runway threshold and report ready for departure with TWR. If you assume DEP, you must hand outbound aircraft over to the en-route centre (CTR) once they are high enough and close to their exit point if specified in their route. Entry and exit points are configurable in <code>CONFIG/nav/AD-entry-exit</code> (see <code>Notice</code> in the directory).

[[File:ATC-pie-screenshot-handoverPane-solo.png|thumbnail|Handover pane in an AD solo session, assuming all three available positions]]
{| class="wikitable" style="text-align:center"
|+ Handovers with virtual ATCs in airport mode
|-
| || colspan="2" | Departure strips || colspan="2" | Arrival strips
|-
! Assuming positions || Receive from || Hand over to || Receive from || Hand over to
|-
! GND only
| DEL || TWR || TWR || Ramp
|-
! TWR only
| GND || DEP || APP || GND
|-
! DEP only
| TWR || CTR || colspan="2" | N/A
|-
! APP only
| colspan="2" | N/A || CTR || TWR
|-
! TWR+GND
| DEL || DEP || APP || Ramp
|-
! TWR+DEP
| GND || CTR || APP || GND
|-
! TWR+APP
| GND || DEP || CTR || GND
|-
! APP+DEP
| TWR || CTR || CTR || TWR
|-
! TWR+GND+DEP
| DEL || CTR || APP || Ramp
|-
! TWR+GND+APP
| DEL || DEP || APP || Ramp
|-
! TWR+APP+DEP
| GND || CTR || CTR || GND
|-
! All 4
| DEL || CTR || CTR || Ramp
|}

=== Instructing aircraft ===
[[File:ATC-pie-screenshot-taxiInstructionTool.png|thumbnail|Click&drag taxi instruction tool at OMDB ground]]
Instructions are given through different means:
* provided the speech recognition modules are installed, you can turn on voice instructions from the solo simulation settings dialog and instruct aircraft through your microphone, using the {{key press|Ctrl}} key as push-to-talk and standard phraseology (see the quick reference tab about it);
* if voice instructions are turned off:
** mouse vector assignments issue the corresponding instructions (see section on vectors above);
** handoffs are issued when dropping strips on an ATC receiver;
* instruct taxi routes by dragging out of radar contacts when they are considered on the ground (low enough or squawking GND);
* the dockable instruction panel works regardless of voice vs. mouse selection;
* alternatively, if the aircraft is connected to CPDLC, you can send instructions through the [[#CPDLC|data link]].

Instructions from the panel are always issued to the callsign entered in the top field, which should fill automatically on aircraft or strip selection when a callsign is known. Therefore, make sure you do not mess up your strip links or your instructions will realistically be acknowledged and followed by the wrong aircraft.

=== Need a scenario? ===
Things you can train for:
* towering a single runway with mixed traffic: select TWR position and an equal balance of departures and arrivals;
* optimising approach spacing in dense traffic: select APP position only, increase traffic density, turn on spacing hints and try to stabilise them all at "3:00" for example;
* change of runways (e.g. irl after wind direction change): start with APP+TWR and select a runway for arrivals at least, run the simulation for a while and change for opposite runway use;
* CTR mode with a low ceiling to increase the number of conflicts to resolve;
* etc.

== Teacher & student connections (ATC tutoring) ==

This session type is made to bring an ATC student and a teacher together for tutorial sessions. To '''set up a session''', the student must connect to the teacher, so make sure the teacher's session is running first. Only one student can connect to a teacher at a time. The teacher creates and manipulates traffic for the student to work with, controls the weather and decides on the ATC neighbours. Strip exchange and ATC text chat is possible, either between both parties ("offline" exchanges) or between the student and the virtual ATCs (in-sim coordination). All exchanges are monitored by the teacher, and transparent to the student. The teacher can also snapshot traffic position situations to recall them later.

In '''teacher sessions''':
* The teaching console is enabled, which allows you to control most aspects of the environment visible to the student.
* You create new traffic holding {{key press|Shift}} down with a right click-and-drag on the radar specifying the position and face heading. A dialog pops up and allows you to choose a callsign (one is initially generated), altitude and other details. If near a ground route node, a parking position or runway, you can create it on the ground, ready to taxi or for departure (NB: parking overrides position/heading input).
* Traffic is initially created in an "unspawned" state (radar contact marked "+"), in other words visible to you but not to the student. This allows you to set its transponder or get it into a certain state before spawning it into the student's world.
* Controlling the traffic is done in the same way as in solo sessions without voice, i.e. using the click&drag vector and taxi tools and the instruction dock. The only difference is that you control the selected aircraft directly, regardless of your strip links and details. You therefore do not need a strip and a correctly filled callsign to instruct a pilot, though it is a good idea to have one if you want your vectors registered and drawn on the radar. The traffic creation dialog offers to create a linked strip with every new aircraft.
* You may pause the whole simulation, or freeze each aircraft individually. Frozen aircraft will result in stationary flights on the student's radar.
* The ATC text chat system allows to chat to the student directly as the teacher, and to simulate private ATC conversations with the student (select callsign to interact as).
* To exchange strips, drop them on "Student" and select whom the strip should appear from on the student's side. Note that for your convenience in further control of the traffic, teacher strips do not disappear on handovers;
* CPDLC is supported, the dialogue windows reflecting the change of perspective (ACFT instead of ATC) and the {{key press|Alt}} key combinations generating requests rather than instructions.

[[Category:ATC-pie]]

ATC-pie installation guide

2021-12-19T18:11:16Z

Mickybadia: v1.8.5

{{forum|83|ATC-Pie support & development}}

{{about|installing and running ATC-pie|a manual on how to use it|ATC-pie user guide}}

== Installing ==

=== Preparing ===
[[ATC-pie]] is free and open source, and programmed in Python3 for Qt5. It is therefore system-independant, but requires Python3 and the PyQt5 library to run. The exact dependencies and required versions are listed in the <code>README</code> file packed in the download. When they are installed, ATC-pie runs straight away without any compiling to do (make, etc.).

=== 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.

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 Git '''repository''':
: <code>git clone git://git.code.sf.net/p/atc-pie/code ATC-pie</code>

=== More to install? ===
I say again: the download/clone alone is not enough; both Python3 and PyQt5 must be installed too. ''Please'' read the <code>README</code> file for extra notes on installation.

With the dependencies installed, at this point you have a working program. But further software pieces can be installed to enable more of its features, as listed below. Depending on your use of ATC-pie, they can be recommended for more realism but they are not required, and can be installed later.

For a 3D '''tower view''' in any airport session, ''[[FlightGear]]'' must be available, with the appropriate aircraft models and scenery data. Note that it can run on a separate machine, as explained [[#Airport scene rendering|down this article]].

To enhance solo sessions with:
* '''voice instruction recognition''' by the AI aircraft, install ''PocketSphinx'' (requires ''PyAudio'');
* '''speech synthesis''' of AI pilots' radio messages, install ''pyttsx''.

For an integrated '''ATC phone line switchboard''' (all sessions except solo), install ''PyAudio'', plus ''PyMumble'' for FlightGear and FSD sessions.

To enhance FlightGear sessions with:
* '''[[CPDLC]]''' and '''full ATC coordination''', including unlimited strip exchange and text messaging, install the ''Python IRC library'' (recommended!);
* '''voice radio simulation''', install the ''FGCom-Mumble'' plugin (requires a ''Mumble''>=1.4 client) or the older ''standalone FGCom'' executable client (note that both variants cannot be used simultaneously).

== Running ==

Depending on your system and preference, you might be double-clicking, typing stuff or pulling your hair out. In any case what you must do is run a Python3 interpreter on the <code>ATC-pie.py</code> file from the downloaded directory.

=== Two program modes ===
[[File:ATC-pie-screenshot-launcherDialog.png|thumbnail|Initial graphical launcher, with AD vs. CTR mode choice]]
On program start, a welcome launcher window should open, from which you may start a session in either airport (AD) or centre (CTR) mode, i.e. respectively with or without a base airfield.

The '''airport mode''' is for ATC positions like approach or tower control. In this mode, ATC-pie places the radar at the chosen base airfield, depicts its tarmac and runways, and enables features like tower viewing and runway selection.

The '''centre mode''' is designed for en-route control centre simulation. It disables all airport-specific features, and allows to place the radar anywhere on Earth. When selecting this mode:
* The location code is a designator of your choice (excluding airport codes), under which to save your location-specific settings. A good idea is to use ICAO airspace designations, e.g. <code>SBBS</code> for the Brasilia FIR in central Brazil or <code>LFFF</code> for the Paris region in France.
* The radar position field specifies the point on which to centre the radar. For example, <code>LFPO>090,15</code> will centre the radar on a point 15 NM to the East of Orly airport. Click on the help button for a summary of valid point specification formats, or read the ''Point specification'' section in the quick reference for more detail.

=== Command line arguments ===
You may bypass the launcher and start directly at a given location with the following command, using an ICAO code for an airport or a previously defined CTR location code:
: <code>./ATC-pie.py location_code</code>

Besides, the following command line options are available:
{| class="wikitable"
! Option || Effect and argument specification || Default
|-
| --map-range=''range'' || Only valid with a location code argument. Defines the distance in NM from the radar centre up to which the map will be drawn and navpoints listed in the navigator (accepted values are 20..500). This does not affect radar range, which can still be greater or lower (and be changed within sessions).' || 100 in AD mode; 300 in CTR mode
|-
| --views-send-from=''port'' || Sets 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 FGMS connection port, chosen on session start. || 5009
|}

=== Starting sessions ===
All session types are started from the ''System'' menu.

Solo simulation:
* wind will be randomised at start, but will be forced to blow in a favourable direction if at least one active runway is selected before start;
* traffic is spawned with intentions according to the ''solo simulation configuration options'' ({{key press|Shift|F11}}), so it is preferable to configure them before starting the session to avoid undesired traffic at start.

FlightGear network session:
* callsigns for ATCs in FlightGear are expected to start with the ICAO code of the controlled airport or sector, and end with a hint on the provided service (twr, gnd, ctr...), e.g. "KORDgnd" (note that FGMS restricts callsign length to 7 characters);
* before choosing your callsign, make sure it is not already in use;
* you can connect multiple ATC-pie instances from the same computer, but you must use a different local port for each one;
* the three "sub-systems" that can be activated support different coordination features and differ in terms of interoperability with other clients, but all can be enabled together:
** '''native ATC-pie coordination''' enables full interaction with other ATC-pie clients (except phone lines), plus CPDLC with FG aircraft;
** '''ATC phone lines''' enables direct voice communications (telephone calls) with other connected ATC-pie clients;
** '''OpenRadar handover compatibility''' implements [[OpenRadar]]'s protocol to enable coordination with its users (will work with ATC-pie clients as a fallback if native sub-system not available), although some limitations apply (see [[ATC-pie#OpenRadar|interoperability note]] in the main article).

== Configuring ==

Here are things you will soon want or have to set up for a regular use of ATC-pie:
* set up a [[#Airport scene rendering|tower view]] to enable visual contact with your traffic in AD sessions;
* for FlightGear and FSD sessions, give yourself a "social name" so that others recognise you when using any of the ATC coordination/exchange features;
* for FlightGear sessions and realistic radio experience, select an [[FGCom]] variant in the system settings, and test the configuration from the ''System'' menu.

If you intend to operate often at a given location, it is sensible to:
* if it is an airfield location, download the latest airport data file from the [https://gateway.x-plane.com/airports/page# X-plane gateway] and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> file there);
* review and fill the various fields in the location set-up dialog (runway capabilities deserve special focus for more realisitc aircraft intentions in AD solo sessions);
* configure the workspace racks, bays and radar screens to suit the environment and service provided, they will be saved for future runs;
* if using the radar, pin your preferred navpoints (they are restored on every run) and consider creating/importing background pictures to map terrain obstacles, procedure charts, etc. (see [[#Background images|section below]]);
* for solo and teacher sessions at airports especially, build an elevation map (see <code>CONFIG/elev/Notice</code>).

For more advanced editable options, read the <code>CONFIG/Notice</code> file.

=== Airport scene rendering ===
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
A '''tower view''' allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any (X-plane seems only to allow for one, but feel free to declare more for ATC-pie), otherwise defaults to somewhere over the airport to allow towering everywhere. It is disabled in CTR mode.
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 to listen for traffic and accept telnet connections.

Running internally only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the ''System'' settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].

Connecting to an external viewer allows to run FlightGear on a different machine and thereby relieve your session from the CPU load a local instance induces. If you want to do so, get a hint of the required positioning options you should start your viewer with, from the tower view tab in the system settings dialog. Of course, scenery, models and liveries must also be available to the running process.

In either case, once activated from the ''View'' menu, the tower view '''control pane''' is enabled, from which you can turn to runway points, follow selected aircraft... Direct FlightGear input in the view window is also possible: right click and drag allows to look around, {{key press|x}} and {{key press|Shift|x}} change the zoom level, etc.

You can hook up '''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 from the ''View'' menu. Additional viewers are registered by their host+port address, from the ''View'' menu at run-time or from a custom settings file (see <code>CONFIG/Notice</code>) read at start-up and on explicit reload (''System'' menu).

Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
* ''HHH'' is the host on which ATC-pie is running;
* ''PPP'' is the default 5009, or the chosen port number if ATC-pie was started with <code>--views-send-from</code>;
* ''TTT'' is the network polling frequency (100 is common practice; change as desired if you know what you are doing).

=== Background images ===
[[File:ATC-pie-screenshot-backgroundPixmapDrawing.png|thumbnail|Pixmap image example with a topographic map shot around LIMW (Aosta, Italy)]]
[[File:ATC-pie-screenshot-backgroundHandDrawing.png|thumbnail|Hand drawing example with procedures for LSGG (Geneva, Switzerland)]]
Background images allow to decorate:
* radar scopes, e.g. to display procedure maps or text annotations of the airspace;
* loose strip bays, to move unracked strips over custom backgrounds, e.g. ground charts of the airport.

There are two ways to create backgrounds in the program. One is to '''import pictures''' (pixmap files like JPEG or PNG, including transparency); the other consists in writing '''drawing specification''' files to paint coloured lines and labelled points (radar backgrounds only). This allows to import anything from complex pictures like terrain maps to schematic drawings like airspace boundaries. The <code>CONFIG/bg/Notice</code> file explains how to import and draw background images.

For example, you can map out procedures (SID, STAR, IAD...), grouping them by associated runways so they toggle together on the radar. Drawings are generally appropriate for that because they avoid manual positioning by directly referring to the points named in the published procedures. But if you want more than schematic line plots and text labels, you should create the picture yourself, for example using an image processing tool like ''GIMP'' and a transparent layer over a real map canvas or a screenshot of your ATC-pie radar with pinned navaids as landmarks.

'''If you have a sector file''' of the format used in VATSIM/IVAO (.sct) for your area, you should try to import it with the "extract drawings from sector file" ''System'' menu tool. It will extract most of the contents around the open location up to the current map range, and translate it to ATC-pie's native drawing format. If you know they are included, it is generally the best option for things like SID/STAR procedures, although the generated files always require some filtering and post-editing. The way to proceed is as follows:
# Run the "extract drawings from sector file" option (''System'' menu) and select the file to extract from. This generates the following files in the <code>OUTPUT</code> directory:
#* <code>ICAO.lst.extract</code>, a menu file for the generated drawings;
#* <code>bg-ICAO-*</code>, the extracted drawings in the native ATC-pie format;
#* <code>bg-extract.err</code>, a log of the errors detected in your sector file (do not be alarmed as they often contain many).
# Import the results:
#* move or copy-paste lines from <code>ICAO.lst.extract</code> to <code>CONFIG/bg/ICAO.lst</code>;
#* move the desired drawing files under <code>CONFIG/bg</code>, adjusting the paths in the <code>.lst</code> menu as you organise subdirectories.
# Post-editing (cleaning)
#: ATC-pie does its best to understand the objects in the sector file and to group things together depending on their type. But not everything can be guessed automatically. This last step is where you filter, merge and split objects, rename points, change colours, etc. to your liking.
#: Each generated drawing section (point list under a colour) is automatically labelled with the line number where it was sourced from in the sector file so you can easily trace it (<code>@nnn</code>). A tool like ''sed'' will help you get rid of all these unwanted suffixes once you have sorted and renamed your objects:
#:: <code>sed -ri 's/ +@[0-9]+$//' file_to_clean</code>

NB: ATC-pie does not package or source from sector files directly because their data is not free. Besides, a lot of it is usually redundant with the airport sources (GPL).

Tips:
* You can check your image configuration without restarting the program, by reloading the files in their current state from the ''System'' menu ({{key press|Alt|F12}}).
* The "image positioning helper" allows to move and resize imported pictures, adjusting the corners visually rather than programmatically if you have no specification for them. All visible pixmap images will be moved simultaneously, so you can work with several at a time if you want to. On dialog box close, a file is generated in the <code>OUTPUT</code> directory for you to copy from.
* An [[OpenStreetMap]] option will take you to the free online map server, centred on your radar centre position. For a quick and dirty start (e.g. for access to coastlines, borders and rivers) you can screenshot the map and use it as a background.

[[Category:ATC-pie]]

ATC-pie

2021-12-19T18:10:15Z

Mickybadia: v1.8.5

{{forum|83|ATC-Pie support & development}}

{{about|the software in general|a manual on how to use it|ATC-pie user guide}}

{{Infobox Software
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.8.5 (Dec. 19, 2021)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''ATC-pie''' is a free (libre) [[air traffic control]] simulation program featuring:
* solo sessions, incl. voice instruction recognition and pilot speech synthesis;
* "multi-player" network sessions ([[FGMS]] and FSD protocols supported);
* 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...) with 3D tower viewing through [[FlightGear]]. It is essentially designed for realism, 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 [[ATC-pie installation guide|installation]] and [[ATC-pie user guide|user]] guides. If you have a question, check the [[ATC-pie FAQ|FAQ]] first, or try the forum for help.

== 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 ===
[[File:ATC-pie-screenshot-stripDetailSheet.png|thumbnail|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 [http://en.wikipedia.org/wiki/Secondary_surveillance_radar 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 ===
[[File:ATC-pie-screenshot-radarIdentification.png|thumbnail|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".

== Screenshots ==

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Solo session with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

== Detailed feature list ==

=== Sessions ===
Available session types:
* Solo simulation (AI traffic)
* FlightGear network connection (FGMS protocol)
* FSD connection (as served by https://github.com/kuroneko/fsd commit bc7d43, latest available in April 2020)
* Teaching service (spawn and simulate traffic visible to a connected student)
* Student session (control traffic simulated by teacher)

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 toggle
* 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:
* Voice radio with 8.33 kHz frequency spacing
* ATIS recording and reminder alarm (see [[:File:ATC-pie-screenshot-ATISdialog.png|dialog]] with pre-filled notepad)
* [[Controller-pilot data link communication]] (CPDLC), incl. multi-element messages
* Text radio chat with preset messages, auto-completion, predefined and custom aliases (context-sensitive replacements), sender blacklist

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

=== 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 [[: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

Data sources:
* Airport and navigation data sourced in the [http://data.x-plane.com 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)
* Real world magnetic declination lookup

=== Session environments ===
{| class="wikitable" style="text-align:center"
! || Solo || FlightGear || FSD || Tutoring (teacher/student)
|-
! Traffic
| AI aircraft generated according to RWY capacities, ACFT equipment, intentions...
| colspan="2" | connected flight sim pilots
| created and simulated by teacher
|-
! ATCs
| virtual ATCs depending on assumed position
| colspan="2" | connected ATC clients (full ATC-pie support, [[#Interoperability with other software|interoperability with other software]])
| teacher-configured ATCs
|-
! Voice radio
| instruction recognition and pilot read-back synthesis
| FGCom [[FGCom_3.0|stand-alone processes]] or [[FGCom-mumble]] plug-in
| working PTT but audio system not integrated (must use third-party software)
| teacher simulates pilots
|-
! ATC phone lines
| rowspan="2" | N/A
| colspan="2" | integrated connection to a Mumble service
| teacher simulates ATCs
|-
! Flight plans
| interface with the FlightGear ''de facto'' [http://flightgear-atc.alwaysdata.net data base by Lenny64]
| available from network, but no FSD support for open/close and only pilots can file/amend
| virtual online system
|-
! Weather
| randomised and evolving
| real world METAR retrieval
| fetch from server or retrieve real world METAR
| controlled by teacher
|-
! Other specific features
| style="text-align:left" |
* mouse-only instructions possible (voice recognition by-pass)
* aircraft type and airline choice with custom appearence in tower view
* configurable airspace rules and traffic density, incl. uncontrolled distractors
| style="text-align:left" |
* multiple radio support with simultaneous transmissions and monitoring
* voice ATIS recording
| 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
|}

== 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.

[[Category:ATC-pie]]
[[Category:ATC clients]]
[[Category:Air Traffic Control]]

ATC-pie

2021-08-14T21:23:13Z

Mickybadia: v1.8.4

{{forum|83|ATC-Pie support & development}}

{{about|the software in general|a manual on how to use it|ATC-pie user guide}}

{{Infobox Software
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.8.4 (Aug. 14, 2021)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''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 [[ATC-pie installation guide|installation]] and [[ATC-pie user guide|user]] guides. If you have a question, check the [[ATC-pie FAQ|FAQ]] first, or try the forum for help.

== Screenshots ==

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Solo session with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

== 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 ===
[[File:ATC-pie-screenshot-stripDetailSheet.png|thumbnail|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 [http://en.wikipedia.org/wiki/Secondary_surveillance_radar 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 ===
[[File:ATC-pie-screenshot-radarIdentification.png|thumbnail|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 [[:File:ATC-pie-screenshot-ATISdialog.png|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:
* Strip exchange: full handover support with ATC-pie, compatible with [[OpenRadar]]
* Voice radio: FGCom integration (using [[FGCom_3.0|stand-alone processes]] or through [[FGCom-mumble|Mumble plug-in]])
* Weather: real world METAR retrieval
* Flight plans: interface with [http://flightgear-atc.alwaysdata.net Lenny64's data base] (the ''de facto'' FG standard)
* ATIS: voice recording through FGCom

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 [[: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

Data sources:
* Airport and navigation data sourced in the [http://data.x-plane.com 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)
* 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.

[[Category:ATC-pie]]
[[Category:ATC clients]]
[[Category:Air Traffic Control]]

ATC-pie FAQ

2021-08-14T21:22:18Z

Mickybadia: v1.8.4

{{forum|83|ATC-Pie support & development}}

This page is a collection of questions asked at least twice about [[ATC-pie]]. It is a good idea to search through it before repeating a question on the forum or anywhere.

== Things "not working" ==

=== Why am I not seeing this aircraft on my radar? ===
Connected to FGMS: '''I know it is there: the pilot is sending chat messages and/or is visible on the online live map...'''

You only see an aircraft on your scopes if a radar contact is established, i.e. if it is visible to the primary radar or if the secondary radar (SSR) picks up a transponder signal from it.

The following cases will therefore prevent you from seeing a connected aircraft:
* The radars are turned off. Turn on at least a primary radar from the ''Options'' menu, or an SSR capability from the ''Radar'' tab in the ''Local settings'' dialog (any setting other than "none" will pick up contacts).
* The aircraft is out of radar range. It can be under the radar floor (minimum signal pick-up alt.) or too far out. In the radar settings, check the floor ("SFC" will pick up all signals down to the ground) and horizontal range. Primary and secondary radars share the same range.
* Its onboard transponder is turned off (and primary is off); see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Otherwise if you accept cheating, you can activate the "radar cheat mode" which will simulate a mode S transponder for all aircraft in horizontal range; see [https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3].

=== Connected pilots do not receive my text messages. ===
This happens with pre-2017.2 clients if you are using the latest protocol to encode properties. Tick the FGMS system option to "use the legacy protocol" for property encoding. Everybody should be able to read you, but it will come at the expense of network throughput. Tell those pilots to upgrade their client.

=== FGCom is not working. ===
First, verify that the FGCom variant selected in the ''system settings'' is the one you want to use. Check that your sound is on, your volume loud and your microphone working (system sound monitor picking up a signal). Close all open sessions and open a single ATC-pie instance.

If you have chosen the '''stand-alone''' FGCom variant, take the steps below in order:
# Echo test
#: Start an ''FGCom configuration test'' from the ''System'' menu. While the test is running, speak in the microphone and check if you can hear yourself back. If so, you may skip directly to step 4.
# Path to executable
#: Verify the FGCom command entered in the system settings. It should contain an executable system command or a relative or absolute path to an FGCom executable file. If you have FlightGear installed on your machine, you can point to the FGCom executable already available with it. On Linux, the default "fgcom" command usually does the job. Otherwise, [https://sourceforge.net/projects/atc-pie/files/fgcom-standalone/ download an FGCom stand-alone program] from ATC-pie's SourceForge file list. In any case, try the entry from a terminal in the ATC-pie directory to manually check that it runs correctly.
# FGCom server status
#: The server may temporarily be down, unfortunately even for up to a few days. Check for responses from the server, e.g. with <code>ping fgcom.flightgear.org</code> (adjusting the server name to match the one entered in the settings). FGCom will not work without a responding server.
# FGCom subprocess error
#: After turning your radio on, check for errors in the logged FGCom output files in the <code>OUTPUT</code> directory.
# Port mess-up in your session?
#: When creating a new radio box at run time, make sure you choose an available port number for each. Caution when running multiple ATC-pie instances: do not use a port more than once across the system at the same time.

If you have chosen the '''FGCom-Mumble plug-in''':
# Plug-in status
#: Check that your Mumble client is connected and properly running the FGCom plug-in.
# Port setting
#: Check that the control port in ATC-pie is set to the one FGCom-Mumble is listening on.
# Echo test
#: Start an ''FGCom configuration test'' from the ''System'' menu.

Note that the two variants are ''not'' interoperable. Users will only be able to hear and interact with others using the same variant (and server) as their own.

=== Recording ATIS with stand-alone FGCom: no beep is heard after pressing "record". ===
Assuming FGCom standalone is working (confirm this with an echo test before reading on)...

Due to the design of this legacy FGCom variant, you may only record an ATIS if the requested frequency is enlisted as recordable on the distant server's "phone book" for the airport. The one for <code>fgcom.flightgear.org</code> was compiled a while ago, based on the latest <code>apt.dat</code> at the time. It filtered the frequencies through the two following conditions:
# it is of the "recorded" type (row code 50);
# its name contains the uppercase string "ATIS".

If you are relying on the old data provided by ATC-pie, in other words you have not downloaded new data or edited the frequencies yourself, check against the <code>.dat</code> file extracted in the <code>OUTPUT</code> directory on your side, as it should still be similar to the one on the server's side. One of the two conditions is probably not met, or the frequency missing. NB: The frequencies in the ATIS drop-down list of ATC-pie are matched against the condition (1), but not against the somewhat restrictive condition (2).

In any case, consider switching to the newer FGCom-Mumble plug-in variant. It simulates radio waves, frequencies and ranges, which avoids the phone book problem all together.

=== Tower view is not starting. ===
Ruling out that FlightGear is not installed at all, your system path settings are probably wrong. From a terminal or a file system navigator, find the right command to start FlightGear and enter it as ''FlightGear executable'' from the system settings. Do not add options of any kind; they will be taken care of internally. You may have to enter a ''FlightGear root directory'' as well, especially if you have the program files installed somewhere unexpected.

=== My tower is in the middle of the sea, and aircraft floating/landing on water! ===
You are missing the FlightGear scenery data for your location, or ATC-pie does not know where it is. If you have downloaded scenery and saved it somewhere, have you tried filling the scenery directory with that location in the system settings? Also check out the ''Tower viewing'' [[ATC-pie_user_guide#Tower_view_window|feature note]] in the user guide.

=== Simulated aircraft appear to dip underground or levitate over taxiways. ===
Do you have a ground elevation map for the location? Quoting from <code>CONFIG/elev/Notice</code>: "''When no elevation map is found for an airport, the field elevation value is used everywhere on the ground. This should be OK for a rough approximation on flat terrain, but ground traffic will not follow any slopes, thus may appear as floating above the ground, or dipping into it.''"

Read the full notice for instructions on how to build your elevation map. Once you have one or decide that your field is flat enough, the next focus is on the FlightGear aircraft models. Each model has its own coordinate system chosen at developer's discretion. ATC-pie must be given the height difference between each model's origin and the aircraft touch-down point (gear wheels) to position aircraft more accurately. You can do this on a per-model basis with ":height" specifications in <code>CONFIG/acft/icao2fgfs</code>. Read the associated <code>Notice</code> file for more information.

A last possible altitude adjustment is available from the location options: "Altitude adjustment for FlightGear views". It applies the given offset to all traffic rendered by the views.

=== Phone lines have broken, choppy or dragged out sound ===
You and the other parties must adjust microphone sensitivity. Toggle the phone squelch adjustment box from the system menu and tune the spinbox next to the "call" button in the ATC coordination panel. Lower values will decrease the threshold for sound pick-up and likely break the sound less, but can generate more lag in the communications. The right balance depends on your local configuration, so a few test calls with other connected ATCs will be necessary to decide on the best acceptable value.

=== I cannot connect to my teacher as a student. ===
Using IPv4 addresses, this typically happens when the teacher is in a local area network behind a router. It is a common setup for home internet, in which the teacher's actual host address is not publicly accessible from outside his private network.

If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either:
* for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local host address;
* or to create a virtual network, using a third-party VPN service.

== What is ...? Why is ...? What value/setting for ...? ==

=== What "social name" should I use for FlightGear/FSD sessions? ===
Choose any name you would like to be recognised by on the network. In ATC-pie, it will appear in the tool tip over your callsign for connected ATCs who see you. This feature is only social in the sense that it does not refer to an account or to anything technical, but it makes sense as typical ATC callsigns (e.g. "VHHHtwr") remain mostly anonymous. Use this field to identify yourself on the network.

=== Are the vector headings true or magnetic? ===
Heading displays in ATC-pie are mostly magnetic so they can be read out to pilots. The exceptions are the navigator and handover list tool tips, which show true radial headings from the radar position, and the teacher's wind section to match the generated ATIS string.

Also note: all directions are geodesic, i.e. initial headings to take on a great circle.

=== What is the purpose of the flat "strip shelf" button in the strip panes? ===
More than a button, the strip shelf is where you should drop the contacts you release without a handover, e.g. parked traffic shutting down, VFR traffic flying out of your airspace, etc. Clicking on the shelf allows to browse the previously shelved strips, and to recall them, for example if shelved inadvertently.

=== What do the various markings along the approach centre line mean? ===
The regularly spaced groups along a centre line represent altitudes on the approach plane. Each group sums up to an AMSL value in accordance with the set flight path angle (also see ''Display conventions'' in the quick reference):
* straight line = 1,000 ft;
* solid diamond = 5,000 ft.

The other markers drawn with thicker lines are the positions of the ILS marker beacons (OM, MM, IM), the line pattern representing the sound triggered by the beacon in the pilot's headset. They are sourced on program start-up from the navigation data (<code>CONFIG/nav/navaid.dat</code>).

=== Why do I keep getting runway incursion alarms? ===
Because you have the runway occupation monitor turned on (''Options'' menu), while not using your runway boxes. The alarm triggers when the radar detects traffic stepping on a runway in either of the following situations:
* the runway is active (marked in use) and no strip is boxed for it;
* it is reserved but there is already traffic on the runway;
* it is reserved for a different aircraft: the boxed strip is linked to a contact that is not the entering aircraft, or the aircraft is linked to a strip different to the one boxed.

Turning the runway occupation monitor off will deactivate all radar warnings regarding runways. If you are interested in the strip boxing and visual runway highlighting system but bothered by the alarm sound, you can mute the sound notification by unticking it in the general settings.

== Where is ...? How to ...? ==

=== Can I draw SID and STAR procedures on the radar? ===
Yes, and virtually anything else, using background images. To learn about those:
* see the corresponding [[ATC-pie_installation_guide#Background images|installation guide section]];
* read the <code>CONFIG/bg/Notice</code> file.

=== How do I assign SIDs and STARs to aircraft? ===
This question is asked quite a lot more than it is relevant to a real controller's task...

What people seem to be after when asking this question is a way to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. The way to handle this is to stack your inbound strips on racks named after your STARs. Racks are indeed above all meant for efficient traffic sequencing. Every rack represents its own sequence of ordered aircraft, which is perfectly suited to control separate approach paths in parallel. With this technique, placing a strip on a STAR-named rack basically serves as the "assignment" itself. Similarly, runway-specific racks can keep track of separate landing sequences at large airports. Then you can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times in the sequence all the way to touchdown.

If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. Routes are lists of waypoints and instructions to follow between the two end airfields. Normally pulled straight from properly filed flight plans, routes are printed on strips prior to departure, then modified as the flights progress and passed along with handovers. Standard departure and arrival procedures (SIDs and STARs) can be referred to in those routes, but only by their entry or exit navpoints. They should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. For example, routes ending with a STAR should end with "FUBAR STAR", which means that waypoint FUBAR is an entry point from which a published STAR must be followed. The keyword "STAR" is in fact a mere specification for the last route leg. Similarly, routes of the form "SID DUMMY ..." specify their first leg as a standard departure to the first waypoint DUMMY. "SID" and "STAR" keywords are recognised by ATC-pie and accounted for in the second line of the radar tag when appropriate (see feature note on routes).

One meaningful wish regarding this question is for easy '''reference in text chat''' messages. Firstly, using racks in the way suggested above, you can use the <code>$rack</code> alias which is substituted by the name of the rack on which the current strip selection is stacked. Otherwise, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". Now if you specifically want to assign a full procedure name like FUBAR1A to a contact and refer to it in a generic text chat message, include a line "sid=FUBAR1A" 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 expanded in your sent messages when that strip is selected.

=== How to set the transition level? ===
You do not. You can however set the transition altitude in the location settings if your airport specification file does not already include one.

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, e.g. for more vertical separation on either side of the transition layer or due to coordination with neighbouring zones and fields.

=== Can I look up ILS frequencies? ===
Yes, in the ''environment info'' dialog.

Besides, you can create aliases with the local notepad for a quick and integrated way of sending them through text chat, which will be saved when you close ATC-pie. For example, use the following format, one runway per line: <code>ils05=111.11 MHz</code>. See [[ATC-pie_user_guide#Public text chat|custom text aliases]] for more.

=== The navigation/airport data is outdated. How can I update it? ===

For '''airport data''' (taxiways, parking positions, frequencies, etc.), the included source is the last world-wide <code>apt.dat</code> compiled before it became too large to maintain as one huge file. We keep it there because it allows to run ATC-pie anywhere in the world without requiring external data, but its contents grows out of date with time. You should check for more recent sources on the [http://gateway.x-plane.com/airports/page X-plane airport gateway], directly accessible from the ''System'' menu, on a per-airport basis. Extract the <code>apt.dat</code> file from the download, rename it after the airport's ICAO code (keeping the extension, e.g. <code>KJFK.dat</code>), and place it in <code>CONFIG/ad</code> (also see the <code>Notice</code> there). Alternatively, for a quick manual touch-up of the included data, you can move and edit extracted files (see <code>OUTPUT/Notice</code>).

For '''navigation data''' (navaids, fixes, airways, etc.), the included data is the latest version of each file that was seen released as GPL, which makes some of it date back to 2013! You should provide more recent navigation data, as explained in <code>CONFIG/nav/Notice</code>.

=== How do I customise the GUI and colours? ===
To change the '''radar or strip drawing colours''', edit the <code>CONFIG/colours.conf</code> file. Each line specifies the paint colour for an object type, in a typical hex <code>RRGGBB</code> (red-green-blue) format or as an SVG colour keyword name like "white". To customise the '''main session window''', place a ''Qt stylesheet'' named <code>main-stylesheet.qss</code> in the <code>CONFIG</code> directory. ATC-pie will apply it to every session window. While you are working on your look and feel, use the reload feature from the "System" menu to avoid restarting after every change (<code>Shift</code>+<code>Alt</code>+<code>F12</code>).

Send us screenshots and share your files if you find a setup looking really cool! :-)

== Miscellaneous ==

=== What's with the funny name? ===
ATC-pie is written in Python, and I reckoned that the ''pyXXX'' naming habit was becoming a little dull, so I merely switched things around. You can surely do the rest of the math in terms of spelling, and later impact on the logo.

=== Why is the learning curve so steep? People would use your program more if you did/provided [...] ===
Often continued with: '''(you must understand that) this is not VATSIM!'''

We do have a [https://sourceforge.net/p/atc-pie/wiki/Wishlist wish list] and will consider any feature or help request. However, though it has a few cheats, ATC-pie has always choosen realism as a criterion for implementation and design, over the mere incentive of converting otherwise happy users of other programs. It is a good thing that different philosophies and work flows are available out there, and there would be much less interest in having them all copy each other, fighting over users instead of understanding that not all of them wish for the same experience. If serious simulation or learning new skills sound like threats to fun for you, you have a perfectly valid reason not to opt for ATC-pie.

[[Category:ATC-pie]]

ATC-pie installation guide

2021-08-14T07:20:47Z

Mickybadia: Mended broken link

{{forum|83|ATC-Pie support & development}}

{{about|installing and running ATC-pie|a manual on how to use it|ATC-pie user guide}}

== Installing ==

=== Preparing ===
[[ATC-pie]] is free and open source, and programmed in Python3 for Qt5. It is therefore system-independant, but requires Python3 and the PyQt5 library to run. The exact dependencies and required versions are listed in the <code>README</code> file packed in the download. When they are installed, ATC-pie runs straight away without any compiling to do (make, etc.).

=== 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.

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 Git '''repository''':
: <code>git clone git://git.code.sf.net/p/atc-pie/code ATC-pie</code>

=== More to install? ===
I say again: the download/clone alone is not enough; both Python3 and PyQt5 must be installed too. ''Please'' read the <code>README</code> file for extra notes on installation.

With the dependencies installed, at this point you have a working program. But further software pieces can be installed to enable more of its features, as listed below. Depending on your use of ATC-pie, they can be recommended for more realism but they are not required, and can be installed later.

For a 3D '''tower view''' in any airport session, ''[[FlightGear]]'' must be available, with the appropriate aircraft models and scenery data. Note that it can run on a separate machine, as explained [[#Airport scene rendering|down this article]].

To enhance solo sessions:
* with '''voice instruction recognition''' by the AI aircraft, install ''PocketSphinx'';
* with '''speech synthesis''' of AI pilots' radio messages, install ''pyttsx''.

To enhance FlightGear and FSD sessions with an integrated '''ATC telephone switchboard''' (direct voice lines), install ''PyMumble''.

To enhance FlightGear sessions:
* with '''[[CPDLC]]''' and '''full ATC coordination''' including unlimited strip exchange and text messaging, install the ''Python IRC library'' (recommended!);
* with '''voice radio simulation''', install the ''FGCom-Mumble'' plugin (requires a ''Mumble''>=1.4 client) or the older ''standalone FGCom'' executable client (note that both variants cannot be used simultaneously).

== Running ==

Depending on your system and preference, you might be double-clicking, typing stuff or pulling your hair out. In any case what you must do is run a Python3 interpreter on the <code>ATC-pie.py</code> file from the downloaded directory.

=== Two program modes ===
[[File:ATC-pie-screenshot-launcherDialog.png|thumbnail|Initial graphical launcher, with AD vs. CTR mode choice]]
On program start, a welcome launcher window should open, from which you may start a session in either airport (AD) or centre (CTR) mode, i.e. respectively with or without a base airfield.

The '''airport mode''' is for ATC positions like approach or tower control. In this mode, ATC-pie places the radar at the chosen base airfield, depicts its tarmac and runways, and enables features like tower viewing and runway selection.

The '''centre mode''' is designed for en-route control centre simulation. It disables all airport-specific features, and allows to place the radar anywhere on Earth. When selecting this mode:
* The location code is a designator of your choice (excluding airport codes), under which to save your location-specific settings. A good idea is to use ICAO airspace designations, e.g. <code>SBBS</code> for the Brasilia FIR in central Brazil or <code>LFFF</code> for the Paris region in France.
* The radar position field specifies the point on which to centre the radar. For example, <code>LFPO>090,15</code> will centre the radar on a point 15 NM to the East of Orly airport. Click on the help button for a summary of valid point specification formats, or read the ''Point specification'' section in the quick reference for more detail.

=== Command line arguments ===
You may bypass the launcher and start directly at a given location with the following command, using an ICAO code for an airport or a previously defined CTR location code:
: <code>./ATC-pie.py location_code</code>

Besides, the following command line options are available:
{| class="wikitable"
! Option || Effect and argument specification || Default
|-
| --map-range=''range'' || Only valid with a location code argument. Defines the distance in NM from the radar centre up to which the map will be drawn and navpoints listed in the navigator (accepted values are 20..500). This does not affect radar range, which can still be greater or lower (and be changed within sessions).' || 100 in AD mode; 300 in CTR mode
|-
| --views-send-from=''port'' || Sets 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 FGMS connection port, chosen on session start. || 5009
|}

=== Starting sessions ===
All session types are started from the ''System'' menu.

Solo simulation:
* wind will be randomised at start, but will be forced to blow in a favourable direction if at least one active runway is selected before start;
* traffic is spawned with intentions according to the ''solo simulation configuration options'' (<code>Shift</code>+<code>F11</code>), so it is preferable to configure them before starting the session to avoid undesired traffic at start.

FlightGear network session:
* callsigns for ATCs in FlightGear are expected to start with the ICAO code of the controlled airport or sector, and end with a hint on the provided service (twr, gnd, ctr...), e.g. "KORDgnd" (note that FGMS restricts callsign length to 7 characters);
* before choosing your callsign, make sure it is not already in use;
* you can connect more than one ATC-pie instance from the same computer, but must use different ports;
* the three "sub-systems" that can be activated support different coordination features and differ in terms of interoperability with other clients, but all can be enabled together:
** '''native ATC-pie coordination''' enables full interaction with other ATC-pie clients, but does not currently operate with other software;
** '''ATC phone lines''' system integrates direct voice (telephone) lines to other connected ATCs in the ATC coordination panel (also ATC-pie only);
** '''OpenRadar handover compatibility''' implements [[OpenRadar]]'s native system to enable coordination with its users, although some limitations apply (see [[ATC-pie#FlightGear_sessions_and_compatibility_with_OpenRadar|interoperability note]] in the main article).

== Configuring ==

Here are things you will soon want or have to set up for a regular use of ATC-pie:
* set up a [[#Airport scene rendering|tower view]] to enable visual contact with your traffic in AD sessions;
* for FlightGear and FSD sessions, give yourself a "social name" so that others recognise you when using any of the ATC coordination/exchange features;
* for FlightGear sessions and realistic radio experience, select an [[FGCom]] variant in the system settings, and test the configuration from the ''System'' menu.

If you intend to operate often at a given location, it is sensible to:
* if it is an airfield location, download the latest airport data file from the [https://gateway.x-plane.com/airports/page# X-plane gateway] and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> file there);
* review and fill the various fields in the location set-up dialog (runway capabilities deserve special focus for more realisitc aircraft intentions in AD solo sessions);
* configure the workspace racks, bays and radar screens to suit the environment and service provided, they will be saved for future runs;
* if using the radar, pin your preferred navpoints (they are restored on every run) and consider creating/importing background pictures to map terrain obstacles, procedure charts, etc. (see [[#Background images|section below]]);
* for solo and teacher sessions at airports especially, build an elevation map (see <code>CONFIG/elev/Notice</code>).

For more advanced editable options, read the <code>CONFIG/Notice</code> file.

=== Airport scene rendering ===
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
A '''tower view''' allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any (X-plane seems only to allow for one, but feel free to declare more for ATC-pie), otherwise defaults to somewhere over the airport to allow towering everywhere. It is disabled in CTR mode.
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 to listen for traffic and accept telnet connections.

'''Running internally''' only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the ''System'' settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].

Connecting to an '''external viewer''' allows to run FlightGear on a different machine and thereby relieve your session from the CPU load a local instance induces. If you want to do so, get a hint of the required positioning options you should start your viewer with, from the tower view tab in the system settings dialog. Of course, scenery, models and liveries must also be available to the running process.

In either case, once activated from the ''View'' menu, the tower view '''control pane''' is enabled, from which you can turn to runway points, follow selected aircraft... Direct FlightGear input in the view window is also possible: right click and drag allows to look around, <code>x</code>/<code>X</code> keys change the zoom level, etc.

You can hook up '''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 from the ''View'' menu. Additional viewers are registered by their host+port address, from the ''View'' menu at run-time or from a custom settings file (see <code>CONFIG/Notice</code>) read at start-up and on explicit reload (''System'' menu).

Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
* ''HHH'' is the host on which ATC-pie is running;
* ''PPP'' is the default 5009, or the chosen port number if ATC-pie was started with <code>--views-send-from</code>;
* ''TTT'' is the network polling frequency (100 is common practice; change as desired if you know what you are doing).

=== Background images ===
[[File:ATC-pie-screenshot-backgroundPixmapDrawing.png|thumbnail|Pixmap image example with a topographic map shot around LIMW (Aosta, Italy)]]
[[File:ATC-pie-screenshot-backgroundHandDrawing.png|thumbnail|Hand drawing example with procedures for LSGG (Geneva, Switzerland)]]
Background images allow to decorate:
* radar scopes, with all sorts of maps and useful information about the airspace, terrain or procedures;
* loose strip bays, to move unracked strips over custom backgrounds, e.g. ground charts of the airport.

There are two ways to create backgrounds in the program. One for all purposes is to '''import pictures''' (pixmap files like JPEG or PNG, including transparency); the other for radar backgrounds consists in writing '''drawing specification''' files to paint coloured lines and labelled points. This allows to import anything from complex coloured height maps to schematic airspace outlines. The <code>CONFIG/bg/Notice</code> file explains how to import and draw background images.

For example, you can map out procedures (SID, STAR, IAD...), grouping them by associated runways. Drawings are generally appropriate for that because specifications allow to directly refer to named points as per the published procedures, and therefore avoid manual positioning. But if you want more than schematic line plots, you should create the picture yourself. Using an image processing tool like ''GIMP'', superimpose a transparent layer on top of a real map canvas, or over a screenshot of your ATC-pie radar with pinned navaids as landmarks, and freely decorate your picture.

'''If you have a sector file''' of the format used in VATSIM/IVAO (.sct) for your area, you should try to import it with the "extract drawings from sector file" ''System'' menu tool. It will extract most of the contents around the open location up to the current map range, and translate it to ATC-pie's native drawing format. If you know they are included, it is generally the best option for things like SID/STAR procedures, although the generated files always require some filtering and post-editing. The way to proceed is as follows:
# Run the "extract drawings from sector file" option (''System'' menu) and select the file to extract from. This generates the following files in the <code>OUTPUT</code> directory:
#* <code>ICAO.lst.extract</code>, a menu file for the generated drawings;
#* <code>bg-ICAO-*</code>, the extracted drawings in the native ATC-pie format;
#* <code>bg-extract.err</code>, a log of the errors detected in your sector file (do not be alarmed as they often contain many).
# Import the results:
#* move or copy-paste lines from <code>ICAO.lst.extract</code> to <code>CONFIG/bg/ICAO.lst</code>;
#* move the desired drawing files under <code>CONFIG/bg</code>, adjusting the paths in the <code>.lst</code> menu as you organise subdirectories.
# Post-editing (cleaning)
#: ATC-pie does its best to understand the objects in the sector file and to group things together depending on their type. But not everything can be guessed automatically. This last step is where you filter, merge and split objects, rename points, change colours, etc. to your liking.
#: Each generated drawing section (point list under a colour) is automatically labelled with the line number where it was sourced from in the sector file so you can easily trace it (<code>@nnn</code>). A tool like ''sed'' will help you get rid of all these unwanted suffixes once you have sorted and renamed your objects:
#:: <code>sed -ri 's/ +@[0-9]+$//' file_to_clean</code>

NB: ATC-pie does not package or source from sector files directly because their data is not free. Besides, a lot of it is usually redundant with the airport sources (GPL).

Tips:
* You can check your image configuration without restarting the program, by reloading the files in their current state from the ''System'' menu (<code>Alt</code>+<code>F12</code>).
* The "image positioning helper" allows to move and resize imported pictures, adjusting the corners visually rather than programmatically if you have no specification for them. All visible pixmap images will be moved simultaneously, so you can work with several at a time if you want to. On dialog box close, a file is generated in the <code>OUTPUT</code> directory for you to copy from.
* An [[OpenStreetMap]] option will take you to the free online map server, centred on your radar centre position. For a quick and dirty start (e.g. for access to coastlines, borders and rivers) you can screenshot the map and use it as a background.

[[Category:ATC-pie]]

ATC-pie FAQ

2021-08-14T07:12:46Z

Mickybadia: v1.8.3

{{forum|83|ATC-Pie support & development}}

This page is a collection of questions asked at least twice about [[ATC-pie]]. It is a good idea to search through it before repeating a question on the forum or anywhere.

== Things "not working" ==

=== Why am I not seeing this aircraft on my radar? ===
Connected to FGMS: '''I know it is there: the pilot is sending chat messages and/or is visible on the online live map...'''

You only see an aircraft on your scopes if a radar contact is established, i.e. if it is visible to the primary radar or if the secondary radar (SSR) picks up a transponder signal from it.

The following cases will therefore prevent you from seeing a connected aircraft:
* The radars are turned off. Turn on at least a primary radar from the ''Options'' menu, or an SSR capability from the ''Radar'' tab in the ''Local settings'' dialog (any setting other than "none" will pick up contacts).
* The aircraft is out of radar range. It can be under the radar floor (minimum signal pick-up alt.) or too far out. In the radar settings, check the floor ("SFC" will pick up all signals down to the ground) and horizontal range. Primary and secondary radars share the same range.
* Its onboard transponder is turned off (and primary is off); see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Otherwise if you accept cheating, you can activate the "radar cheat mode" which will simulate a mode S transponder for all aircraft in horizontal range; see [https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3].

=== Connected pilots do not receive my text messages. ===
This happens with pre-2017.2 clients if you are using the latest protocol to encode properties. Tick the FGMS system option to "use the legacy protocol" for property encoding. Everybody should be able to read you, but it will come at the expense of network throughput. Tell those pilots to upgrade their client.

=== FGCom is not working. ===
First, verify that the FGCom variant selected in the ''system settings'' is the one you want to use. Check that your sound is on, your volume loud and your microphone working (system sound monitor picking up a signal). Close all open sessions and open a single ATC-pie instance.

If you have chosen the '''stand-alone''' FGCom variant, take the steps below in order:
# Echo test
#: Start an ''FGCom configuration test'' from the ''System'' menu. While the test is running, speak in the microphone and check if you can hear yourself back. If so, you may skip directly to step 4.
# Path to executable
#: Verify the FGCom command entered in the system settings. It should contain an executable system command or a relative or absolute path to an FGCom executable file. If you have FlightGear installed on your machine, you can point to the FGCom executable already available with it. On Linux, the default "fgcom" command usually does the job. Otherwise, [https://sourceforge.net/projects/atc-pie/files/fgcom-standalone/ download an FGCom stand-alone program] from ATC-pie's SourceForge file list. In any case, try the entry from a terminal in the ATC-pie directory to manually check that it runs correctly.
# FGCom server status
#: The server may temporarily be down, unfortunately even for up to a few days. Check for responses from the server, e.g. with <code>ping fgcom.flightgear.org</code> (adjusting the server name to match the one entered in the settings). FGCom will not work without a responding server.
# FGCom subprocess error
#: After turning your radio on, check for errors in the logged FGCom output files in the <code>OUTPUT</code> directory.
# Port mess-up in your session?
#: When creating a new radio box at run time, make sure you choose an available port number for each. Caution when running multiple ATC-pie instances: do not use a port more than once across the system at the same time.

If you have chosen the '''FGCom-Mumble plug-in''':
# Plug-in status
#: Check that your Mumble client is connected and properly running the FGCom plug-in.
# Port setting
#: Check that the control port in ATC-pie is set to the one FGCom-Mumble is listening on.
# Echo test
#: Start an ''FGCom configuration test'' from the ''System'' menu.

Note that the two variants are ''not'' interoperable. Users will only be able to hear and interact with others using the same variant (and server) as their own.

=== Recording ATIS with stand-alone FGCom: no beep is heard after pressing "record". ===
Assuming FGCom standalone is working (confirm this with an echo test before reading on)...

Due to the design of this legacy FGCom variant, you may only record an ATIS if the requested frequency is enlisted as recordable on the distant server's "phone book" for the airport. The one for <code>fgcom.flightgear.org</code> was compiled a while ago, based on the latest <code>apt.dat</code> at the time. It filtered the frequencies through the two following conditions:
# it is of the "recorded" type (row code 50);
# its name contains the uppercase string "ATIS".

If you are relying on the old data provided by ATC-pie, in other words you have not downloaded new data or edited the frequencies yourself, check against the <code>.dat</code> file extracted in the <code>OUTPUT</code> directory on your side, as it should still be similar to the one on the server's side. One of the two conditions is probably not met, or the frequency missing. NB: The frequencies in the ATIS drop-down list of ATC-pie are matched against the condition (1), but not against the somewhat restrictive condition (2).

In any case, consider switching to the newer FGCom-Mumble plug-in variant. It simulates radio waves, frequencies and ranges, which avoids the phone book problem all together.

=== Tower view is not starting. ===
Ruling out that FlightGear is not installed at all, your system path settings are probably wrong. From a terminal or a file system navigator, find the right command to start FlightGear and enter it as ''FlightGear executable'' from the system settings. Do not add options of any kind; they will be taken care of internally. You may have to enter a ''FlightGear root directory'' as well, especially if you have the program files installed somewhere unexpected.

=== My tower is in the middle of the sea, and aircraft floating/landing on water! ===
You are missing the FlightGear scenery data for your location, or ATC-pie does not know where it is. If you have downloaded scenery and saved it somewhere, have you tried filling the scenery directory with that location in the system settings? Also check out the ''Tower viewing'' [[ATC-pie_user_guide#Tower_view_window|feature note]] in the user guide.

=== Simulated aircraft appear to dip underground or levitate over taxiways. ===
Do you have a ground elevation map for the location? Quoting from <code>CONFIG/elev/Notice</code>: "''When no elevation map is found for an airport, the field elevation value is used everywhere on the ground. This should be OK for a rough approximation on flat terrain, but ground traffic will not follow any slopes, thus may appear as floating above the ground, or dipping into it.''"

Read the full notice for instructions on how to build your elevation map. Once you have one or decide that your field is flat enough, the next focus is on the FlightGear aircraft models. Each model has its own coordinate system chosen at developer's discretion. ATC-pie must be given the height difference between each model's origin and the aircraft touch-down point (gear wheels) to position aircraft more accurately. You can do this on a per-model basis with ":height" specifications in <code>CONFIG/acft/icao2fgfs</code>. Read the associated <code>Notice</code> file for more information.

A last possible altitude adjustment is available from the location options: "Altitude adjustment for FlightGear views". It applies the given offset to all traffic rendered by the views.

=== Phone lines have broken, choppy or dragged out sound ===
You and the other parties must adjust microphone sensitivity. Toggle the phone squelch adjustment box from the system menu and tune the spinbox next to the "call" button in the ATC coordination panel. Lower values will decrease the threshold for sound pick-up and likely break the sound less, but can generate more lag in the communications. The right balance depends on your local configuration, so a few test calls with other connected ATCs will be necessary to decide on the best acceptable value.

=== I cannot connect to my teacher as a student. ===
Using IPv4 addresses, this typically happens when the teacher is in a local area network behind a router. It is a common setup for home internet, in which the teacher's actual host address is not publicly accessible from outside his private network.

If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either:
* for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local host address;
* or to create a virtual network, using a third-party VPN service.

== What is ...? Why is ...? What value/setting for ...? ==

=== What "social name" should I use for FlightGear/FSD sessions? ===
Choose any name you would like to be recognised by on the network. In ATC-pie, it will appear in the tool tip over your callsign for connected ATCs who see you. This feature is only social in the sense that it does not refer to an account or to anything technical, but it makes sense as typical ATC callsigns (e.g. "VHHHtwr") remain mostly anonymous. Use this field to identify yourself on the network.

=== Are the vector headings true or magnetic? ===
Heading displays in ATC-pie are mostly magnetic so they can be read out to pilots. The exceptions are the navigator and handover list tool tips, which show true radial headings from the radar position, and the teacher's wind section to match the generated ATIS string.

Also note: all directions are geodesic, i.e. initial headings to take on a great circle.

=== What is the purpose of the flat "strip shelf" button in the strip panes? ===
More than a button, the strip shelf is where you should drop the contacts you release without a handover, e.g. parked traffic shutting down, VFR traffic flying out of your airspace, etc. Clicking on the shelf allows to browse the previously shelved strips, and to recall them, for example if shelved inadvertently.

=== What do the various markings along the approach centre line mean? ===
The regularly spaced groups along a centre line represent altitudes on the approach plane. Each group sums up to an AMSL value in accordance with the set flight path angle (also see ''Display conventions'' in the quick reference):
* straight line = 1,000 ft;
* solid diamond = 5,000 ft.

The other markers drawn with thicker lines are the positions of the ILS marker beacons (OM, MM, IM), the line pattern representing the sound triggered by the beacon in the pilot's headset. They are sourced on program start-up from the navigation data (<code>CONFIG/nav/navaid.dat</code>).

=== Why do I keep getting runway incursion alarms? ===
Because you have the runway occupation monitor turned on (''Options'' menu), while not using your runway boxes. The alarm triggers when the radar detects traffic stepping on a runway in either of the following situations:
* the runway is active (marked in use) and no strip is boxed for it;
* it is reserved but there is already traffic on the runway;
* it is reserved for a different aircraft: the boxed strip is linked to a contact that is not the entering aircraft, or the aircraft is linked to a strip different to the one boxed.

Turning the runway occupation monitor off will deactivate all radar warnings regarding runways. If you are interested in the strip boxing and visual runway highlighting system but bothered by the alarm sound, you can mute the sound notification by unticking it in the general settings.

== Where is ...? How to ...? ==

=== Can I draw SID and STAR procedures on the radar? ===
Yes, and virtually anything else, using background images. To learn about those:
* see the corresponding [[ATC-pie_installation_guide#Background images|installation guide section]];
* read the <code>CONFIG/bg/Notice</code> file.

=== How do I assign SIDs and STARs to aircraft? ===
This question is asked quite a lot more than it is relevant to a real controller's task...

What people seem to be after when asking this question is a way to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. The way to handle this is to stack your inbound strips on racks named after your STARs. Racks are indeed above all meant for efficient traffic sequencing. Every rack represents its own sequence of ordered aircraft, which is perfectly suited to control separate approach paths in parallel. With this technique, placing a strip on a STAR-named rack basically serves as the "assignment" itself. Similarly, runway-specific racks can keep track of separate landing sequences at large airports. Then you can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times in the sequence all the way to touchdown.

If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. Routes are lists of waypoints and instructions to follow between the two end airfields. Normally pulled straight from properly filed flight plans, routes are printed on strips prior to departure, then modified as the flights progress and passed along with handovers. Standard departure and arrival procedures (SIDs and STARs) can be referred to in those routes, but only by their entry or exit navpoints. They should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. For example, routes ending with a STAR should end with "FUBAR STAR", which means that waypoint FUBAR is an entry point from which a published STAR must be followed. The keyword "STAR" is in fact a mere specification for the last route leg. Similarly, routes of the form "SID DUMMY ..." specify their first leg as a standard departure to the first waypoint DUMMY. "SID" and "STAR" keywords are recognised by ATC-pie and accounted for in the second line of the radar tag when appropriate (see feature note on routes).

One meaningful wish regarding this question is for easy '''reference in text chat''' messages. Firstly, using racks in the way suggested above, you can use the <code>$rack</code> alias which is substituted by the name of the rack on which the current strip selection is stacked. Otherwise, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". Now if you specifically want to assign a full procedure name like FUBAR1A to a contact and refer to it in a generic text chat message, include a line "sid=FUBAR1A" 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 expanded in your sent messages when that strip is selected.

=== How to set the transition level? ===
You do not. You can however set the transition altitude in the location settings if your airport specification file does not already include one.

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, e.g. for more vertical separation on either side of the transition layer or due to coordination with neighbouring zones and fields.

=== Can I look up ILS frequencies? ===
Yes, in the ''environment info'' dialog.

Besides, you can create aliases with the local notepad for a quick and integrated way of sending them through text chat, which will be saved when you close ATC-pie. For example, use the following format, one runway per line: <code>ils05=111.11 MHz</code>. See [[ATC-pie_user_guide#Public text chat|custom text aliases]] for more.

=== The navigation/airport data is outdated. How can I update it? ===

For '''airport data''' (taxiways, parking positions, frequencies, etc.), the included source is the last world-wide <code>apt.dat</code> compiled before it became too large to maintain as one huge file. We keep it there because it allows to run ATC-pie anywhere in the world without requiring external data, but its contents grows out of date with time. You should check for more recent sources on the [http://gateway.x-plane.com/airports/page X-plane airport gateway], directly accessible from the ''System'' menu, on a per-airport basis. Extract the <code>apt.dat</code> file from the download, rename it after the airport's ICAO code (keeping the extension, e.g. <code>KJFK.dat</code>), and place it in <code>CONFIG/ad</code> (also see the <code>Notice</code> there). Alternatively, for a quick manual touch-up of the included data, you can move and edit extracted files (see <code>OUTPUT/Notice</code>).

For '''navigation data''' (navaids, fixes, airways, etc.), the included data is the latest version of each file that was seen released as GPL, which makes some of it date back to 2013! You should provide more recent navigation data, as explained in <code>CONFIG/nav/Notice</code>.

=== How do I customise the GUI and colours? ===
To change the '''radar or strip drawing colours''', edit the <code>CONFIG/colours.ini</code> file. Each line specifies the paint colour for an object type, in a typical hex <code>RRGGBB</code> (red-green-blue) format or as an SVG colour keyword name like "white". To customise the '''main session window''', place a ''Qt stylesheet'' named <code>main-stylesheet.qss</code> in the <code>CONFIG</code> directory. ATC-pie will apply it to every session window. While you are working on your look and feel, use the reload feature from the "System" menu to avoid restarting after every change (<code>Shift</code>+<code>Alt</code>+<code>F12</code>).

Send us screenshots and share your files if you find a setup looking really cool! :-)

== Miscellaneous ==

=== What's with the funny name? ===
ATC-pie is written in Python, and I reckoned that the ''pyXXX'' naming habit was becoming a little dull, so I merely switched things around. You can surely do the rest of the math in terms of spelling, and later impact on the logo.

=== Why is the learning curve so steep? People would use your program more if you did/provided [...] ===
Often continued with: '''(you must understand that) this is not VATSIM!'''

We do have a [https://sourceforge.net/p/atc-pie/wiki/Wishlist wish list] and will consider any feature or help request. However, though it has a few cheats, ATC-pie has always choosen realism as a criterion for implementation and design, over the mere incentive of converting otherwise happy users of other programs. It is a good thing that different philosophies and work flows are available out there, and there would be much less interest in having them all copy each other, fighting over users instead of understanding that not all of them wish for the same experience. If serious simulation or learning new skills sound like threats to fun for you, you have a perfectly valid reason not to opt for ATC-pie.

[[Category:ATC-pie]]

ATC-pie

2021-08-14T07:12:36Z

Mickybadia: v1.8.3, moving sections across articles to balance sizes

{{forum|83|ATC-Pie support & development}}

{{about|the software in general|a manual on how to use it|ATC-pie user guide}}

{{Infobox Software
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.8.3 (Aug. 13, 2021)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''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 [[ATC-pie installation guide|installation]] and [[ATC-pie user guide|user]] guides. If you have a question, check the [[ATC-pie FAQ|FAQ]] first, or try the forum for help.

== Screenshots ==

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Solo session with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

== 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 ===
[[File:ATC-pie-screenshot-stripDetailSheet.png|thumbnail|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 [http://en.wikipedia.org/wiki/Secondary_surveillance_radar 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 ===
[[File:ATC-pie-screenshot-radarIdentification.png|thumbnail|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 [[:File:ATC-pie-screenshot-ATISdialog.png|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:
* Strip exchange: full handover support with ATC-pie, compatible with [[OpenRadar]]
* Voice radio: FGCom integration (using [[FGCom_3.0|stand-alone processes]] or through [[FGCom-mumble|Mumble plug-in]])
* Weather: real world METAR retrieval
* Flight plans: interface with [http://flightgear-atc.alwaysdata.net Lenny64's data base] (the ''de facto'' FG standard)
* ATIS: voice recording through FGCom

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 [[: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

Data sources:
* Airport and navigation data sourced in the [http://data.x-plane.com 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)
* Real world magnetic declination lookup

== Interoperability with other software ==

=== FlightGear sessions and compatibility with OpenRadar ===
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 while respecting both approaches as much as possible, the following principles and restrictions apply to strip exchange:
* 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.

=== FSD sessions and compatibility with Euroscope ===
Euroscope is a popular program to control on VATSIM, a flight simulation network whose protocol is historically based on FSD, available in ATC-pie. 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 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:Air Traffic Control]]

ATC-pie installation guide

2021-08-14T07:12:33Z

Mickybadia: v1.8.3, moving sections across articles to balance sizes

{{forum|83|ATC-Pie support & development}}

{{about|installing and running ATC-pie|a manual on how to use it|ATC-pie user guide}}

== Installing ==

=== Preparing ===
[[ATC-pie]] is free and open source, and programmed in Python3 for Qt5. It is therefore system-independant, but requires Python3 and the PyQt5 library to run. The exact dependencies and required versions are listed in the <code>README</code> file packed in the download. When they are installed, ATC-pie runs straight away without any compiling to do (make, etc.).

=== 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.

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 Git '''repository''':
: <code>git clone git://git.code.sf.net/p/atc-pie/code ATC-pie</code>

=== More to install? ===
I say again: the download/clone alone is not enough; both Python3 and PyQt5 must be installed too. ''Please'' read the <code>README</code> file for extra notes on installation.

With the dependencies installed, at this point you have a working program. But further software pieces can be installed to enable more of its features, as listed below. Depending on your use of ATC-pie, they can be recommended for more realism but they are not required, and can be installed later.

For a 3D '''tower view''' in any airport session, ''[[FlightGear]]'' must be available, with the appropriate aircraft models and scenery data. Note that it can run on a separate machine, as explained [[#Airport scene rendering|down this article]].

To enhance solo sessions:
* with '''voice instruction recognition''' by the AI aircraft, install ''PocketSphinx'';
* with '''speech synthesis''' of AI pilots' radio messages, install ''pyttsx''.

To enhance FlightGear and FSD sessions with an integrated '''ATC telephone switchboard''' (direct voice lines), install ''PyMumble''.

To enhance FlightGear sessions:
* with '''[[CPDLC]]''' and '''full ATC coordination''' including unlimited strip exchange and text messaging, install the ''Python IRC library'' (recommended!);
* with '''voice radio simulation''', install the ''FGCom-Mumble'' plugin (requires a ''Mumble''>=1.4 client) or the older ''standalone FGCom'' executable client (note that both variants cannot be used simultaneously).

== Running ==

Depending on your system and preference, you might be double-clicking, typing stuff or pulling your hair out. In any case what you must do is run a Python3 interpreter on the <code>ATC-pie.py</code> file from the downloaded directory.

=== Two program modes ===
[[File:ATC-pie-screenshot-launcherDialog.png|thumbnail|Initial graphical launcher, with AD vs. CTR mode choice]]
On program start, a welcome launcher window should open, from which you may start a session in either airport (AD) or centre (CTR) mode, i.e. respectively with or without a base airfield.

The '''airport mode''' is for ATC positions like approach or tower control. In this mode, ATC-pie places the radar at the chosen base airfield, depicts its tarmac and runways, and enables features like tower viewing and runway selection.

The '''centre mode''' is designed for en-route control centre simulation. It disables all airport-specific features, and allows to place the radar anywhere on Earth. When selecting this mode:
* The location code is a designator of your choice (excluding airport codes), under which to save your location-specific settings. A good idea is to use ICAO airspace designations, e.g. <code>SBBS</code> for the Brasilia FIR in central Brazil or <code>LFFF</code> for the Paris region in France.
* The radar position field specifies the point on which to centre the radar. For example, <code>LFPO>090,15</code> will centre the radar on a point 15 NM to the East of Orly airport. Click on the help button for a summary of valid point specification formats, or read the ''Point specification'' section in the quick reference for more detail.

=== Command line arguments ===
You may bypass the launcher and start directly at a given location with the following command, using an ICAO code for an airport or a previously defined CTR location code:
: <code>./ATC-pie.py location_code</code>

Besides, the following command line options are available:
{| class="wikitable"
! Option || Effect and argument specification || Default
|-
| --map-range=''range'' || Only valid with a location code argument. Defines the distance in NM from the radar centre up to which the map will be drawn and navpoints listed in the navigator (accepted values are 20..500). This does not affect radar range, which can still be greater or lower (and be changed within sessions).' || 100 in AD mode; 300 in CTR mode
|-
| --views-send-from=''port'' || Sets 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 FGMS connection port, chosen on session start. || 5009
|}

=== Starting sessions ===
All session types are started from the ''System'' menu.

Solo simulation:
* wind will be randomised at start, but will be forced to blow in a favourable direction if at least one active runway is selected before start;
* traffic is spawned with intentions according to the ''solo simulation configuration options'' (<code>Shift</code>+<code>F11</code>), so it is preferable to configure them before starting the session to avoid undesired traffic at start.

FlightGear network session:
* callsigns for ATCs in FlightGear are expected to start with the ICAO code of the controlled airport or sector, and end with a hint on the provided service (twr, gnd, ctr...), e.g. "KORDgnd" (note that FGMS restricts callsign length to 7 characters);
* before choosing your callsign, make sure it is not already in use;
* you can connect more than one ATC-pie instance from the same computer, but must use different ports;
* the three "sub-systems" that can be activated support different coordination features and differ in terms of interoperability with other clients, but all can be enabled together:
** '''native ATC-pie coordination''' enables full interaction with other ATC-pie clients, but does not currently operate with other software;
** '''ATC phone lines''' system integrates direct voice (telephone) lines to other connected ATCs in the ATC coordination panel (also ATC-pie only);
** '''OpenRadar handover compatibility''' implements [[OpenRadar]]'s native system to enable coordination with its users, although some limitations apply (see [[ATC-pie_user_guide#FlightGear_sessions_and_compatibility_with_OpenRadar|interoperability note]] in the user guide).

== Configuring ==

Here are things you will soon want or have to set up for a regular use of ATC-pie:
* set up a [[#Airport scene rendering|tower view]] to enable visual contact with your traffic in AD sessions;
* for FlightGear and FSD sessions, give yourself a "social name" so that others recognise you when using any of the ATC coordination/exchange features;
* for FlightGear sessions and realistic radio experience, select an [[FGCom]] variant in the system settings, and test the configuration from the ''System'' menu.

If you intend to operate often at a given location, it is sensible to:
* if it is an airfield location, download the latest airport data file from the [https://gateway.x-plane.com/airports/page# X-plane gateway] and place it in <code>CONFIG/ad</code> (see the <code>Notice</code> file there);
* review and fill the various fields in the location set-up dialog (runway capabilities deserve special focus for more realisitc aircraft intentions in AD solo sessions);
* configure the workspace racks, bays and radar screens to suit the environment and service provided, they will be saved for future runs;
* if using the radar, pin your preferred navpoints (they are restored on every run) and consider creating/importing background pictures to map terrain obstacles, procedure charts, etc. (see [[#Background images|section below]]);
* for solo and teacher sessions at airports especially, build an elevation map (see <code>CONFIG/elev/Notice</code>).

For more advanced editable options, read the <code>CONFIG/Notice</code> file.

=== Airport scene rendering ===
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
A '''tower view''' allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any (X-plane seems only to allow for one, but feel free to declare more for ATC-pie), otherwise defaults to somewhere over the airport to allow towering everywhere. It is disabled in CTR mode.
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 to listen for traffic and accept telnet connections.

'''Running internally''' only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the ''System'' settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].

Connecting to an '''external viewer''' allows to run FlightGear on a different machine and thereby relieve your session from the CPU load a local instance induces. If you want to do so, get a hint of the required positioning options you should start your viewer with, from the tower view tab in the system settings dialog. Of course, scenery, models and liveries must also be available to the running process.

In either case, once activated from the ''View'' menu, the tower view '''control pane''' is enabled, from which you can turn to runway points, follow selected aircraft... Direct FlightGear input in the view window is also possible: right click and drag allows to look around, <code>x</code>/<code>X</code> keys change the zoom level, etc.

You can hook up '''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 from the ''View'' menu. Additional viewers are registered by their host+port address, from the ''View'' menu at run-time or from a custom settings file (see <code>CONFIG/Notice</code>) read at start-up and on explicit reload (''System'' menu).

Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
* ''HHH'' is the host on which ATC-pie is running;
* ''PPP'' is the default 5009, or the chosen port number if ATC-pie was started with <code>--views-send-from</code>;
* ''TTT'' is the network polling frequency (100 is common practice; change as desired if you know what you are doing).

=== Background images ===
[[File:ATC-pie-screenshot-backgroundPixmapDrawing.png|thumbnail|Pixmap image example with a topographic map shot around LIMW (Aosta, Italy)]]
[[File:ATC-pie-screenshot-backgroundHandDrawing.png|thumbnail|Hand drawing example with procedures for LSGG (Geneva, Switzerland)]]
Background images allow to decorate:
* radar scopes, with all sorts of maps and useful information about the airspace, terrain or procedures;
* loose strip bays, to move unracked strips over custom backgrounds, e.g. ground charts of the airport.

There are two ways to create backgrounds in the program. One for all purposes is to '''import pictures''' (pixmap files like JPEG or PNG, including transparency); the other for radar backgrounds consists in writing '''drawing specification''' files to paint coloured lines and labelled points. This allows to import anything from complex coloured height maps to schematic airspace outlines. The <code>CONFIG/bg/Notice</code> file explains how to import and draw background images.

For example, you can map out procedures (SID, STAR, IAD...), grouping them by associated runways. Drawings are generally appropriate for that because specifications allow to directly refer to named points as per the published procedures, and therefore avoid manual positioning. But if you want more than schematic line plots, you should create the picture yourself. Using an image processing tool like ''GIMP'', superimpose a transparent layer on top of a real map canvas, or over a screenshot of your ATC-pie radar with pinned navaids as landmarks, and freely decorate your picture.

'''If you have a sector file''' of the format used in VATSIM/IVAO (.sct) for your area, you should try to import it with the "extract drawings from sector file" ''System'' menu tool. It will extract most of the contents around the open location up to the current map range, and translate it to ATC-pie's native drawing format. If you know they are included, it is generally the best option for things like SID/STAR procedures, although the generated files always require some filtering and post-editing. The way to proceed is as follows:
# Run the "extract drawings from sector file" option (''System'' menu) and select the file to extract from. This generates the following files in the <code>OUTPUT</code> directory:
#* <code>ICAO.lst.extract</code>, a menu file for the generated drawings;
#* <code>bg-ICAO-*</code>, the extracted drawings in the native ATC-pie format;
#* <code>bg-extract.err</code>, a log of the errors detected in your sector file (do not be alarmed as they often contain many).
# Import the results:
#* move or copy-paste lines from <code>ICAO.lst.extract</code> to <code>CONFIG/bg/ICAO.lst</code>;
#* move the desired drawing files under <code>CONFIG/bg</code>, adjusting the paths in the <code>.lst</code> menu as you organise subdirectories.
# Post-editing (cleaning)
#: ATC-pie does its best to understand the objects in the sector file and to group things together depending on their type. But not everything can be guessed automatically. This last step is where you filter, merge and split objects, rename points, change colours, etc. to your liking.
#: Each generated drawing section (point list under a colour) is automatically labelled with the line number where it was sourced from in the sector file so you can easily trace it (<code>@nnn</code>). A tool like ''sed'' will help you get rid of all these unwanted suffixes once you have sorted and renamed your objects:
#:: <code>sed -ri 's/ +@[0-9]+$//' file_to_clean</code>

NB: ATC-pie does not package or source from sector files directly because their data is not free. Besides, a lot of it is usually redundant with the airport sources (GPL).

Tips:
* You can check your image configuration without restarting the program, by reloading the files in their current state from the ''System'' menu (<code>Alt</code>+<code>F12</code>).
* The "image positioning helper" allows to move and resize imported pictures, adjusting the corners visually rather than programmatically if you have no specification for them. All visible pixmap images will be moved simultaneously, so you can work with several at a time if you want to. On dialog box close, a file is generated in the <code>OUTPUT</code> directory for you to copy from.
* An [[OpenStreetMap]] option will take you to the free online map server, centred on your radar centre position. For a quick and dirty start (e.g. for access to coastlines, borders and rivers) you can screenshot the map and use it as a background.

[[Category:ATC-pie]]

ATC-pie user guide

2021-08-14T07:12:30Z

Mickybadia: v1.8.3, moving sections across articles to balance sizes

{{forum|83|ATC-Pie support & development}}

This article is a guide to the air traffic control simulation program [[ATC-pie]], describing some of its major features. A more exhaustive list can be found in the main article. For download and installation help, refer to the [[ATC-pie installation guide]]. For support and troubleshooting, the [[ATC-pie FAQ]] might get you an answer first. Otherwise kindly ask on the dedicated FlightGear sub-forum so that the discussion is public.

Other sources to learn the program are:
* the [https://www.youtube.com/playlist?list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb online] '''video tutorial''';
* the in-app '''quick reference''' available from the ''Help'' menu (summary of mouse/keyboard gestures, display conventions...);
* a skilled '''teacher''' to connect to as a student (personal training);
* to '''train solo'''!

== Flight strips ==

Whether dematerialised or on physical paper, printed out or filled by hand, the '''flight progress strip''' is the essential piece of air and ground traffic control. Every aircraft in contact is represented by a unique strip, and every strip represents a contact. This helps to ensure that no aircraft is ever forgotten about. Strip positioning and updating then enable to monitor the aircraft's status, sequence number, position, intentions, etc.

=== Strip details and linking ===
A click on the "new strip" tool bar button (shortcut <code>F2</code>) or double-click on an empty strip rack or bay space will open a dialog to fill flight details on a fresh blank strip, e.g. destination, type of aircraft, etc. Double-clicking on an existing strip allows to edit the filled details.

If providing radar service, strips should be '''linked''' to identified contacts to inform the radar display with the filled details and enable joint selection. To link a strip to a radar contact, select one and middle-click on the other. Conflicts between the strip details and the values squawked by the linked transponder contact are reported: the strip displays a "!!XPDR" warning and the strip dialog labels the conflicting details.

A strip can also be linked to a filed flight plan (FPL). This will make radar and strip display fall back on filed information for missing details. The strip dialog also shows the mismatching information between the two, though this is rather common because the strip typically gets updated as the flight progresses.

All together, a selection can involve up to three linked elements: strip, radar contact, flight plan. You can pull details from linked elements to strips (strip panel bottom menu), and push strip details to their linked flight plan if necessary (strip dialog bottom tick box). Unlinking is possible with <code>Shift</code>+middle-click. If you use linking carefully, auto-fill options are available from the general settings, to fill blank strip details with newly-linked information.

For fast and efficient service, every initial contact by a pilot should basically make you hit <code>F2</code> and type the spoken callsign. You should then soon figure out if, for example:
* a flight plan is already filed: a matching FPL count is displayed near the callsign field as you type, if any (click on the button to view them);
* a flight plan must be filed (e.g. IFR departure not filed by lazy pilot): select "new FPL" from the bottom line to open a fresh FPL detail sheet to link to the strip;
* he was asked to contact you by a previous ATC, in which case you may have a strip handed over to you already;
* it is a new contact: keep filling the strip with details the pilot gives you.

=== Strip placeholders ===
ATC-pie provides with three types of placeholders for flight strips: ''racks'', ''loose strip bays'' and ''runway boxes''. According to your ATC position and local facilities, you should choose and arrange your placeholders for optimal control. Strips can then be moved between them using mouse drag and drop.

[[File:ATC-pie-screenshot-stripRacks.png|thumbnail|Strip rack panel]]
A '''strip rack''' is the preferred way of keeping track of a sequence, e.g. a departure queue at a runway threshold. Rack panels can be created from the main window workspace, popped out as separate windows, and a persistent one can be found among the available docks. You can create as many racks as you wish in every panel. Double click on a rack's name to rename it or edit its properties. Use mouse drag to move strips up and down a rack sequence.

A '''loose strip bay''' allows free-hand positioning of strips in its reserved space. Such bays are useful for unsequenced traffic, or to map out relative positions when controlling without a radar. You may also import background images, e.g. a ground chart to keep visual track of taxiing aircraft and vehicles. See <code>CONFIG/bg/Notice</code> to learn how.

[[File:ATC-pie-screenshot-runwayReserved.png|thumbnail|Reserved runway marked in yellow]]
A '''runway box''' is a placeholder for a single strip, named after a physical runway and denoting a clearence to use it (enter, cross, land...). Runway boxes are contained in their own dock, with one made visible for each runway marked as in use in either direction. Thorough use of runway boxes will help you avoid bad mistakes like clear an aircraft to land over lined up traffic. When freed, runway boxes start and display a timer together with the wake turbulance category of the last contained strip to help with TKOF/LDG separation. What is more, if you use radar, a filled runway box marks the runway as ''reserved'' on the scope.

Besides, there are two other places a strip can be dropped on, usually when releasing a contact:
* an ATC callsign in the ATC panel to initiate a handover;
* a '''strip shelf''' (flat button at the bottom of loose and racked strip panels), which clears the strip from your workbench and stores it as shelved.

== Vectors, routes and separation warnings ==

ATC-pie can register and analyse issued vectors and routes to:
* inform strip and radar display;
* help monitor traffic, checking tracked positions against route/vector assignments;
* help manage traffic, anticipating route and FL conflicts between controlled aircraft.

=== Vectors ===
[[File:ATC-pie-screenshot-courseAndAssignmentsGraphics.png|thumbnail|Course/vector drawing for linked radar contact]]
Registering vectors on strips enhances the drawing of linked radar contacts, enables easy monitoring of tracks and detection of aircraft flying off course. To register vectors automatically when a radar contact is linked to a strip, use the following mouse gestures:
* click and drag out of a radar contact to issue a heading vector;
* holding <code>Shift</code>, click and drag vertically for altitude/FL vectors;
* holding <code>Shift</code>, click and drag horizontally for speed instructions;
* holding <code>Shift</code>, double-click on the radar target to clear registered vecors from the linked strip.

See [https://www.youtube.com/watch?v=BvA3MRlGJjU video 5] of the tutorial for more on vectoring, and check the quick reference ''display conventions'' to interpret the lines and colours of the course and vector graphics around radar contacts.

NB: In network sessions, an appropriate text chat instruction is suggested for every mouse vectoring action. This allows you to send it easily, for example to pilots whose communications are limited to text chat.

=== Routes ===
[[File:ATC-pie-screenshot-routeDetailsView.png|thumbnail|Route details dialog with world path drawn, available when both end airfields are recognised]]
A '''route''' is analysed for every strip with recognised departure and destination airports (entry fields both turned green), 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);
* if ambiguous (navpoint names are not all unique around the world), a waypoint is always the nearest homonym to the point beginning the leg;
* other tokens are kept as route leg specifications to the following waypoint (e.g. airways between fixes).

[[File:ATC-pie-screenshot-routeDrawing.png|thumbnail|Assigned routes are drawn as dashed lines on the radar scope when linked to contacts]]
Routes on flight plans and strips are viewable in a route dialog, showing geodesic paths, headings and leg distances on a world map. When a specified route is linked to a radar contact, ATC-pie works out its current leg based on distance to destination, and:
* details of the current leg are displayed in the selection info pane, and the route viewing button enabled;
* the strip shows only the remainder of the route for this contact;
* the route to go is drawn as a dashed line on the radar (unless aircraft is inbound and near enough);
* the radar tag 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.

NB: If DEP and ARR airports are not both recognised, radar tags show the strip destination detail if it is filled, possibly with a heading if it is recognised.

See tutorial [https://www.youtube.com/watch?v=LfdukpBc90w video 7] for a demonstration of routes.

=== Conflicts and anticipation ===
[[File:ATC-pie-screenshot-routeConflictDetection.png|thumbnail|Route conflict depiction]]
ATC-pie 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 aircraft with a linked strip and an assigned route or heading. 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. When the projections of two aircraft intersect, a conflict is anticipated if the respective intervals between the current and assigned altitudes overlap. When an aircraft's altitude is unknown, the assigned altitude will be assumed. If an altitude assignment is missing, a ''possible'' conflict is reported.

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 || Thick bright red intersecting circles || Separation loss between aircraft
|-
| Path conflict || Red circles and paths || Anticipated paths and altitudes are intersecting
|-
| Possible path conflict || Yellow circles and paths || Paths intersecting but some altitudes unknown
|}

== Communications with aircraft ==

=== Voice radio ===
In solo sessions, voice radio interaction is simulated through speech recognition of instructions and read-back synthesis.

In FlightGear network sessions, '''multiple radios''' can be opened and tuned in simultaneously. You can transmit on either one by holding down the PTT button of the chosen radio, or on a selected set (''Kbd PTT'' boxes ticked) using the <code>Ctrl</code> keyboard key. This lets you PTT on multiple frequencies at once (merged frequencies), for example to service GND+TWR frequencies in view of splitting them seemlessly again later. Note that while you will be broadcasting on, and hearing incoming transmissions from, all frequencies, pilots will not be hearing each other across frequencies. If you monitor frequencies that you are not servicing, a trick is to set their volume to "soft" to tell them apart.

The '''''PTT turns off sounds''''' option is recommended if you do not wear a headset. It will avoid picking up GUI sound notifications with your microphone while transmitting.

=== CPDLC ===
When [[CPDLC]] is serviced (location setting), aircraft can establish a data link from their cockpit for a direct text communication channel supplementing the radio frequency. You can monitor connections from the CPDLC dock and open a window for each active or terminated connection in the CPDLC history. Combining the <code>Alt</code> key with a double-click on a strip or radar contact opens the current or latest dialogue for the selected callsign.

Each active CPDLC dialogue window allows to manually compose preformatted or free text message elements. But the most frequent and convenient way of creating message elements is to combine the <code>Alt</code> key with a mouse gesture (also see ''Mouse gestures'' in the quick reference):
* click-and-drag vectoring gesture to send a heading, altitude/FL or speed instruction (see [[#Vectors|section on vectors]]);
* strip drop on an ATC to initiate a CPDLC authority transfer or to send the aircraft a "contact" instruction;
* "OK" button click in the instruction panel to send the corresponding formatted instruction.

Created message elements are appended to the message buffer in the connection dialogue window until you send the message manually. The other party must then acknowledge it before it times out.

=== Radio text chat ===
Although voice communications should be encouraged for realism whenever possible, ATC-pie has a powerful text chat system for keyboard interaction with pilots in network sessions. In FlightGear sessions, all messages from within at least 100 NM and up to the radar range are visible in the chat. In FSD sessions, whose protocol simulates text frequencies, ATC-pie tunes the chat to the "publicised frequency" in the radio panel.

'''Text aliases''' are dollar-prefixed words that ATC-pie tries to replace with context-dependant values when sent. For example, <code>$metar</code> expands to the current primary station weather. This allows to write and save formatted messages instead of repeating chunks of a recurrent format. For instance, anybody will enjoy the comfort of sending "Current weather is $metar" instead of copy-pasting a weather look-up for every such message.

Aliases can be predefined or custom. Predefined aliases take values that are specified by the program, e.g. <code>$metar</code>, and may depend on the local environment (declination, airport elevation...), on your configuration (transition altitude, runways in use...) or on the current selection (QDM to airport, assigned route...). They are all listed with their meaning in the "quick reference", ''Text aliases'' section. Make sure to take a look.

All other aliases will be considered custom, in other words to take values specified by you. You can define text aliases on three different levels:
* world (saved for replacement anywhere that the program will be opened), in the general notes (notepad dock);
* location (saved for this airport or centre), in the local notes;
* single aircraft contact (by selected strip), in the strip comments.

Here is how ATC-pie decides what to do with a text alias of the form <code>$foo</code> in a sent message:
# If it is one of the predefined list, the specified substitution is performed. If not, it is a custom alias and we carry on to the next step.
# Look for a line beginning with <code>foo=</code> in the general notes. If one is found, the alias is replaced with what follows the '<code>=</code>' character.
# Look for a line beginning with <code>foo=</code> in the local notes. If one is found, the alias is replaced with what follows the '<code>=</code>' character.
# If a strip is part of the current selection, search likewise in its comment field and substitute if the search succeeds.
# Substitution is unsuccessful. ATC-pie will open an edit box so that you can review your message before sending it.

Moreover, ATC-pie strips everything up to the first '''pipe character''' (<code>|</code>) in the message if any, before it is processed and sent. You may test this by sending "stripped part|sent part" and observe that only the "sent part" makes it to the message contents. You can therefore make your life easier with piped shortcuts in your preset message list. They will pop up like any other message in the filtered menu as you type. For example, the following preset message enables something like a dot-command for sending a bearing to your base airport in a few key strokes:
: <code>.qdm|Heading to airport $qdm</code>

Lastly, if a troll or angry user is polluting your session with undesired messages, add their callsign to the '''senders blacklist'''. All messages from the user will then be filtered out from the message pane. You can view and clear this list at any time.

== ATC coordination ==

"ATC coordination" refers to the following:
* strip exchange, i.e. sending and receiving strips (handovers);
* ATC phone lines, for private voice calls (only in FlightGear and FSD sessions);
* CPDLC authority transfers (not available in FSD sessions);
* ''who-has'' requests, to query ATCs about who is claiming control of callsigns;
* ATC text chat, to exchange text messages between ATCs (not available in solo sessions).

=== Strip exchange ===
[[File:ATC-pie-screenshot-receivedStrip.png|thumbnail|Example of a strip received from "GND"]]
To hand a strip over, drag it and drop it on the recipient in the list of controllers in the ''ATC coordination'' dock. A received strip appears with an identification of the sender which disappears as soon as the strip is clicked on.

A received strip lands on the collecting rack set for the sender if any (double-click on a rack name to add an ATC callsign from which to collect strips), or on the "Default" rack otherwise. It may link automatically to an identified radar contact according to the selected auto-link options (general settings).

See [https://www.youtube.com/watch?v=oQIud-cAlT4 tutorial video 6] for a presentation of the feature.

=== ATC phone lines ===
Phone lines allow to call and talk to other ATCs directly from the ''ATC coordination'' dock. Each line has an outgoing state that you control, toggling between open and closed with a double-click on its phone icon. Opening a line places a call to the connected ATC, showing as "incoming" on their side. When two parties have their line open to one another, they are in direct communication (no PTT). In other words, opening an incoming call puts you on the phone with the caller. Closing a call hangs up the active line, but you can pick it back up as long as the other party holds it open ("still incoming" for you).

You can only talk to one ATC at a time but may place multiple outgoing calls. If a call you placed is answered while you are in another call, the answered call switches to show as incoming without interrupting the one in progress. Conversely, opening (answering) an incoming call while already in another call drops the current line. If an incoming call you answer turns to "placed" (outgoing only) instead of "in progress", the other party was already on the phone and is now seeing an incoming call from you.

=== ATC text chat ===
The ATC text messaging system allows to chat with other ATCs in channels that are separate from the "radio text chat" read by pilots. It offers '''private channels''' for one-to-one conversations, and a '''general ATC chat room''' in network sessions, readable by all connected ATCs.

'''Note on interoperability in FG sessions''': While only ATC-pie integrates ATC text chat in its interface, other users can join the same channel with a regular IRC client. They will be able to send and receive public and private messages and chat with everybody, at the only cost of ignoring the system messages that will sometimes appear on their side. For best results, they should use their FlightGear network callsign as their IRC nickname.

== Solo sessions ==

In solo sessions, you control virtual IFR planes, receiving and handing over strips to virtual ATCs depending on your position and the aircraft's intentions. You can train as an en-route controller in CTR mode, or as an airport controller in AD mode, where four combinable positions are available:
* ground (GND), to taxi aircraft between parking positions and runways;
* tower (TWR), to control runways and immediate surroundings;
* departure (DEP), to bring departing traffic to their exit point;
* approach (APP), to vector arrivals onto final.

=== Objectives ===
In '''CTR mode''', your task is to transit the aircraft across your airspace, always ensuring separation, and to hand each of them over to the most appropriate neighbouring centre North, South, East or West of your sector. You can specify local navpoints in the location settings so that the system includes them as turning points in the randomised aircraft routes.

In '''airport mode''', traffic is either inbound or outbound. Assuming APP, inbound aircraft must be sequenced and vectored into tower range for handover, unless you are in the TWR position as well. Each inbound aircraft either requests ILS or visual. Assuming TWR, you must clear them to land when appropriate, i.e. cleared for ILS approach or expected runway reported in sight. If landing cannot take place (too high, not cleared...), aircraft will go around. Controlling GND, you must move inbound traffic near their parking position once they have vacated the runway, and hand them over to the ramp. Outbound traffic must be brought to hold short of a runway threshold and report ready for departure with TWR. If you assume DEP, you must hand outbound aircraft over to the en-route centre (CTR) once they are high enough and close to their exit point if specified in their route. Entry and exit points are configurable in <code>CONFIG/nav/AD-entry-exit</code> (see <code>Notice</code> in the directory).

[[File:ATC-pie-screenshot-handoverPane-solo.png|thumbnail|Handover pane in an AD solo session, assuming all three available positions]]
{| class="wikitable" style="text-align:center"
|+ Handovers with virtual ATCs in airport mode
|-
| || colspan="2" | Departure strips || colspan="2" | Arrival strips
|-
! Assuming positions || Receive from || Hand over to || Receive from || Hand over to
|-
! GND only
| DEL || TWR || TWR || Ramp
|-
! TWR only
| GND || DEP || APP || GND
|-
! DEP only
| TWR || CTR || colspan="2" | N/A
|-
! APP only
| colspan="2" | N/A || CTR || TWR
|-
! TWR+GND
| DEL || DEP || APP || Ramp
|-
! TWR+DEP
| GND || CTR || APP || GND
|-
! TWR+APP
| GND || DEP || CTR || GND
|-
! APP+DEP
| TWR || CTR || CTR || TWR
|-
! TWR+GND+DEP
| DEL || CTR || APP || Ramp
|-
! TWR+GND+APP
| DEL || DEP || APP || Ramp
|-
! TWR+APP+DEP
| GND || CTR || CTR || GND
|-
! All 4
| DEL || CTR || CTR || Ramp
|}

=== Instructing aircraft ===
[[File:ATC-pie-screenshot-taxiInstructionTool.png|thumbnail|Click&drag taxi instruction tool at OMDB ground]]
Instructions are given through different means:
* provided the speech recognition modules are installed, you can turn on voice instructions from the solo simulation settings dialog and instruct aircraft through your microphone, using the <code>Ctrl</code> key as push-to-talk and standard phraseology (see the quick reference tab about it);
* if voice instructions are turned off:
** mouse vector assignments issue the corresponding instructions (see section on vectors above);
** handoffs are issued when dropping strips on an ATC receiver;
* instruct taxi routes by dragging out of radar contacts when they are considered on the ground (low enough or squawking GND);
* the dockable instruction panel works regardless of voice vs. mouse selection;
* alternatively, if the aircraft is connected to CPDLC, you can send instructions through the [[#CPDLC|data link]].

Instructions from the panel are always issued to the callsign entered in the top field, which should fill automatically on aircraft or strip selection when a callsign is known. Therefore, make sure you do not mess up your strip links or your instructions will realistically be acknowledged and followed by the wrong aircraft.

=== Need a scenario? ===
Things you can train for:
* towering a single runway with mixed traffic: select TWR position and an equal balance of departures and arrivals;
* optimising approach spacing in dense traffic: select APP position only, increase traffic density, turn on spacing hints and try to stabilise them all at "3:00" for example;
* change of runways (e.g. irl after wind direction change): start with APP+TWR and select a runway for arrivals at least, run the simulation for a while and change for opposite runway use;
* CTR mode with a low ceiling to increase the number of conflicts to resolve;
* etc.

== Teacher & student connections (ATC tutoring) ==

This session type is made to bring an ATC student and a teacher together for tutorial sessions. To '''set up a session''', the student must connect to the teacher, so make sure the teacher's session is running first. Only one student can connect to a teacher at a time. The teacher creates and manipulates traffic for the student to work with, controls the weather and decides on the ATC neighbours. Strip exchange and ATC text chat is possible, either between both parties ("offline" exchanges) or between the student and the virtual ATCs (in-sim coordination). All exchanges are monitored by the teacher, and transparent to the student. The teacher can also snapshot traffic position situations to recall them later.

In '''teacher sessions''':
* The teaching console is enabled, which allows you to control most aspects of the environment visible to the student.
* You create new traffic holding <code>Shift</code> down with a right click-and-drag on the radar specifying the position and face heading. A dialog pops up and allows you to choose a callsign (one is initially generated), altitude and other details. If near a ground route node, a parking position or runway, you can create it on the ground, ready to taxi or for departure (NB: parking overrides position/heading input).
* Traffic is initially created in an "unspawned" state (radar contact marked "+"), in other words visible to you but not to the student. This allows you to set its transponder or get it into a certain state before spawning it into the student's world.
* Controlling the traffic is done in the same way as in solo sessions without voice, i.e. using the click&drag vector and taxi tools and the instruction dock. The only difference is that you control the selected aircraft directly, regardless of your strip links and details. You therefore do not need a strip and a correctly filled callsign to instruct a pilot, though it is a good idea to have one if you want your vectors registered and drawn on the radar. The traffic creation dialog offers to create a linked strip with every new aircraft.
* You may pause the whole simulation, or freeze each aircraft individually. Frozen aircraft will result in stationary flights on the student's radar.
* The ATC text chat system allows to chat to the student directly as the teacher, and to simulate private ATC conversations with the student (select callsign to interact as).
* To exchange strips, drop them on "Student" and select whom the strip should appear from on the student's side. Note that for your convenience in further control of the traffic, teacher strips do not disappear on handovers;
* CPDLC is supported, the dialogue windows reflecting the change of perspective (ACFT instead of ATC) and the <code>Alt</code> key combinations generating requests rather than instructions.

[[Category:ATC-pie]]

ATC-pie FAQ

2021-05-02T09:09:41Z

Mickybadia: Added entry on APP centre line markings

{{forum|83|ATC-Pie support & development}}

This page is a collection of questions asked at least twice about [[ATC-pie]]. It is a good idea to search through it before repeating a question on the forum or anywhere.

== Things "not working" ==

=== Why am I not seeing this aircraft on my radar? ===
Connected to FGMS: '''I know it is there: the pilot is sending chat messages and/or is visible on the online live map...'''

You only see an aircraft on your scopes if a radar contact is established, i.e. if it is visible to the primary radar or if the secondary radar (SSR) picks up a transponder signal from it.

The following cases will therefore prevent you from seeing a connected aircraft:
* The radars are turned off. Turn on at least a primary radar from the ''Options'' menu, or an SSR capability from the ''Radar'' tab in the ''Local settings'' dialog (any setting other than "none" will pick up contacts).
* The aircraft is out of radar range. It can be under the radar floor (minimum signal pick-up alt.) or too far out. In the radar settings, check the floor ("SFC" will pick up all signals down to the ground) and horizontal range. Primary and secondary radars share the same range.
* Its onboard transponder is turned off (and primary is off); see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Otherwise if you accept cheating, you can activate the "radar cheat mode" which will simulate a mode S transponder for all aircraft in horizontal range; see [https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3].

=== Connected pilots do not receive my text messages. ===
This happens with pre-2017.2 clients if you are using the latest protocol to encode properties. Tick the FGMS system option to "use the legacy protocol" for property encoding. Everybody should be able to read you, but it will come at the expense of network throughput. Tell those pilots to upgrade their client.

=== FGCom is not working. ===
First, verify that the FGCom variant selected in the ''system settings'' is the one you want to use. Check that your sound is on, your volume loud and your microphone working (system sound monitor picking up a signal). Close all open sessions and open a single ATC-pie instance.

If you have chosen the '''stand-alone''' FGCom variant, take the steps below in order:
# Echo test
#: Start an ''FGCom configuration test'' from the ''System'' menu. While the test is running, speak in the microphone and check if you can hear yourself back. If so, you may skip directly to step 4.
# Path to executable
#: Verify the FGCom command entered in the system settings. It should contain an executable system command or a relative or absolute path to an FGCom executable file. If you have FlightGear installed on your machine, you can point to the FGCom executable already available with it. On Linux, the default "fgcom" command usually does the job. Otherwise, [https://sourceforge.net/projects/atc-pie/files/fgcom-standalone/ download an FGCom stand-alone program] from ATC-pie's SourceForge file list. In any case, try the entry from a terminal in the ATC-pie directory to manually check that it runs correctly.
# FGCom server status
#: The server may temporarily be down, unfortunately even for up to a few days. Check for responses from the server, e.g. with <code>ping fgcom.flightgear.org</code> (adjusting the server name to match the one entered in the settings). FGCom will not work without a responding server.
# FGCom subprocess error
#: After turning your radio on, check for errors in the logged FGCom output files in the <code>OUTPUT</code> directory.
# Port mess-up in your session?
#: When creating a new radio box at run time, make sure you choose an available port number for each. Caution when running multiple ATC-pie instances: do not use a port more than once across the system at the same time.

If you have chosen the '''FGCom-Mumble plug-in''':
# Plug-in status
#: Check that your Mumble client is connected and properly running the FGCom plug-in.
# Port setting
#: Check that the control port in ATC-pie is set to the one FGCom-Mumble is listening on.
# Echo test
#: Start an ''FGCom configuration test'' from the ''System'' menu.

Note that the two variants are ''not'' interoperable. Users will only be able to hear and interact with others using the same variant (and server) as their own.

=== Recording ATIS with stand-alone FGCom: no beep is heard after pressing "record". ===
Assuming FGCom standalone is working (confirm this with an echo test before reading on)...

Due to the design of this legacy FGCom variant, you may only record an ATIS if the requested frequency is enlisted as recordable on the distant server's "phone book" for the airport. The one for <code>fgcom.flightgear.org</code> was compiled a while ago, based on the latest <code>apt.dat</code> at the time. It filtered the frequencies through the two following conditions:
# it is of the "recorded" type (row code 50);
# its name contains the uppercase string "ATIS".

If you are relying on the old data provided by ATC-pie, in other words you have not downloaded new data or edited the frequencies yourself, check against the <code>.dat</code> file extracted in the <code>OUTPUT</code> directory on your side, as it should still be similar to the one on the server's side. One of the two conditions is probably not met, or the frequency missing. NB: The frequencies in the ATIS drop-down list of ATC-pie are matched against the condition (1), but not against the somewhat restrictive condition (2).

In any case, consider switching to the newer FGCom-Mumble plug-in variant. It simulates radio waves, frequencies and ranges, which avoids the phone book problem all together.

=== Tower view is not starting. ===
Ruling out that FlightGear is not installed at all, your system path settings are probably wrong. From a terminal or a file system navigator, find the right command to start FlightGear and enter it as ''FlightGear executable'' from the system settings. Do not add options of any kind; they will be taken care of internally. You may have to enter a ''FlightGear root directory'' as well, especially if you have the program files installed somewhere unexpected.

=== My tower is in the middle of the sea, and aircraft floating/landing on water! ===
You are missing the FlightGear scenery data for your location, or ATC-pie does not know where it is. If you have downloaded scenery and saved it somewhere, have you tried filling the scenery directory with that location in the system settings? Also check out the ''Tower viewing'' [[ATC-pie_user_guide#Tower_view_window|feature note]] in the user guide.

=== Simulated aircraft appear to dip underground or levitate over taxiways. ===
Do you have a ground elevation map for the location? Quoting from <code>CONFIG/elev/Notice</code>: "''When no elevation map is found for an airport, the field elevation value is used everywhere on the ground. This should be OK for a rough approximation on flat terrain, but ground traffic will not follow any slopes, thus may appear as floating above the ground, or dipping into it.''"

Read the full notice for instructions on how to build your elevation map. Once you have one or decide that your field is flat enough, the next focus is on the FlightGear aircraft models. Each model has its own coordinate system chosen at developer's discretion. ATC-pie must be given the height difference between each model's origin and the aircraft touch-down point (gear wheels) to position aircraft more accurately. You can do this on a per-model basis with ":height" specifications in <code>CONFIG/acft/icao2fgfs</code>. Read the associated <code>Notice</code> file for more information.

A last possible altitude adjustment is available from the location options: "Altitude adjustment for FlightGear views". It applies the given offset to all traffic rendered by the views.

=== I cannot connect to my teacher as a student. ===
Using IPv4 addresses, this typically happens when the teacher is in a local area network behind a router. It is a common setup for home internet, in which the teacher's actual host address is not publicly accessible from outside his private network.

If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either:
* for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local host address;
* or to create a virtual network, using a third-party VPN service.

== What is ...? Why is ...? What value/setting for ...? ==

=== What "social name" should I use for FlightGear/FSD sessions? ===
Choose any name you would like to be recognised by on the network. In ATC-pie, it will appear in the tool tip over your callsign for connected ATCs who see you. This feature is only social in the sense that it does not refer to an account or to anything technical, but it makes sense as typical ATC callsigns (e.g. "VHHHtwr") remain mostly anonymous. Use this field to identify yourself on the network.

=== Are the vector headings true or magnetic? ===
Heading displays in ATC-pie are mostly magnetic so they can be read out to pilots. The exceptions are the navigator and handover list tool tips, which show true radial headings from the radar position, and the teacher's wind section to match the generated ATIS string.

Also note: all directions are geodesic, i.e. initial headings to take on a great circle.

=== What is the purpose of the flat "strip shelf" button in the strip panes? ===
More than a button, the strip shelf is where you should drop the contacts you release without a handover, e.g. parked traffic shutting down, VFR traffic flying out of your airspace, etc. Clicking on the shelf allows to browse the previously shelved strips, and to recall them, for example if shelved inadvertently.

=== What do the various markings along the approach centre line mean? ===
The regularly spaced groups along a centre line represent altitudes on the approach plane. Each group sums up to an AMSL value in accordance with the set flight path angle (also see ''Display conventions'' in the quick reference):
* straight line = 1,000 ft;
* solid diamond = 5,000 ft.

The other markers drawn with thicker lines are the positions of the ILS marker beacons (OM, MM, IM), the line pattern representing the sound triggered by the beacon in the pilot's headset. They are sourced on program start-up from the navigation data (<code>CONFIG/nav/navaid.dat</code>).

=== Why do I keep getting runway incursion alarms? ===
Because you have the runway occupation monitor turned on (''Options'' menu), while not using your runway boxes. The alarm triggers when the radar detects traffic stepping on a runway in either of the following situations:
* the runway is active (marked in use) and no strip is boxed for it;
* it is reserved but there is already traffic on the runway;
* it is reserved for a different aircraft: the boxed strip is linked to a contact that is not the entering aircraft, or the aircraft is linked to a strip different to the one boxed.

Turning the runway occupation monitor off will deactivate all radar warnings regarding runways. If you are interested in the strip boxing and visual runway highlighting system but bothered by the alarm sound, you can mute the sound notification by unticking it in the general settings.

== Where is ...? How to ...? ==

=== Can I draw SID and STAR procedures on the radar? ===
Yes, and virtually anything else, using background images. To learn about those:
* see the corresponding [[ATC-pie_user_guide#Background images|user guide section]];
* read the <code>CONFIG/bg-img/Notice</code> file;
* examine the (otherwise useless) packaged KSFO example.

'''If you have a sector file''' of the ".sct" format used in VATSIM/IVAO, you should try to import it with the provided drawing extraction tool. It will extract most of the contents for the open location and current map range, including SID/STAR procedures, and translate them to ATC-pie's native drawing format. It is generally the best solution if you know your procedures are included.
# Run the "extract drawings from sector file" option (''System'' menu) and select the file to extract from. This generates the following files in the <code>OUTPUT</code> directory:
#* <code>ICAO.lst.extract</code>, a menu file for the generated drawings;
#* <code>bg-ICAO-*</code>, the extracted drawings in the native ATC-pie format;
#* <code>bg-extract.err</code>, a log of the errors detected in your sector file (do not be alarmed as they often contain many).
# Import the results:
#* move or copy-paste lines from <code>ICAO.lst.extract</code> to <code>CONFIG/bg-img/ICAO.lst</code>;
#* move the desired drawing files under <code>CONFIG/bg-img</code>, adjusting the paths in the <code>.lst</code> menu as you organise subdirectories.
# Post-editing (cleaning)
#: ATC-pie does its best to understand the objects in the sector file and to group things together depending on their type. But not everything can be guessed automatically. This last step is where you filter, merge and split objects, rename points, change colours, etc. to your liking.
#: Each generated drawing section (point list under a colour) is automatically labelled with the line number where it was sourced from in the sector file so you can easily trace it (<code>@nnn</code>). A tool like ''sed'' will help you get rid of all these unwanted suffixes once you have sorted and renamed your objects:
#:: <code>sed -ri 's/ +@[0-9]+$//' file_to_clean</code>

Tip: You can check your image configuration without restarting the program, by reloading from the ''System'' menu or pressing <code>Alt+F12</code>.

NB: ATC-pie does not package or source from sector files directly because their data is not free. Besides, a lot of it is usually redundant with the airport sources (GPL).

=== How do I assign SIDs and STARs to aircraft? ===
This question is asked quite a lot more than it is relevant to a real controller's task...

What people seem to be after when asking this question is a way to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. The way to handle this is to stack your inbound strips on racks named after your STARs. Racks are indeed above all meant for efficient traffic sequencing. Every rack represents its own sequence of ordered aircraft, which is perfectly suited to control separate approach paths in parallel. With this technique, placing a strip on a STAR-named rack basically serves as the "assignment" itself. Similarly, runway-specific racks can keep track of separate landing sequences at large airports. Then you can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times in the sequence all the way to touchdown.

If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. Routes are lists of waypoints and instructions to follow between the two end airfields. Normally pulled straight from properly filed flight plans, routes are printed on strips prior to departure, then modified as the flights progress and passed along with handovers. Standard departure and arrival procedures (SIDs and STARs) can be referred to in those routes, but only by their entry or exit navpoints. They should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. For example, routes ending with a STAR should end with "FUBAR STAR", which means that waypoint FUBAR is an entry point from which a published STAR must be followed. The keyword "STAR" is in fact a mere specification for the last route leg. Similarly, routes of the form "SID DUMMY ..." specify their first leg as a standard departure to the first waypoint DUMMY. "SID" and "STAR" keywords are recognised by ATC-pie and accounted for in the second line of the radar tag when appropriate (see feature note on routes).

One meaningful wish regarding this question is for easy '''reference in text chat''' messages. Firstly, using racks in the way suggested above, you can use the <code>$rack</code> alias which is substituted by the name of the rack on which the current strip selection is stacked. Otherwise, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". Now if you specifically want to assign a full procedure name like FUBAR1A to a contact and refer to it in a generic text chat message, include a line "sid=FUBAR1A" 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 expanded in your sent messages when that strip is selected.

=== How to set the transition level? ===
You do not. You can however set the transition altitude in the location settings if your airport specification file does not already include one.

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, e.g. for more vertical separation on either side of the transition layer or due to coordination with neighbouring zones and fields.

=== Can I look up ILS frequencies? ===
Yes, in the ''environment info'' dialog.

Besides, you can create aliases with the local notepad for a quick and integrated way of sending them through text chat, which will be saved when you close ATC-pie. For example, use the following format, one runway per line: <code>ils05=111.11 MHz</code>. See [[ATC-pie_user_guide#Public text chat|custom text aliases]] for more.

=== The navigation/airport data is outdated. How can I update it? ===

For '''airport data''' (taxiways, parking positions, frequencies, etc.), the included source is the last world-wide <code>apt.dat</code> compiled before it became too large to maintain as one huge file. We keep it there because it allows to run ATC-pie anywhere in the world without requiring external data, but its contents grows out of date with time. You should check for more recent sources on the [http://gateway.x-plane.com/airports/page X-plane airport gateway], directly accessible from the ''System'' menu, on a per-airport basis. Extract the <code>apt.dat</code> file from the download, rename it after the airport's ICAO code (keeping the extension, e.g. <code>KJFK.dat</code>), and place it in <code>CONFIG/ad</code> (also see the <code>Notice</code> there). Alternatively, for a quick manual touch-up of the included data, you can move and edit extracted files (see <code>OUTPUT/Notice</code>).

For '''navigation data''' (navaids, fixes, airways, etc.), the included data is the latest version of each file that was seen released as GPL, which makes some of it date back to 2013! You should provide more recent navigation data, as explained in <code>CONFIG/nav/Notice</code>.

=== How do I customise the GUI and colours? ===
To change the '''radar or strip drawing colours''', edit the <code>CONFIG/colours.ini</code> file. Each line specifies the paint colour for an object type, in a typical hex <code>RRGGBB</code> (red-green-blue) format or as an SVG colour keyword name like "white". To customise the '''main session window''', place a ''Qt stylesheet'' named <code>main-stylesheet.qss</code> in the <code>CONFIG</code> directory. ATC-pie will apply it to every session window. While you are working on your look and feel, use the reload feature from the "System" menu to avoid restarting after every change (<code>Shift+Alt+F12</code>).

Send us screenshots and share your files if you find a setup looking really cool! :-)

== Miscellaneous ==

=== What's with the funny name? ===
ATC-pie is written in Python, and I reckoned that the ''pyXXX'' naming habit was becoming a little dull, so I merely switched things around. You can surely do the rest of the math in terms of spelling, and later impact on the logo.

=== Why is the learning curve so steep? People would use your program more if you did/provided [...] ===
Often continued with: '''(you must understand that) this is not VATSIM!'''

We do have a [https://sourceforge.net/p/atc-pie/wiki/Wishlist wish list] and will consider any feature or help request. However, though it has a few cheats, ATC-pie has always choosen realism as a criterion for implementation and design, over the mere incentive of converting otherwise happy users of other programs. It is a good thing that different philosophies and work flows are available out there, and there would be much less interest in having them all copy each other, fighting over users instead of understanding that not all of them wish for the same experience. If serious simulation or learning new skills sound like threats to fun for you, you have a perfectly valid reason not to opt for ATC-pie.

[[Category:ATC-pie]]

ATC-pie

2021-05-02T08:20:23Z

Mickybadia: v1.8.2

{{forum|83|ATC-Pie support & development}}

{{about|the software in general|a manual on how to use it|ATC-pie user guide}}

{{Infobox Software
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.8.2 (May 2, 2021)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''ATC-pie''' is an [[air traffic control]] simulation program featuring:
* solo sessions, incl. voice instruction recognition and pilot speech synthesis;
* network sessions through [[FGMS]] and FSD;
* tutorial sessions for teacher supervision of an ATC student.

It can simulate en-route centre control (CTR) as well as airport-based services (TWR, APP, GND...), and allows 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 [[ATC-pie installation guide|installation]] and [[ATC-pie user guide|user]] guides. If you have a question, check the [[ATC-pie FAQ|FAQ]] first, or try the forum for help.

== Screenshots ==

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Playing solo with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

== 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 ===
[[File:ATC-pie-screenshot-stripDetailSheet.png|thumbnail|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 [http://en.wikipedia.org/wiki/Secondary_surveillance_radar 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 ===
[[File:ATC-pie-screenshot-radarIdentification.png|thumbnail|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 airfiled)
* 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 [[:File:ATC-pie-screenshot-ATISdialog.png|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 land 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:
* Strip exchange: full handover support with ATC-pie, compatible with [[OpenRadar]]
* Voice radio: [[FGCom]] integration (using stand-alone processes or through Mumble plug-in)
* Weather: real world METAR retrieval
* Flight plans: interface with [http://flightgear-atc.alwaysdata.net Lenny64's data base] (the ''de facto'' FG standard), incl. filing, editing, opening and closing
* ATIS: voice recording through FGCom
* In-app announcement of ATC sessions on Lenny64's event page

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 [[: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

Data sources:
* Airport and navigation data sourced in the [http://data.x-plane.com 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)
* Real world magnetic declination lookup

[[Category:ATC-pie]]
[[Category:ATC clients]]
[[Category:Air Traffic Control]]

File:ATC-pie-screenshot-towerViewing.png

2021-03-11T08:24:31Z

Mickybadia:

=={{int:filedesc}}==
{{Information
|description={{en|1=Tower viewing in [[ATC-pie]], following a departing aircraft at [[LSZH]]}}
|date=2015-08-16 17:25:26
|source={{own}}
|author=[[User:Mickybadia|Mickybadia]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:ATC-pie screenshots]]

Controller-pilot data link communication

2021-02-23T17:16:03Z

Mickybadia: Added technical section for ACFT dev's to format their message lines

{{WIP}}

'''Controller-pilot data link communication''' (CPDLC) is a direct connection between ATC and aircraft through which pilots and controllers can communicate based on text, thereby relieving radio traffic.
Its use is increasing everywhere in real life, and an extension to FlightGear is currently under development to support it in the multi-player environment.

== Status in FlightGear multi-player ==
[[File:CPDLC-generic-dialog.png|thumb|Screenshot of the generic CPDLC dialog add-on]]
[[File:A320-CPDLC.png|thumb|Displays the A320 CPDLC cockpit instrumentation]]
Recent efforts have already taken place towards implementing it in MP:
* the [[Virtual FSWeekend Hackathon 2020]] attracted a team to work on the [[Hackathon Proposal: CPDLC|CPDLC proposal]];
* CPDLC extension was merged to 'next' in January 2021;
* a generic CPDLC dialog add-on is available (see screenshot); Nasal helpers in this addon should be moved to FGDATA once stable (needs feedback from aircraft developers)
* work is currently in progress on at least one cockpit CPDLC panel;
* ATC client [[ATC-pie]] is fully operational, ready to service its first logons to come.

== Technical section: protocol message line format ==
From a FlightGear model point of view, four fgCommands are available:
* <code>cpdlc-connect</code> with an ATC callsign argument;
* <code>cpdlc-send</code> with a formatted text line argument representing the CPDLC message to send, see ''cpdlc_message'' below;
* <code>cpdlc-next-message</code>, to collect the next queued message, also formatted as per ''cpdlc_message'' below;
* <code>cpdlc-disconnect</code>.

A message is known to be queued and ready for a <code>cpdlc-next-message</code> call when property <code>/network/cpdlc/rx/new-message</code> is true.
Dequeued messages are collected in <code>/network/cpdlc/rx/message</code>.
At any connected moment, the current "data authority" (ATC currently connected to the data link) is available in <code>/network/cpdlc/link/data-authority</code>.

Below is the format for the exchanged messages, in an EBNF style mixed with regular expressions.

cpdlc_message ::= // second format useful if '|' present inside an element
| <msg_element> ('|' <msg_element>)* // no spaces around separator
| <custom_separator:SEP> ' ' <msg_element> (' ' <SEP> ' ' <msg_element>)*

custom_separator ::= [^0-9A-Za-z ]+

msg_element ::= <msg_element_identifier> (' ' <msg_element_parameter>)*

msg_element_identifier ::= [A-Z]{3}[DU]-[0-9]+ // as specified in ICAO doc 4444

msg_element_parameter ::=
| [0-9]{3} // heading and speed parameters
| (FL)?[0-9]+ // altitude/FL
| RIGHT|LEFT // direction (e.g. in turn instr's)
| ...
| .* // free texts (route, "due to" reason, etc.)

ATC-pie user guide

2021-02-12T17:31:56Z

Mickybadia: v1.8.1

{{forum|83|ATC-Pie support & development}}

This article is a guide to the air traffic control simulation program [[ATC-pie]], describing some of its major features. A more exhaustive list can be found in the main article. For download and installation help, refer to the [[ATC-pie installation guide]].

Anyone motivated to write a full user guide is obviously welcome to contact the developer, or improve this article. For support and troubleshooting, the [[ATC-pie FAQ]] might get you an answer first. Otherwise kindly ask on the FlightGear forum, where we have a dedicated sub-forum, so the discussion is public and its contents shared.

Other sources to learn the program are:
* the [https://www.youtube.com/playlist?list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb online] '''video tutorial''';
* the in-app '''quick reference''' available from the ''Help'' menu (summary of mouse/keyboard gestures, display conventions...);
* a skilled '''teacher''' to connect to as a student (personal training);
* to '''play solo'''!

== Flight strips ==

Whether dematerialised or on physical paper, printed out or filled by hand, the '''flight progress strip''' is the essential piece of air and ground traffic control. Every aircraft in contact is represented by a unique strip, and every strip represents a contact. This helps to ensure that no aircraft is ever forgotten about. Strip positioning and updating then enable to monitor the aircraft's status, sequence number, position, intentions, etc.

=== Filling details and linking ===
A click on the "new strip" tool bar button (shortcut <code>F2</code>) or double-click on an empty strip rack or bay space will open a dialog to fill flight details on a fresh blank strip, e.g. destination, type of aircraft, etc. Double-clicking on an existing strip allows to edit the filled details.

If providing radar service, strips should be '''linked''' to identified contacts to inform the radar display with the filled details and enable joint selection. To link a strip to a radar contact, select one and middle-click on the other. Conflicts between the strip details and the values squawked by the linked transponder contact are reported: the strip displays a "!!XPDR" warning and the strip dialog labels the conflicting details.

A strip can also be linked to a filed flight plan (FPL). This will make radar and strip display fall back on filed information for missing details. The strip dialog also shows the mismatching information between the two, though this is rather common because the strip typically gets updated as the flight progresses.

All together, a selection can involve up to three linked elements: strip, radar contact, flight plan. You can pull details from linked elements to strips (strip panel bottom menu), and push strip details to their linked flight plan if necessary (strip dialog bottom tick box). Unlinking is possible with SHIFT+middle-click. If you use linking carefully, auto-fill options are available from the general settings, to fill blank strip details with newly-linked information.

For fast and efficient service, every initial contact by a pilot should basically make you hit <code>F2</code> and type the callsign announced. You should then soon figure out if:
* a flight plan is already filed: a matching FPL count is displayed near the callsign field as you type, if any (click on the button to view them);
* a flight plan must be filed (e.g. IFR departure not filed by lazy pilot): select "new FPL" from the bottom line to open a fresh FPL detail sheet to link to the strip;
* he was asked to contact you by a previous ATC, in which case you may have a strip handed over to you already;
* etc.

=== Strip placeholders ===
ATC-pie provides with three types of placeholders for flight strips: ''racks'', ''loose strip bays'' and ''runway boxes''. According to your ATC position and local facilities, you should choose and arrange your placeholders for optimal control. Strips can then be moved between them using mouse drag and drop.

[[File:ATC-pie-screenshot-stripRacks.png|thumbnail|Strip rack panel]]
A '''strip rack''' is the preferred way of keeping track of a sequence, e.g. a departure queue at a runway threshold. Rack panels can be created from the main window workspace, popped out as separate windows, and a persistent one can be found among the available docks. You can create as many racks as you wish in every panel. Double click on a rack's name to rename it or edit its properties. Use mouse drag to move strips up and down a rack sequence.

A '''loose strip bay''' allows free-hand positioning of strips in its reserved space. Such bays are useful for unsequenced traffic, or to map out relative positions when controlling without a radar. You may also import background images, e.g. a ground chart to keep visual track of taxiing aircraft and vehicles. See <code>CONFIG/bg-img/Notice</code> to learn how.

[[File:ATC-pie-screenshot-runwayReserved.png|thumbnail|Reserved runway marked in yellow]]
A '''runway box''' is a placeholder for a single strip, named after a physical runway and denoting a clearence to use it (enter, cross, land...). Runway boxes are contained in their own dock, with one made visible for each runway marked as in use in either direction. Thorough use of runway boxes will help you avoid bad mistakes like clear an aircraft to land over lined up traffic. When freed, runway boxes start and display a timer together with the wake turbulance category of the last contained strip to help with TKOF/LDG separation. What is more, if you use radar, a filled runway box marks the runway as ''reserved'' on the scope.

Besides, there are two other places a strip can be dropped on, usually when releasing a contact:
* an ATC callsign in the ATC panel to initiate a handover;
* a '''strip shelf''' (flat button at the bottom of loose and racked strip panels), which clears the strip from your workbench and stores it as shelved.

== Airport scene rendering ==

=== Tower view window ===
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
This feature allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any (X-plane seems only to allow for one, but feel free to declare more for ATC-pie), otherwise defaults to somewhere over the airport to allow towering everywhere. It is disabled in CTR mode.
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 to listen for traffic and accept telnet connections.

'''Running internally''' only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the ''System'' settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].

Connecting to an '''external viewer''' allows to run FlightGear on a different machine and thereby relieve your session from the CPU load a local instance induces. If you want to do so, get a hint of the required positioning options you should start your viewer with, from the tower view tab in the system settings dialog. Of course, scenery, models and liveries must also be available to the running process.

In either case, once activated from the ''View'' menu, the tower view '''control pane''' is enabled, from which you can turn to runway points, follow selected aircraft... Direct FlightGear input in the view window is also possible: right click and drag allows to look around, <code>x</code>/<code>X</code> keys change the zoom level, etc.

=== Additional scene views ===
You can hook up '''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 from the ''View'' menu. Additional viewers are registered by their host+port address, from the ''View'' menu at run-time or from a custom settings file (see <code>CONFIG/Notice</code>) read at start-up and on explicit reload (''System'' menu).

Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
* ''HHH'' is the host on which ATC-pie is running;
* ''PPP'' is the default 5009, or the chosen port number if ATC-pie was started with <code>--views-send-from</code>;
* ''TTT'' is the network polling frequency (100 is common practice; change as desired if you know what you are doing).

== Vectors, routes and separation warnings ==

ATC-pie can register and analyse issued vectors and routes to:
* inform strip and radar display;
* help monitor traffic, checking tracked positions against route/vector assignments;
* help manage traffic, anticipating route and FL conflicts between controlled aircraft.

=== Vectors ===
[[File:ATC-pie-screenshot-courseAndAssignmentsGraphics.png|thumbnail|Course/vector drawing for linked radar contact]]
Registering vectors on strips enhances the drawing of linked radar contacts, enables easy monitoring of tracks and detection of aircraft flying off course. To register vectors automatically when a radar contact is linked to a strip, use the following mouse gestures:
* click and drag out of a radar contact to issue a heading vector;
* holding <code>SHIFT</code>, click and drag vertically for altitude/FL vectors;
* holding <code>SHIFT</code>, click and drag horizontally for speed instructions;
* holding <code>SHIFT</code>, double-click on the radar target to clear registered vecors from the linked strip.

See [https://www.youtube.com/watch?v=BvA3MRlGJjU video 5] of the tutorial for more on vectoring, and check the quick reference ''display conventions'' to interpret the lines and colours of the course and vector graphics around radar contacts.

NB: In network sessions, an appropriate text chat instruction is suggested for every mouse vectoring action. This allows you to send it easily, for example to pilots whose communications are limited to text chat.

=== Routes ===
[[File:ATC-pie-screenshot-routeDetailsView.png|thumbnail|Route details dialog with world path drawn, available when both end airfields are recognised]]
A '''route''' is analysed for every strip with recognised departure and destination airports (entry fields both turned green), 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);
* if ambiguous (navpoint names are not all unique around the world), a waypoint is always the nearest homonym to the point beginning the leg;
* other tokens are kept as route leg specifications to the following waypoint (e.g. airways between fixes).

[[File:ATC-pie-screenshot-routeDrawing.png|thumbnail|Assigned routes are drawn as dashed lines on the radar scope when linked to contacts]]
Routes on flight plans and strips are viewable in a route dialog, showing geodesic paths, headings and leg distances on a world map. When a specified route is linked to a radar contact, ATC-pie works out its current leg based on distance to destination, and:
* details of the current leg are displayed in the selection info pane, and the route viewing button enabled;
* the strip shows only the remainder of the route for this contact;
* the route to go is drawn as a dashed line on the radar (unless aircraft is inbound and near enough);
* the radar tag 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.

NB: If DEP and ARR airports are not both recognised, radar tags show the strip destination detail if it is filled, possibly with a heading if it is recognised.

See tutorial [https://www.youtube.com/watch?v=LfdukpBc90w video 7] for a demonstration of routes.

=== Conflicts and anticipation ===
[[File:ATC-pie-screenshot-routeConflictDetection.png|thumbnail|Route conflict depiction]]
ATC-pie 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 aircraft with a linked strip and an assigned route or heading. 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. When the projections of two aircraft intersect, a conflict is anticipated if the respective intervals between the current and assigned altitudes overlap. When an aircraft's altitude is unknown, the assigned altitude will be assumed. If an altitude assignment is missing, a ''possible'' conflict is reported.

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 || Thick bright red intersecting circles || Separation loss between aircraft
|-
| Path conflict || Red circles and paths || Anticipated paths and altitudes are intersecting
|-
| Possible path conflict || Yellow circles and paths || Paths intersecting but some altitudes unknown
|}

== Playing solo ==

In solo sessions, you control virtual IFR planes, receiving and handing over strips to virtual ATCs depending on your position and the aircraft's intentions. You can train as an en-route controller in CTR mode, or as an airport controller in AD mode, where four combinable positions are available:
* ground (GND), to taxi aircraft between parking positions and runways;
* tower (TWR), to control runways and immediate surroundings;
* departure (DEP), to bring departing traffic to their exit point;
* approach (APP), to vector arrivals onto final.

=== Objectives ===
When '''playing CTR''', your task is to transit the aircraft across your airspace, always ensuring separation, and to hand each of them over to the most appropriate neighbouring centre North, South, East or West of your sector. You can specify local navpoints in the location settings so that the system includes them as turning points in the randomised aircraft routes.

In '''airport mode''', traffic is either inbound or outbound. Assuming APP, inbound aircraft must be sequenced and vectored into tower range for handover, unless you are in the TWR position as well. Each inbound aircraft either requests ILS or visual. Playing TWR, you must clear them to land when appropriate, i.e. cleared for ILS approach or expected runway reported in sight. If landing cannot take place (too high, not cleared...), aircraft will go around. Controlling GND, you must move inbound traffic near their parking position once they have vacated the runway, and hand them over to the ramp. Outbound traffic must be brought to hold short of a runway threshold and report ready for departure with TWR. If you play DEP, you must hand outbound aircraft over to the en-route centre (CTR) once they are high enough and close to their exit point if specified in their route. Entry and exit points are configurable in <code>CONFIG/nav/AD-entry-exit</code> (see <code>Notice</code> in the directory).

[[File:ATC-pie-screenshot-handoverPane-solo.png|thumbnail|Handover pane when playing solo in airport mode, assuming all three available positions]]
{| class="wikitable" style="text-align:center"
|+ Handovers with virtual ATCs in airport mode
|-
| || colspan="2" | Departure strips || colspan="2" | Arrival strips
|-
! Assuming positions || Receive from || Hand over to || Receive from || Hand over to
|-
! GND only
| DEL || TWR || TWR || Ramp
|-
! TWR only
| GND || DEP || APP || GND
|-
! DEP only
| TWR || CTR || colspan="2" | N/A
|-
! APP only
| colspan="2" | N/A || CTR || TWR
|-
! TWR+GND
| DEL || DEP || APP || Ramp
|-
! TWR+DEP
| GND || CTR || APP || GND
|-
! TWR+APP
| GND || DEP || CTR || GND
|-
! APP+DEP
| TWR || CTR || CTR || TWR
|-
! TWR+GND+DEP
| DEL || CTR || APP || Ramp
|-
! TWR+GND+APP
| DEL || DEP || APP || Ramp
|-
! TWR+APP+DEP
| GND || CTR || CTR || GND
|-
! All 4
| DEL || CTR || CTR || Ramp
|}

=== Instructing aircraft ===
[[File:ATC-pie-screenshot-taxiInstructionTool.png|thumbnail|Click&drag taxi instruction tool at OMDB ground]]
Instructions are given through different means:
* provided the speech recognition modules are installed, you can turn on voice instructions from the solo simulation settings dialog and instruct aircraft through your microphone, using the <code>Ctrl</code> key as push-to-talk and standard phraseology (see the quick reference tab about it);
* if voice instructions are turned off:
** mouse vector assignments issue the corresponding instructions (see section on vectors above);
** handoffs are issued when dropping strips on an ATC receiver;
* instruct taxi routes by dragging out of radar contacts when they are considered on the ground (low enough or squawking GND);
* the dockable instruction panel works regardless of voice vs. mouse selection;
* alternatively, if the aircraft is connected to CPDLC, you can send instructions through the data link (see ''Mouse gestures'' in the quick reference, combining the <code>ALT</code> key).

Instructions from the panel are always issued to the callsign entered in the top field, which should fill automatically on aircraft or strip selection when a callsign is known. Therefore, make sure you do not mess up your strip links or your instructions will realistically be acknowledged and followed by the wrong aircraft.

=== Need a scenario? ===
Things you can train for:
* towering a single runway with mixed traffic: select TWR position and an equal balance of departures and arrivals;
* optimising approach spacing in dense traffic: select APP position only, increase traffic density, turn on spacing hints and try to stabilise them all at "3:00" for example;
* 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 change for opposite runway use;
* CTR mode with a low ceiling to increase the number of conflicts to resolve;
* etc.

== ATC coordination ==

"ATC coordination" refers to the following:
* strip exchange, i.e. sending and receiving strips (handovers);
* voice land lines (direct phone calls);
* CPDLC authority transfers;
* ''who-has'' requests, to query the system and know who is claiming contact/control of callsigns;
* ATC text chat, to exchange messages between connected ATCs.

=== Strip exchange ===
[[File:ATC-pie-screenshot-receivedStrip.png|thumbnail|Example of a strip received from "GND"]]
To hand a strip over, drag it and drop it on the recipient in the list of connected controllers (''ATC coordination'' dock). Received strips appear on their collecting rack (if defined), with an identification of the sender which disappears as soon as the strip is clicked on. They may link automatically to identified radar contacts, according to the auto-link configuration (general settings). Double-click on the rack name to add an ATC callsign from which to collect strips.

See [https://www.youtube.com/watch?v=oQIud-cAlT4 tutorial video 6] for a presentation of the feature.

=== Voice land lines ===

Land lines allow to call and talk to other ATCs directly from the ''ATC coordination'' dock. Each land line has an outgoing state that you control, toggling between open and closed with a double-click on its phone icon. Opening a line places a call to the connected ATC, showing as "incoming" on their side. Opening an incoming call puts you on the phone with the caller. In other words, if both parties have a line open, they are in direct communication (no PTT).

You can only talk to one ATC at a time but may place multiple outgoing calls. Opening (answering) an incoming call while already in another call drops the current line, which you can pick back up as long as the other party holds it open ("still incoming"). If a call you placed is answered while you are in another call, the former switches to show as incoming without interrupting the one in progress. Conversely, if an incoming call you answer turns to "placed" (outgoing only) instead of "in progress", the other party was already on the phone and is now seeing an incoming call from you.

=== ATC text chat ===
The ATC text messaging system allows to talk to other ATCs in channels that are separate from the public one read by pilots. It offers '''private channels''' simulating one-to-one landline conversations, and a '''general ATC chat room''' in network sessions, readable by all connected ATCs. Note however that ATC-pie features a direct voice (phone) land line switching system for a lot more realistic coordination between human ATCs!

'''Note on interoperability''': While only ATC-pie integrates ATC-side text chat in its interface, other users can join the same channel with an IRC client. They will be able to send and receive public and private messages and chat with everybody, at the only cost of ignoring the system messages that will sometimes appear on their side. For best results, they should use their FlightGear network callsign as their IRC nickname.

=== FlightGear sessions and compatibility with OpenRadar ===
On FlightGear session start, there are three "sub-systems" that can be activated for coordination. They differ in terms of supported features and interoperability with other clients:
* the '''IRC sub-system''' enables all coordination features with other ATC-pie clients, but does not currently operate with other software;
* the '''PyMumble land lines''' enable direct voice (telephone) lines to other connected ATCs in the ''ATC coordination'' panel (also ATC-pie only);
* the '''OpenRadar handover service''' is [[OpenRadar]]'s native system, which ATC-pie implements to enable coordination with its users, but some limitations apply (see below).
Both systems can be enabled together.

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 while respecting both approaches as much as possible, the following principles and restrictions apply to strip exchange:
* 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 properly;
* 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: 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;
* phone land lines;
* CPDLC.

Note that who-has requests are fully supported.

=== FSD sessions and compatibility with Euroscope ===
Euroscope is a popular program to control on VATSIM, a flight simulation network which is historically based on the FSD protocol, although made incompatible with it today. For a long time Euroscope allowed to connect to "plain" FSD servers, until it started being tailored more specifically for VATSIM, and closed the door to outside FSD connections. Older versions of Euroscope are still around, which ATC-pie is able to interact with, 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 land lines to Euroscope clients.

ATC-pie clients interact normally between each other for all coordination purposes listed above, but note that CPDLC is not supported by the FSD protocol (so there will be no transfers).

== Background images ==

[[File:ATC-pie-screenshot-backgroundPixmapDrawing.png|thumbnail|Pixmap image example with a topographic map shot around LIMW (Aosta, Italy)]]
[[File:ATC-pie-screenshot-backgroundHandDrawing.png|thumbnail|Hand drawing example with procedures for LSGG (Geneva, Switzerland)]]
Background images allow to decorate:
* radar scopes, with all sorts of maps and useful information about the airspace, terrain or procedures;
* loose strip bays, to move unracked strips over custom backgrounds, e.g. ground charts of the airport.

There are two ways to create backgrounds in the program. One working for all purposes is to '''import pictures''' (pixmap files like JPEG or PNG, including transparency); the other works only for radar backgrounds and consists in writing '''drawing specification''' files to paint coloured lines and labelled points. This allows to import anything from the most complex coloured height map to the the most schematic airspace outline. The <code>CONFIG/bg-img/Notice</code> file explains how to import and draw background images.

For example, you can map out procedures (SID, STAR, IAD...), grouping them by associated runways. Drawings are generally appropriate for that because they allow referring to named points as per the published procedures and avoid manual positioning. But if you want more than schematic line plots, you should create the picture yourself. Using an image processing tool like ''GIMP'', superimpose a transparent layer on top of a real map canvas, or over a screenshot of your ATC-pie radar with pinned navaids as landmarks, and freely decorate your picture.

ATC-pie comes with a couple of '''helper tools''' to create or import background images:
# If you have a VATSIM/IVAO sector file for your area (.sct), the "extract drawings from sector file" option will translate the contained diagrams into ATC-pie drawings. While the generated files always require some filtering and post-editing, it is generally the best option for things like SID/STAR diagrams.
# Located in the ''System'' menu, the "image positioning helper" allows to move and resize imported pictures, adjusting the corners visually rather than programmatically if you have no specification for them. All visible pixmap images will be moved simultaneously, so you can work with several at a time if you want to. On dialog box close, a file is generated in the <code>OUTPUT</code> directory for you to copy from.
# An [[OpenStreetMap]] option will take you to the free online map server, centred on your radar centre position. For a quick and dirty start (e.g. for access to coastlines, borders and rivers) you can screenshot the map and use it as a background.

== Communications with aircraft ==

The features described in this section apply to multi-player sessions only (excluding voice radio in FSD). In solo sessions, voice radio interaction is dealt with through speech recognition of instructions and read-back synthesis (see above).

=== Voice radio ===
'''Multiple 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 if you do not wear a headset. It will avoid picking up GUI sound notifications with your microphone while transmitting.

=== Radio text chat ===
ATC-pie has a powerful text chat system for those who use the keyboard extensively to interact with pilots in network sessions, although voice communications should be encouraged for realism whenever possible. In FlightGear sessions, all messages are visible between range. FSD simulates text frequencies; ATC-pie tunes to the "publicised frequency" in the radio panel.

First, '''text aliases''' are dollar-prefixed words that ATC-pie tries to replace with context-dependant values when sent. For example, <code>$metar</code> expands to the current primary station weather. This allows to write and save formatted messages instead of repeating chunks of a recurrent format. For instance, anybody will enjoy the comfort of sending "Current weather is $metar" instead of copy-pasting a weather look-up for every such message.

Aliases can be predefined or custom. Predefined aliases take values that are specified by the program, e.g. <code>$metar</code>, and may depend on the local environment (declination, airport elevation...), on your configuration (transition altitude, runways in use...) or on the current selection (QDM to airport, assigned route...). They are all listed with their meaning in the "quick reference", ''Text aliases'' section. Make sure to take a look.

All other aliases will be considered custom, in other words to take values specified by you. You can define text aliases on three different levels:
* world (saved for replacement anywhere that the program will be opened), in the general notes (notepad dock);
* location (saved for this airport or centre), in the local notes;
* single aircraft contact (by selected strip), in the strip comments.

Here is how ATC-pie decides what to do with a text alias of the form <code>$foo</code> on chat message send:
# If it is one of the predefined list, the substitution is the one described. If not, it is a custom alias and we carry on to the next step.
# Look for a line beginning with <code>foo=</code> in the general notes. If one is found, the alias is substituted with what follows the '<code>=</code>' character.
# Perform the same search through the local notes. If nothing is found, consider the current selection.
# If a strip is part of the current selection, look inside the comment field and search likewise.
# Substitution is unsuccessful. ATC-pie will open an edit box so that you can review your message before sending it.

Moreover, ATC-pie strips everything up to the first '''pipe character''' (<code>|</code>), if any, before a message is processed and sent. You may check this with test line "stripped part|sent part" and observe that only the "sent part" makes it to the message contents. You can therefore make your life easier with piped shortcuts in your preset message list. They will pop up like any other message in the filtered menu as you type. For example, the following preset message enables something like a dot-command for sending a bearing to your base airport in a few key strokes:
: <code>.qdm|Heading to airport $qdm</code>

Lastly, if a troll or angry user is polluting your session with undesired messages, add their callsign to the '''senders blacklist'''. All messages from the user will then be filtered out from the message pane. You can view and clear this list at any time.

== Teacher & student connections (ATC tutoring) ==

This session type is made to bring an ATC student and a teacher together for tutorial sessions. To '''set up a session''', the student must connect to the teacher, so make sure the teacher's session is running first. Only one student can connect to a teacher at a time. The teacher creates and manipulates traffic for the student to work with, controls the weather and decides on the ATC neighbours. Strip exchange and ATC text chat is possible, either between both parties ("offline" exchanges) or between the student and the virtual ATCs (in-sim coordination). All exchanges are monitored by the teacher, and transparent to the student. The teacher can also snapshot traffic position situations to recall them later.

When '''playing teacher''':
* The teaching console is enabled, which allows you to control most aspects of the environment visible to the student.
* You create new traffic holding SHIFT down with a right click-and-drag on the radar specifying the position and face heading. A dialog pops up and allows you to choose a callsign (one is initially generated), altitude and other details. If near a ground route node, a parking position or runway, you can create it on the ground, ready to taxi or for departure (NB: parking overrides position/heading input).
* Traffic is initially created in an "unspawned" state (radar contact marked "+"), in other words visible to you but not to the student. This allows you to set its transponder or get it into a certain state before spawning it into the student's world.
* Controlling the traffic is done in the same way as in solo sessions without voice, i.e. using the click&drag vector and taxi tools and the instruction dock. The only difference is that you control the selected aircraft directly, regardless of your strip links and details. You therefore do not need a strip and a correctly filled callsign to instruct a pilot, though it is a good idea to have one if you want your vectors registered and drawn on the radar. The traffic creation dialog offers to create a linked strip with every new aircraft.
* You may pause the whole simulation, or freeze each aircraft individually. Frozen aircraft will result in stationary flights on the student's radar.
* The ATC text chat system allows to chat to the student directly as the teacher, and to simulate landline conversations with the student (select ATC callsign to interact as).
* To exchange strips, drop them on "Student" and select whom the strip should appear from on the student's side. Note that for your convenience in further control of the traffic, teacher strips do not disappear on handovers.

[[Category:ATC-pie]]

ATC-pie

2021-02-12T17:30:57Z

Mickybadia: v1.8.1

{{forum|83|ATC-Pie support & development}}

{{about|the software in general|a manual on how to use it|ATC-pie user guide}}

{{Infobox Software
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.8.1 (Feb. 12, 2021)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''ATC-pie''' is an [[air traffic control]] simulation program featuring:
* solo sessions, incl. voice instruction recognition and pilot speech synthesis;
* network sessions through [[FGMS]] and FSD;
* tutorial sessions for teacher supervision of an ATC student.

It can simulate en-route centre control (CTR) as well as airport-based services (TWR, APP, GND...), and allows 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 [[ATC-pie installation guide|installation]] and [[ATC-pie user guide|user]] guides. If you have a question, check the [[ATC-pie FAQ|FAQ]] first, or try the forum for help.

== Screenshots ==

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Playing solo with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

== 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 ===
[[File:ATC-pie-screenshot-stripDetailSheet.png|thumbnail|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 [http://en.wikipedia.org/wiki/Secondary_surveillance_radar 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 ===
[[File:ATC-pie-screenshot-radarIdentification.png|thumbnail|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 airfiled)
* 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
* Separation incident alarm
* Runway occupation/incursion detection
* Position/track vs. strip assignment mismatch warning system
* Anticipated route/vector conflict warnings

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 [[:File:ATC-pie-screenshot-ATISdialog.png|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 land 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:
* Strip exchange: full handover support with ATC-pie, compatible with [[OpenRadar]]
* Voice radio: [[FGCom]] integration (using stand-alone processes or through Mumble plug-in)
* Weather: real world METAR retrieval
* Flight plans: interface with [http://flightgear-atc.alwaysdata.net Lenny64's data base] (the ''de facto'' FG standard), incl. filing, editing, opening and closing
* ATIS: voice recording through FGCom
* In-app announcement of ATC sessions on Lenny64's event page

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 [[: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

Common data sources:
* Airport and navigation data sourced in the [http://data.x-plane.com 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)
* Real world magnetic declination lookup

[[Category:ATC-pie]]
[[Category:ATC clients]]
[[Category:Air Traffic Control]]

ATC-pie user guide

2021-01-17T21:26:27Z

Mickybadia: v1.8.0

{{forum|83|ATC-Pie support & development}}

This article is a guide to the air traffic control simulation program [[ATC-pie]], describing some of its major features. A more exhaustive list can be found in the main article. For download and installation help, refer to the [[ATC-pie installation guide]].

Anyone motivated to write a full user guide is obviously welcome to contact the developer, or improve this article. For support and troubleshooting, the [[ATC-pie FAQ]] might get you an answer first. Otherwise kindly ask on the FlightGear forum, where we have a dedicated sub-forum, so the discussion is public and its contents shared.

Other sources to learn the program are:
* the [https://www.youtube.com/playlist?list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb online] '''video tutorial''';
* the in-app '''quick reference''' available from the ''Help'' menu (summary of mouse/keyboard gestures, display conventions...);
* a skilled '''teacher''' to connect to as a student (personal training);
* to '''play solo'''!

== Flight strips ==

Whether dematerialised or on physical paper, printed out or filled by hand, the '''flight progress strip''' is the essential piece of air and ground traffic control. Every aircraft in contact is represented by a unique strip, and every strip represents a contact. This helps to ensure that no aircraft is ever forgotten about. Strip positioning and updating then enable to monitor the aircraft's status, sequence number, position, intentions, etc.

=== Filling details and linking ===
A click on the "new strip" tool bar button (shortcut <code>F2</code>) or double-click on an empty strip rack or bay space will open a dialog to fill flight details on a fresh blank strip, e.g. destination, type of aircraft, etc. Double-clicking on an existing strip allows to edit the filled details.

If providing radar service, strips should be '''linked''' to identified contacts to inform the radar display with the filled details and enable joint selection. To link a strip to a radar contact, select one and middle-click on the other. Conflicts between the strip details and the values squawked by the linked transponder contact are reported: the strip displays a "!!XPDR" warning and the strip dialog labels the conflicting details.

A strip can also be linked to a filed flight plan (FPL). This will make radar and strip display fall back on filed information for missing details. The strip dialog also shows the mismatching information between the two, though this is rather common because the strip typically gets updated as the flight progresses.

All together, a selection can involve up to three linked elements: strip, radar contact, flight plan. You can pull details from linked elements to strips (strip panel bottom menu), and push strip details to their linked flight plan if necessary (strip dialog bottom tick box). Unlinking is possible with SHIFT+middle-click. If you use linking carefully, auto-fill options are available from the general settings, to fill blank strip details with newly-linked information.

For fast and efficient service, every initial contact by a pilot should basically make you hit <code>F2</code> and type the callsign announced. You should then soon figure out if:
* a flight plan is already filed: a matching FPL count is displayed near the callsign field as you type, if any (click on the button to view them);
* a flight plan must be filed (e.g. IFR departure not filed by lazy pilot): select "new FPL" from the bottom line to open a fresh FPL detail sheet to link to the strip;
* he was asked to contact you by a previous ATC, in which case you may have a strip handed over to you already;
* etc.

=== Strip placeholders ===
ATC-pie provides with three types of placeholders for flight strips: ''racks'', ''loose strip bays'' and ''runway boxes''. According to your ATC position and local facilities, you should choose and arrange your placeholders for optimal control. Strips can then be moved between them using mouse drag and drop.

[[File:ATC-pie-screenshot-stripRacks.png|thumbnail|Strip rack panel]]
A '''strip rack''' is the preferred way of keeping track of a sequence, e.g. a departure queue at a runway threshold. Rack panels can be created from the main window workspace, popped out as separate windows, and a persistent one can be found among the available docks. You can create as many racks as you wish in every panel. Double click on a rack's name to rename it or edit its properties. Use mouse drag to move strips up and down a rack sequence.

A '''loose strip bay''' allows free-hand positioning of strips in its reserved space. Such bays are useful for unsequenced traffic, or to map out relative positions when controlling without a radar. You may also import background images, e.g. a ground chart to keep visual track of taxiing aircraft and vehicles. See <code>CONFIG/bg-img/Notice</code> to learn how.

[[File:ATC-pie-screenshot-runwayReserved.png|thumbnail|Reserved runway marked in yellow]]
A '''runway box''' is a placeholder for a single strip, named after a physical runway and denoting a clearence to use it (enter, cross, land...). Runway boxes are contained in their own dock, with one made visible for each runway marked as in use in either direction. Thorough use of runway boxes will help you avoid bad mistakes like clear an aircraft to land over lined up traffic. When freed, runway boxes start and display a timer together with the wake turbulance category of the last contained strip to help with TKOF/LDG separation. What is more, if you use radar, a filled runway box marks the runway as ''reserved'' on the scope.

Besides, there are two other places a strip can be dropped on, usually when releasing a contact:
* an ATC callsign in the ATC panel to initiate a handover;
* a '''strip shelf''' (flat button at the bottom of loose and racked strip panels), which clears the strip from your workbench and stores it as shelved.

== Airport scene rendering ==

=== Tower view window ===
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
This feature allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any (X-plane seems only to allow for one, but feel free to declare more for ATC-pie), otherwise defaults to somewhere over the airport to allow towering everywhere. It is disabled in CTR mode.
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 to listen for traffic and accept telnet connections.

'''Running internally''' only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the ''System'' settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].

Connecting to an '''external viewer''' allows to run FlightGear on a different machine and thereby relieve your session from the CPU load a local instance induces. If you want to do so, get a hint of the required positioning options you should start your viewer with, from the tower view tab in the system settings dialog. Of course, scenery, models and liveries must also be available to the running process.

In either case, once activated from the ''View'' menu, the tower view '''control pane''' is enabled, from which you can turn to runway points, follow selected aircraft... Direct FlightGear input in the view window is also possible: right click and drag allows to look around, <code>x</code>/<code>X</code> keys change the zoom level, etc.

=== Additional scene views ===
You can hook up '''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 from the ''View'' menu. Additional viewers are registered by their host+port address, from the ''View'' menu at run-time or from a custom settings file (see <code>CONFIG/Notice</code>) read at start-up and on explicit reload (''System'' menu).

Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
* ''HHH'' is the host on which ATC-pie is running;
* ''PPP'' is the default 5009, or the chosen port number if ATC-pie was started with <code>--views-send-from</code>;
* ''TTT'' is the network polling frequency (100 is common practice; change as desired if you know what you are doing).

== Vectors, routes and separation warnings ==

ATC-pie can register and analyse issued vectors and routes to:
* inform strip and radar display;
* help monitor traffic, checking tracked positions against route/vector assignments;
* help manage traffic, anticipating route and FL conflicts between controlled aircraft.

=== Vectors ===
[[File:ATC-pie-screenshot-courseAndAssignmentsGraphics.png|thumbnail|Course/vector drawing for linked radar contact]]
Registering vectors on strips enhances the drawing of linked radar contacts, enables easy monitoring of tracks and detection of aircraft flying off course. To register vectors automatically when a radar contact is linked to a strip, use the following mouse gestures:
* click and drag out of a radar contact to issue a heading vector;
* holding <code>SHIFT</code>, click and drag vertically for altitude/FL vectors;
* holding <code>SHIFT</code>, click and drag horizontally for speed instructions;
* holding <code>SHIFT</code>, double-click on the radar target to clear registered vecors from the linked strip.

See [https://www.youtube.com/watch?v=BvA3MRlGJjU video 5] of the tutorial for more on vectoring, and check the quick reference ''display conventions'' to interpret the lines and colours of the course and vector graphics around radar contacts.

NB: In network sessions, an appropriate text chat instruction is suggested for every mouse vectoring action. This allows you to send it easily, for example to pilots whose communications are limited to text chat.

=== Routes ===
[[File:ATC-pie-screenshot-routeDetailsView.png|thumbnail|Route details dialog with world path drawn, available when both end airfields are recognised]]
A '''route''' is analysed for every strip with recognised departure and destination airports (entry fields both turned green), 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);
* if ambiguous (navpoint names are not all unique around the world), a waypoint is always the nearest homonym to the point beginning the leg;
* other tokens are kept as route leg specifications to the following waypoint (e.g. airways between fixes).

[[File:ATC-pie-screenshot-routeDrawing.png|thumbnail|Assigned routes are drawn as dashed lines on the radar scope when linked to contacts]]
Routes on flight plans and strips are viewable in a route dialog, showing geodesic paths, headings and leg distances on a world map. When a specified route is linked to a radar contact, ATC-pie works out its current leg based on distance to destination, and:
* details of the current leg are displayed in the selection info pane, and the route viewing button enabled;
* the strip shows only the remainder of the route for this contact;
* the route to go is drawn as a dashed line on the radar (unless aircraft is inbound and near enough);
* the radar tag 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.

NB: If DEP and ARR airports are not both recognised, radar tags show the strip destination detail if it is filled, possibly with a heading if it is recognised.

See tutorial [https://www.youtube.com/watch?v=LfdukpBc90w video 7] for a demonstration of routes.

=== Conflicts and anticipation ===
[[File:ATC-pie-screenshot-routeConflictDetection.png|thumbnail|Route conflict depiction]]
ATC-pie 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 aircraft with a linked strip and an assigned route or heading. 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. When the projections of two aircraft intersect, a conflict is anticipated if the respective intervals between the current and assigned altitudes overlap. When an aircraft's altitude is unknown, the assigned altitude will be assumed. If an altitude assignment is missing, a ''possible'' conflict is reported.

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 || Thick bright red intersecting circles || Separation loss between aircraft
|-
| Path conflict || Red circles and paths || Anticipated paths and altitudes are intersecting
|-
| Possible path conflict || Yellow circles and paths || Paths intersecting but some altitudes unknown
|}

== Playing solo ==

In solo sessions, you control virtual IFR planes, receiving and handing over strips to virtual ATCs depending on your position and the aircraft's intentions. You can train as an en-route controller in CTR mode, or as an airport controller in AD mode, where four combinable positions are available:
* ground (GND), to taxi aircraft between parking positions and runways;
* tower (TWR), to control runways and immediate surroundings;
* departure (DEP), to bring departing traffic to their exit point;
* approach (APP), to vector arrivals onto final.

=== Objectives ===
When '''playing CTR''', your task is to transit the aircraft across your airspace, always ensuring separation, and to hand each of them over to the most appropriate neighbouring centre North, South, East or West of your sector. You can specify local navpoints in the location settings so that the system includes them as turning points in the randomised aircraft routes.

In '''airport mode''', traffic is either inbound or outbound. Assuming APP, inbound aircraft must be sequenced and vectored into tower range for handover, unless you are in the TWR position as well. Each inbound aircraft either requests ILS or visual. Playing TWR, you must clear them to land when appropriate, i.e. cleared for ILS approach or expected runway reported in sight. If landing cannot take place (too high, not cleared...), aircraft will go around. Controlling GND, you must move inbound traffic near their parking position once they have vacated the runway, and hand them over to the ramp. Outbound traffic must be brought to hold short of a runway threshold and report ready for departure with TWR. If you play DEP, you must hand outbound aircraft over to the en-route centre (CTR) once they are high enough and close to their exit point if specified in their route. Entry and exit points are configurable in <code>CONFIG/nav/AD-entry-exit</code> (see <code>Notice</code> in the directory).

[[File:ATC-pie-screenshot-handoverPane-solo.png|thumbnail|Handover pane when playing solo in airport mode, assuming all three available positions]]
{| class="wikitable" style="text-align:center"
|+ Handovers with virtual ATCs in airport mode
|-
| || colspan="2" | Departure strips || colspan="2" | Arrival strips
|-
! Assuming positions || Receive from || Hand over to || Receive from || Hand over to
|-
! GND only
| DEL || TWR || TWR || Ramp
|-
! TWR only
| GND || DEP || APP || GND
|-
! DEP only
| TWR || CTR || colspan="2" | N/A
|-
! APP only
| colspan="2" | N/A || CTR || TWR
|-
! TWR+GND
| DEL || DEP || APP || Ramp
|-
! TWR+DEP
| GND || CTR || APP || GND
|-
! TWR+APP
| GND || DEP || CTR || GND
|-
! APP+DEP
| TWR || CTR || CTR || TWR
|-
! TWR+GND+DEP
| DEL || CTR || APP || Ramp
|-
! TWR+GND+APP
| DEL || DEP || APP || Ramp
|-
! TWR+APP+DEP
| GND || CTR || CTR || GND
|-
! All 4
| DEL || CTR || CTR || Ramp
|}

=== Instructing aircraft ===
[[File:ATC-pie-screenshot-taxiInstructionTool.png|thumbnail|Click&drag taxi instruction tool at OMDB ground]]
Instructions are given through different means:
* provided the speech recognition modules are installed, you can turn on voice instructions from the solo simulation settings dialog and instruct aircraft through your microphone, using the <code>Ctrl</code> key as push-to-talk and standard phraseology (see the quick reference tab about it);
* if voice instructions are turned off:
** mouse vector assignments issue the corresponding instructions (see section on vectors above);
** handoffs are issued when dropping strips on an ATC receiver;
* instruct taxi routes by dragging out of radar contacts when they are considered on the ground (low enough or squawking GND);
* the dockable instruction panel works regardless of voice vs. mouse selection;
* alternatively, if the aircraft is connected to CPDLC, you can send instructions through the data link (see ''Mouse gestures'' in the quick reference, combining the <code>ALT</code> key).

Instructions from the panel are always issued to the callsign entered in the top field, which should fill automatically on aircraft or strip selection when a callsign is known. Therefore, make sure you do not mess up your strip links or your instructions will realistically be acknowledged and followed by the wrong aircraft.

=== Need a scenario? ===
Things you can train for:
* towering a single runway with mixed traffic: select TWR position and an equal balance of departures and arrivals;
* optimising approach spacing in dense traffic: select APP position only, increase traffic density, turn on spacing hints and try to stabilise them all at "3:00" for example;
* 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 change for opposite runway use;
* CTR mode with a low ceiling to increase the number of conflicts to resolve;
* etc.

== ATC coordination ==

"ATC coordination" refers to the following:
* strip exchange, i.e. sending and receiving strips (handovers);
* CPDLC authority transfers;
* voice land lines (direct phone calls);
* ''who-has'' requests, to query the system and know who is claiming contact/control of callsigns;
* ATC text chat, to exchange messages between connected ATCs (see ''Communications'' section).

=== Strip exchange ===
[[File:ATC-pie-screenshot-receivedStrip.png|thumbnail|Example of a strip received from "GND"]]
To hand a strip over, drag it and drop it on the recipient in the list of connected controllers. Received strips appear on their collecting rack (if defined), with an identification of the sender which disappears as soon as the strip is clicked on. They may link automatically to identified radar contacts, according to the auto-link configuration (general settings). Double-click on the rack name to add an ATC callsign from which to collect strips.

See [https://www.youtube.com/watch?v=oQIud-cAlT4 tutorial video 6] for a presentation of the feature.

=== FlightGear sessions and compatibility with OpenRadar ===
On FlightGear session start, there are three "sub-systems" that can be activated for coordination. They differ in terms of supported features and interoperability with other clients:
* the '''IRC sub-system''' enables all coordination features with other ATC-pie clients, but does not currently operate with other software;
* the '''PyMumble land lines''' enable direct voice (telephone) lines to other connected ATCs in the ''ATC coordination'' panel (also ATC-pie only);
* the '''OpenRadar handover service''' is [[OpenRadar]]'s native system, which ATC-pie implements to enable coordination with its users, but some limitations apply (see below).
Both systems can be enabled together.

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 while respecting both approaches as much as possible, the following principles and restrictions apply to strip exchange:
* 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 properly;
* 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: 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;
* phone land lines;
* CPDLC.

Note that who-has requests are fully supported.

=== FSD sessions and compatibility with Euroscope ===
Euroscope is a popular program to control on VATSIM, a flight simulation network which is historically based on the FSD protocol, although made incompatible with it today. For a long time Euroscope allowed to connect to "plain" FSD servers, until it started being tailored more specifically for VATSIM, and closed the door to outside FSD connections. Older versions of Euroscope are still around, which ATC-pie is able to interact with, 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 land lines to Euroscope clients.

ATC-pie clients interact normally between each other for all coordination purposes listed above, but note that CPDLC is not supported by the FSD protocol (so there will be no transfers).

== Background images ==

[[File:ATC-pie-screenshot-backgroundPixmapDrawing.png|thumbnail|Pixmap image example with a topographic map shot around LIMW (Aosta, Italy)]]
[[File:ATC-pie-screenshot-backgroundHandDrawing.png|thumbnail|Hand drawing example with procedures for LSGG (Geneva, Switzerland)]]
Background images allow to decorate:
* radar scopes, with all sorts of maps and useful information about the airspace, terrain or procedures;
* loose strip bays, to move unracked strips over custom backgrounds, e.g. ground charts of the airport.

There are two ways to create backgrounds in the program. One working for all purposes is to '''import pictures''' (pixmap files like JPEG or PNG, including transparency); the other works only for radar backgrounds and consists in writing '''drawing specification''' files to paint coloured lines and labelled points. This allows to import anything from the most complex coloured height map to the the most schematic airspace outline. The <code>CONFIG/bg-img/Notice</code> file explains how to import and draw background images.

For example, you can map out procedures (SID, STAR, IAD...), grouping them by associated runways. Drawings are generally appropriate for that because they allow referring to named points as per the published procedures and avoid manual positioning. But if you want more than schematic line plots, you should create the picture yourself. Using an image processing tool like ''GIMP'', superimpose a transparent layer on top of a real map canvas, or over a screenshot of your ATC-pie radar with pinned navaids as landmarks, and freely decorate your picture.

ATC-pie comes with a couple of '''helper tools''' to create or import background images:
# If you have a VATSIM/IVAO sector file for your area (.sct), the "extract drawings from sector file" option will translate the contained diagrams into ATC-pie drawings. While the generated files always require some filtering and post-editing, it is generally the best option for things like SID/STAR diagrams.
# Located in the ''System'' menu, the "image positioning helper" allows to move and resize imported pictures, adjusting the corners visually rather than programmatically if you have no specification for them. All visible pixmap images will be moved simultaneously, so you can work with several at a time if you want to. On dialog box close, a file is generated in the <code>OUTPUT</code> directory for you to copy from.
# An [[OpenStreetMap]] option will take you to the free online map server, centred on your radar centre position. For a quick and dirty start (e.g. for access to coastlines, borders and rivers) you can screenshot the map and use it as a background.

== Communications ==

The features described in this section do not apply to solo sessions, where text sending is disabled and voice radio interaction is dealt with through speech recognition and synthesis (see the appropriate section above).

=== FGCom radio ===
'''Multiple 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 if you do not wear a headset. It will avoid picking up GUI sound notifications with your microphone while transmitting.

=== Radio text chat ===
ATC-pie has a powerful text chat system for those who use the keyboard extensively to interact with pilots in network sessions, although voice communications should be encouraged for realism whenever possible.

First, '''text aliases''' are dollar-prefixed words that ATC-pie tries to replace with context-dependant values when sent. For example, <code>$metar</code> expands to the current primary station weather. This allows to write and save formatted messages instead of repeating chunks of a recurrent format. For instance, anybody will enjoy the comfort of sending "Current weather is $metar" instead of copy-pasting a weather look-up for every such message.

Aliases can be predefined or custom. Predefined aliases take values that are specified by the program, e.g. <code>$metar</code>, and may depend on the local environment (declination, airport elevation...), on your configuration (transition altitude, runways in use...) or on the current selection (QDM to airport, assigned route...). They are all listed with their meaning in the "quick reference", ''Text aliases'' section. Make sure to take a look.

All other aliases will be considered custom, in other words to take values specified by you. You can define text aliases on three different levels:
* world (saved for replacement anywhere that the program will be opened), in the general notes (notepad dock);
* location (saved for this airport or centre), in the local notes;
* single aircraft contact (by selected strip), in the strip comments.

Here is how ATC-pie decides what to do with a text alias of the form <code>$foo</code> on chat message send:
# If it is one of the predefined list, the substitution is the one described. If not, it is a custom alias and we carry on to the next step.
# Look for a line beginning with <code>foo=</code> in the general notes. If one is found, the alias is substituted with what follows the '<code>=</code>' character.
# Perform the same search through the local notes. If nothing is found, consider the current selection.
# If a strip is part of the current selection, look inside the comment field and search likewise.
# Substitution is unsuccessful. ATC-pie will open an edit box so that you can review your message before sending it.

Moreover, ATC-pie strips everything up to the first '''pipe character''' (<code>|</code>), if any, before a message is processed and sent. You may check this with test line "stripped part|sent part" and observe that only the "sent part" makes it to the message contents. You can therefore make your life easier with piped shortcuts in your preset message list. They will pop up like any other message in the filtered menu as you type. For example, the following preset message enables something like a dot-command for sending a bearing to your base airport in a few key strokes:
: <code>.qdm|Heading to airport $qdm</code>

Lastly, if a troll or angry user is polluting your session with undesired messages, add their callsign to the '''senders blacklist'''. All messages from the user will then be filtered out from the message pane. You can view and clear this list at any time.

=== ATC text chat ===
The ATC text messaging system allows to talk to other ATCs in channels that are separate from the public one read by pilots. It offers '''private channels''' simulating one-to-one landline conversations, and a '''general ATC chat room''' in network sessions, readable by all connected ATCs. Note however that ATC-pie features a direct voice (phone) land line switching system for a lot more realistic coordination between human ATCs!

'''Note on interoperability''': While only ATC-pie integrates ATC-side text chat in its interface, other users can join the same channel with an IRC client. They will be able to send and receive public and private messages and chat with everybody, at the only cost of ignoring the system messages that will sometimes appear on their side. For best results, they should use their FlightGear network callsign as their IRC nickname.

== Teacher & student connections (ATC tutoring) ==

This session type is made to bring an ATC student and a teacher together for tutorial sessions. To '''set up a session''', the student must connect to the teacher, so make sure the teacher's session is running first. Only one student can connect to a teacher at a time. The teacher creates and manipulates traffic for the student to work with, controls the weather and decides on the ATC neighbours. Strip exchange and ATC text chat is possible, either between both parties ("offline" exchanges) or between the student and the virtual ATCs (in-sim coordination). All exchanges are monitored by the teacher, and transparent to the student. The teacher can also snapshot traffic position situations to recall them later.

When '''playing teacher''':
* The teaching console is enabled, which allows you to control most aspects of the environment visible to the student.
* You create new traffic holding SHIFT down with a right click-and-drag on the radar specifying the position and face heading. A dialog pops up and allows you to choose a callsign (one is initially generated), altitude and other details. If near a ground route node, a parking position or runway, you can create it on the ground, ready to taxi or for departure (NB: parking overrides position/heading input).
* Traffic is initially created in an "unspawned" state (radar contact marked "+"), in other words visible to you but not to the student. This allows you to set its transponder or get it into a certain state before spawning it into the student's world.
* Controlling the traffic is done in the same way as in solo sessions without voice, i.e. using the click&drag vector and taxi tools and the instruction dock. The only difference is that you control the selected aircraft directly, regardless of your strip links and details. You therefore do not need a strip and a correctly filled callsign to instruct a pilot, though it is a good idea to have one if you want your vectors registered and drawn on the radar. The traffic creation dialog offers to create a linked strip with every new aircraft.
* You may pause the whole simulation, or freeze each aircraft individually. Frozen aircraft will result in stationary flights on the student's radar.
* The ATC text chat system allows to chat to the student directly as the teacher, and to simulate landline conversations with the student (select ATC callsign to interact as).
* To exchange strips, drop them on "Student" and select whom the strip should appear from on the student's side. Note that for your convenience in further control of the traffic, teacher strips do not disappear on handovers.

[[Category:ATC-pie]]

ATC-pie FAQ

2021-01-17T21:17:10Z

Mickybadia: v1.8.0

{{forum|83|ATC-Pie support & development}}

This page is a collection of questions asked at least twice about [[ATC-pie]]. It is a good idea to search through it before repeating a question on the forum or anywhere.

== Things "not working" ==

=== Why am I not seeing this aircraft on my radar? ===
Connected to FGMS: '''I know it is there: the pilot is sending chat messages and/or is visible on the online live map...'''

You only see an aircraft on your scopes if a radar contact is established, i.e. if it is visible to the primary radar or if the secondary radar (SSR) picks up a transponder signal from it.

The following cases will therefore prevent you from seeing a connected aircraft:
* The radars are turned off. Turn on at least a primary radar from the ''Options'' menu, or an SSR capability from the ''Radar'' tab in the ''Local settings'' dialog (any setting other than "none" will pick up contacts).
* The aircraft is out of radar range. It can be under the radar floor (minimum signal pick-up alt.) or too far out. In the radar settings, check the floor ("SFC" will pick up all signals down to the ground) and horizontal range. Primary and secondary radars share the same range.
* Its onboard transponder is turned off (and primary is off); see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Otherwise if you accept cheating, you can activate the "radar cheat mode" which will simulate a mode S transponder for all aircraft in horizontal range; see [https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3].

=== Connected pilots do not receive my text messages. ===
This happens with pre-2017.2 clients if you are using the latest protocol to encode properties. Tick the FGMS system option to "use the legacy protocol" for property encoding. Everybody should be able to read you, but it will come at the expense of network throughput. Tell those pilots to upgrade their client.

=== FGCom is not working. ===
First, verify that the FGCom variant selected in the ''system settings'' is the one you want to use. Check that your sound is on, your volume loud and your microphone working (system sound monitor picking up a signal). Close all open sessions and open a single ATC-pie instance.

If you have chosen the '''stand-alone''' FGCom variant, take the steps below in order:
# Echo test
#: Start an ''FGCom configuration test'' from the ''System'' menu. While the test is running, speak in the microphone and check if you can hear yourself back. If so, you may skip directly to step 4.
# Path to executable
#: Verify the FGCom command entered in the system settings. It should contain an executable system command or a relative or absolute path to an FGCom executable file. If you have FlightGear installed on your machine, you can point to the FGCom executable already available with it. On Linux, the default "fgcom" command usually does the job. Otherwise, [https://sourceforge.net/projects/atc-pie/files/fgcom-standalone/ download an FGCom stand-alone program] from ATC-pie's SourceForge file list. In any case, try the entry from a terminal in the ATC-pie directory to manually check that it runs correctly.
# FGCom server status
#: The server may temporarily be down, unfortunately even for up to a few days. Check for responses from the server, e.g. with <code>ping fgcom.flightgear.org</code> (adjusting the server name to match the one entered in the settings). FGCom will not work without a responding server.
# FGCom subprocess error
#: After turning your radio on, check for errors in the logged FGCom output files in the <code>OUTPUT</code> directory.
# Port mess-up in your session?
#: When creating a new radio box at run time, make sure you choose an available port number for each. Caution when running multiple ATC-pie instances: do not use a port more than once across the system at the same time.

If you have chosen the '''FGCom-Mumble plug-in''':
# Plug-in status
#: Check that your Mumble client is connected and properly running the FGCom plug-in.
# Port setting
#: Check that the control port in ATC-pie is set to the one FGCom-Mumble is listening on.
# Echo test
#: Start an ''FGCom configuration test'' from the ''System'' menu.

Note that the two variants are ''not'' interoperable. Users will only be able to hear and interact with others using the same variant (and server) as their own.

=== Recording ATIS with stand-alone FGCom: no beep is heard after pressing "record". ===
Assuming FGCom standalone is working (confirm this with an echo test before reading on)...

Due to the design of this legacy FGCom variant, you may only record an ATIS if the requested frequency is enlisted as recordable on the distant server's "phone book" for the airport. The one for <code>fgcom.flightgear.org</code> was compiled a while ago, based on the latest <code>apt.dat</code> at the time. It filtered the frequencies through the two following conditions:
# it is of the "recorded" type (row code 50);
# its name contains the uppercase string "ATIS".

If you are relying on the old data provided by ATC-pie, in other words you have not downloaded new data or edited the frequencies yourself, check against the <code>.dat</code> file extracted in the <code>OUTPUT</code> directory on your side, as it should still be similar to the one on the server's side. One of the two conditions is probably not met, or the frequency missing. NB: The frequencies in the ATIS drop-down list of ATC-pie are matched against the condition (1), but not against the somewhat restrictive condition (2).

In any case, consider switching to the newer FGCom-Mumble plug-in variant. It simulates radio waves, frequencies and ranges, which avoids the phone book problem all together.

=== Tower view is not starting. ===
Ruling out that FlightGear is not installed at all, your system path settings are probably wrong. From a terminal or a file system navigator, find the right command to start FlightGear and enter it as ''FlightGear executable'' from the system settings. Do not add options of any kind; they will be taken care of internally. You may have to enter a ''FlightGear root directory'' as well, especially if you have the program files installed somewhere unexpected.

=== My tower is in the middle of the sea, and aircraft floating/landing on water! ===
You are missing the FlightGear scenery data for your location, or ATC-pie does not know where it is. If you have downloaded scenery and saved it somewhere, have you tried filling the scenery directory with that location in the system settings? Also check out the ''Tower viewing'' [[ATC-pie_user_guide#Tower_view_window|feature note]] in the user guide.

=== Simulated aircraft appear to dip underground or levitate over taxiways. ===
Do you have a ground elevation map for the location? Quoting from <code>CONFIG/elev/Notice</code>: "''When no elevation map is found for an airport, the field elevation value is used everywhere on the ground. This should be OK for a rough approximation on flat terrain, but ground traffic will not follow any slopes, thus may appear as floating above the ground, or dipping into it.''"

Read the full notice for instructions on how to build your elevation map. Once you have one or decide that your field is flat enough, the next focus is on the FlightGear aircraft models. Each model has its own coordinate system chosen at developer's discretion. ATC-pie must be given the height difference between each model's origin and the aircraft touch-down point (gear wheels) to position aircraft more accurately. You can do this on a per-model basis with ":height" specifications in <code>CONFIG/acft/icao2fgfs</code>. Read the associated <code>Notice</code> file for more information.

A last possible altitude adjustment is available from the location options: "Altitude adjustment for FlightGear views". It applies the given offset to all traffic rendered by the views.

=== I cannot connect to my teacher as a student. ===
Using IPv4 addresses, this typically happens when the teacher is in a local area network behind a router. It is a common setup for home internet, in which the teacher's actual host address is not publicly accessible from outside his private network.

If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either:
* for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local host address;
* or to create a virtual network, using a third-party VPN service.

== What is ...? Why is ...? What value/setting for ...? ==

=== What "social name" should I use for the FlightGear/FSD system settings? ===
Choose any name you would like to be recognised by on the network. In ATC-pie, it will appear in the tool tip over your callsign for connected ATCs who see you. This feature is only social in the sense that it does not refer to an account or to anything technical, but it makes sense as typical ATC callsigns (e.g. "VHHHtwr") remain mostly anonymous. Use this field to identify yourself on the network.

=== Are the vector headings true or magnetic? ===
Heading displays in ATC-pie are mostly magnetic so they can be read out to pilots. The only exceptions are for easier human identification, because true North is at the top of the map. For example, navigator and handover list tool tips are true radial headings from the radar position.

Also note: all directions are geodesic, i.e. initial headings to take on a great circle.

=== What is the purpose of the flat "strip shelf" button in the strip panes? ===
More than a button, the strip shelf is where you should drop the contacts you release without a handover, e.g. parked traffic shutting down, VFR traffic flying out of your airspace, etc. Clicking on the shelf allows to browse the previously shelved strips, and to recall them, for example if shelved inadvertently.

=== Why do I keep getting runway incursion alarms? ===
Because you have the runway occupation monitor turned on (''Options'' menu), while not using your runway boxes. The alarm triggers when the radar detects traffic stepping on a runway in either of the following situations:
* the runway is active (marked in use) and no strip is boxed for it;
* it is reserved but there is already traffic on the runway;
* it is reserved for a different aircraft: the boxed strip is linked to a contact that is not the entering aircraft, or the aircraft is linked to a strip different to the one boxed.

Turning the runway occupation monitor off will deactivate all radar warnings regarding runways. If you are interested in the strip boxing and visual runway highlighting system but bothered by the alarm sound, you can mute the sound notification by unticking it in the general settings.

== Where is ...? Can I ...? How to ...? ==

=== Can I draw SID and STAR procedures on the radar? ===
Yes, and virtually anything else, using background images. To learn about those:
* see the corresponding [[ATC-pie_user_guide#Background images|user guide section]];
* read the <code>CONFIG/bg-img/Notice</code> file;
* examine the (otherwise useless) packaged KSFO example.

'''If you have a sector file''' of the ".sct" format used in VATSIM/IVAO, you should try to import it with the provided drawing extraction tool. It will extract most of the contents for the open location and current map range, including SID/STAR procedures, and translate them to ATC-pie's native drawing format. It is generally the best solution if you know your procedures are included.
# Run the "extract drawings from sector file" option (''System'' menu) and select the file to extract from. This generates the following files in the <code>OUTPUT</code> directory:
#* <code>ICAO.lst.extract</code>, a menu file for the generated drawings;
#* <code>bg-ICAO-*</code>, the extracted drawings in the native ATC-pie format;
#* <code>bg-extract.err</code>, a log of the errors detected in your sector file (do not be alarmed as they often contain many).
# Import the results:
#* move or copy-paste lines from <code>ICAO.lst.extract</code> to <code>CONFIG/bg-img/ICAO.lst</code>;
#* move the desired drawing files under <code>CONFIG/bg-img</code>, adjusting the paths in the <code>.lst</code> menu as you organise subdirectories.
# Post-editing (cleaning)
#: ATC-pie does its best to understand the objects in the sector file and to group things together depending on their type. But not everything can be guessed automatically. This last step is where you filter, merge and split objects, rename points, change colours, etc. to your liking.
#: Each generated drawing section (point list under a colour) is automatically labelled with the line number where it was sourced from in the sector file so you can easily trace it (<code>@nnn</code>). A tool like ''sed'' will help you get rid of all these unwanted suffixes once you have sorted and renamed your objects:
#:: <code>sed -ri 's/ +@[0-9]+$//' file_to_clean</code>

Tip: You can check your image configuration without restarting the program, by reloading from the ''System'' menu or pressing <code>Alt+F12</code>.

NB: ATC-pie does not package or source from sector files directly because their data is not free, and a lot of it is redundant with its own GPL-licensed X-plane source (GPL).

=== How do I assign SIDs and STARs to aircraft? ===
This question is asked quite a lot more than it is relevant to a real controller's task...

What people seem to be after when asking this question is a way to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. The way to handle this is to stack your inbound strips on racks named after your STARs. Racks are indeed above all meant for efficient traffic sequencing. Every rack represents its own sequence of ordered aircraft, which is perfectly suited to control separate approach paths in parallel. With this technique, placing a strip on a STAR-named rack basically serves as the "assignment" itself. Similarly, runway-specific racks can keep track of separate landing sequences at large airports. Then you can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times in the sequence all the way to touchdown.

If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. Routes are lists of waypoints and instructions to follow between the two end airfields. Normally pulled straight from properly filed flight plans, routes are printed on strips prior to departure, then modified as the flights progress and passed along with handovers. Standard departure and arrival procedures (SIDs and STARs) can be referred to in those routes, but only by their entry or exit navpoints. They should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. For example, routes ending with a STAR should end with "FUBAR STAR", which means that waypoint FUBAR is an entry point from which a published STAR must be followed. The keyword "STAR" is in fact a mere specification for the last route leg. Similarly, routes of the form "SID DUMMY ..." specify their first leg as a standard departure to the first waypoint DUMMY. "SID" and "STAR" keywords are recognised by ATC-pie and accounted for in the second line of the radar tag when appropriate (see feature note on routes).

One meaningful wish regarding this question is for easy '''reference in text chat''' messages. Firstly, using racks in the way suggested above, you can use the <code>$rack</code> alias which is substituted by the name of the rack on which the current strip selection is stacked. Otherwise, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". Now if you specifically want to assign a full procedure name like FUBAR1A to a contact and refer to it in a generic text chat message, include a line "sid=FUBAR1A" 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 expanded in your sent messages when that strip is selected.

=== How to set the transition level? ===
You do not. You can however set the transition altitude in the location settings if your airport specification file does not already include one.

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, e.g. for more vertical separation on either side of the transition layer or due to coordination with neighbouring zones and fields.

=== Can I look up ILS frequencies? ===
Yes, in the ''environment info'' dialog.

Besides, you can create aliases with the local notepad for a quick and integrated way of sending them through text chat, which will be saved when you close ATC-pie. For example, use the following format, one runway per line: <code>ils05=111.11 MHz</code>. See [[ATC-pie_user_guide#Public text chat|custom text aliases]] for more.

=== The navigation/airport data is outdated. How can I update it? ===

For '''airport data''' (taxiways, parking positions, frequencies, etc.), the included source is the last world-wide <code>apt.dat</code> compiled before it became too large to maintain as one huge file. We keep it there because it allows to run ATC-pie anywhere in the world without requiring external data, but its contents grows out of date with time. You should check for more recent sources on the [http://gateway.x-plane.com/airports/page X-plane airport gateway], directly accessible from the ''System'' menu, on a per-airport basis. Extract the <code>apt.dat</code> file from the download, rename it after the airport's ICAO code (keeping the extension, e.g. <code>KJFK.dat</code>), and place it in <code>CONFIG/ad</code> (also see the <code>Notice</code> there). Alternatively, for a quick manual touch-up of the included data, you can move and edit extracted files (see <code>OUTPUT/Notice</code>).

For '''navigation data''' (navaids, fixes, airways, etc.), the included data is the latest version of each file that was seen released as GPL, which makes some of it date back to 2013! You should provide more recent navigation data, as explained in <code>CONFIG/nav/Notice</code>.

=== How do I customise the GUI and colours? ===
To change the '''radar or strip drawing colours''', edit the <code>CONFIG/colours.ini</code> file. Each line specifies the paint colour for an object type, in a typical hex <code>RRGGBB</code> (red-green-blue) format or as an SVG colour keyword name like "white". To customise the '''main session window''', place a ''Qt stylesheet'' named <code>main-stylesheet.qss</code> in the <code>CONFIG</code> directory. ATC-pie will apply it to every session window. While you are working on your look and feel, use the reload feature from the "System" menu to avoid restarting after every change (<code>Shift+Alt+F12</code>).

Send us screenshots and share your files if you find a setup looking really cool! :-)

== Miscellaneous ==

=== What's with the funny name? ===
ATC-pie is written in Python, and I reckoned that the ''pyXXX'' naming habit was becoming a little dull, so I merely switched things around. You can surely do the rest of the math in terms of spelling, and later impact on the logo.

=== Why is the learning curve so steep? People would use your program more if you did/provided [...] ===
Often continued with: '''(you must understand that) this is not VATSIM!'''

We do have a [https://sourceforge.net/p/atc-pie/wiki/Wishlist wish list] and will consider any feature or help request. However, though it has a few cheats, ATC-pie has always choosen realism as a criterion for implementation and design, over the mere incentive of converting otherwise happy users of other programs. It is a good thing that different philosophies and work flows are available out there, and there would be much less interest in having them all copy each other, fighting over users instead of understanding that not all of them wish for the same experience. If serious simulation or learning new skills sound like threats to fun for you, you have a perfectly valid reason not to opt for ATC-pie.

[[Category:ATC-pie]]

ATC-pie installation guide

2021-01-17T21:15:44Z

Mickybadia: v1.8.0

ATC-pie

2021-01-17T21:13:43Z

Mickybadia: v1.8.0

{{forum|83|ATC-Pie support & development}}

{{about|the software in general|a manual on how to use it|ATC-pie user guide}}

{{Infobox Software
| title = ATC-pie
| logo = ATC-pie-logo.png
| image = ATC-pie-screenshot-towerViewing.png
| alt = Tower viewing, following a departing aircraft
| developedby = Michael Filhol
| initialrelease = February 1, 2015
| latestrelease = 1.8.0 (Jan. 17, 2021)
| writtenin = Python
| writteninversion = 3
| os = Any
| platform = Qt5
| developmentstatus = Active
| type = ATC client
| license = GNU GPL v3
| website = http://mickybadia.free.fr/atcpie
}}

'''ATC-pie''' is an [[air traffic control]] simulation program featuring:
* solo sessions, incl. voice instruction recognition and pilot speech synthesis;
* network sessions through [[FGMS]] and FSD;
* tutorial sessions for teacher supervision of an ATC student.

It can simulate en-route centre control (CTR) as well as airport-based services (TWR, APP, GND...), and allows 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 [[ATC-pie installation guide|installation]] and [[ATC-pie user guide|user]] guides. If you have a question, check the [[ATC-pie FAQ|FAQ]] first, or try the forum for help.

== Screenshots ==

Visit the [[:Category:ATC-pie screenshots|ATC-pie screenshot category]] for more.

<gallery mode="packed">
ATC-pie-screenshot-sectorView.png|Sector view around Geneva
ATC-pie-screenshot-soloMode.png|Playing solo with three coloured racks
ATC-pie-screenshot-backgroundPixmapDrawing.png|Background image display
ATC-pie-screenshot-airportCloseUp.png|Depiction of airport tarmac and objects
ATC-pie-screenshot-runwayIncursion.png|Runway incursion detected and highlighted in red
ATC-pie-screenshot-flightPlans.png|Flight plan editor
</gallery>

== 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 ===
[[File:ATC-pie-screenshot-stripDetailSheet.png|thumbnail|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 [http://en.wikipedia.org/wiki/Secondary_surveillance_radar 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 ===
[[File:ATC-pie-screenshot-radarIdentification.png|thumbnail|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 ==

=== General ===
Available session 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)

Available modes for all session types:
* Airport (for ATC positions such as TWR, GND, APP, DEP at a selected airfiled)
* 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
* Current leg and next waypoint display with geodesic calculations of headings and distances
* Anticipated route/vector conflict warnings and separation incident alarm
* Position/track vs. strip assignment mismatch warning system
* Traffic identification assistant
* 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 [[:File:ATC-pie-screenshot-ATISdialog.png|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 land 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:
* Strip exchange: full handover support with ATC-pie, compatible with [[OpenRadar]]
* Voice radio: [[FGCom]] integration (using stand-alone processes or through Mumble plug-in)
* Weather: real world METAR retrieval
* Flight plans: interface with [http://flightgear-atc.alwaysdata.net Lenny64's data base] (the ''de facto'' FG standard), incl. filing, editing, opening and closing
* ATIS: voice recording through FGCom
* In-app announcement of ATC sessions on Lenny64's event page

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 [[: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

Common data sources:
* Airport and navigation data sourced in the [http://data.x-plane.com 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)
* Real world magnetic declination lookup

[[Category:ATC-pie]]
[[Category:ATC clients]]
[[Category:Air Traffic Control]]

FlightGear Newsletter November 2020

2021-01-03T13:11:42Z

Mickybadia: Link to CPDLC proposal page

{{User:Skybike/Template:Newsletter-header-translate|2020-11}}
{{TOC_right|limit=2}}
''We would like to emphasize that the monthly newsletter cannot live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) is welcome to contribute to the newsletter. If you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== Development news ==


===2020.3 LTS released===

'''2020.3''' was [https://www.flightgear.org/download/ released] on November 6th 2020. Read the release notice and [[Changelog_2020.3|changelog]] for what's new.

2020.3.x is a [[Release_plan#General_release_concept|Long Term Stable release]] (LTS). Bug fixes will be backported, and the build maintained, for a much longer period than development preview builds.

[[Keflavik_Airport|Keflavik Airport]] (BIKF), in south-west Iceland, is the featured airport.

There is an additional development preview binary of the work-in-progress [[Compositor]] bundled with the LTS, like in the 2020.1 preview build.

OSM2City scenery for the whole of Iceland was built for the LTS earlier this year, but is not bundled due to the innosetup installer size limit. It is available from the [[Areas_populated_with_osm2city_scenery|OSM2City download list page]].

The first version released on the flightgear.org website is labelled 2020.3.2. 2020.3.1 was a preliminary soft release to find bugs and installer issues.

For upcoming point releases of the 2020.3.x LTS, the current plan is to include some minor improvements like launcher UI tweaks, as well as bug fixes.

<gallery mode-"packed">
Iceland_in_FlightGear_2020_01_Volcanic_plume_and_snow_(Aerospatiale_Alouette_III).jpg|Eyjafjallajökull volcanic plume
Iceland_viewed_from_space_in_Earthview_(Flightgear_2020.x)_02.jpg|Iceland from space
Rainbow_sculpture_at_Keflavik_International_Airport_(BIKF)_in_Iceland_(Flightgear_2020.x)_01.jpg|Rainbow sculpture at BIKF
The_Jet_Nest_sculpture_at_Keflavik_International_Airport_(BIKF)_in_Iceland_(Flightgear_2020.x)_1024_04.jpg|Jet nest sculpture at BIKF
Reykjavik_at_sunset_with_OSM2City_output_(Flightgear_2020.x)_02.jpg|Rekjavik OSM2City (near BIRK)
</gallery>

===The road ahead===

'''See [[FlightGear_Newsletter_October_2020#Help_wanted|Help wanted]].'''

There are a lot of big infrastructure changes already nearly completed, well underway, and planned. These will be for the LTS after 2020.3.x.

With the LTS released, a lot of big changes have ''already'' been merged into the "next" branch:
* [[Compositor]] rendering framework - next has switched to the Compositor.
* [[World_Scenery_3.0_roadmap|World Scenery 3.0]] (next generation scenery) initial deployment. WS 3.0 uses [[Virtual_Planet_Builder|Virtual Planet Builder]] instead of terragear for terrain building.
* [[CompositeViewer_Support|Composite Viewer]] - This allows Flightgear to have multiple top-level windows showing independent views of the scenery, and will also allow implementation of things like cockpit rear-view mirrors and cockpit displays of external views (tail cams, gear view etc). [[:File:Fg-cv-textures2.jpeg|Screenshot]]

Some other big infrastructure changes being worked on, but not on next: replacement of the in-sim UI using Qt, infrastructure for regular world builds, runtime airport generation, move to a higher version of [[OpenGL#Status|OpenGL]] (4.x is planned), OSM2City world build and [[OSM2City]] tech improvements etc.

If you are wondering when Flightgear will move to Vulkan using the newly released [[Vulkan Scene Graph]] (VSG) which is the successor to OSG that FG currently uses, VSG will be looked at after the current set of infrastructure and OpenGL 4.x according to plans mentioned by devs - as Vulkan Scene Graph hopefully should be mature and stable by then.

For those curious, keep and eye on the 'next' branch, or the [http://download.flightgear.org/builds/nightly/ nightly builds]. The history of changes on 'next' can be viewed by clicking the "History" link for each repository on the sourceforge website: [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/ FlightGear] , [https://sourceforge.net/p/flightgear/simgear/ci/next/tree/ SimGear] , [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ FGData]

The 'next' branch will build towards the next Development Preview release, and ultimately the next LTS. As always, nightly builds of the next branch are available at [http://download.flightgear.org/builds/nightly/ download.flightgear.org].

Core development is coordinated via the fg-devel [[Mailing_lists|mailing list]], to get involved you can just sign up on the [https://sourceforge.net/projects/flightgear/lists/flightgear-devel sourceforge] page.

===Photo texture support===
Nathaniel Warner (nathaniel515) has submitted a patch to allow orthophoto textures to optionally be used and this is available in nightlies - see the [https://forum.flightgear.org/viewtopic.php?f=5&t=37866 forum thread]. This works with current WS 2.0 scenery.

====Updates to the FG homepage====

Developers, there is a wiki [[2020_LTS_Keflavik_news_post_draft|draft page here]] to write a description of improvements since 2018.3 LTS to your craft or feature, with several accompanying screenshots.

James has said he is willing to review and update the homepage if material is submitted to the wiki, or otherwise handed over to him:
: ''James Turner [[https://sourceforge.net/p/flightgear/mailman/message/37145199/ 1]] : If anyone wants to do an article on a particular aircraft or feature for the Website, that would be excellent: don’t be shy: if you can provide some text and a couple of screenshots, it can be turned into a post easily.''

These will be published as news posts after 2020.3 LTS release, maybe about a week apart, or when material is available. If there is not enough material, several small items can be collected into a news post.

For screenshots, it's possible to pause the sim and [[Howto:Make_nice_screenshots|turn up]] settings, if you normally have settings lower on an older laptop or similar - there may be suitable screenshots already submitted SOTM section in the [https://forum.flightgear.org/viewforum.php?f=88 forum] under CC-BY-SA-4.0 that have not been [[Special:UploadWizard|uploaded]] to the wiki [[:Category:Screenshots at high settings|high settings screenshots category]] yet.

The most important things are the points about what to write, and some screenshots. Don't worry if wording or English is not perfect, it can be adjusted later. Knowledge of wiki syntax isn't needed for a simple draft, just click edit and type. URLs to screenshots can simply be pasted if you don't know how to upload, along with a note giving CC-BY-SA-4.0 permission.

=== Virtual FSWeekend Hackathon 2020 report===
The Hacakthon was a success with a lot of contributors new to the project and contributors in non-core areas starting with core code and FGData contributions. See StuartB's writeup on the [https://sourceforge.net/p/flightgear/mailman/message/37153143/ Hacakathon and lessons learned]

Normally in mid-November a group of FlightGear enthusiasts participate in FSWeekend at Lelystad Airport in the Netherlands. Over the years this has been a focal point for both finishing existing development/releases and a catalyst for new ideas in FlightGear, as well as an opportunity for FlightGear enthusiasts to share a beer. FSWeekend 2020 was cancelled, so to keep the spirit alive, a [[Virtual FSWeekend Hackathon 2020|Virtual FSWeekend Hackathon]] was held.

The current thought is to look at having a Hackathon every year, but at a different time to FSWeekend.

The hack projects/areas worked on were: [[Hackathon_Proposal:_CompositeViewer_and_Canvas|CompositeViewer and Canvas]],
[[Hackathon Proposal: CPDLC|Controller-pilot data link communication (CPDLC)]], [[Hackathon_Proposal:Feature_Scaling|Feature Scaling]],
[[Hackathon_Proposal:_more_diversified_facade_textures_osm2city|OSM2City Facades]]
), [[Hackathon_Proposal:POH_Checklists|POH Checklists]] , [[Hackathon_Proposal:_Wake_from_multiplayer_aircraft|Wake from AI Aircraft]],
[[Hackathon_Proposal:_WS3.0_Effects|WS3.0 Effects/Scenery]]

A substantial amount of the results from the Hacakathon are already merged on the next branch (and available on nightlies).

== New software tools and projects ==
=== FGCom-mumble ===
[https://github.com/hbeni/fgcom-mumble FGCom-Mumble] aims to provide a mumble based FGCom implementation. This will simulate radio communications in a seamless frequency spectrum.

The project aims to be easy to use: Pilots just install the plugin, open mumble, join a channel on a mumble server and start using their radio stack in Flightgear.

The development is discussed in the {{forum link|title=FGCom-mumble|f=32|t=37644}}. Releases can be downloaded from {{github source|user=hbeni|repo=fgcom-mumble|text=GitHub}}.

The project also has a flightgear wikipage: [[FGCom-mumble]]

===== Test server available! =====
I was able to get a small virtual linux server and deployed a test bed onto it.
* The address is mumble://fgcom.hallinger.org for mumble
* A status page can be viewed at http://fgcom.hallinger.org

I did already test this and i think it works fine. There is an outstanding issue with ATIS broadcasts stopping after a short while, but i currently think this is a library bug somewhere else.

To connect/use, you need to self-compile mumble; [https://github.com/hbeni/fgcom-mumble/wiki#compiling-mumble-140-plugin-branch-from-krzmbrzl-on-a-debian-testing-bullseye-system i wrote a small guide for debian/bullseye]. Or you try the precompiled one: http://fgcom.hallinger.org/mumble-fgcom-test.tar.gz

We should gather around to get a small testing event :) Feel free to chime in at the {{forum link|title=forums thread|f=32|t=37644}}!

=== Red Griffin ATC 2.0 released ===

Antonello Biancalana (Red Griffin) has released [[Red Griffin ATC|version 2.0]] of his speaking Air Traffic Controller (ATC) [[Addon]]. This addon uses TTS, and simulates an AI ATC. This is also available from FGAddon.

For feedback see the {{forum link|t=36755|title=Red Griffin ATC - Speaking ATC addon for FlightGear}} thread.

Demo of a previous version of the ATC addon:
{{#ev:youtube|ZOxDTGj9UnQ|480px||Demonstration video of a previous version of the Red Griffin ATC addon for an older version of Flightgear. Video from March 2020.}}

== In the hangar ==




=== New aircraft ===
====C172S with FG1000====
[[User:wlbragg|Wlbragg]] and the C172 team are working on the Cessna 172S SkyHawk SP, with the [[FG1000]] glass cockpit.

The team are requesting thorough testing to find any needed tuning changes and missing elements.

The engine and systems work is already available, done, or will be completed shortly.

The team are placing a request/call for help with "exterior and interior cabin modeling" to make this a complete C172S.

See the [https://forum.flightgear.org/viewtopic.php?f=4&t=38240 forum thread] for more information and screenshots (Newest: [https://i.imgur.com/q2DeuhL.png 1], Older: [https://i.imgur.com/QsjgtGc.png 2], [https://i.imgur.com/TlsZ5dw.png 3], [https://i.imgur.com/rA8a2D0.png 4]).

Github repository and downloads:
* [https://github.com/c172p-team/c172p/tree/FG1000-variant C172S with FG1000] and [https://github.com/c172p-team/c172p/archive/FG1000-variant.zip download]
* [https://github.com/c172p-team/c172p/tree/Issue-1307 C172S compositor branch] and [https://github.com/c172p-team/c172p/archive/Issue-1307.zip download]

====Airbus A320====
The [[Airbus_A320_Family|Airbus A320]] family is available on the 2020.3 LTS release. This is a complete overhaul/replacement that has been worked on for many years by a team before releasing on LTS. It has the most detailed systems of glass cockpit airliners currently released in FGAddon, and a JSBSim FDM.

[[File:A320-family-cockpit.png|480px|Airbus A320]]

===Eurocopter AS532 Cougar===
FGUK have released the {{wikipedia|Eurocopter_AS532_Cougar|Eurocopter AS532 Cougar}} now known as the Airbus Helicopters H215M and it's military variant the {{wikipedia|Eurocopter_AS332_Super_Puma|Eurocopter AS332 Super Puma}}. This is a twin engine multi-purpose helicopter.

Features: 90% Accurate FDM. 7 Configuration options, 15 Liveries. Multiplayer crew / Passenger function. ALS Glass and fuselage effects with livery specific reflection levels. Rotor wash on grass effects. Functional Winch man. Search and Recovery function for recovering other downed choppers over Multiplayer.

For more details, screenshots, and download see the [https://forum.flightgear.org/viewtopic.php?f=4&t=38259 forum thread].

{{#ev:youtube|UKEGI9EH7bk|480px||Airbus AS352 Cougar - a development video showing a return trip to oil rigs at sea. By FGUK.}}

=== Updated aircraft ===
===Cessna 182S===
The [[Cessna 182S]] ([https://github.com/HHS81/c182s git version]) got some enhancements:
* The Airspeed Indicator was reworked based on photos of a C182T and now corresponds to the real model.
* The Alternate static air system was modeled, and now the outer static ports can ice, causing the static port to be blocked. If this occurs, one can pull the red static air knob in the cockpit to switch the static system to a port inside the cabin. The Venturi effect will introduce some errors/misreadings, because cabin pressure is lower than the outside atmosphere based on speed. This was the last Cockpit item missing, so the Cockpit can be considered complete!
* Flap operation does consume electrical power now, which can be used in the preflight check to test the electrical system.
* Currently we have multiplayer enhancements in the works, involving a canvas redo for the registration number; and the damage system is nearly finished. Once we completed that, Heiko wants to do a FGAddon release.

===FGUK development videos===

{{#ev:youtube|JCzNF3qwmWo|480px||Harrier GR9 - sound model development. By FGUK}}

{{#ev:youtube|4Ie0DLF47G8|480px||Westland Sea King alpha - hovering and maneuvering. By FGUK.}}

{{#ev:youtube|gApaRpYVfy4|480px||Work-in-progress SA 330 PUMA FDM test. Low flight over Wales, UK. By MrChillStorm.}}





== Help wanted ==
{{Help wanted}}

== AI ==


The AI team makes FlightGear more realistic, colorful and lively every month. You can support the important development of ''Interactive Traffic'' and contribute at the FlightGear {{forum link|title=AI|f=23}}.



== Scenery corner ==















== Community news ==






===Flightgear on youtube===

GinGin has re-created a [[Space Shuttle|space shuttle]] landing video of the Terminal Area Energy Management (TAEM) and Landing phases, overlayed with real voice communications between astronauts and mission control in the shuttle mission STS 155. The FlightGear's simulation of the space shuttle is the most detailed simulation outside NASA's internal ones, and has a JSBSim FDM backed by extensive windtunnel data.

{{#ev:youtube|ECJjC-i_3l8|700px||FlightGear [[Space Shuttle]] external view video recording TAEM and landing phases. View fullscreen for 2k video.}}

=== FlightGear on Facebook ===
Since early December 2010, FlightGear has an [https://www.facebook.com/FlightGear official Facebook page]. If you have a Facebook account please feel free to join the page.

=== FlightGear on Instagram ===
In January 2018 the [https://www.instagram.com/flightgear_sim/ @flightgear_sim Instagram account] was brought back to life. If you've got nice screenshots to be featured, feel free to {{forum link|text=contact the maintainer|t=33636}}.

=== FlightGear on FlightSim.com ===
FlightGear has also a [https://www.flightsim.com/vbfs/forumdisplay.php?102-FlightGear sub-forum] on flightsim.com - just like the commercial flight sims. It is an opportunity to showcase what FG can do, get people curious and answer any questions they may have with regard to the software or the project.

== Multiplayer events ==









== Contributing ==

=== Translators needed ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====

If you want to participate in the screenshot contest , you can submit your candidate to the {{forum link|title=this|f=88}}. Be sure to see the first post for participation rules. For purposes of convenience and organization, at the end of the month or after 20 entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there.

''Thanks for reading {{PAGENAME}}!''

{{Appendix}}

[[Category:Changes after 2020.3]]
[[Category:FlightGear Newsletter|2020 11]]

[[de:FlightGear Newsletter {{#time: F Y | 2020-11 | de }}]]

Controller-pilot data link communication

2020-12-13T21:39:29Z

Mickybadia: updated screenshot

File:CPDLC-generic-dialog.png

2020-12-13T20:57:12Z

Mickybadia: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Screenshot of the generic CPDLC dialog add-on}}
|date=2020-12-13
|source={{own}}
|author=[[User:Mickybadia|Mickybadia]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:Screenshots]]

Hackathon Proposal: CPDLC

2020-12-10T16:19:07Z

Mickybadia: Added disclaimer in intro (page contains old ideas and outdated specs)

This is the original material for the [[CPDLC]] proposal, published and edited in the run-up to the [[Virtual FSWeekend Hackathon 2020]], followed by the delivered results. It contains outdated/wrong information.

== Issues/ideas ==
The following could be done in the hackathon:
* write the Nasal to exchange the right data with the outside system;
* write the IRC hook to connect FlightGear to IRC (not least a generic capability, that other applications may use)
* involving core dev's at least for the design choice, a way to get rid of the middleware eventually, e.g. allow Nasal connections to FG-approved servers (like irc.flightgear.org) or integrate specific accesses in the C++ code base (sort of the same history as FGCom, going from standalone executables to an option in the FG menu)?
* can someone create a sketch of a block diagram of the elements that need to communicate and the connections between them? -- p callahan Done -- J Redpath

[[File:CPDLC Block.png|thumb|Block diagram for CPDLC subsystem]]
The block diagram describes how such a system might operate. The crucial elements are the IRC Hook and the FlightGear API. These are what the aircraft / ATC talk to directly, and therefore where input and output occur.

The IRC hook will require elements such as:
* Connection
* Respond to PING
* Disconnection
* Transmit and receive PRIVMSG to a specified UID
* Error handling - if UID does not exist, if server disconnects, if ...

The FlightGear API will require elements such as:
* Connection
* Disconnection
* Transmit + receive message element (including message history as a vector)

One option is to have a
/sim/network/cpcdlc/received/
message
sender
status
.. etc ….

and then an additional

/sim/network/cpcdlc/signals/message-received

Then in C++ you fill in all the ‘received’ values from your socket callback, and fire value changed on the signal property. This will allow a Nasal listener to process the received data.

For message history, you could either have multiple received nodes (e.g. received[0], [1], [2]) or else a Nasal hook that accesses a vector.

For transmitted messages, a similar scheme would work; however, what would probably be better would be:

<tt>fgcommand(‘cpcdlc-transmit’, props.Node.new({‘receient’:’blah’, ‘mesage’:’foobarzot’,<etc, etc>});</tt>

We’d use the same to establish the connection:

<tt>fgcommand(‘cpcdlc-connect’, props.Node.new({
’server’: “foo.bar.com’,
‘port’ : 666,
‘callsign’ : ‘wibble’,
<etc, etc?
‘recv-path’ : ‘/sim/network/cpcdlc/received’,
‘recv-signal’ : /sim/network/cpcdlc/signals/received'
});</tt>

== Available ATC-pie IRC scheme ==
When connected to an IRC server, e.g. <code>irc.flightgear.org</code>, ATC-pie features an integrated text chat system for ATCs to coordinate off the (public) FG text chat. The choice of IRC and plain text lines was in part motivated by the possibility for users of other clients (e.g. OpenRadar) still to take part via their own IRC client.

The connection is also used to embed special commands, in the form of escaped text lines, starting with <code>___ATC-pie___ </code>, e.g. for strip exchange (handovers) or "who-has" requests. Commands were later added to support CPDLC, which is ready for ACFT to connect. What follows is a description of those CPDLC-related commands.

Note that the IRC nicknames are assumed to match the FGMS network callsigns, so the first line sent after connection is always:
:<code>NICK <callsign>\r\n</code>
Then, from an ACFT point of view, every CPDLC command is sent to the current (or requested) data authority (ATC) via an escaped chat message line:
:<code>PRIVMSG <atc> :___ATC-pie___ <command_line>\r\n</code>

Command lines that an aircraft can send to an ATC are:
* <code>CPDLC_CONNECT</code>: attempt log-on
* <code>CPDLC_MSG <msg_contents></code>: connected CPDLC dialogue message (see below)
* <code>CPDLC_DISCONNECT</code>: connection shut down

Command lines that an aircraft can receive from an ATC are:
* <code>CPDLC_CONNECT</code>: accepted log-on, or new data authority (link has been transferred)
* <code>CPDLC_MSG <msg_contents></code>: connected CPDLC dialogue msg (see below)
* <code>CPDLC_DISCONNECT</code>: connection voluntarily dropped by ATC, or refused log-on

The contents of connected dialogue messages (contained in CPDLC_MSG lines) can be discussed as part of the interface between aircraft and ATC-pie, but for the moment they are of either format below:
* <code>REQUEST <display_text>(<sep_char><encoded_instruction>)*</code>: likely answered with an INSTR msg
* <code>INSTR <display_text>(<sep_char><encoded_instruction>)*</code>: never sent by ACFT, only received
* <code>ACK</code>: acknowledgement/"WILCO"
* <code>REJECT <optional_reason></code>
* <code>TEXT <free_text></code>

== Results ==
We have a proof of concept up and running :)
[[File:Cpdlc-demo.png|thumb|CPDLC demo dialg]]

* Basic IRC protocol has been implemented in C++
* Some dummy CPDLC messages have been successfully passed around
* CPDLC connect/disconnect works, handover to othe ATS unit works
* Inbound CPDLC messages are processed and queued for later display in the cockpit
* A simple PUI dialog interface is available in FGAddon

[[Category:Hackathon 2020 Ideas]]

Controller-pilot data link communication

2020-12-10T16:16:50Z

Mickybadia: Added screenshot

Controller-pilot data link communication

2020-12-10T16:07:58Z

Mickybadia: Starting a clean page for the topic, separate from Hackathon/dev considerations of when this was ramping up

CPDLC

2020-12-10T15:59:47Z

Mickybadia: Redirecting to proper spelt-out name

#REDIRECT [[Controller-pilot data link communication]]