atc.dat File Overview
atc.dat files' main purpose is to provide airspace boundaries for regional, approach and large tower controllers as well as all the other data needed to create a working ATC controller in the simulator. A master atc.dat file is provided with the simulator, giving this information worldwide. Tower controllers which are not defined in atc.dat are created based on the frequencies given in the various apt.dat files with a small generic airspace volume.
atc.dat files may also be provided in custom airport folders, inside a sub-folder named "Earth nav data". This allows for the master file to be overridden, or for new or fictional airports to have non-generic airspace volumes. However, for most airports, providing a custom atc.dat file will be counterproductive since it will block any future updates to the base system data, either as provided by X-Plane or from a subscription service.
If you have subscribed to a commercial navdata service, this will provide an updated atc.dat file along with all of the other data. This copy exists in the same location as the rest of the custom navdata, also under an "Earth nav data" folder. As with the other navdata, X-Plane will use this file automatically if it is present.
The contents of whichever files are read are used by the ATC system, the map, and the included FMS to ensure that data remains consistent across all systems.
Interaction with apt.dat
Any tower controllers defined in atc.dat files are preferred over autogenerated ones based only on frequencies and airport location from apt.dat. While the autogenerated controllers are fine for most smaller airports, any larger airport with a non-trivial airspace boundary will benefit from the more detailed definition possible in atc.dat. This also means that any frequencies defined for tower in apt.dat are overridden by those defined in any atc.dat file. The simulator tracks this and, since X-Plane 12, will always show the actual in-use frequencies in the "Airport" pop-out on the map, and both FMS and ATC will use the same frequencies. This process is used to ensure that the latest controller data from a commercial navdata subscription is fully used. If you wish to enforce a specific set of frequencies for a given airport you can create an airport-specific atc.dat file, but bear in mind that this will prevent updated definitions in the master atc.dat file being used in future. Airspace polygons are optional for tower controllers defined in atc.dat, so detailed airspace boundaries need not be given if you only wish to set tower frequencies.
File Format
As with several other files, a standard header is used which provides a basic ID and a file version number:
A 1000 ATCFILE
After this, one or more controllers are given. These should start with basic information about the controller:
CONTROLLER NAME ALGIERS FACILITY_ID DAAA ROLE ctr ICAO DAAA
FACILITY_ID specifies a unique identifier for this controller; often this will simply be the same as an airport's ICAO code. However, approach and regional controllers are not necessarily based at a specific airport.
An ICAO line, if present, specifies the airport at which this controller is based. This is optional for approach and regional controllers but required for tower controllers.
The ROLE specifies which type of controller is being defined and should be one of the following:
del: Clearance Deliverygnd: Groundtwr: Towertracon: Tracon/approachctr: Regional/center
Generally there is no point in specifying del or gnd controllers in atc.dat since these controller types have no airspace and are always associated with a specific airport. The normal controller creation process, based entirely on the airport’s location and frequencies given in apt.dat, is enough to fully specify these and they are not currently provided as part of any commercial data subscription or in the base atc.dat provided with the simulator.
Next should be one or more frequencies (25kHz) or channels (8.33kHz) on which the controller should transmit:
FREQ 12045 CHAN 119380
It is permitted to mix both FREQ and CHAN lines, and to have multiple of each. Only one frequency should be given per line. If a large number of frequencies are given, the simulator may ignore later ones but there is no other penalty for including many.
For tracon and ctr controllers, and optionally for twr controllers, an airspace volume should be given. This is specified as zero (for twr) or one (for tracon/ctr) or more polygons, where each polygon has an upper and lower altitude in feet AMSL and at least three points in geographic co-ordinates in latitude/longitude order:
AIRSPACE_POLYGON_BEGIN 0 60000 POINT 39.000000 4.666667 POINT 39.000000 4.685000 POINT 39.000000 5.000000 ... AIRSPACE_POLYGON_END
Airspace volumes may not be nested, but multiple may be given. For ground and clearance-delivery controllers, airspace volume definitions are permitted but unused since these controllers have no airspace responsibility. Tower controllers have their airspace checked against the central location of their home airport.
Finally the controller definition may include a "VOICE_DEF" line but this is currently obsolete and ignored.
Each controller definition should end with the line:
CONTROLLER_END
Any errors detected during load of atc.dat files are written to the standard Log.txt logfile.
For a full, detailed example file please see Resources/default scenery/1200 atc data/Earth nav data/atc.dat in your X-Plane installation.
Optional Data
A number of optional entries are available. Most of the time these are only set at the region level, so will not appear in most atc.dat files. Each of these entries is specific to a single controller and must appear with CONTROLLER/CONTROLLER_END pairs.
"SQUAWK <integer>” : Specify which squawk code should be used for non-controlled aircraft i.e. 1200 in the US, 7000 in the UK etc.
"PRESSURE_UNITS <inhg|mbar>" : Specify whether this controller uses US or international pressure units.
"FREQUENCY_STYLE <faa|icao>" : Specify whether this controller uses FAA or ICAO phrasing for frequencies.
"CLASS <A-G>" : Specify the airspace class. Currently unused.
"TRANSITION_ALT <integer>" : Specify a custom transition altitude in feet, often used at airport level in the EU.
"TRANSITION_LAYER_MIN <integer>" : Specify the minimum thickness in feet of the transition layer.
Region Definitions
An additional file in the same format, named "atc_regions.dat", exists. This file creates fictional top-level controllers which are used as a fallback for when no other airspace is defined. They also define the main characteristics of that region which make it distinct from other regions; in other words, any controllers which are centered in a given top-level controller's area will inherit the characteristics of that top-level controller. In general this file should not be edited since all the airspace boundaries are configured to cover the whole globe.
For each of these controllers, the NAME parameter is always given as "TopLevel". There are two additional values which may be set on top-level controllers:
"SPOKEN_NAME <string>" : This is required, and gives the name for both text and speech. Note that matching .wav or .opus files must be given for each supported voice covering the pronunciation.
"ALLOW_FISO <bool>" : Specifies whether this region's airports are treated 100% as fully-controlled, or whether FISO airports are supported.