Getting Started

The radar client interface that vice provides is based on STARS. For familiarity to VATSIM controllers, vice generally follows the keyboard command scheme implemented in CRC's STARS implementation; see the discussion of vice's STARS emulation below for more information.

The first time you launch vice, a window is shown for configuring the simulation. (After the first time, the window can be brought up by clicking the "replay" button in the menubar: .) A number of scenarios are available, some departure-only and some including both departures and arrivals. Here is an example:

After selecting an ARTCC, the available TRACONs and ATCT/TRACONs in that ARTCC are shown. Selecting one of those gives a number of scenarios to choose from. Here the ZNY ARTCC has been selected and then the PHL ATCT/TRACON. After choosing a scenario and clicking the "Next" button, a window with further settings is shown:

In the second configuration window, you can set the airport departure rate (ADR) for all of the airports that may have departures in the scenario as well as the airport arrival rate (AAR) for all of the arrival airports. (The PHL scenario only includes the Philadelphia Airport, though many other scenarios include multiple airports.) Both of these rates are specified in terms of aircraft per hour, so an ADR of 30 corresponds to one aircraft departing every two minutes (on average). If you'd like an arrival-only scenario, for example, just set all of the departure rates to zero.

For arrivals, the "Go around probability" slider allows setting the probability that each arrival goes around. You may also select "Include random arrival pushes", which will periodically bump up the rate of arrivals to increase the challenge of vectoring aircraft. "Push frequency" sets how often arrival pushes happen and "Length of push" sets how long they last before traffic returns to regular levels.

After you have configured the simulation, click "Ok" and you will have a STARS scope and flight strip window to work with. Use the usual STARS commands as appropriate (to initiate track, accept handoffs, handoff to other controllers, etc.), and the additional ATC commands below to issue control commands to aircraft.

After the simulation starts, you may click on the button in the menubar to show a window with information about the scenario, including the active controllers, the departures, arrivals, approaches and overflight routes, and airspace awareness rules. For this PHL scenario, four arrivals, two approaches, and three departures are active. Other scenarios may be more complex.

The approach codes—here, "27R" and "35"— are used in vice's aircraft control commands like "expect approach" and "cleared approach".

To adjust the amount of space used for flight strips, right click the line separating the flight strips from the radar window and drag left or right with your mouse. You can also remove flight strips entirely by opening the settings window, in the menubar, and disabling "Show flight strips" under the "Flight strips" header.

A number of buttons are available in the menu bar at the top of the window:

• / : pause or resume the simulation.
• : opens the window to select a new scenario and set its parameters.
• : open a window that allows changing various settings. The most useful one is the simulation rate: you can speed up time during slow times or to increase the challenge.
• : show the window that lists the currently active departures, arrivals, and approaches.
• : opens a window that shows a summary of vice's ATC commands and frequently-used STARS commands.
• : open a window with controls for launching aircraft, either automatically or manually.
• : open this webpage to review vice's documentation.
• : display information about the version of vice you have installed.
• : join the vice Discord.
• : Toggle full-screen mode.

When you exit vice, it remembers everything going on—all of the aircraft in flight, the instructions they have been given, etc. The next time you launch vice, it loads all of that back in and you can continue where you left off. If you'd like to start something new, just click and configure a new simulation.

When vice is paused, you can hover the mouse above a radar track to see information about the instructions the aircraft has been given so far—for example, altitude and speed assignments, whether it has been sent direct to a fix, the approach it has been assigned, etc. An example is shown below. This information is especially useful when resuming a vice session after you have been away from it for a while.

If you are signed in to Discord, vice can automatically update your activity status there with information about your current vice session (the number of arrivals and departures, the position you're controlling, etc.) When you first launch vice you are given the option to disable this feature if you would like. The settings window, available by clicking in the menubar, can also be used to enable or disable this feature.

Drawing Routes

vice can draw the active departures, approaches, and arrivals for the current simulation. This can be helpful when studying those for an airport, since they are drawn directly on the radar scope with annotations that give the fixes, any altitude or speed restrictions, and procedure turns.

To toggle whether a route is drawn on the scope, click the checkbox on the left next to it in the information window that is shown at the start or after clicking on the button in the menubar. For example, here is how the HVN RNAV Runway 2 approach is rendered:

We can see the procedure turn at PEPER and that it is both the IAF and the IF; altitude restrictions at both SALLT and PEPER, that SALLT is the FAF, and that arrivals from KEYED will not fly the procedure turn.

Launching Aircraft

When a new simulation starts, vice automatically launches new departures and arrivals based on the departure and arrival rates set in the "New Simulation" window. During a simulation, clicking on the departing plane icon in the menubar opens a window that allows more control over aircraft launches and also for issuing releases for airports where "hold for release" is in effect.

The rates for automatic launches can be adjusted in this window. Alternatively, aircraft can be launched manually. If manual launches are selected, the window shows all of the available departure runways and exits as well as all of the arrivals, as shown below. Clicking the aircraft icon for a departure or arrival causes the aircraft shown to be launched. If you'd like a different aircraft for the next launch (for example, to have a heavy aircraft), click the redo icon until you're happy with the selection. The window also shows the elapsed time since the launch of each type as well as how many miles in trail (MIT) there would be if the next aircraft was launched. To delete all of the aircraft from the simulation and restart, click the trash icon: .

Multiple Controllers

With vice you can also have multiple controllers working aircraft together. Select "Create multi-controller" in the "New Simulation" window and you can select an ARTCC, ATCT/TRACON, and scenario in the same way that you do with a single controller. For multi-controller scenarios, there are some additional settings, shown beneath the list of scenarios:

Each multi-controller simulation has a name associated with it; vice chooses a random one by default (above, it's "choice-length"). You're welcome to choose a different name if you prefer. These names can be used so that you can tell other people which simulation to choose in order to join you. You may also enable "Require password" and enter a password for the simulation so that only people you allow can join it.

Selecting "Join multi-controller" shows a list of the simulations that are currently available, including how many controllers are signed into each one. Note that the simulation names are shown in the first column. After selecting one, you can choose one of the available control positions and join. vice also allows you to join a simulation as an observer, in which case you have no control capabilities.

ATC Commands

A variety of instructions can be issued to aircraft by an aircraft controller. To issue an instruction, first press the [TAB] key. This will place the STARS radar into "target generation" mode and the characters "TG" will appear above the text input area (which is by default on the left side of the STARS window, towards the top.

The commands below can then be entered to issue control commands to aircraft. As you enter commands, they will be shown in the STARS input area. You can correct errors with the backspace key or press the [ESCAPE] key to exit target generation mode.

To indicate which aircraft should be given a command, you can either enter a command and click on an aircraft's radar track in the STARS window or you can enter the aircraft's callsign followed by a space before the command, and then press the "enter" key. You can also give just the callsign suffix, if that is enough to unambiguously identify a single aircraft. The callsign of the last aircraft you issued to a command to is shown after "TG" when target generation mode is activated. If you'd like to give another instruction to that aircraft, you can skip entering its callsign. Entering another aircraft's callsign causes the command to be issued to that aircraft instead.

After you issue a command, the virtual pilot's readback is shown in the readback window below the STARS window. After receiving an instruction, the aircraft will start following that instruction, to the best of its abilities. Unlike VATSIM, the pilots will always do exactly what you tell them to.

If you'd like to issue multiple commands to an aircraft at once, enter the commands one after another with a space between them. To open a window that shows the available ATC commands when using vice, click the button in the top menubar.

Windows

To install vice on Windows, download and launch the installer below. After installation, vice will be available in the Windows Start menu and a shortcut will be added to your desktop.

Macintosh

On a Mac, download the zip file below; it contains a universal binary that runs on both Intel and Apple CPUs. Note that MacOS Big Sur or a more recent version of OSX is required. After opening the zip file, drag Vice.app to your Applications folder to install it.

Linux

On Linux systems, it is necessary to install vice from source. See the directions on building vice on Linux in the source code distribution for details.

Reporting Bugs

If you encounter bugs in vice, apologies! It would be of great help if you would send in a report if vice crashes or if you see mistakes in how it simulates aircraft or the STARS interface.

The best way to report bugs is via the "bugs" channel on the vice discord. Alternatively, if you have a github account, you can file bugs directly in vice's issue tracker.

Release History

0.11.10 (15 April 2025)

• New scenarios: GTF (Merry), PCT SHD (Ketan K).
• Scenario updates: JAX (Jud Lopez), LIB (Matt P), CLT (agnuse), DCA (Ketan K), A90 (radarcontacto).
• Fixed a bug where wind gusts would cycle between the gust windspeed all the way down to zero wind.
• Fixed a bug where handoffs between virtual controllers during aircraft prespawn would never be accepted.
• STARS:
  • Fixed a bug where the partial datablock for a track would sometimes be drawn after a handoff was accepted before the controller clicked the track to switch from the FDB.
  • Fixed drawing of PREF submenu.
  • Fixed a few bugs with entering values with the keyboard after selecting DCB buttons.
  • Various improvements to improve performance with many tracks on the screen.
• Facility engineering:
  • Routes can now contain lat-long coordinates in the form 4900N/05000W.
  • Routes can now have /shift after a fix to signify that the location of the fix should be randomly shifted by a given distance before or after the fix.
  • Routes can now have /ph after a fix to signify fly present heading after the fix.
  • Routes can now have /tc after a fix to signify that communications should be handed off at the fix; this is useful for aircraft where control has been flashed from a virtual controller to a human controller earlier but where the virtual controller will continue to control the aircraft for a while before having them contact the human.

0.11.9 (22 March 2025)

• New scenarios: SCT Del Rey, ABQ (Ketan K), ISP (Thomas Halpin).
• Scenario updates: BOS, F11 (radarcontacto), SCTLA, DelRey, SNA, ONT, SAN, BUR, SBA, NCT (Ketan K), SCT, A80, F11, C90 (Jud Lopez), D01 (Andrew S, Jud Lopez), P80 (Ethan Malimon), JFK, ABE, PHL (Matt Pharr), EWR (aq86), D10 (anguse).
• Vice now supports random VFR distractor aircraft (only added to some scenarios so far).
• Improved realism of hold for release aircraft spawning.
• Fixed bugs with intercepting the final approach course for some (unusual) approaches.
• Fixed some bugs where reserved beacon codes would be issued automatically.
• Fixed a bug that would sometimes prevent departures from climbing to obey upcoming altitude restrictions.
• Added "dark mode" for flight strips.
• Added commands for "squawk standby": SQS, "squawk on": SQON, and "squawk altitude": SQON.
• STARS:
  • Reworked TGT GEN for entering aircraft commands: [Tab] can now be used to enable it.
  • Added commands to enter pilot-reported altitude for altitude that aren't squawking altitude.
  • Added commands to specify beacon code banks.
  • Added support for Mode C intruders, including suppression and the system list.
  • Multiple improvements to the specifics of handling unassociated tracks (now that VFR gives us many more of them).
  • Reworked how DCB submenus are drawn to be more realistic.
• Facility engineering:
  • Added "custom_spcs" in "stars_config" to allow specifying facility-specific special purpose codes that aircraft can have assigned to them. There is also now "display_custom_spcs" under the "pdb" adaptation in "stars_config" to determine whether such SPCs are shown in partial datablocks.
  • Added "beacon_code_blocks" to "controller_configs" to allow specifying per-controller default monitored beacon code blocks.
  • STARS now has a .VFR command to toggle whether the VFR airports are shown on the scope and a new .DRAWROUTE command for drawing complex routes.
  • For "atpa_volumes", an optional string "id" may be given for the name of the volume in the STARS SSA INTRAIL list item.
  • Added "departure_runways_as_one" to airport definitions to allow treating groups of runways as a single unit for departure sequencing purposes.
  • Added commands to set and clear scratchpads at fixes in routes (for virtual controllers).
  • An error is issued if "scope_char" is set for a controller but it specifies the value that vice would have chosen automatically.

0.11.8 (19 February 2025)

• New scenario: SBA (Ketan K).
• Scenario updates: SAN, BUR, NCT, L30 (Ketan K), EWR, JFK (Mike LeGall), JAX (Jud Lopez), D01, GJT, ASE, COS (Andrew S), MDT (Allison L), BOS (radarcontacto).
• Aircraft can now intercept the approach for non-ILS approaches.
• Multiple fixes to the server that should reduce memory use and make the server more robust.
• There's now a few minutes delay before takeoff for released "hold for release" aircraft.
• Aircraft will now intercept an approach if they are direct to a fix on it.
• Fixed bug where overflights would be climbed to their cruising altitude.
• Aircraft wait 5-10 seconds before changing their beacon codes when a new one is assigned.
• Fixed bug where departures would climb prematurely.
• Aircraft that are too high when they cross the threshold go missed.
• Fix bug with delayed descents when aircraft are cleared for the approach after being told to intercept.
• UI: rework table layouts for departure/arrival rates to be more compact.
• An audio alert can now be optionally played when aircraft check in or transmit radio messages.
• Props now lose a bit of speed in climbs.
• A notification sound can now be played when aircraft transmit on the radio or first call in.
• STARS:
  • Multiple bug fixes to how point outs are shown
  • Flash "DB" in data blocks for duplicate beacon codes.
  • Fixed bug where altimeter would not be shown for airports in "altimeters" under some circumstances.
  • Controllers can now take control of point outs via [HND OFF][SLEW]
  • Point outs can now be recalled by slewing the target.
  • Fix WX blocks to be 0.5nm wide.
• Facility engineering:
  • All approaches must have a fix denoted as the FAF via /faf.
  • "VOR" and "Localizer" may now be given for the "type" of approaches.
  • /hoID may be given after a fix in a route to cause the aircraft to be handed off to the given controller id at that fix. (Mostly useful for aircraft controlled by virtual controllers.)

0.11.7 (31 January 2025)

• New scenarios: MDT (Allison L), PVD (radarcontacto).
• Scenario updates: DCA (radarcontacto), SCT (Aiden), JFK airspace (Mike LeGall), Y90 (Merry), L30, NCT, P80, SCT, SDF (Ketan K).
• Airspace boundaries are now displayed using the scenario information window (displayed by clicking in the menubar.)
• Improve fetching of airport weather (Makoto Sakaguchi.)
• Fixed a bug that was causing vice to crash when loading saved sims.
• Fixed a bug where "expedite" would be refused incorrectly.
• Fixed a bug where departures would climb beyond upcoming altitude constraints in SIDs.
• Fixed a bug where aircraft would incorrectly descend along an approach they weren't yet cleared for.
• Fixed multiple bugs with the launch control window.
• Removed text input from the messages pane: it's back to just printing radio calls and messages.
• Updated handoffs so that there is a delay of 5-10 seconds before aircraft call in after the track is accepted. Note that you can't give control instructions to an aircraft until they call in and are on your frequency.
• STARS:
  • Continue to display the id for external facility handoffs in datablocks for a few seconds.
  • Improved the accuracy of the mapping of precipitation to WX levels.
  • Allow selecting "," as an alternative to ";" for TGT GEN.
  • Departures are now auto-tracked by default.
  • Improve representation of SPCs (Makoto Sakaguchi.)
  • Improve handling of altimeters in SSA list: don't draw more than 6, allow developer to specify the ones to draw via "altimeters" in "stars_config" if there are more than 6.
  • When a partial callsign is given to specify an aircraft to be given an instruction, it must be a unique suffix of an aircraft callsign; we no longer accept a prefix or the middle part of a callsign.
  • OJTI mode now available where an instructor can issue aircraft control commands (Michael Trokel).
• Facility engineering:
  • New adaptations under "stars_config": "handoff_acceptance_flash_duration" gives the number of seconds datablocks flash after an accepted handoff, "handoff_sector_display_duration" gives the number of seconds the external sector id is displayed after a handoff, and "display_handoff_facility_only" inhibits the display of external facility sector ids in datablocks.
  • Airspace is now specified per-controller rather than being classified as departure/approach airspace.
  • In controller specifications, "full_name" is now "radio_name" to better reflect its use.
  • "/clearapp" can be added after a fix in a route to cause aircraft to be cleared for the approach at that fix. (Useful for ambient traffic under computer control.)
  • An error is now issued if more than one controller has the same sector id assigned.
  • Fix parsing of both approaches and altitude constraints in the ARINC424 data (Makoto Sakaguchi.)
  • Updated to latest AIRAC cycle.
  • Fixed a bug with Δ in scratchpad assignments in scenario definitions.
  • "tower_controller" is no longer included in approach definitions.
  • Expanded the magnetic declination database to include Japan and Puerto Rico.

0.11.6 (22 October 2024)

• New scenario: LGA HAARP (Tyler T).
• Scenario updates: CHS, F11 (Michael Knight), SCT, C90, MKE (Jud Lopez).
• Updated how aircraft control instructions are entered: press ; to enable "target generation" mode in STARS, after which control commands can be entered.
• Fixed a bug where aircraft that went around after being handed off to tower wouldn't contact tower the next time.
• Fixed a few bugs related to the 250kts speed limit at 10,000'.
• Added more compact "hold for release" interface for airports that don't use STARS coordination lists.
• STARS:
  • Added OJTI mode, where an instructor can sign in and issue commands to all aircraft, regardless of which controller is responsible for them.
  • Added support for restriction areas. System restriction areas are automatically generated based on the current FAA TFRs.
  • Multiple improvements to video map handling, including supporting multiple colors and map categories. (Currently only available through dat2vice.)
  • CA and MSAW alerts are no longer generated for unassociated tracks.
• Facility engineering:
  • It is no longer required that all runways have routes for all exits.
  • "arrival_groups" is no longer supported: arrivals must be specified using the "inbound_flows" variable.
  • "star" is now optional for arrivals; the pilot contact message has been improved for arrivals not on STARs.
  • Added an adaptation ("yellow_entries") for coordination lists that causes list entries to be yellow, not green.
  • Added an adaptation ("use_legacy_font") to "stars_config" to select the legacy STARS font. (The font used can also be selected in the "settings" window.)

0.11.5 (20 September 2024)

• New scenario: SGF (Tyler T).
• Scenario updates: D10 (Austin Jenkins), EWR (Mike LeGall), CID (Tyler T), D01, COS (Andrew S), AAC.
• Massive update to the aircraft performance database (EkimWasHere).
• The virtual local controllers now actively try to sequence departures well, including getting wake turbulence separation right.
• Multiple improvements to the aircraft flight model, including better handling of 250kts at 10,000', more realistic climb/descent and acceleration/deceleration profiles.
• STARS:
  • Added support for coordination lists (used for "hold for release").
  • Added support for significant points, including *F command to show bearing/distance to them.
  • Fixed a number of small errors in system lists.
  • Improved handling of preference sets: a separate one is stored for each TRACON.
• Multiple improvements to the accuracy of flight strips.
• Added global scale controls for departure and arrival/overflight rates.
• Facility engineering:
  • Added "scratchpad1" adaptation to "stars_config", providing 4 preset scratchpad formats for departures.
  • In "expect_approach" in STARs, different approaches can be specified depending on the destination airport.
  • An array of altitudes may be specified for departures and overflights; one will be chosen at random for each aircraft.
  • For GA ("n" airline) aircraft, "GAsinglepiston", "GAmultipiston", and "GAturbine" fleets are now available.

Key Concepts

Aircraft are shown on the STARS scope as radar tracks; a datablock next to them shows the aircraft's callsign and additional information about it. A leader line connects the radar track to the datablock. Here is an example:

Here we see the datablock showing the aircraft's callsign, LXJ137, its altitude in hundreds of feet (040) multiplexing with its destination airport (CDW), and its groundspeed in tens of knots (28) multiplexing with its aircraft type, CL30. The "H" after groundspeed is the aircraft's consolidated wake turbulence (CWT) category—upper small. (See the section on datablocks for extensive documentation of datablocks and the information that they may show.)

The blue circle shows the aircraft's current position and the purple circles show its course over the past 25 seconds; we can see that it is flying to the Northeast. Finally, the "P" in the middle of the circle (the position symbol) indicates which controller has owner of the aircraft's track.

A single controller may own an aircraft's track and a single controller may own control of an aircraft. The same controller may own both or two different controllers may the track and control. A controller must have control of an aircraft in order to issue instructions to the pilot. See the discussion of Track Ownership below for more information about how control and track ownership are transferred between controllers.

Each controller in the terminal environment is responsible for at least one terminal control position (TCP). (A single controller may cover multiple positions when multiple positions have been consolidated.) Each TCP is identified by three characters:

• The first character gives the facility; more or less the TRACON or ATCT/TRACON where the position is located.
• Facilities are split into multiple areas; the second character which area the TCP is in.
• Finally, each area is split into sectors; these are denoted by the third character.

Consider for example the N4P TCP: the N indicates the N90 (New York) TRACON; the 4 is for the fourth area (which is the Newark area) of N90; finally, the P is the Yardley sector of the Newark area.

Other controllers, both real and virtual, may be signed in when you're running a vice scenario. The list of controllers is available in the "Controllers" drop-down in the scenario information window. Among other useful information, it shows the TCP identifier associated with each controller and whether the controller is human.

Entering Commands

Some STARS commands are entirely keyboard based: you enter a command and hit the [ENTER] key to issue the command. As you type, your input will be shown in the input area, which is by default on the left side of the screen. Entering a space starts a new line. To edit your input, the backspace key can be used. Alternatively, pressing [ESCAPE] clears the input and any errors that are displayed.

Many STARS commands involve selecting an aircraft that they apply to; in STARS this is called "slewing" the aircraft. To slew an aircraft in vice, click on its radar track with the left mouse button. You will often enter a command with the keyboard and then slew an aircraft; if the documentation below, [SLEW] indicates that an aircraft should be slewed to execute the command.

Many STARS keyboard commands take additional parameters such as a number or the name of an airport. These will be shown in parenthesis with the number and type of character expected. Thus (#) indicates that a single digit should be entered, without any parenthesis. Similarly, (ABC) indicates that three letters are expected.

For commands that take runways, (RWY) will be used. Runways are specified with their number and then, if required, "L", "C", or "R" to distinguish between parallel runways. Runways numbered 9 or less should not have a leading zero. (AIRPORT) denotes an airport given to a command; airports should be specified using three letters, dropping the leading "K".

Many keyboard commands take an aircraft identifier, which will be denoted (ACID) in the following. The aircraft identifier may be given as either the aircraft's complete callsign, e.g., "UAL650", or as the aircraft's beacon code. Some commands also take a tab list identifier, which is a number from 0–99 that is associated with aircraft that are displayed in system lists like coordination lists.

It is also common for commands to take identify a controller using the controller's ID (e.g., the TCP for a terminal position). In the following documentation, (CID) indicates such a controller id. There are a number of rules that define how these are specified; they are discussed in more detail below.

The STARS keyboard has a number of custom keys that are not present on standard keyboards. In the following documentation, when one of the STARS keys in square brackets below is shown, the corresponding regular keyboard key should be entered.

When issuing a command leads to an error, STARS prints an abbreviated message above the input area. These are the error codes that vice currently uses:

Specifying Controllers

A number of STARS commands take controller IDs to specify other controllers; examples include handoffs and point outs. The following rules apply to them:

• For pairs controllers in the same facility, the full TCP may be entered, or the facility may be omitted and only the area and sector given. Thus, for a handoff from Yardley, N4P, to LaGuardia departure, N1L, the Yardley controller could specify 1L for LaGaurdia departure.
• If the other controller is in the same area of the same facility, then only the sector needs to be entered: for example, N4P can hand off to N4A, the Newark North arrival position, just by specifying A for the TCP.
• For TCPs outside of the facility, the delta (∆) symbol must be specified before the TCP; in vice delta is mapped to the backtick key. The full three-letter TCP may be given, though the area and sector may be omitted if the facility only has one TCP.
• To handoff to an enroute controller, the enroute facility identifier and sector must be provided; enroute sectors are identified by two-digit numbers. For the home ARTCC, the facility identifier is generally C, unless a neighboring ARTCC's facility identifier is "C", in which case the facility identifier for the home ARTCC changes from a "C" to the regular facility identifier. Thus, for ZNY, "N" is used rather than "C". The sector may be omitted if there is only one enroute controller signed on.
• For handoffs, airspace awareness rules may be provided in the scenario definition; these are rules that associate specific controllers with departing aircraft based on their altitude, the fix they are flying to, and possibly their aircraft type. When such a rule applies to an aircraft, a handoff to a corresponding enroute controller can be initiated simply by entering the enroute facility identifier, without the sector. For a handoff to a controller in a neighboring facility where an airspace awareness rule applies, just ∆ and the facility id are sufficient.

The airspace awareness definitions in a scenario can be found in the scenario information window, accessed by clicking in the main menu bar.

The following STARS commands offer further control over how airspace awareness is applied:

The Cursor Home and Hiding the Cursor

After a keyboard command is entered, the STARS cursor may be optionally returned to a "home" position and hidden. It will then reappear when the mouse is moved. The "CURSOR HOME" button in the auxiliary DCB menu can be used to toggle this behavior. If not specified using one of the following commands, the default home position is at the upper-left of the SSA list.

Quick Reference

For basic controlling, a small number of STARS commands are used frequently. The following table lists them and gives a short description of their operation.

The DCB

The display control bar (DCB) is a menu that is shown by default at the top of the STARS window. Many aspects of STARS's behavior can be configured using the DCB.

There are four types of buttons in the DCB:

• Toggle buttons: these enable and disable various features. When enabled, they have a lighter color than usual and appear depressed (like the "OFF CNTR" and "WX 3", "WX 4", and "WX 5" buttons above.) Clicking them toggles whether they are enabled.
• Menu buttons: when clicked, they replace the contents of the DCB with those for another DCB menu. For example, clicking "MAPS" from the main DCB brings up a menu for configuring which STARS video maps are displayed.
• Spinners: these allow setting various STARS parameters using the mouse wheel. For example, clicking "RANGE" allows setting the radar's range in nautical miles. Spinners capture the mouse and don't allow the cursor to leave their button until the user either clicks the mouse or presses the [ESCAPE] key. When a spinner is active, it is also possible to enter a new value for it using the keyboard and then pressing [ENTER].
• Disabled buttons: these are shown in dark grey and represent STARS functionality that is not currently available in vice.

DCB submenus generally have buttons that return to the main DCB menu—look for a button labeled "DONE" or "SHIFT". Alternatively, pressing the [ESCAPE] key will return to the main DCB menu.

The main DCB menu offers the following controls:

• RANGE: sets the range of the radar scope (see STARS Configuration).
• PLACE CNTR/OFF CNTR: controls to set the center point of the radar scope (see STARS Configuration).
• RR/PLACE RR/RR CNTR: controls for range rings that are shown on the display
• MAPS (and the six buttons to the right): controls the visible video maps.
• WX*: controls which levels of weather intensity are displayed.
• BRITE: controls the brightness of various elements on the display.
• LDR DIR/LDR: configures leader lines from radar tracks to data blocks.
• CHAR SIZE: sets the character size for various elements on the display.
• PREF: allows loading and saving STARS preference sets.
• SITE: configures which radar sites are active.
• SSA FILTER/GI TEXT FILTER: configures which elements of the System Status Area list are displayed.
• SHIFT: displays the auxiliary DCB menu (documented below).

Here is the auxiliary DCB:

Many of its buttons are disabled; the enabled ones are:

• VOL: controls the volume of STARS audio alerts. A short test sound is played when it is changed.
• HISTORY: sets the number of dots drawn showing the aircraft's radar track history.
• H_RATE: sets the rate in seconds that a new dot is added to aircraft history trails.
• CURSOR HOME: controls whether the cursor is hidden and returned to home position after a keyboard command is entered.
• DCB LEFT/RIGHT/TOP/BOTTOM: sets the side of the radar scope where the DCB is displayed.
• PTL LNTH/PTL OWN/PTL ALL: controls Predicted Track Lines (PTLs).
• DWELL: enables or disables dwell mode.
• TPA/ATPA: displays a submenu to configure terminal proximity alerts (TPAs) and automated TPAs.
• SHIFT: returns to the main DCB menu.

Press the [DCB] key (control-F8) to toggle whether the DCB is visible.

Track Ownership

Controllers must both own an aircraft's track and have control of the aircraft in order to issue instructions to the aircraft's pilot. Managing ownership of tracks and control of an aircraft is at the core of how multiple controllers work together to control an aircraft; it is crucial that controllers hand off both the track and control of an aircraft before it enters another controller's airspace.

Untracked Aircraft

When an aircraft departs an airport, its track and control may not be owned by any controller. VFR aircraft may also enter a controller's airspace without being tracked; these are known as unassociated tracks since there is no flight plan associated with them. These aircraft have a limited datablock, which only shows the aircraft's altitude in hundreds of feet. The datablock is drawn in green indicating that the current controller does not own it, and the asterisk shown in the position symbol at the center of its track (the blue dot) also indicates that its track is unowned.

If an unassociated track's transponder is turned off, it appears with a plus sign in its position symbol and no altitude is shown; such a track is also referred to as a primary-only or primary track, since no secondary information is returned by its transponder. If its transponder is on but it is not squawking altitude, a diamond is used for its position symbol. Here are some examples.

   

After a controller has tracked a departure, departures will contact the controller on the radio; look for a message in the input window below the STARS scope:

A controller can initiate track of an uncontrolled aircraft track using the following commands:

For departures, you may disable the "Auto track departures" checkbox in the "Settings" window to not automatically initiate track on the departing aircraft that you are responsible for in the current scenario.

When you own an aircraft's track, the datablock becomes white a full datablock and the letter corresponding to your position's TCP (here, "G") will appear at the center of the radar track.

Note that you can not issue control instructions to an aircraft unless it is on your radio frequency. If you track a departure before it contacts you, it is still under the tower's control and tuned to the tower's radio frequency. Once the (virtual) tower controller tells the aircraft to "contact departure", they will check in with a message on your radio frequency. It is at this point that you also have control of the aircraft and can start issuing control commands to it.

Inbound Handoffs

Aircraft entering your airspace will be generally owned by another controller (human or virtual) before they are handed off to you. Initially, they are displayed with a partial datablock that shows altitude in hundreds of feet, groundspeed in tens of knots, and the scratchpad, if set. Often it is a center controller who owns the aircraft and a "C" will be displayed for the position id, as in the example below:

The controller who owns the aircraft's track may eventually hand it off to you; at this point, the datablock will turn white, start flashing, and change to a full datablock as shown below.

The datablock will continue flashing until you accept the handoff by slewing the aircraft's radar track using one of the following commands:

After a handoff is accepted, the aircraft's datablock will stop flashing and remain white. However, as with departures, you do not have control of the aircraft until the other controller instructs the aircraft to contact you, transferring control as well. After the aircraft contacts you on the radio, you may start issuing control instructions to it.

Outbound Handoffs

When you are ready to hand off an aircraft's track to another controller, a number of commands are available to do so:

(For these commands, determining the correct controller ID to enter has a few subtleties and is discussed further below.) The datablocks of outbound handoffs have an identifier for the target controller stuffed into the second line of the datablock, four characters in. For JBU52 below, it is "V", corresponding to the intrafacility position "1V" that the aircraft is being handed off to, and for TAM9021, it is "C", corresponding to a center position. For handoffs outside the facility (including to center), the position identifier is shown in the datablock multiplexed with the altitude and scratchpad (it is "N86" for TAM9021.)

After the other controller accepts the handoff, control of the aircraft's track is transferred to them. The aircraft's datablock will start flashing to notify you of this and the letter on the track will switch to be the other controller's. After a few seconds the datablock will stop flashing. Note that at this point you still retain control of the aircraft and can issue control instructions to it since you haven't yet transferred control to the other controller.

When you are ready to transfer control of the aircraft to the controller who has accepted the track, enter the FC command in the command input window and slew the aircraft. This will instruct the aircraft to switch frequencies to the next controller. Clicking on the track of an aircraft that has been handed off causes the datablock color to switch to green; this can be used to remember that you have transferred communications of an aircraft to the other controller.

Redirecting Handoffs

An incoming handoff can be redirected to another TCP by entering the TCP's ID and slewing the aircraft, just as if you owned the track and were handing it off. Doing so will add RD to the datablock shown to the handoff initiator and the redirector, and show the TCP to where the track was redirected to. This also turns the datablock green for the redirector. Here is a datablock for a redirected handoff as seen by the original handoff initiator; we can see that it has been handed off to the "X" TCP at the facility.

Redirected handoffs can be canceled using the same commands as are used for canceling regular handoffs.

Terminating Control

In addition to handing off tracks to other controllers; a controller may terminate control, otherwise known as "radar services terminated, frequency change approved". The following commands are available:

Point Outs

Point outs let controllers direct another controller's attention to an aircraft; some facilities may have prearranged coordination procedures where an aircraft may pass through another controller's aircraft after a point out, or a point out may be performed before verbally coordinating with another controller. The following commands are available for point outs:

An outbound point out is shown on the originator's scope with "PO" to the right of the aircraft id, followed by one character identifying the other controller's TCP. (Here, "B", for TCP 1B.)

An inbound point out causes the corresponding aircraft's datablock to switch to a FDB and flash yellow, with "PO" shown after the aircraft id.

Clicking on a point out acknowledges it. This causes the datablock to stop flashing but leaves the datablock yellow. A second click reverts to a green datablock, but leaves it as a FDB. A third click will then change back to a regular green PDB.

On the originator's scope, an accepted point out causes a flashing "PO" to appear to the right of the aircraft id for a few seconds.

An inbound point out can be rejected by entering UN[SLEW]; a flashing "UN" is shown to the right of the datablock on the originator's scope in this case.

Track Information

Much information is encoded in the radar track symbol of an aircraft and the datablock displayed next to it. STARS provides many different ways to configure how this information is presented in an effort to balance providing the necessary information about aircraft that are important to a controller while minimizing the visual clutter from aircraft that are less relevant.

Track Symbols

The location of each aircraft visible to RADAR is shown using a primary target symbol. Which shape is used for the symbol depends on which RADAR mode has been selected and which RADAR sites are active. FUSED is the default radar mode, in which case a small blue circle is used for aircraft tracks, as in the examples so far.

In MULTI mode, a small blue rectangle is used in place of the circle and the rectangle is oriented based on the aircraft's heading; this example is flying in a northeasterly direction:

In SINGLE mode, a blue rectangle is also used, but the size of the rectangle varies based on how close the track is to the RADAR site and the rectangle is oriented toward the RADAR site rather than according to the aircraft's heading. The track is bigger the farther away it is from the RADAR site, which helps show the degree of uncertainty in its position. SINGLE mode also includes a green line on the far side of the track with respect to the RADAR site's position. This track is 50 miles from the RADAR site so has a relatively large rectangle, and the RADAR site is to the East, so the green line is on the left:

In SINGLE mode, if the aircraft is very far from the RADAR site, only the outline of the blue rectangle is shown.

The brightness of track symbols is controlled using "PRI" in the DCB BRITE menu.

Track History

STARS can draw a trail of small purple circles behind a track to show its prior path. The number of circles drawn and the time between adding a new circle to the trail is set using the HISTORY and H_RATE buttons in the auxiliary DCB:

HISTORY sets the number of history dots; it may range from 0 to 10. Here is a track with a full complement of 10 history dots:

H_RATE sets the time in seconds before STARS tries to add another history dot. Note that after this time passes, STARS does not immediately add another dot; rather, it waits until the next RADAR position is received for the aircraft. Under FUSED RADAR mode, positions are received every second, and under MULTI and SINGLE modes they are received every 5 seconds. Thus, for example, under FUSED mode with a H_RATE of 4.5, a new history dot is added every 5 seconds: STARS waits 4.5 seconds since adding the previous dot, which by definition occurred when a new RADAR position was received. When the next arrives in 0.5 more seconds, a dot is added, leading to a 5 second overall rate.

The brightness of track symbols is controlled with "HST" in the DCB BRITE menu.

Position Symbols

All tracks have a single-character position symbol at their center that indicates which controller owns the track. Position symbols are determined as follows:

• If the track is owned by a controller in the current controller's facility, the controller's sector ID is used. (For example, if N4P is the current controller's TCP, an aircraft controlled by N1V would be shown with an "V".
• If the track is owned by a terminal controller in an adjacent facility, the facility id is shown.
• If the track is owned by an enroute controller, either "C" or the enroute facility ID is shown.

The brightness of track symbols is controlled using "POS" in the DCB BRITE menu.

For unassociated primary tracks that are not squawking altitude, the triangle that is normally drawn for their position symbol can be disabled.

For unassociated tracks that do have functioning transponders, is also possible to select individual beacon codes or beacon codes blocks; unassociated aircraft squawking matching beacon codes are then displayed with different position symbols than the usual. By default, all 12xx beacon codes are handled this way. In that case, aircraft not squawking altitude are drawn with a triangle position symbol and those that are are drawn with a square.

Datablock Types

There are three datablock formats that may be used, depending on circumstances: limited datablocks (LDBs), partial datablocks (PDBs), and full datablocks (FDBs)s.

Limited Datablocks (LDBs)

Limited datablocks are shown when a target is not tracked by a TCP. By default, they only display the altitude's altitude in hundreds of feet, though if the track is slewed, they display the aircraft's assigned squawk code and groundspeed for a short period of time.

A few commands are also available to control the display of squawk (beacon) codes in LDBs:

The brightness of LDBs is controlled using LDB in the DCB BRITE menu.

If you're searching for an unassociated aircraft squawking a specific beacon code, the beacon code display command can be used to cause all aircraft squawking that code to flash it in yellow in their limited datablock.

Partial Datablock (PDBs)

Partial Datablocks are associated datablocks that are owned by another controller. They show the aircraft's altitude and groundspeed (in tens of knots), followed by a letter indicating its consolidated wake turbulence (CWT) category; see below for more information about CWT. The altitude may alternate with the aircraft's scratchpad or destination airport, as in the example below:

Some STARS facilities use variations on the above PDB format: they may also include the secondary scratchpad, time-share the aircraft type with the groundspeed and CWT category, not include the groundspeed, or show the groundspeed and CWT category separately.

Slewing a PDB converts it to a full datablock; a second slew returns it to a PDB.

The brightness of PDBs is also controlled using LDB in the DCB BRITE menu.

Full Datablock (FDBs)

Full datablocks provide the most information about aircraft; at minimum, they show the aircraft identifier (i.e., its callsign), its altitude in hundreds of feet, its groundspeed in tens of knots, a letter denoting its CWT category, and the aircraft type. Groundspeed and CWT category alternate with the aircraft type, as shown here:

Various other information may be present in a FDB. Here we see the primary scratchpad "L30" and the secondary scratchpad "DEP" alternating with the altitude, where a "+" after "DEP" indicates that the secondary scratchpad is shown. We also see a temporary, controller-assigned altitude of 12,000 feet indicated by "A120" in the third line.

The brightness of FDBs is also controlled using FDB in the DCB BRITE menu.

The FDB is displayed for a track if any of the following is true:

• The track is owned by the current controller.
• The track is being handed off from another controller to the current controller.
• The track is a redirected handoff where the current controller has either redirected it or had it redirected to them.
• Another controller has pointed out the track to the current controller and the point out hasn't been cleared.
• The user has clicked on a track owned by another controller.
• The track is owned by a controller whose sector id the user has quicklooked.
• The track has been force quicklooked to the current controller by another controller.
• "Quick look all" has been enabled by the controller.
• The aircraft is squawking a special purpose code (e.g., 7700 for an emergency) or if it has an active safety alert (e.g., low altitude).

A command is also available to control whether the FDB is displayed for overflights that are not under the user's control:

"Beaconator"

The "beaconator" feature is enabled by holding the F1 key on the keyboard. In full datablocks, it causes the aircraft id to be replaced with the code the aircraft is squawking. Partial datablocks show the sqwawk code in the first line, and limited datablocks show the squawk code and aircraft id. Here is an example of all three types of datablock, alternating with the beaconator enabled and disabled.

Datablock Control Commands

Additional Datablock Entries

A number of additional useful pieces of information can be found in datablocks, depending on the circumstances.

Scratchpads

In STARS, scratchpads are used to convey information to controllers—for example, the departure exit gate, or an assigned approach. Each aircraft has a primary scratchpad and a secondary scratchpad. Either may be set independently. Scratchpads are three characters by default, but may be four at some facilities. They may contain letters, numbers, plus signs, periods, delta symbols, forward slashes, and asterisks, though they may not contain three numbers. The following commands can be used to manage scratchpads:

In PDBs and FDBs, the primary scratchpad multiplexes with the aircraft's altitude. The secondary scratchpad is only shown in FDBs, where it also multiplexes with the altitude and primary scratchpad, if set; it also has a plus sign displayed after it in the datablock. In the example below, the aircraft has "I2L" for its primary scratchpad and "SS" for its second.

Ident

If a controller has instructed an aircraft to ident, a flashing "ID" will appear in its datablock. In FDBs, "ID" replaces the CWT category next to the airspeed and the aircraft type is temporarily no longer displayed. LDBs display the aircraft's squawk code and "ID" for identing aircraft, and PDBs display "ID" at the end of the second line of the datablock.

Temporary Altitude

In order to help remember the altitudes they have assigned aircraft, controllers may associate a temporary altitude with each aircraft under their control. Temporary altitudes given in hundreds of feet and are shown on the right side of the bottom line of FDBs; here, we can see that AAL929, currently at 3,700', has been assigned a temporary altitude of 3,000'.

Two commands are available to manage the temporary altitudes associated with aircraft.

Requested Altitude

The requested final cruising altitudes of departing aircraft may optionally be displayed in FDBs, multiplexed with the airspeed and aircraft type. The following commands are available to control this:

Pilot-Reported Altitude

If an aircraft's transponder is not transmitting altitude, the altitude field in the full datablock is left blank. Further, "ISR" is shown in yellow, indicating that there is an increased separation requirement for the aircraft compared to regular IFR separation.

For such aircraft, the pilot may verbally report their current altitude to the controller. A few commands are available to record pilot-reported altitude so that it can be displayed in the datablock. Here, the aircraft has reported that they are at 9,000'. "ISR" is no longer displayed and an asterisk after the altitude indicates that it is pilot-reported and not from the transponder.

Consolidated Wake Turbulence (CWT)

Each type of aircraft has been assigned a Consolidated Wake Turbulence (CWT) category by the FAA. CWT categories range from "A" to "I" and go in decreasing order of aircraft size. Aircraft CWT categories are shown in both PDBs and FDBs. This table lists the categories and has representative aircraft types for each one.

Squawk Codes

IFR aircraft have preassigned squawk codes and should already be squawking them, though a few commands are available to issue new squawk codes to aircraft if needed:

Note that when using these STARS commands, you will need to use the SQ command in the aircraft control window to inform aircraft of their new squawk code.

If an aircraft is not squawking the beacon code assigned to it, the bottom line of the full datablock shows both the code it is squawking (on the left) and the code it has been assigned (on the right). The code that it should be squawking flashes to alert the controller.

Special Purpose Codes (SPCs)

If an aircraft squawks a special purpose code (SPC) (e.g., 7600 for a radio failure, 7700 for an emergency, etc.), the corresponding two-letter code is shown in red at the top of the FDB and an alert sounds. The alert can be silenced by slewing the aircraft. Here is an example for an aircraft squawking 7700.

The controller may also associate an SPC with an aircraft regardless of what it is squawking by entering a SPC and slewing the aircraft. An alert sound is not played in this case. The following codes may be used:

It is also possible to add custom codes for a facility via "custom_spcs" in "stars_config". Custom SPCs are shown in yellow.

Leader Lines and Positioning Datablocks

Leader lines connect radar tracks to the datablocks of the associated aircraft. They may have eight orientations, corresponding to the eight cardinal and ordinal directions. Here is an example of a radar track with a leader line East of the aircraft (left) and Northwest of it (right):

The DCB offers two buttons for configuring leader lines:

The top button, LDR DIR, is a spinner that controls the default direction of leader lines for aircraft whose tracks that are owned by the current controller. The bottom button, LDR, controls the length of all leader lines. The leader line length can range from 0 to 7, with the range of lengths shown below:

A number of keyboard commands are available to specify leader lines, including ways to specify them for subsets of the aircraft. These all use the numbers 1-9 to specify a leader line direction; depending on the command, 5 may be used to clear a previously-set direction or it may be invalid.

If you have a numeric keypad on your keyboard, you have an easy reference to the association between numbers and directions; consider the aircraft to be at the position of the "5" key and then the other numbers specify the direction of the leader line relative to the aircraft. If you don't have a numeric keypad, visualize one, or refer to this figure:

A number of commands are available to configure leader lines, where all uses of (#) below correspond to a number following the above convention for specifying directions:

Quicklook

"Quicklook" makes it possible to specify that all tracks owned by another controller will be shown with a full datablock instead of a partial datablock. This can be useful when one controller is feeding aircraft to another; quicklook gives some more visibility into the flow of inbound aircraft. When "quicklook plus" is used, the datablocks of quicklooked aircraft are also shown in white rather than green.

A number of commands are available to control quicklook:

The currently-active quicklook positions can be shown in the SSA list, after "QL:".

Force Quicklook

A controller can also "force quicklook" a track that they own to cause its full datablock to be shown on another controller's display. Force quicklooked aircraft also have yellow datablocks for the recipient, until they clear the forced quicklook by slewing the track.

Dwell Mode

Dwell mode increases the brightness of the track and datablock of the aircraft closest to the mouse cursor, if the mouse is reasonably close to a radar track. Here is an example of it:

It can be configured using the DWELL button in the auxiliary DCB; it may take the value OFF, ON, or LOCK. OFF disables DWELL mode and ON enables it, with the increase in brightness lasting as long as the mouse cursor is close to a track. With LOCK mode, the increased brightness of a track persists, even after the mouse cursor moves away. Only when another track is approached by the mouse cursor does the brightness increase switch to it.

Dwell mode can also be configured using the keyboard:

Altitude Filters

Controllers can set altitude filters to hide the datablocks and leader lines of aircraft outside a range of altitudes of interest; doing so can help reduce the amount of clutter on the screen. Here is an example of a track that is outside the filter range:

Note that if an track is pointed out or is an inbound handoff, its full datablock will still be shown, even if it is outside of the current altitude filter.

STARS supports two filters, one for unassociated tracks and one for associated tracks. Each of these filters is a range of altitudes, specified in hundreds of feet. The following commands are available to manage altitude filters:

Tools

STARS offers a variety of tools to help with vectoring aircraft and ensuring they remain separated. For most of the tools in this section, the font size is based on the TOOLS font size in the CHAR SIZE menu of the DCB and the brightness is based on the TLS setting in the BRITE menu of the DCB.

Flight Plan / Beacon Code Display

Position Reporting

Collision Alerts and Mode C Intruders

If there is a loss of separation between aircraft or if STARS predicts an imminent loss of separation, a collision alert will be issued where red text "CA" is shown in the aircraft datablocks and an alert sound will be played. The alert sound continues until one of the aircraft is slewed. Here is an example of a pair of aircraft with CA alerts:

An alert is also issued if an unassociated track loses separation with an associated track; in this case, the unassociated track is called a mode C intruder (MCI). No alerts are issued for pairs of unassociated tracks.

A few commands are available to enable and disable collision alerts and MCI alerts:

If collision alerts are globally disabled, "TW OFF: CA" will be displayed in the SSA list. If they are disabled for a particular aircraft, a triangle will be shown after the aircraft's callsign in its datablock. Here is a case where disabling CA for two aircraft was not a good idea.

Minimum Safe Altitude Warnings

If aircraft are beneath the minimum vectoring altitude at their location, a minimum safe altitude warning (MSAW) may be issued. Aircraft with MSAWs have "LA" (for "low altitude") displayed in red at the top of their datablocks. An alert sound is played when an MSAW is issued; it can be silenced by slewing the corresponding aircraft. Here is an example of such an aircraft:

MSAWs can be configured with these commands:

When MSAW is disabled or inhibited, an asterisk is shown after its datablock. (If both MSAW and CA is disabled for an aircraft, a plus sign will be shown after its datablock).

A map showing the minimum vectoring altitudes used for MSAWs is included in the "SYS PROC" maps available from the "MAPS" menu in the DCB.

Predicted Track Lines

PTLs (Predicted Track Lines) show the aircraft's predicted course over the course of 0.5 to 3 minutes into the future. Here is an example of a track with a PTL:

PTLs can be controlled using these buttons in the auxiliary DCB menu, which is shown by selecting SHIFT from the main DCB.

PTL OWN sets whether PTLs are shown for tracks that are owned by the TCP, and PTL ALL sets whether PTLs are shown all associated tracks in the current altitude filters. It is also possible to display or hide the PTL of individual aircraft using a keyboard command.

Range Bearing Lines

Range bearing lines (RBLs) track the distance and heading between aircraft and/or fixes. For example, the image below shows an RBL between two aircraft, indicating that N63A is 6.50nm miles along a 118 heading from AAL86. In this case, the RBL was drawn from AAL86 to N63A; if it had been drawn the other way, the label would be next to AAL86 and the heading would be 118+180=298. The "-1" at the end of the label indicates that this is RBL number 1. If additional RBLs were created, they would be given successive numbers to identify them.

RBLs may be created between pairs of aircraft, and aircraft and a fixed location, or a pair of fixed locations. When aircraft are involved, the corresponding RBL endpoint moves along with the aircraft.

The following commands are available to create and delete RBLs:

Minimum Separation

The predicted minimum separation between two aircraft can be shown. Below we see that based on their current routes the two aircraft are predicted to have a minimum separation of 2.15nm and that separation will occur when they are at the two points marked by small triangles.

The following commands are available to create and minimum separation lines.

TPA/ATPA

The terminal proximity alert (TPA) and automated TPA (ATPA) tools provide graphical representations that aid in ensuring that there is sufficient separation between aircraft. A TPA cone can be associated with an aircraft to show a given distance in nautical miles in front of it; see the left image below for a TPA cone marking 4nm. A TPA J-ring is a circle around an aircraft's radar track of specified radius; the right image below shows a J-ring with a 4nm radius.

The following keyboard commands are also available to configure TPA cones and J-rings:

ATPA automatically generates cones for aircraft in the approach volume for a runway. (Approach volumes are generally along the glideslope for a runway.) For example, the image below shows a 5nm cone in front of BAW6895, indicating the required separation for a CWT F-class aircraft (upper large) behind an upper-heavy B-class aircraft. The current in-trail distance, 4.55nm, is shown in BAW6895's datablock, and both that distance and the cone are red, indicating an ATPA alert for loss of separation.

This table shows the minimum in-trail distances required by ATPA for aircraft on approaches; NOWGT is used if the weight class of an aircraft is unknown:

ATPA alerts are issued if a loss of separation is expected in the next 24 seconds, and ATPA warnings (which are drawn in yellow) are issued if a loss of separation is expected in the next 24-45 seconds.

TPA and ATPA can be configured by selecting "SHIFT" from the main DCB menu and then "TPA/ATPA". The following options are provided:

The first four buttons toggle a particular TPA/ATPA option and display "ENABLED" if the corresponding option is enabled, and "INHIBTD" if it is inhibited. "DONE" returns to the previous DCB menu.

• A/TPA MILEAGE: whether the respective radius or length are shown with TPA J-rings or TPA/APTA cones.
• INTRAIL DIST: determines whether the in-trail distance to the next aircraft is shown in the datablocks for arrivals in an ATPA volume.
• ALERT CONES: determines whether ATPA warning and alert cones are automatically created when insufficient separation is predicted. If disabled but monitor cones are enabled, monitor cones will be shown.
• MONITOR CONES: determines whether monitor cones may be automatically created for all arrivals in an ATPA volume.

The following keyboard commands are also available to configure ATPA:

For facility engineers, the ATPA approach volumes are listed in the "PROCESSING AREAS" map list, which can be selected via "SYS PROC" from the DCB "MAPS" menu. Individual maps can be displayed and then hidden by entering [MAPS](###) where ### is the map number associated with the volume.

Compass

To help with determining headings when vectoring aircraft, a compass rose may be displayed around the edges of the STARS radar scope:

The brightness of the compass rose is controlled by CMP in the BRITE DCB menu and the size of the font used is set based on TOOLS in the CHAR SIZE DCB menu.

Range Rings

Range rings are concentric circles drawn around a selected point with successive steps between their radii that are 2, 5, 10, or 20nm. With 5nm steps, the default, here are the 5 and 10nm range rings drawn around KEWR:

A few buttons on the main DCB make it possible to configure range rings. Clicking on RR activates a spinner that allows selecting the step between radii. If PLACE RR is clicked, then the next location clicked on the radar scope will become the range rings' center point. Finally, clicking RR CNTR causes the range rings to be centered on the point at the center of the radar scope; If the range rings are not currently centered, RR CNTR is drawn depressed.

The radius of the range rings can also be set by entering [RANGE] and then 2, 5, 10, or 20, and then pressing enter.

The brightness of range rings can be controlled with the "RR" spinner in the "BRITE" menu of the main DCB. If the brightness is set to 0, range rings are not drawn.

CRDA

The Converging Runways Display Aid (CRDA) helps ensure separation between aircraft approaching intersecting runways. It does so by drawing "ghost" aircraft on one course that correspond to aircraft on another course. The idea is perhaps best understood with an example:

Here four aircraft are approaching KPHL, AAL45 and JZA868 landing runway 27R and JIA1524 and FFT5099 landing runway 17. With CRDA enabled, ghosts of the aircraft landing 27R are drawn on the runway 17 approach course at the same distance out as they are from the point where the two runways intersect. If we compare the separation of AAL45's ghost with FFT5099, we can see that there will be adequate separation between the two aircraft—FFT5099 will be well past where the runways intersect before AAL45 lands. It's a little tighter with JZA868 and JIA1524, though CRDA might give us the hint to slow down JZA868 to increase distance between them.

Ghost aircraft may be positioned via either "stagger" or "tie" mode. With stagger mode, the ghosts are the same difference from a common point (e.g., the intersection of two runways); the controller's goal is then to ensure adequate separation between ghost and actual aircraft radar tracks. Alternatively, with tie mode, ghosts are offset so that the controller's goal is to have actual aircraft radar tracks coincide with the ghost tracks in order to achieve separation.

When CRDA is available at an airport, the CRDA status list may be displayed on the STARS scope. Entering [MULTIFUNC]TN toggles whether it is shown, and [MULTIFUNC]TN[SLEW] repositions it on the screen. In the example below, we can see from the "S" in the line two below "CRDA STATUS" that CRDA is enabled in stagger mode for runways 27R/17 at KPHL for the current controller, who has ID 6F.

Ghost radar tracks are normally only generated for aircraft within a pre-defined volume of space around an approach course and only if their heading is within a specified range of the approach heading. However, a number of commands below allow forcing a ghost track even if these criteria are not met.

A variety of commands are available to configure CRDA. Some take an airport's identifier, which should be given without the initial "K": i.e., "PHL" for Philadelphia, not "KPHL":

Significant Points

There are a number of significant points associated with each TRACON; these include arrival fixes and exits, airports in the TRACON and other relevant fixes (e.g., those with predefined holds.) STARS offers two commands that print the distance and heading from a selected point (e.g. an aircraft) to a significant point.

Restriction Areas

Restriction areas are annotations on STARS maps that add additional information, usually related to temporary conditions (flight restrictions, events, etc.) They may be circular, polygonal, or have no shape associated with them, and may include text that provides additional information about them. They are drawn in yellow in the STARS window and their brightness is controlled via the "Map group B" brightness.

Here is a circular restriction area with 2nm radius centered at the KFRG airport:

Restriction areas may be defined by the controller using commands described below or may be defined in scenario definition files (see STARS and Video Maps). If a controller defines a restriction area, it is make available to all other controllers in the session. As a convenience, vice also downloads the current FAA TFRs and automatically generates restriction areas for them.

The currently-available restriction areas can be seen via the restriction area list, which can be displayed and positioned using these commands:

Here is an example of the restriction area list:

Restriction area numbers 1—100 are used for user-defined restriction areas and 101—200 for system-defined restriction areas.

The following commands can be used to create and delete restriction areas. (Note that system restriction areas cannot be deleted.) The syntax of the (RATEXT) and (RALOC) specifiers used for restriction areas is discussed below.

In the restriction area commands, (RATEXT) is used to indicate specification of the text associated with the restriction area. One or two lines of text may be specified; if a second line is given, it should be separated from the first by a space. Because space is used to separate lines, periods must be entered for spaces within a line of text. These periods are converted to spaces by vice.

Depending on the context, a third line with additional qualifiers can be entered: ∆ to indicate that the text should blink and + to indicate that its associated shape should be shaded, or * followed by a number from 1—8 to specify a color for the graphics. Here are the colors associated with each number:

(RALOC) corresponds to specifying a location. One way to do so is by clicking a point in the STARS window; alternatively, the names of a fix, a fix offset by a given distance in a given direction, or a latitude-longitude coordinate may be provided. If keyboard entry is used, [ENTER] must be pressed after each location. Here are a few examples of text input:

• CCC: specifies that the location of the CCC VOR should be used.
• CCC/320/2.5: specifies a point 2.5nm miles along the 320 bearing from the CCC VOR.
• 403758N/0734617W: specifies a latitude-longitude coordinate 40.37.58N, 73.46.17W. In other words, for latitude, the first two digits are degrees, the next two are minutes, and the next two are seconds, followed by a "N" or an "S". For longitude, three digits are used for degrees (and leading 0s must be used if necessary), then two digits for each of minutes and seconds, followed by "W" or "E". Latitude and longitude coordinates are separated by a slash /.

Putting all of the above together, the a restriction area above that is a 2nm circle around KFRG might be created by [F12]C2 REPUBLIC FRG[ENTER][ENTER]. We could instead make a shaded area with two lines of flashing by entering [F12]C2 REPUBLIC SHADED.AREA +∆ FRG[ENTER][ENTER]. Here is the result:

A number of commands are available to modify existing restriction areas and manage which ones are displayed:

Airspace

Note: this feature is not present in real-world STARS.

vice is able to indicate when aircraft are outside of the departure or approach airspace, if it has information about the airspace boundaries. (This information is not available at all airports.) If an aircraft is outside of its assigned airspace, a red "AS" error will be printed at the top of its datablock, as shown below. The valid altitudes for the aircraft are shown as well, if there are any valid altitudes at its current location. For example, the aircraft below is at 5,000' but should be between 11,000' and 12,000' (or should be at a different location!)

The airspace volumes associated with controllers can be displayed by clicking on the button in the menubar to display the information window and then opening the "Airspace" section.

STARS Configuration

Range and Center

The left side of the main DCB has a few buttons for controlling the range of the STARS scope and where it is centered:

Clicking on RANGE activates the range spinner, which allows setting the scope range to be between 6 and 256 nautical miles. The center of the scope can be changed by clicking PLACE CNTR and clicking in the scope. Finally, OFF CNTR is shown as depressed when the scope's center is different than the default center specified in the scenario configuration. Clicking on it restores the center to the default.

Alternatively, center of the radar scope can be moved by clicking the right mouse button and dragging. Zoom in and out using the mouse wheel; each step increases or decreases the radius shown by one nautical mile. Holding down the control key while using the mouse wheel gives three mile steps in the radius. Zooming and panning the scope in this way can be disabled with vice's settings window, which is displayed when the in the menubar is clicked.

Character Size

Clicking the CHAR SIZE button in the main DCB brings up the character size DCB menu, shown here:

The sizes controlled by the buttons are:

• DATA BLOCKS: data block text.
• LISTS: STARS system lists.
• DCB: text in the DCB.
• TOOLS: the various STARS tools.
• POS: track position symbols

Clicking DONE returns to the main DCB.

All types of character sizes may range from 0 to 5, except for DCB, which goes from 0 to 2.

Brightness

Selecting the BRITE button in the main DCB brings up the brightness DCB menu, shown here:

The item brightness that the buttons control are:

• DCB: the DCB itself.
• MPA: maps in group "A" (generally, the primary video maps).
• FDB: full data blocks, the cursor, and preview area.
• POS: position symbols in radar tracks owned by the controller.
• OTH: datablocks and position symbols for tracks owned by other controllers and ghost tracks.
• RR: range rings.
• BCN: beacon targets (not currently used).
• HST: history circles behind track paths.
• WXC: weather contrast; i.e., the stippled patterns.
• BKC: background contrast.
• MPB: maps in group "B" (generally, the secondary maps).
• LST: system lists.
• LDB: limited and partial datablocks and their position symbols.
• TLS: STARS tools.
• CMP: the compass rose at the edges of the STARS display
• PRI: primary target symbols.
• WX: weather.

Some of these brightnesses can be set to 0, in which case "OFF" is shown in the BRITE menu and the corresponding item isn't drawn at all. Others have a minimum required brightness.

RADAR Sites

The STARS RADAR configuration can be managed by clicking the SITE button in the main DCB, which also shows the current RADAR mode. STARS supports three RADAR modes:

• SINGLE: RADAR data from a single RADAR site is used determine aircraft locations.
• MULTI: multiple RADAR sites are used to determine aircraft locations, where (more or less), the closest site to each aircraft is used.
• FUSED: RADAR data from multiple sites is combined with ADS-B data from aircraft to determine their locations.

SINGLE mode can be selected by clicking on a radar site in the SITE DCB sub-menu (here, NXX and PHL are available.) MULTI and FUSED are selected by clicking on the corresponding buttons.

Note that the choice of RADAR mode affects which symbols are used for tracks in STARS. Furthermore, in SINGLE and MULTI modes, radar tracks are only updated once every 5 seconds. In FUSION mode, they are updated once per second.

Audio

Audio alerts are played when there is a minimum safe altitude warning for an aircraft, if an aircraft is squawking a special purpose code (e.g., 7700 for an emergency), it a SPC has been manually assigned to an aircraft, or if there is a conflict alert between two aircraft. The "VOL" control in the main DCB can be used to control the volume of these alerts.

A few keyboard commands can be used to control audio:

vice also provides optional audio alerts for when there is an inbound handoff to the current controller and when an outbound handoff is accepted (though real-world STARS does not have these.) These alerts can be enabled and disabled under the "STARS" section of vice's settings menu.

Preferences

Various details of the current STARS configuration like brightness settings, font sizes, and the layout of the system lists can be saved in a STARS preference set. The current preference set stores the preference settings that are currently active, and up to 32 additional named preference sets can be stored. vice stores separate preferences for each TRACON, which makes it easy to customize STARS's settings in different ways for different facilities.

Functionality for loading and saving preference sets can be accessed by clicking PREF on the main DCB menu, which brings up the PREF menu:

Here we can see that there are two saved preference sets, PHLN and FINAL, and that FINAL is active. Clicking on a saved preference set selects it and loads its settings. Preferences can be restored to their defaults by clicking on DEFAULT. Clicking RESTORE restores the preferences to what they were when the PREF button was clicked to bring up the PREF DCB menu. If a preference set is selected, then SAVE is enabled; clicking on it saves the current preference settings to the selected preference set. DELETE deletes the selected preference set.

A new preference set is created when SAVE AS is clicked: the preview area will prompt PREF SET NAME and the name for the preference set can be entered, followed by the ENTER key. Preference set names may be up to 7 alphanumeric characters and may not be a number between 1 and 32.

These keyboard commands are available for preference sets:

Display Elements

In addition to radar tracks and their datablocks, the STARS display contains various system lists that display useful text information, video maps of the local control area, and, optionally, a weather radar showing precipitation. These are all described in this section.

System Lists

The system lists show various types of useful information in the form of text. Their font size can be adjusted using the "LISTS" control in the "CHAR SIZE" DCB menu and their brightness is set with "LST" in the "BRITE" DCB menu.

vice currently doesn't support two STARS system lists: the VFR List and the Coast/Suspend List; both will be added in the future when the aircraft simulation supports VFR and lost radar tracks. Otherwise, all of the system lists other than ones for CRDA and maps are documented in this section; see the CRDA documentation above for information about the CRDA system list and Video Maps for information about the maps system list.

System Status Area List

The System Status Area (SSA) list displays general information about the configuration of the STARS radar scope. Here is an example:

The red triangle indicates that STARS is functioning correctly; in vice it will always be there. The first line of text shows the current zulu time 03:07:27 and the altimeter at the primary airport for the current scenario, PHL. The following line shows the network status (always "OK/OK/NA" in vice) as well as the current radar mode, FUSED. Next is the current range shown from the scope's center, 17nm, and the length of predicted track lines (PTLs), 0.5 minutes. Next are the altitude filters, first for unassociated tracks and then for associated tracks (both in hundreds of feet.) The next few line again shows the altimeter at PHL and contains the altimeters at nearby airports in multi-airport scenarios.

A few lines are only shown when corresponding features are enabled. Here, "QL: 6S" indicates that TCP 6S has been quicklooked and "TW OFF: MSAW" indicates that MSAW has been disabled system-wide. Finally, we can see that CRDA has been enabled for the runway pair 27R/17, with the "S" indicating "stagger" mode.

The SSA list is always visible; a keyboard command is available to position it:

GI text: general information text... TODO

Which elements are displayed in the SSA list can be configured by selecting the "SSA FILTER" menu from the main DCB, which brings up the SSA DCB.

The buttons toggle display of the following elements:

• TIME: current time in zulu
• STATUS: system status; always "OK/OK/NA"
• RADAR: radar mode: FUSED, MULTI, or SINGLE
• SPC: whether to show an alert for any special purpose codes currently being squawked by aircraft (e.g., "RF" for an aircraft squawking 7600 due to a radio failure.)
• RANGE: radar range
• ALT FIL: altitude filters
• AIRPORT: altimeter at nearby airports
• QL: quick looked sectors
• CRDA: active CRDA runway pairs
• WX: available and displayed weather precipitation levels
• ALTSTG: show altimeter at primary airport
• CODES: show selected beacon codes
• PTL: length of predicted track lines
• WX HIST: weather history snapshot currently being displayed
• TW OFF: disabled system features (e.g., CA, MSAW)

Flight Plan List

The flight plan list shows untracked aircraft that have departed an airport that you are responsible for. Once they are tracked, they are automatically removed from the list. Here is an example:

In addition to the aircraft's callsign (middle column) and assigned beacon code (right column), the left column shows a tab number that is associated with the

Tower List

The tower list shows arrivals at an airport. Up to three tower lists can be displayed; each show arriving aircraft sorted by their distance to the airport. The assignment of airports to tower lists is done by the facility engineer in the scenario specification and can't be changed while vice is running. Here is an example, showing a few arrivals to PHL:

The following commands can be used to configure the tower lists. For all of them the first number gives the tower list index and must be 1, 2, or 3.

Alert List

The Alert List shows the aircraft that currently have altitudes below the minimum vectoring altitude at their present position (LA) or have collision alerts (CA). Below we see that JZA868 is too low (and is currently at 600 feet altitude) and that separation has been lost between JIA1524 and NKS9096.

The maximum number of lines in the alert list is hard-coded to 50 and it is not possible to hide the alert list. However, its position in the STARS window can be set using the following command:

MCI Suppression List

If specific MCI alerts have been suppressed, the corresponding pairs of callsigns and beacon codes are listed in the MCI suppression list. Commands are available to control whether it is displayed and where it is placed on the screen.

Coordination Lists

Coordination lists are used for tower and departure controllers to coordinate aircraft releases. When there is a departure ready to be released from an airport the controller is responsible for, it is added to the coordination list by the tower controller. After the departure controller releases an aircraft, it will depart within the next few minutes. Here is an example coordination list:

Aircraft that are awaiting release flash, as DPJ7156 is here. Released aircraft are no longer flashing and have a plus sign after their tab list number (here, 0 and 2 for EJA5253 and LXJ13, respectively.) The coordination list also includes the aircraft type, the aircraft's assigned squawk code, its exit, and its requested final altitude.

These keyboard commands are used to manage coordination lists and releases:

Coordination list identifiers ((ID) in the above commands) are one to three alphanumeric characters. They can be found in the scenario information window, accessed by clicking the button in the menubar. Here we can see that the "REPUBLIC" coordination list has id "A".

Sign On List

The sign-on list shows the TCP covered by the current controller as well as the time they signed on (in Zulu time).

It can be configured using these commands:

Video Maps

One or more video maps may be displayed in the STARS window to show items like airports and runways, approaches, important fixes, and geographical features like bridges. There are default video maps specified for each control position and controllers may add an remove maps depending on circumstances.

The main DCB includes a MAPS button, which displays the DCB MAPS menu, and six buttons to toggle the display of six video maps; here are six from a KJFK scenario:

The button for map number 849, CLASS_B, is depressed, indicating that the corresponding map (which shows the class B airspace) is currently visible. The other maps are not currently displayed. Clicking on map's button toggles whether it is visible.

Here is the MAPS DCB menu for that same scenario:

The map labeled 4L_R which has number 201, is currently visible, though none of the others are. Each map is in one of two map groups—A or B; the brightness of the groups is controlled by MPA and MPB in the BRITE DCB menu. Unfortunately, STARS doesn't directly show which group a particular map is in.

The other buttons in the MAPS DCB do the following:

• DONE: returns to the main menu.
• CLR ALL: deselects all video maps.
• GEO MAPS: toggles display of the maps system list and shows the available video maps in it.
• SYS PROC: toggles display of the maps system list and shows maps related to STARS system operation (e.g., CRDA regions, ATPA volumes, RADAR site ranges, etc.) in it.
• CURRENT: toggles display of the maps system list and shows the currently displayed maps in it.

Depending on which maps have been included, there may be buttons for the following map categories; when pressed, they cause the corresponding type of available maps to be shown in the maps system list: AIRPORT, CONTROL, DANGER AREAS, GENERAL AV, GEO POINTS, MIL, RUNWAYS, and SID STAR.

Here is the maps system list for that same KJFK scenario. For each map, we have the map number, the map label (as shown in the DCB), and a longer name describing the map's contents. Maps that are currently displayed have > symbols next to them.

The following keyboard commands can be used to manage video maps.

Weather

The current weather radar that shows precipitation can be displayed on the STARS scope. Here is an example North of KORD during some summer thunderstorms. The blue-green areas indicate light precipitation, while the mustard-colored area is moderate to heavy precipitation. Stippling in the radar also indicates the strength, where a denser stipple is heavier precipitation.

AWI8111 would be well-advised to turn a few degrees to the right.

The brightness of the weather on the STARS scope can be controlled using the "WX" spinner in the BRITE menu of the DCB and the brightness of the stipple is controlled using the "WXC" BRITE control. It is also possible to control which levels of precipitation are shown using the "WX*" buttons in the main DCB. When precipitation of a given level is available to be displayed, "AVL" is shown in the button and the button has a blue-grey color. When there is no precipitation at a level, the corresponding button has the regular green color.

With the selection above, the three lowest levels, WX1 and WX2 are not shown, while all of the higher levels of precipitation are.

If the WX button in the SSA list is enabled, the currently available WX levels and whether they are displayed is shown in the SSA list. In the example below, there is precipitation at levels 1–5, though not 6. Levels 3, 4, and 5 are shown in the STARS window:

A few keyboard commands related to weather are available:

Facility Enginerring FAQ

Specifying Locations

Throughout the vice configuration files, it's often necessary to specify various locations on the Earth. vice has a built-in database of all of the airports, VORs, NDBs, and fixes in the United States (courtesy of the FAA), which allows using these directly for specifying locations. The locations of runway thresholds are available via the syntax KJFK-22L where the airport name and runway specifier are separated by a hyphen.

Locations can also be specified via latitude-longitude positions, given as strings. For convenience, multiple latitude-longitude formats are supported.

(In all of the examples above, the location specified is the same—the JFK VOR.)

In vice, if you hold down the control and shift keys and click on a point on the video map, the corresponding latitude-longitude position is copied to the clipboard—this can be very useful when developing new scenarios!

Routes

When an aircraft's route is given, vice allows airways to be used to describe the route, which simplifies the route specification when an aircraft is in fact flying along an airway. Airways are given as part of the route; for example "WHITE V1 DPK" has the aircraft join V1 departing WHITE and follow V1 until DPK. (The alternative, "WHITE DIXIE MOVFA JFK DPK", is more typing and more error-prone to enter.)

vice uses a custom syntax for specifying the routes of aircraft that allows giving additional information that is used in the simulation. In addition to the lateral positions along the route, it is possibly to specify speed and altitude restrictions, handoff points, and headings to fly.

Here is an example route from a JFK departure. The first two fixes along the departure runway are automatically provided by vice so the route starts with the specified fixes in the departure procedure. The "/h223" after "RNGRR" specifies that the aircraft should fly a 223 heading as departing RNGRR. It will maintain that heading until it is further vectored by the controller. If there are further fixes after such a heading, the aircraft may be sent direct to one of those fixes by the controller.

  "SKORR METSS RNGRR/h223"
            

A variety of such things can be specified along with a fix:

• /arestriction: for IFR routes, cross the fix with the specified altitude restriction (with altitudes specified in 100s of feet). For VFR, aircraft will be at a random altitude within a given altitude range. The following options are available for specifying altitude restrictions:
  • low-high: cross at an altitude between low and high.
  • alt-: cross at or below alt.
  • alt+: cross at or above alt.
  • alt: cross at alt.
• /delete: the aircraft will be deleted when it reaches the fix
• /hheading: depart the fix at specified heading
• /iaf: indicates that the fix is an IAF (initial approach fix)
• /if: indicates that the fix is the IF (intermediate fix)
• /faf: indicates that the fix is the FAF (final approach fix). This must be specified for one fix in each approach.
• /flyover: indicates that the fix is a flyover fix (as opposed to the default, fly-by). Aircraft must pass directly over flyover fixes before turning to the next fix, while they may turn early with fly-by fixes.
• /phheading: fly present heading (rounded to the nearest 5 degree increment) departing the fix.
• /sspeed: cross the fix at the given speed

A number of specifiers are intended for ambient traffic that's not under the control for a human:

• /clearapp: the aircraft will be cleared for the assigned approach passing the fix.
• /ho: the aircraft should be handed off from the virtual controller when it passes the fix. A TCP may be specified after /ho, in which case the aircraft is handed off to the corresponding virtual controller. If no TCP is specified, the aircraft is handed off to the appropriate human controller.
• /tc: "transfer comms": after passing a /ho fix, normally aircraft call in a few seconds after the human controller accepts the handoff. However, if /tc is specified at a later fix in the route, they won't contact the controller until reaching that fix.
• /poTCP id: when the aircraft passes the fix and if it is under the control of a virtual controller, issue a point out to the controller identified by the given TCP id (i.e., the controller ID that would be used when doing a point out in STARS.)
• /radiusnum: rather than flying precisely to the fix, the aircraft will fly to a random point within num miles of the fix.
• /shiftnum: rather than flying precisely to the fix, the aircraft will fly along the route to the fix but will turn for the next fix at a random distance before or after the fix, up to num/2 nautical miles in each direction.
• /spspscratchpad: sets the aircraft's primary scratchpad to the given value.
• /ssspscratchpad: sets the aircraft's secondary scratchpad to the given value.
• /cpsp: clears the aircraft's primary scratchpad
• /cssp: clears the aircraft's secondary scratchpad

In addition to /radius and /shift, which are also useful for randomizing VFR routes, there's an additional specifier that can be used with VFR aircraft routes:

• /airwork: the aircraft should perform airwork centered around the fix. An altitude restriction must be specified using /a to give an altitude range for the airwork. By default, they will do so for 15 minutes and remain within 7nm of the fix; alternatively, the time or distance may be specified via /airworkradiusnm and/or /airworkminutesm. For example: /airwork30m10nm specifies 30 minutes of airwork within a 10nm radius of the fix.

If the aircraft should follow an arc leaving a fix, /arc can be given after the fix. It can be used in two ways:

• Both a radius in nautical miles as well as the fix at the center of the arc's circle can be specified. For example, HANAV/arc16OMN specifies a 16nm radius arc centered at OMN.
• Alternatively, just the length of the arc may be given. For example, WUPMA/arc7.5 ALABE has aircraft fly along the 7.5nm long arc between WUPMA and ALABE.

For both uses, the direction of the arc is automatically determined based on the position of the following fix.

For approach fixes that have procedure turns, a number of additional items can be specified:

• /hilpt: there is a hold in lieu of procedure turn (i.e., a racetrack procedure turn) associated with the fix. The default is right turns and a 1 minute limit for ILS/VOR/LOC approaches and a 4 nm limit for RNAV approaches. Different limits can be specified directly; for example /hilpt6nm gives a procedure turn with a 6 nm limit and /hilpt2min specifies a 2 minute limit. For left turns, add a l after the slash, like /lhilpt.
• /pt45: specifies that there is a standard 45 degree procedure turn at the fix. (This has the same defaults— right turns, 1 minute (ILS/VOR/LOC) / 4 nm (RNAV)—as HILPTs. Alternative values are specified the same way.)
• /ptaaltitude: if the aircraft should descend during the procedure turn, this can be used to specify the final altitude it should have at the end of the turn. (The altitude should be given in 100s of feet.)
• /nopt180: specifies that aircraft approaching the fix in the 180 degree semicircle of directions aligned with the final approach course should not perform the procedure turn. (As an example, see the KJAX RNAV Z 8 approach; this applies for aircraft between heading 346 and 166 arriving at UDAQI.)
• /nopt: when specified at a fix prior to one with a procedure turn, indicates that aircraft that pass that fix should not fly the procedure turn.

Airlines and Aircraft

Departures, arrivals, and overflights all need to know about which airlines fly their routes and which aircraft they use for them. Airlines are specified via objects with the following members: for the database of possible airlines. In that file, each airline may have one or more aircraft fleets specified, in its "fleets" member.

If neither "fleet" nor "types" is specified, vice randomly chooses an aircraft type from the "default" fleet, but if a particular fleet's aircraft is a better match to a route, you may want to use it or to specify aircraft types directly. For example, AAL's "long" fleet would be a good choice for trans-Atlantic flights.

For reference, the available types of aircraft and their performance characteristics are available in the openscope-aircraft.json file.

As is probably obvious, both of these databases are by way of openScope, which kindly made them available under the MIT license.

Scenario Groups

vice offers users a variety of ATC scenarios, where a scenario consists of one or more airports being controlled, a control position (departure, approach, etc.), and airport configurations—the runways that are active at each airport. Scenarios are organized in scenario groups, which generally collect multiple control scenarios at a single airport. Each scenario group is specified by its own JSON file; see the resources/scenarios/ directory in the vice source code distribution for examples.

These are the elements of a scenario group:

Airports

The airports in a scenario group are specified via the "airports" member of the scenario group. Each airports is a separate member, named according to the airport's ICAO code (e.g., "KJFK"). The airport object then has the following member variables:

Approaches

The member names in the airport "approaches" object give the abbreviated name of each approach, as used in vice's ATC commands.

Approaches may be specified using data automatically loaded from the FAA CIFP or manually. To use CIFP data, run vice from the command-line and give it the argument -route KXYZ, where KXYZ is the ICAO code for the airport. vice will print identifiers for the available approaches and their associated fixs. For example:

  > ..\vice.exe -routes KMIA
  [...]  
  Approaches:
  I12  : DHP GLRIA/a3000+/lhilpt1.0min/pta3000/iaf PIANA/a3000+ VEPCO/a2000+
  [...]
  RY12 : WORPP/iaf GLRIA/a3000/if PIANA/a3000+ VEPCO/a2000+
         FOGSO/s210/iaf GLRIA/a3000/if PIANA/a3000+ VEPCO/a2000+
  [...]

Approach ids encode the type of approach—for example, I12 is an ILS approach to runway 27 and RY12 is an RNAV Y runway 12 approach. Given the id, the approach can be specified with:

Support for loading routes from the CIFP is new so please confirm that routes are correct and report any bugs you find. Note that not all approaches are included in the CIFP.

Alternatively, approaches can be defined manually using the following members:

Departures

There are two pieces for specifying departures: their initial route leaving the airport, which depends on the active departure runway, and their subsequent route out of the TRACON, which does not. These two parts are specified separately.

The "departure_routes" object in the airport definition gives the initial routing for departures, based both on the runway they are departing as well as their exit fix. Here is an excerpt from the KJFK departure routes:

  "departure_routes": {
    "13R": {
      "ARD,DIXIE,RBV,WHITE": {
        "cleared_altitude": 5000,
        "sid": "JFK5",
        "waypoints": "KJFK-31L/h185"
      },
      ...
            

The members of "departure_routes" are strings identifying the departure runway; each departure runway's routes are then represented by an object with one or more members that specify comma-separated lists of exit fixes. (Thus, the specification above applies to departures with exit ARD, DIXIE, RBV, or WHITE, departing runway 13R.)

The exit fix specifiers may include additional text after a period to allow specifying situation-dependent exits. For example, we might specify one route for "RBV.PISTONS", another for "RBV.TURBOPROPS", and a third for "RBV.JETS". vice treats all of these as going to the "RBV" exit. When departures are defined in "departures", they can then refer to the appropriate exit in their "exit" specifier.

The departure route specification includes the following members:

Either "assigned_altitude" or "cleared_altitude" must be specified.

The other part of specifying departures is the array of objects stored in "departures". Each one describes a departure to a particular destination. Here is a JFK departure to Paris Charles de Gaulle:

    {
      "airlines": [
        {
          "fleet": "long",
          "icao": "AFR"
        }
      ],
      "destination": "LPFG",
      "exit": "HAPIE",
      "route": "HAPIE YAHOO WHALE N251A JOOPY NATZ MALOT NATZ GISTI LESLU M142 LND N160 NAKID M25 ANNET UM25 UVSUV UM25 INGOR UM25 LUKIP LUKIP9E",
      "scratchpad": "HAP",
    },
  ...
            

A few additional things must be specified with each departure:

It is optional to specify the final altitude for departures.

Arrivals and Overflights

Note: until recently, overflights were not supported and arrivals were specified using the "arrival_groups" variable, which is no longer available.

Arrivals and overflights are specified via the "inbound_flows" variable, which allows specifying the ways that aircraft from adjacent facilities enter the TRACON. "inbound_flows" has two members, "arrivals" and "overflights", each of which is an array of arrival and overflight specifiers, respectively.

vice allows specifying multiple arrival and overflight procedures together so that it can sequence them as a group. Thus, if an overflight route corresponds to a STAR, at least at the beginning, both should be specified together in the same "inbound_flow". Similarly, if multiple STARs have the same initial route, they should be together as well.

Arrivals

Each object stored in the "arrivals" array corresponds to a STAR. These objects have the following members:

STARs are sometimes able to deliver aircraft to multiple airports. Therefore, the "airlines" member is an object with airport names as members. Each of the airports is associated with an array of objects that specify departure airports, airlines, and (optionally) airline fleets. Here is an excerpt from the CAMRN4 arrival group at KJFK:

  "airlines": {
    "KFRG": [
      {
        "airport": "KDCA",
        "icao": "EJA"
      },
      ...
    ],
    "KJFK": [
      {
        "airport": "MMMY",
        "fleet": "long",
        "icao": "AMX"
      },
      ...
    ]
  }
            

We can see that CAMRN4 applies to both the KFRG and KJFK airports, though with different airlines and different departure airports for the arrivals. The specified departure airports (here, KDCA and MMMY) are only used so that flight strips and data blocks on the scope are realistic, but the specified airlines are used to select the type of aircraft from their fleets. As elsewhere, a value for "fleet" may be specified to limit which types of aircraft may be chosen.

There are two ways to specify a STAR's waypoints: automatically using data loaded from the FAA CIFP or manually. To use CIFP data, ensure that the STAR is available by running vice from the command-line and providing the -routes KXYZ argument, where KXYZ is the name of the airport. vice will print the available STARS with their transitions. For example,

> ..\vice.exe -routes KLGA
STARs:
APPLE3.SHLBK: SHLBK LOUIE/a13000 BACKY ODESA DQO RUUTH WNDYL BRAND/a8000 KORRY DEPDY TYKES MINKS JERZY RENUE APPLE PROUD/flyover/h45
APPLE3.SWANN: SWANN GATBY KERNO ODESA DQO RUUTH WNDYL BRAND/a8000 KORRY DEPDY TYKES MINKS JERZY RENUE APPLE PROUD/flyover/h45
APPLE3.ALL  : RUUTH WNDYL BRAND/a8000 KORRY DEPDY TYKES MINKS JERZY RENUE APPLE PROUD/flyover/h45
[...]

If the STAR specified in the "star" parameter is present, vice will automatically use the available routes to define the STAR's transitions and runway-specific waypoints. In that case, one additional parameter must be specified:

Alternatively, the waypoints may be specified manually using one required and one optional member.

The "runway_waypoints" member can be used for STARs that have different routes depending on the arrival airport and runway. When the user instructs the aircraft to expect a particular approach then the corresponding waypoints are added to its route. As an example, the specification of the KPHL JIIMS4 arrival starts with the following string for "waypoints": "HEKMN N039.27.43.645,W074.56.38.400/ho JIIMS/a8000". (The second point is used to set the handoff point to be between HEKMN and JIIMS.) It then has the following "runway_waypoints", corresponding to the runway-specific routes into KPHL, the only active airport in the scenario. Note that all start with JIIMS, the same fix at the end of "waypoints".

  "runway_waypoints": {
    "KPHL": {
      "27L": "JIIMS/a8000 ZMRMN CHPMN PSOUT MKORD/h087",
      "27R": "JIIMS/a8000 ZMRMN CHPMN PSOUT MKORD/h087",
      "17": "JIIMS/a8000 SNEDE/h312",
      "35": "JIIMS/a8000 SNEDE/h312",
      "9L": "JIIMS/a8000 WUDRR WEVVE ERNYY/h268",
      "9R": "JIIMS/a8000 WUDRR WEVVE ERNYY/h268"
    }
  },
            

Overflights

An overflight is an aircraft that enters the TRACON already airborne, and flies through it without landing. Overflights are also specified in "inbound_flows" in the "overflights" member, which is an array of overflight specifiers. Each specifier may have the following members.

Each overflight specification includes one or more "airlines" in an array of objects that specify the airlines and aircraft that should be included in the overflight. In addition to the "icao", "fleet", and "types" members documented in Airlines and Aircraft, the following members may be specified:

VFR Aircraft

vice allows the specification of VFR "distractor" aircraft in scenarios; this provides realistic extra clutter in the scope and sometimes aircraft that need to be accounted for when vectoring IFR aircraft. Currently there is no interaction with them—they won't call up for flight following or Bravo clearances, but will fly around and do their thing. (Flight following and such will come at some point in the future.) For now, vice ensures that VFR aircraft remain clear of B and C class airspace.

VFR distractors are specified using the "vfr" field in an airport's specification object in a scenario JSON file. They can either be specified with a specific route to fly, or it is possible to specify that they should fly a random route that ends up at one of the other airports that has VFR departures. In practice, it works well to have VFR departures both from class D and uncontrolled airports inside a TRACON but also from such airports up to 30-50 miles outside the TRACON; this gives good variety of both flights within the TRACON but also overflights, departures that land outside the TRACON, and arrivals that land within it.

Element	Type	Description
"random_routes"	Object	Specifies that the airport should have VFR departures that fly to one of the other VFR airports (or possibly, back to the originating airport). Routes between the airports are randomized so that different aircraft follow slightly different routes, even if they are going to the same destination airport. Two members may be specified. "rate" (Number): the average number of VFR departures per hour. "fleet" (String, Optional): which general aviation aircraft fleet to use. Current options are: "default", "GAsinglepiston", "GAjet", "GAmultipiston", "GAturbine", "cessna", "lightGA", and "fastGA". See the section for "General Aviation USA" in the openscope-airlines.json file in the vice distribution for which aircraft types are in each of these fleets.
"routes"	Array of objects	Each entry specifies a VFR flow to a specific destination airport with a specified route. This offers more control than "random_routes" but requires a bit more work. "name" (String): a brief description of the route. "rate" (Number): the average number of departures along this route per hour. "fleet" (String): which GA aircraft fleet to use; see "fleet" above for the current options. "waypoints" (String): waypoints that describe the route that should be flown between the current airport and the destination airport. "destination" (String): destination airport. "description" (String, Optional): description of the entry. Not used by vice but useful to remind yourself what a series of lat-longs represents.

As discussed in Routes, there are additional specifiers that can be included with VFR routes that are useful with the "routes" option; adding /radius to fixes along routes is an easy way to add randomness to VFR routes. /airwork can also be used to have aircraft go out and do practice airwork from an airport.

Altitude restrictions in VFR routes are also handled specially: if a range of altitudes is specified using /a at a waypoint, VFR aircraft will select a random altitude within that range.

When defining VFR routes, it's a good idea to be mindful of class B/C airspace. When vice wants to create a VFR departure, it generates a random route, either fully on its own if "random_routes" is used, or using the route given in "waypoints" if "routes" is used. It then simulates the aircraft's flight and checks to see if it enters B/C airspace. If it does, it discards the route and generates a new one. It keeps doing this until it finds a valid route, but eventually it will give up if it's not being successful. Thus, feel free to define routes that are close to the boundaries of such airspace, but give vice some space to work with via /radius and altitude ranges so that it has a chance of finding a valid route.

Two other useful tools when working on VFR: in the STARS scope, if you type .VFR and press enter, vice will show all of the VFR departure airports by drawing a circle around their location and displaying their name. Entering .VFR again hides them.

Second, if you enter .DRAWROUTE in the STARS scope, you can click on a series of points to define a route. After each click, the clipboard is updated to have the lat-long coordinates of the entire route. Pressing [Backspace] removes the last point from the route. Here is an example of specifying a route along the south shore of Long Island and then North along the Hudson River for a N90 scenario.

  "PHL_DQO27_33": [
    "N039.21.58.949,W075.28.55.977",
    "N039.25.56.240,W075.29.47.255",
    "N039.26.20.204,W075.27.28.196",
    "N039.22.24.699,W075.26.48.535",
    "N039.21.58.949,W075.28.55.977"
  ]

  "PHL_DU_APP27": [
    {
      "boundaries": [
        "PHL_DQO27_33"
      ],
      "lower": 5000,
      "upper": 6000
    }